The TinyOS serial stack is designed to work with Active Messages so that packets received over the radio can be easily forwarded on to the PC.  To that end, the high-level serial and radio components provide the same interfaces.  The TinyOS serial stack has layers for packet formatting, error checking, and a read/write buffer.  However, for our project, we wanted to simplify the PC side so we didn’t have to use the TinyOS JNI libraries to receive TinyOS Active Message packets.  A simple program to read ASCII characters over the serial connection would suffice for our purposes — Minicom does this quite well and is easily installed on Ubuntu Linux and can be configured to read from attached USB devices.

The goal was to produce a TinyOS component that provided a command for transmitting ASCII character strings over the serial connection to a PC.  The  implementation is very similar to the Pulse Oximeter code I wrote for Atmel-based devices, however this time I targeted MSP430-based devices, such as the TelosB or Tmote Sky.  The implementation uses the Msp430Uart1C component for accessing the serial connection. This component provides the UartByte or UartStream interfaces for reading and writing and the Resource interface for gaining control of the UART. Msp430Uart1C also provides the Msp430UartConfigure interface for setting the baud rate.

The control flow for writing a character string is as follows: First, request the UART resource. Second, when the resource has been granted, call UartStream.send() to transmit the string. Lastly, when UartStream.sendDone() is signaled, signal the higher level application that the character string has been sent or an error message if something went wrong. In my SerialAscii module, I have the following command to send a character string:

  command error_t SerialAscii.sendAscii(char *str)
  {
    bufferLength = strlen(str);
    if(bufferLength > BUFFER_SIZE)
      return FAIL;
    memcpy(strBuffer,str,bufferLength);  // copy string into a buffer
    call Resource.request(); // request access to the UART
    return SUCCESS;
  }

I copy the string into a buffer to keep the application from modifying it before being transmitted. When the resource request is granted, I transmit the string:

  event void Resource.granted()
  {
    error_t result = call UartStream.send(strBuffer,bufferLength);
    if(result == FAIL)
      post sendDoneFailTask();  // return failure message to the user if something bad happened
  }

Lastly, when the string is sent, I release the resource and signal the higher level application:

  async event void UartStream.sendDone(uint8_t *buf, uint16_t len, error_t error)
  {
    // call Resource.release() in each of these tasks
    if(error == SUCCESS)
      post sendDoneSuccessTask(); // signal SerialAscii.sendAsciiDone(SUCCESS);
    else
      post sendDoneFailTask(); // signal SerialAscii.sendAsciiDone(FAIL);
  }

I’ve made my code available here. Let me know if you find any bugs or have any comments or suggestions.

Prior to writing the driver/interface code, I had to procure the pulseox hardware.  Detailed descriptions of hardware, software, and applications are found at the Harvard CodeBlue website.  I first ordered a Smiths Medical OEM Digital Micro Power Pulse Oximeter Board.  I was able to get in contact with sales staff by emailing Smiths Medical.  The pulseox board comes with a finger sensor and runs about $200.

Next, I needed an interface board to connect the BCI pulseox board to the 51 pin connector on the Crossbow IRIS.  The Harvard CodeBlue source code has documentation for a PCB layout and suggests that you order the PCB from an online manufacturer.  You also have to purchase some other components that must be soldered onto the interface board.  Fortunately, I was able to “skip” this step with the help of Leo Selavo, who graciously supplied me with two interface boards.  He emphasized that soldering the components onto the interface board requires a lot of skill and experience and if I were to try on my own that I would most likely break the PCB or components several times until I got it right.  The setup with pulseox board, interface board, IRIS mote, and finger sensor is illustrated below:

Pulse Oximeter on IRIS

With the pulseox board, interface board, and of course IRIS mote, I was ready to get my heart rate.  The biggest challenge still lay ahead: writing code to interface with the pulseox.  The CodeBlue pulseox code was written in 2005 for TinyOS 1.0.  All of the low level UART and mote hardware interfaces have changed drastically since then, so the old code wouldn’t just work right out of the box.  I had seen plenty of posts on the CodeBlue mailing list about implementations for the pulseox in TinyOS 2.x, but nobody had bitten the bullet and actually written anything.

