2007 TinyOS

From Seamonster

Jump to: navigation, search

Motes ("Telos-B")


Related



Contents

Introduction

SEAMONSTER makes use of Tmote Sky devices in summer 2007 with lifetime extended into winter if possible. The number of devices is small, 20--30, and the sampling rate and interface issues are minimal (once per minute, ADC and serial port). There are four deployment locations in consideration:

  1. 5 Motes: Top of Lemon Glacier: Pressure transducer (serial), temp sensors, and a daisy chain back to a microserver on Cairn Peak.
  2. 15 Motes: USGS Gauging Station, Lemon Creek watershed: ADC signals sampled once every minute.
  3. 1 Mote: Douglas Island Channel (Gulf of Alaska): Analog devices only, once every minute.
  4. 1 Mote: Auke Lake: Same as Douglas Channel.


Main complication: Inexperience with TinyOS coupled with Mote Base Station intermittennt operation: Motes form a Subnet anchored on a BaseStation/Microserver (uS). The uS runs on a limited duty-cycle that varies from "mostly on" in the summer to "mostly off" in winter, and the Mote Base Station will only be on when the uS is on. This should typically be for two-hour periods at least once every two days, so there is plenty of bandwidth to bring in this "light" data volume. We're just missing a bunch of crucial details.

Part 0. Operation in Narrative Form

A Tmote is programmed as a base station and connected to a Microserver USB port. An external antenna is placed to give good visibility to other Field Motes. When the Microserver boots up the Base Station mote will receive power and turn on. It must perform the following operations:

  • Accumulate data files from any Motes in radio contact
  • After Single Board Computer boots: Move any data files to SBC memory, delete its copy.
    • SBC memory = USB thumb drive or primary SD card
  • Time synchronization with Field Motes (see Synchronization below).
  • Advanced: Move any configuration files in SBC "UploadToMote" directory to target Mote(s).


A set of Field Motes (Tmote Sky + Enclosure + Power + Sensors) are placed in the nearby environment. Each one follows this procedure:

  • Advanced: Consult a configuration file to drive the following procedure.
  • Step 1: Determine nSleep parameter value
  • Sleep for nSleep seconds in lowest power mode, for example 50 seconds.
  • Boot to full power + radio ON
  • Determine other operating parameter values
  • Set two GIO channels high (this will turn on a separate sensor power supply)
  • Wait for (tWarmup) seconds (say 4 seconds)
  • Sample up to 6 ADC channels
  • Advanced: Instead of ADC, execute a serial-port exchange with a sensor.
  • Turn off GIO
  • Consult clock to obtain year / Julian day / hour / minute
  • Wrap data in a short data file, typically 11 -- 16 bytes { data, time, mote-index }
  • Send any data files (own or received) towards base station, delete own copy on successful send.
  • Advanced: If exist (new configuration file): Replace old configuration file
  • If timing signal available on radio: Synchronize clock
  • After nRadioOn seconds turn radio OFF
  • Goto Step 1

The above steps complete in about 10 seconds + nSleep seconds so that (nSleep + 10) / 60 is the sampling interval in minutes. The procedure is designed to produce data and scale power consumption down based on estimated power reserve and desired deployment time. The synchronization keeps the system moving data to the Microserver and the GIO On/Off cycling conserves sensor power. The warmup period is ideally very short or zero although in the case of turbidimeters or pressure transducers some stabilization time might be necessary. In that case, if for example a sample requires one minute of warmup, the sampling rate will necessarily have to be reduced to conserve power.

Part 1: Operation Elaboration

Same as above with a few more details.

  • Motes run in perpetual cycles: { Boot+sample+comm } then { sleep }
  • During Sample+Comm phase:
    • Operate some GPIO (turn instrument power on)
    • Store some data values (ADC and serial)
    • Perform radio traffic functions
    • Enter a timed sleep
  • During Sleep Phase:
    • Go to lowest power, then Reset to full power
    • Open question: During sleep is radio off?
      • This depends on the expected power consumption etc
  • Advanced ideas
    • Reconfigure self based on a received command file
    • Memory check: Am I running out of memory?
      • If memory is running short: stay awake longer in hopes of offloading
  • Configuration
    • Envision a single nesC program for Motes at < 250kbytes.
    • Envision a variant of TOSBase for base stations
      • Must have write privilege over USB to file system
      • Must write to /mnt/thumbdrive/TOSBase if thumbdrive mounted or...
      • simply write to /home/brick/TOSBaseData to avoid worrying about thumb mounted
    • Ideal: Configuration parameters are localized to a single nesC 'file'
    • Question: What is a nesC file? Does this even exist???

