Contiki for probes

From Glacsweb Wiki
Jump to: navigation, search


contiki - Notes on testing and understanding contiki

initial aim is to port all our workflow/ideas/algorithms to Contiki. Hopefully this will aid code reuse and portability. BUT Contiki seems poorly managed and documented etc so we need to be careful with our checked-out version. Contiki slides is essential reading.

i)Contiki has been ported to our msp430, with the RPM radio interface

Do we need 6lowpan? current plan is use lighter lower-level ad-hoc protocol available. Rime provides "best effort multihop unicast" and flooding (netflood?) Plus hob-by-hop data collection (collect). probably stick to Rime unless it has obtrusive features

Software to test in contiki:

Overo-builds for software to talk to contiki may use combination of C and python (like set RTC, read status etc and data collection) Python is the main control language on the base stations.

  • contiki shell extensions? - Yes this turned out to be VERY useful!
    • adapt shell to our probes so we can have a set of useful debug tools and admin tools
    • status - get settings like sampling interval etc
    • adapt blink for debugging
    • set schedule/sampling interval - RTC etc (Nov. still hard-coded)
    • EEPROM ringbuffer reset
  • made simple Python code to interface with the above for basestation

Contiki Shell and data formats

status - is used once a day to find out BatV, RTC time/date and buffer settings

sense - can be used to take immediate readings

???? ID - is used to get all unread data from node ID

format of data should be:

  1. ID year month day hour min temp press strain conductivity X Y Z

these are raw 16 bit decimal values

basic behaviour design

Because the nodes could go out of radio range for months - we sample into EEPROM, then communicate only once or twice a day. The new data in the EEPROM buffer is read and sent at 12:00 and perhaps at 24:00. Design issues include how does base keep track of missing data or ask for retransmissions, how much will our RTCs (and hence wake-ups) drift?

  • setup and admin needs the ability to:
    • set the real time clock in probe/s
    • read the status, clock etc of nodes (for checks)
    • set the schedule (for checking/debug)
      • this could be used to set a faster schedule (really sample interval)
      • base interval for sensing is 30min, fastest may be 60s
    • reset the data buffer (after debug session for example)
  • normal node behaviour
    • sample all sensors to data buffer every hour (or other interval, stored in eeprom) with radio off
    • 12:00 only - wake up, turn on radio, send data from EEPROM buffer
      • base station will run some kind of listener from about 11:59
      • base will need a way to know when to sleep, when to request resends or network reconfigs


IDs for probes will be: two wired probes 1.1 1.2, the remaining 1.40, 1.41, 1.42 etc (this makes them continue unique ID from previous probe IDs