What I wanted was to be able to use the pulseox like a sensor on the MTS300/310 sensorboard: call a Pulse.read() or Oxygen.read() command and get back a uint16_t with pulse or blood oxygen saturation.  This is fairly straightforward since I had experience modifying the MTS310 sensorboard code to power on the sensors manually.  I created configurations PulseC and OxygenC to provide SplitControl and Read interfaces to power on the sensor and read, respectively.  I then wired PulseC and OxygenC to a PulseoxP, which functioned as an intermediary between the application and the low-level pulseox driver code.  Like in the original CodeBlue source, I created a BciC configuration and BciP implementation to communicate with the pulseox directly through the UART and return data back to PulseoxP.

The key changes between the CodeBlue TinyOS 1.0 code and my implementation are all found in BciP (or BCIM.nc in the original CodeBlue source).  Two issues come to mind.  First, setting the mote hardware pins is done differently in TinyOS 2.1.  Calls like TOSH_SET_PW0_PIN() are replaced by abstractions.  I had to wire MicaBusC.PW0 to the GeneralIO interface in BciC and then call GeneralIO.set() in BciP.

The second difference is with the UART.  TinyOS 1.0 uses the HPLUART interface for low level UART communication, but this has been replaced by Atm128Uart0C for the Atmel 1281 architecture.  The CodeBlue source code initializes the low level UART to its default state, turns it off, and then sets the hardware registers to the desired UART configuration so that the mote can communicate with the pulseox board.  After figuring out what the CodeBlue UART configuration code did, I can’t believe that you can actually write to the registers directly!  Imagine if you could do that with user-level code on a PC!  To enable transmissions and reception along with interrupts for the UART in TinyOS 1.x, you had to do the following:

// Enable tx/rx interrupts and tx/rx
outp(((1 << RXCIE) | (1 << TXCIE) | (1 << RXEN) | (1 << TXEN)) ,UCSR0B);

TinyOS 1.0 uses the outp() macro to set bits of a given register, but this macro does not exist in TinyOS 2.x.  Instead, the UART register bits are configured in a struct with fields for each bit in the register.  For the above example in TinyOS 2.1, the following union represents the control register in Atm128Uart.h:

/* UART Control Register */
typedef union {
struct Atm128_UCSRB_t {
uint8_t txb8 : 1; //!< UART Transmit Data Bit 8
uint8_t rxb8 : 1; //!< UART Receive Data Bit 8
uint8_t ucsz2 : 1; //!< UART Character Size (Bit 2)
uint8_t txen : 1; //!< UART Transmitter Enable
uint8_t rxen : 1; //!< UART Receiver Enable
uint8_t udrie : 1; //!< USART Data Register Enable
uint8_t txcie : 1; //!< UART TX Complete Interrupt Enable
uint8_t rxcie : 1; //!< UART RX Complete Interrupt Enable
} bits;
uint8_t flat;
} Atm128UartControl_t;

The flat uint8_t is a real slick way to convert all the elements in the struct to a single word, which can then be written to the register. Following the code that initializes the UART in tos/chips/atm128/HplAtm128UartP.nc, I was able to configure the UART to run with the pulseox board requirements: 4800 baud, double rate, transmission and reception interrupts enabled, no parity checking, 1 stop bit, and 8 bit word size.  So, with the previous example to enable transmissions and reception, you do the following in TinyOS 2.x:

Atm128UartControl_t ctrl;
ctrl.bits = (struct Atm128_UCSRB_t) {rxcie:1, txcie:1, rxen:1, txen:1};
UCSR0B = ctrl.flat; // ctrl.flat

I ran my concerns by the CodeBlue mailing list, which elicited a reply from Prof. Matt Welsh that I was headed in the right direction.  I finished my implementation, worked out some compile errors, and loaded the new pulseox and general data collection code onto a mote to see what would happen.  Almost never does my TinyOS code run correctly on the first try — usually I spend hours or days debugging, but this time it was magic.  A number jumped onto the screen in the data column of my PC Java application, which was connected wirelessly though a base station mote to the pulseox mote.  The sensor readings seemed reasonable for a heart rate, for jumping up and down and breathing hard made it go up and laying down and trying to breathe slowly made it slow down.

Pulse Oximeter Reading

I have made my code available here and any feedback, suggestions, or questions are encouraged.  To use it, place the pulseox directory into the tos/sensorboards directory in TinyOS 2.x.  In the makefile for your application, add the line “SENSORBOARD=pulseox”.