Part 2: GIO

The basic idea here is to conserve power by turning the GIO pins 4 and 5 off during sleep.


U2-6 and U2-8 are GIO 4 and 5, the pins we'll use to turn powered sensors on and off. (We do not do I2C communication.) During boot these two pins simply go high and stay high until sleep. Logic high will turn on a standard 2-MOSFET solid state switch or will simply power temp sensors which draw only 10uA.


Powered sensors may have their own batteries, would share a common ground with the Tmotes. Analog temp sensor can be driven directly off Tmote Vcc but the problem with this is the continuous drain; need to determine if a switch is necessary here as well. Ideally all switching is done internal to the Field Mote enclosure with a power lead coming off the N-pin bulkhead connector.

Part 3: ADC basic

  • ADC will tend to operate on signals fit into the 0--2.5V range
  • How to reduce a signal to a single value is an open question
    • For example take 10 samples over 1 second and average?
    • Generalize raw data as N samples per second over M seconds?
    • Some other form of low pass, e.g. combine { median filter, averaging } ?
    • Obviously this depends upon the sensor characteristics.
    • The two primary sensors we use are a temp sensor and a turbidimeter.
  • Collect from 1 to 6 ADC channels, format data as packets.
    • It appears ADC 0, 1, 2, 3, 6, and 7 are accessible.
    • I have already redirected the PAR/TSR channels in Oscope to ADC0/1 to verify operation of a couple analog devices.
  • Data-point (i.e. reduced) sample rate is nominally 1 / minute.
  • This gets less if a warmup interval is necessary.
  • If can't push data down the line towards base station: Archive until...

Part 4: Serial basic

