exp id=6868 (2 wsn nodes)

wsn430-9.grenoble.iot-lab.info      tutorial_cc1101.hex Failure
wsn430-25.grenoble.iot-lab.info     tutorial_cc1101.hex Failure

• {(archi='wsn430:cc1101' AND site='grenoble' AND mobile='0') AND type = 'default'}
• firmware downloaded to "Desktop" from https://www.iot-lab.info/wp-content/uploads/2014/02/tutorial_cc1101.hex

• run tests on A8 nodes (gw and open-a8)
• identify ok/robust nodes => updated u-boot on gw and open-a8 nodes, re-tested gw

Write a technical doc. with ( @pissard ):

• state of the art
• hardware description
• software description
• experiment use case
  • radio characterizaton
  • tiles example
  • contiki/coap

On the panel : https://www.iot-lab.info/testbed/profiles.php
we must change Frequency in Period.

update tutorials

Verify that the start/stop/reset/command web order has the same behavior for wsn430 and M3

• deploy GRE a8 on prod (228 nodes)
• deploy ROC a8 on prod (175 nodes) => now requires migration of the whole ROC platform to prod
• deploy STRAS a8 on prod (14 nodes)

• Launch Test on WSN430 nodes site
• Take off nodes with errors (Control Node timeout)

get_failed_logs.sh currently loops endlessly when fetching logs from gateways.

Looping is required because ssh requests are sent to the front-end in parallel, in batches of 10, and some requests can fail, most likely because of load control on the ssh server.

This is normally not a problem in a nominal case where gateways are sane and do eventually serve requests. However, in a degraded case, some gateways may never reply, and cause get_failed_logs.sh to loop endlessly.

• create clusters of 8 nodes (out of identified robust nodes)
• create clusters based on radio locality (?)

• create clusters of 8 valid M3 nodes based on locality
• deploy clusters in oar on test platform
• check it works !

• integrate FTDI failure detector in oar "suspected node" periodic check (currently only does ping)
• integrate ssh check in start-experiment logic (for a8 nodes)
• decide how to handle broken nodes (exclude, report broken, manual reboot, ...)

http://sed.inrialpes.fr/stages/stages2014/stage-roomba-wsn.html

To follow the work done by the other sites and integrate a Turtlebot2 and a Roomba on Grenoble.

• provide reboot primitive ?
• choose an implement policies

• integrate Rocquencourt nodes on test platform
• check x,y,z settings for all nodes (m3, a8, wsn430)
• turn on all nodes
• deploy software (EH)

• define scope of tutorial (keep it simple: just sensors ? a bit of radio ?)
• create or re-use basic firmware code (sensors-collecting ? ipv4 rime contiki sample ?)
• create tutorial document in www.iot-lab.info
• validate & publish tutorial

• Test and Read M3 tutorials on dev-grenoble ( @fsaintma @fambon )
• Build radio tutorials with profile settings( @pissard )
• Example with tiles and step detection ( @pissard ) => #53
• Example for characterisation RSSI (@cladmi, @pissard) => #31

Script to test FTDI bugs ( @fambon )

• run with printf on open node (DONE)
• find robust nodes = find the identity and number of robust nodes (DONE)
• try a physical intervention on ten breakable nodes (DONE)

Related issue (FTDI bug): #13.

• investigate what needs to be done to create UIDs for M3 nodes
• check minimum requirements for effectively unique IDs
• implement basic UID "lib" for firmwares to use
• register UID / node ID association in OAR

• Sensors integration (@cladmi)
• Tests radio (@cladmi)

• 4 pages article-like document => #57
• présentation: 30 mns : iot intro, platform presentation, use-cases (slides) => #78
• tutorial: 1h30
  • platform use : nodes reservation, programmation, expe and monitoring => www.iot-lab.info/tutorials
  • work on experimention under Contiki using iot standars : 6LoWPAN and CoAP => #58, #59
• 2 or 3 iot-lab engineers (mission orders, hotel reservations)
• inscriptions required
  http://iihm.imag.fr/nigay/gtmob/

• présentation 30 mns : iot intro, platform presentation, use-cases
• tutorial 1h30 :
  • platform use : nodes reservation, programmation, expe and monitoring
  • work on experimention under Contiki using iot standars : 6LoWPAN and CoAP