I found that every time I called Read.read() for some of the sensors, that there would often be a delay in getting my data back with Read.readDone(). This delay was because each call to Read.read() would power on the sensor, requiring a warm-up time before a sample could be retrieved. While the warm-up time for the accelerometer is 17ms, the warm-up time for the light sensor is an excruciatingly long 1200ms! So, I would call Read.read() at 20ms intervals, but have to wait over a second to get data from the light sensor. When the data sample is returned at Read.readDone(), the sensor would power off again, thus requiring another warm-up the next time a sample is requested. Basically, the constant warm-up lag in the current TinyOS code prevents sampling at a reasonably fast rate using Read.

I also found that if I wished to get both axes of the accelerometer or magnetometer simultaneously, that only one axis would ever return data. The accelerometer, magnetometer, and light/photo sensors use the ArbitratedResource interface to block all other sensors that use the same resource when one sensor has a lock on the resource. If the x-axis accelerometer was sampling with Read.read(), it would have a lock on a UQ_ACCEL_RESOURCE identifier, preventing the y-axis from sampling simultaneously, since its resource is also identified by UQ_ACCEL_RESOURCE. I wasn’t the only one with these problems, as illustrated by this TinyOS mailing list post. The mailing list poster also points out that the ReadStream interface blocks data sampling for all sensors but the first one that calls it: if you try using ReadStream to get streaming data for the accelerometer x-axis and the magnetometer x-axis, the call to ReadStream.read() for the accelerometer would block the sampling of the magnetometer if it was called first. With ReadStream, all sensors use the same resource identifier, so when one is sampling, it has the lock, and all others must wait. The resource arbitration effectively prevents multiple sensors from sampling data simultaneously using ReadStream.

This automated power control for Read as well as the blocking for Read and ReadStream really limits the functionality of the sensorboard. Initially, I thought it was a hardware constraint. You would think that since the board has all those sensors on it, the manufacturers would have designed it such that you can use all the sensors at the same time. It turns out, that it isn’t a hardware problem — it’s just that the MTS300/310 sensorboard code is written so you can only effectively use one sensor at a time. I managed to change this by modifiying the behavior of the Read.read() of every MTS sensor.

The current TinyOS code uses SplitControlPowerManagerC to power on the sensor when you call Read.read(). Read.read() triggers the power manager to call the sensor’s SplitControl interface. Supposedly, when Read.readDone() is signaled and the sensor data is ready, the power manager will keep the sensor powered on for some amount of time in case the sensor is needed again — this is from the comments in PowerManagerP.nc. However, from my testing, there is no evidence that the sensor stays on after Read.readDone() is signaled. The warm-up routine starts all over again the next time Read.read() is called. It’s possible that 20ms is too much time between samples, but it appears from the power manager code that the sensor is turned off immediately if no resource requests for that sensor are pending. Currently, I can’t find anywhere in the MTS310 sensorboard code or in the power manager code where some kind of backoff timer is set before powering down the sensor.

To that end, I eliminated this automated power control through the power manager. I altered each sensor’s interface in the mts300 code library so that each sensor provided a SplitControl interface. This now allows me to manually power on each sensor I want to use before I start sampling. I then have a timer call Read.read() at regular intervals for each sensor I want, which returns the data with Read.readDone(). When I’m done sampling, I can turn the sensors off.

The current code is more a less a hack and has a weird side effect. For example, since the x and y-axis accelerometers use the same AccelP module with the same SplitControl power interface, only one accelerometer has to call SplitControl.start() to turn the sensor on. The same goes for the magnetometer and the light/photo sensors, as well as for calling SplitControl.stop() to power down the sensors. Otherwise, the warm-up/power on sequence is triggered twice for the same sensor if you want to use both axes of the accelerometer or magnetometer, or wish to use both light and temperature sensors. Edit: this issue has been fixed in the code.  Calling SplitControl.start() for both axes of the accelerometer/magnetometer will only run the power on sequence once, but both calls will return SplitControl.startDone().  The same applies for SplitControl.stop().

The modified sensorboard code can be downloaded here, which is a zipped directory of all the mts300 sensor code, but changed to mts310. Just unzip it into the tos/sensorboards directory. The configurations AccelXC, AccelYC, MagXC, MagYC, MicC, PhotoC, and TempC have all been modified to provide the SplitControl interface, so for example you can call AccelXC.start() to power on the accelerometer, then AccelXC.read() to get data, and then AccelXC.stop() to power the accelerometer off. I’ve used this extensively with the accelerometers, magnetometers, acoustic, and light sensors and it seems to work without any issues.