See the main sensor specifications page for details on the Global Water WL15 pressure transducer. The main points are that it has a certain lifetime on a 9V battery (which we'd like to extend by means of on/off cycles) and a serial port RS232 connection: 38,400 baud, 8 bits, No parity, 1 stop bit, Flow control Xon / Xoff.


The first question is: Can a Tmote handle this comm format? If so, second question is: Can we turn the unit on, let it warm up, and get a reasonably reliable pressure (i.e. water depth) reading? If so, third question is: What command sequence do we send and what do we expect to receive? With that figured out, last question is: How to wrap the result up in a data-point file?


Once these are worked out the data file can be treated like the ADC-files we produce from analog signals.

Part 5: Messaging basic

As described below under Synchronization we expect about 4 bytes of overhead and between two and 12 bytes of data to comprise a data-point value. Actually the data might go a little higher if we also grab "onboard" sensor values like PAR/TSR/RH. The point is that the data files are small.


Question: Should we really bundle multiple samples before sending? Reason is that the filenames (whatever that means) use again as much memory as the data itself. File system mechanics in TinyOS?


We assume that some variation of the multi-hop algorithm handles message passing, where we hope that a bottleneck does not develop near the base station due to limited base station availability as slaved to the microserver duty cycle. The base station should be on for two hours every two days at a minimum and therefore is should have plenty of time to receive all incoming data. Routing tables and other overhead are (we hope) transparently not our problem.

Part 6: Synchronization

In my simple definition, radio synchronization simply means ensuring that both transmit and receive radios are ON in a system that uses periodic sleep/radio-OFF intervals to conserve power. The logic for synchronizing radios presented here is rudimentary but hopefully covers the basic issues. The bottom line is this: This is an EASY implementation (on paper) and the main concern is synchronizing mote-to-mote if they are on for 10 seconds out of every minute and their clocks drift off by 10 seconds.


The Microservers for bullet-proofing reasons tend to operate for two hours at a time. These operational intervals are generally scheduled to favor the top of Even UTC hours. In summer when power is available they tend to run "as continuously as possible" with occasional reboot interruptions of about four minutes. In winter the microservers will tend to be on around local noon every couple of days but this is subject to the Even-UTC-hour constraint. For example a microserver would schedule itself to come on at 1 pm local time if there are an odd number of hours between the local time zone and Greenwich.


Next we note that a single Microserver can support a Tmote Sky "Tier-2" subnet. The Mote Base Station will be ON when the Microserver is ON as it is powered from the Microserver SBC USB port. The Base Station will have a two hour window in which to talk to Motes. Any mote that comes up in that two hour window with data to contribute to the Base Station can get the job done provided it has necessary intermediaries in a Multi-hop case. So to make life as absolutely easy as possible we will try to deploy as one-hop network. Mostly.


What about elements of the subnet that do not see the Base Station directly? First estimate rate of data accumulation and time-capacity based on available storage:

  • Sample once per minute
  • 2 bytes x 6 samples (that's the maximum; I'll also parenthetically give the minimum: 1 sample = 2 bytes)
  • Time/ID tag = 1 byte for myID, three bytes for Year Month Day Hour Minute.
  • Result is 16 (6) bytes per sample with no compression, or 23kbytes (min 9kbytes) per day.


Using 75% of the available 1MByte of data storage on the M25P80 chip (the rest is for the TinyOS operational program) means a single mote can store 32 days (85 days) of data, its own or muling somebody else's. We'll also assume the memory is configured as a ring buffer so only the most recent values are stored.

Part 7: Advanced Operational Ideas

First idea is to parameterize all these operational numbers in a single file and read these values prior to the relevant execution (sleep, sampling, etcetera). Part of normal operation would be to take a newly received parameter file and substitute it for the existing one. In this way some external agency can decide to change sampling rates (for example) and can effect this by simply pushing a new parameter file to the mote.


There is one immediate problem with this idea in practice: Going to more than one sample per second extends message size by one byte as the mote most include 'seconds' in its time stamp. Maybe should include this from the get-go.


Another advanced idea: Reverse-pressure for multi-hop data recovery. If Base Station is not seeing mote N it could pressure other visible motes to stay on longer in the hope of catching an asynchronous operational interval on N.

Part 8: In Practice

This is how it is actually done (with links to software pages TBC).

  • We program a base station mote with TOSBase and connect it to the USB port of the Microserver. An external high-visibility antenna is connected to the TOSBase mote through the microserver case.
  • TOSBase establishes a serial port / socket connection to a program running on the Microserver called sf for serial forwarder.
  • The other motes (according to their programming) are set out nearby, running a different program. They will sample their connected sensors, create little data packets, and periodically transmit them.
  • Side note: If the network is configured with multihop then these messages can reach the base mote by means of multiple jumps. Ideally/easier each mote is only one hop away from the base station (which is listening 100% of the time, in theory) so that multihopping is not necessary.
  • Side note: We are using Tmotes so we have two example programs endemic to their 'Boomerang' TinyOS distribution: Oscilloscope and Delta. Oscilloscope is nice in that it sends six channels worth of data by default, and Delta is nice because while it only sends one channel of data it does so using 'multihop' so in principle this can travel through multiple intermediaries before reaching the base mote, plus it has a built in sleep-duty-cycle.
  • The other motes continue to send data in this way until they run out of gas.
  • This leaves us with the question of "what does the sf program do???" which is described next.


serial forwarder a.k.a. sf

This program listens to the base mote using a socket/port connection and accumulates data packets into a simple buffer. There is only one buffer allocated for all of the motes that might be out there. This means that if there are four such motes, each must encode its own identity into its data packets. These will be parsed out later back at the lab server.


Each time a packet is received by sf from the base mote and written to the mote-data buffer it is appended by the current time, available from the system's real-time clock. This time gives an approximation of when that data packet was sent and more roughly when the data was collected. When the buffer reaches a certain size, sf simply creates a file containing the current time in the microserver "data accumulator" directory. sf then writes the mote data buffer and resets the buffer pointer.


We will implement file transfer (rsync) and clean-up processes that are independent of sf so that it doesn't have too much to do.


Further Elaborations

  • The data accumulator directory is by default on the Microserver SD card: /root/data. There is about 256MB worth of data capacity there.
  • The way that a data stream is interpreted in the "default demonstration" mode is via one of two java applications. The one associated with the Delta program is called Trawler and the one associated with the oscilloscope TOS program is called appropriately enough oscilloscope. Both of these programs have a plotting window that scrolls with time.
Retrieved from "http://robfatland.net/seamonster/index.php?title=2007_TinyOS"
Personal tools