Contiki for probes
Contiki
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:
- 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
Network
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