Sidewinder: A Predictive Data Forwarding Protocol for Mobile Wireless Sensor Networks
Matthew Keally, Gang Zhou, Guoliang Xing
IEEE SECON 2009
June 22-26, Rome, Italy, acceptance ratio: 81/431=18.8%

There is a more heavyweight solution, if you like Eclipse.  Since I’ve been using Subclipse with Eclipse on several machines to keep all my code in sync, I’ve found Eclipse to be pretty useful.  A TinyOS 2.x Eclipse plugin is available on this site that provides syntax highlighting and it appears as though it will compile and install source code as well (though I haven’t tried that part).

2/21/2009: Since I’m on the topic of Eclipse, I’ve noticed that the Ubuntu repository Eclipse version is 3.2, but 3.4 is available from the Eclipse website.  Following this guide, it seems that you can override the /usr/eclipse directory with the new version if you want to upgrade.  Plugins will have to be reinstalled, though.

Another annoyance I’ve come across while programming TinyOS applications is the need for multiple interfaces of the same type.  For example, it would be great to have an array of timers with different firing intervals.  Like most things TinyOS, documentation on something like this is thin and not explained very well.  There are a few similar examples in the TinyOS 2.x Programming Manual, but I found it oriented towards someone who really knows what they’re doing.  Now that I’ve found a solution, I’ve decided to post it so that others can benefit.  Of course, if you’re reading this and have a better solution, let me know.

My main purpose in doing this is to sample data from different sensors on the MTS310 sensorboard at different intervals.  I would like to associate one periodic timer with one particular sensor.  Of course, this leads to my nasty initial solution such as this in the *AppC.nc file:

implementation {
...
components new TimerMilliC() as Sensor1Timer;
components new TimerMilliC() as Sensor2Timer;
components new TimerMilliC() as Sensor3Timer;
...
App.Sensor1Timer -> Sensor1Timer;
App.Sensor2Timer -> Sensor2Timer;
App.Sensor3Timer -> Sensor3Timer;
...
}

This means that in the *C.nc file, I’ve got something like:

module *C {
uses{
...
interface Timer as Sensor1Timer;
interface Timer as Sensor2Timer;
interface Timer as Sensor3Timer;
...
}
}
Having three different timer interfaces means I’ve got to implement fired() three different times (Sensor1Timer.fired(), Sensor2Timer.fired(), and so on), despite the code being almost exactly the same for each fired() instance. What if I have a custom sensorboard with ten sensors? What a mess that would be.

I figured out how to simplify this using parameterized interfaces: essentially an array of timer interfaces. This is obtusely described in the TinyOS Programming Manual in the Parameterized Wiring section. While the programming manual suggests the use of unique(“identifier“) for each array element (timer instance), I wanted to be able to associate a specific timer with a specific sensor and know which timer it was that fired so I can sample data from the appropriate sensor. unique() abstracts away the index for each parameterized element so when a timer fires, the index provided isn’t really associated with a particular sensor. I defined an enum in an *.h file that describes indexes for each timer in the array:

enum{
SENSOR_ONE = 0, SENSOR_TWO = 1, SENSOR_THREE = 2,
};

Then, in the *AppC.nc file, I changed the wiring to reflect the new parameterized interfaces:

App.SampleTimer[SENSOR_ONE] -> Sensor1Timer;
App.SampleTimer[SENSOR_TWO] -> Sensor2Timer;
App.SampleTimer[SENSOR_THREE] -> Sensor3Timer;

This allowed me to alter the interfaces section of the *C.nc file, where all timers are identified by SampleTimer and an unsigned 8-bit id (the index provided in the enum):

interface Timer as SampleTimer[uint8_t id];

This way I can call SampleTimer.startPeriodic[SENSOR_ONE]() for the first timer, and use the other elements in the enum for the other timers in the array. When a timer fires, there is only one fired() event in my *C.nc file:

event void SampleTimer.fired[uint8_t id](){
// read data for this particular sensor and do something with it
if(id == SENSOR_ONE)
// read sensor one data here
else if(id == SENSOR_TWO)
// read sensor two data here
...
}

I can use the id provided by the event to figure out which timer it was that fired and then read data from the appropriate sensor. The code is greatly simplified this way and easily allows the addition or removal of timers and sensors. Furthermore, this parameterized wiring can be used with any interface, such as handling radio packets of different AM types.