2 ou 3 iot-lab engineers

For some M3 and A8 nodes, we loose the uart connection. The FTDI component connecting the node looses the USB connection.

We are in contact with HikoB to correct the bug. In the meantime, we have defined a work-around using the deployment.

• investigate sicslowpan requirements (addresses, configuration settings, code mods)
• decide addressing scheme (logical, using flash-stored info, or physical, using uuid)
• update contiki platforms init code
• update idle-firmware (if using flash-stored addressing scheme)
• provide documentation and example

When reloading an experiment from the web interface, the new experiment duration can be specified.
However, it's not taken in to account and the previous duration is used.

Example for characterisation RSSI (@cladmi, @pissard)

Fusionner tout le code dans un seul répertoire (comme pour wsn430) serait extrêmement compliqué (différents systèmes de build, suivi des versions,...) et peu dans l'esprit 'clone/fork' de git/git-hub.

En tenant compte de l'existant, on propose de diviser iot-lab en plusieurs projets git-hub hébergés sous github.com/iot-lab/

• openlab (le fork https://github.com/hikob/openlab) qui deviendra le 'master' openlab cogéré avec hikoB.

  Il contient le source pour les noeuds M3 (et d'autres noeuds distribués par HikoB) : driver, et Free-RTOS avec des libs utilitaires et de comm.

• wsn430. qui contient le source actuel pour les noeuds WSN430

• contiki : (le fork https://github.com/hikob/contiki-os) qui deviendra le 'master' openlab cogéré avec hikoB.

  c'est un contiki 2.7 avec la plateforme M3.
  NB: pour la compilation, il est nécessaire de pointer sur openlab

• riot (https://github.com/RIOT-OS/RIOT)

• iot-lab : 1 projet 'chapeau' qui sera un point d'entrée pour installer le projet iot-lab complet constitué des différents projets git-hub.

  il contiendra le wiki de la 'doc détaillée', des outils de scripts nécessaires, des utilitaires indépendants des archi/os,...
  pour ce regroupement, nous n'avons pas encore choisi les 3 solutions qui s'offrent à nous : sub-modules, sub-tree, simplement script shell.

NB: Pour rester cohérent avec une vision OS ou OS enrichi (cas openlab = freertos+driver+lib), on sortirait à terme de wsn430: tiny-os (en faire un projet git-hub à part entière) et contiki (en l'intégrant dans le contiki existant avec une branche WSN430 tant que l'on n'a pas migré en 2.7 la version wsn...).

On en discute au sprint mais je suis preneur d'ici là de toutes les remarques ou propositions...

A+
Roger

• decide which M3 sites will go live => Grenoble only
• decide which M3 nodes will go live => never dead nodes (~200)
• decide when M3 nodes are included in production => 5-7 may => 15 may
• communicate on date and extent => send out mail on 21st april => mail+news published 13-14 may.
• switch selected nodes to prod => (plan for tasks: web, network, oar, security on gw) => #52

Profiles parameters, e.g. sampling frequency, number of measured values, averaging window, if not set with care, can potentially cause an overflow of the platform. The overflow can happen at gw level, network level, or at disk space level.

To address the issue:

• select use-cases
• check which values are reasonable
• implement sanity checks in GUI

• develop test script for A8 nodes qualification ( @fambon / @fsaintma )
• publish test script on github
• run on all A8 nodes -- DONE 1/2 (need another pass, with rebooted gw)
• report identity and number or robust nodes

Delete file extension check (elf|hex|ihex)
Add Rest method for firmware validation (isElf, isHex)
Add this firmware validation in webportal when user upload it

• use run_all.sh on M3 nodes
• report identity and number of robust nodes

follow-up on issue #9. Json for wsn430 profiles also needs a fix.

In the Rocquencourt map the wsn430 coordinates are not on the same frame of M3/A8.

switch nodes to prod platform (task list in #37)

• publish test script adapted for A8 nodes in iot-lab github => run_all.sh
• run tests on a8 nodes => needs platform update & re-run => running 5 rounds
• identify "robust" a8 nodes => updated u-boot and re-tested

https://launchpad.net/gcc-arm-embedded
For the moment, the 'Latest version is 4.8-2014-q1-update ' is used in tests.