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.

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.

I think I’ve got about 10,000 lines that I’ve written for this over the past few months, which easily surpasses anything I’ve worked on before.  Nearly every week I’ve made significant changes to existing code and added in a lot of new stuff.  Something of this size in a constant state of change is a new challenge to me.

Consequently, I’ve taken a lot of steps to keep everything organized since I can’t do it in my head.  Since the code is mostly in Java, I’ve done my best to take advantage of its object oriented nature.  I try to keep things as loosely coupled as possible so that when I’ve got to make some modifications, it doesn’t screw everything.  I’ve made use of Java packages to group stuff together that has similar functions.  On top of all that, I’ve put the project into a Subversion repository so I can always go back to old stuff and so that I can work on it from multiple machines without it being a huge headache.

Of course, this is standard procedure for any programmer, but until now it’s never been absolutely necessary for any projects I’ve worked on alone.  During my internships, I had worked on stuff that was in the tens of thousands of lines, but it had been contributed to by other people.  Good programming practices made sense since other people would be working with my code and vice versa.  With what I’m working on now, it’s almost as if some of the stuff was written by someone else.  I’ll come across a method that I wrote two months ago and not remember much of how it worked.  I feel like a one man programming team.  I recall an interview of Bjarne Stroustrup that complained about grad students that would work on their own projects and write terrible code, not expecting that later on it would be needed for another project or possibly released to others.  I’d rather not fall into that trap since the stuff I’m working on now will likely see plenty of use in the future.

Increased comprehensiveness is one reason they say that Extreme Programming is so valuable — having someone else there with you really helps in making something that not only works, but is built in such a way that everyone can understand it.  Some people, including myself, can often write something that is almost completely unintelligible to others.  Knowing this is one reason I like to avoid cramming several actions into one line, for which I’ve gotten grief from others about being “verbose”.  I’d rather be verbose, but understandable than concise ambiguous.  I’ve never understood why people brag about writing a program in as few lines as possible, usually in some loosely-typed scripting language.  For part of this project, I had to use someone else’s MATLAB script to convert some trace data.  Of course, they crammed the conversion code into about fifteen lines that took me forever to figure out what it did (partly because I’ve never used MATLAB).  Not wanting to revisit that, I translated the code into Java in a more drawn out format so it would integrate well with the rest of my project.

I’m sure there are plenty of things I could do to make my code more better than it is now, but it’s hard to improve when there isn’t someone to give you feedback.  I can learn from my successes and mistakes from previous projects when working on my current project, however.  It seems as if most good programming practices don’t matter so much when the code size is small, but when a threshold is crossed, they seem to go from irrelevant to absolutely necessary.

First, the mouse.  I have a Razer Copperhead USB mouse that’s been great for years and when I first booted after the installation, it didn’t work.  The lights came on, but I couldn’t move it.  If I unplugged it and plugged it back in, it worked fine.  This would happen every time I rebooted the machine: no movement, unplug, plug back in.  After some digging around, I found the problem was that the mouse firmware had to be upgraded.  Of course, Razer only has the update software for Windows, so after some screwing around with that, I rebooted with the Linux machine and it worked fine without having to unplug the mouse.

Second, the dual head support for my ATI video card was lacking after the initial install, just mirroring my primary monitor onto the other.  I was able to fix this by installing the proprietary ATI drivers and using the ATI Catalyst Control Center to “merge” both screens into one.  Of course, this didn’t entirely fix the problem since every time I rebooted, the mirroring came back.  I finally found out that after I set the displays correctly in the ATI Control Center that I had to open up the Ubuntu Display Settings panel and hit “Apply”.

Both of these problems were really annoying, kept me searching and frustrated for hours, and have rather quirky solutions.  While I really like Linux, stuff like this doesn’t seem to happen as much with Mac or Windows.  However, community support is pretty good so after some extensive research I was finally able to find others with my problems that had found solutions.

Now everything seems to be working well, except that the stand for my monitor arrived bent.  It’s only a couple millimeters out of shape and the box it came in seemed undamaged, so I’m not sure what happened.  It’s bad enough that when I type sometimes the monitor wobbles.  It’s something I could probably live with, but the wobbling is annoying and I paid for a new product (not refurbished) so I don’t feel like letting it go.  So, I spent two hours with phone tree hell HP tech support about returning it and then filed an RMA request from the online vendor.  It would be best if I could just replace the stand since the monitor is fine — there’s only one stuck pixel.  Shipping the whole thing back is going to be expensive if the RMA is approved.  I guess the question is if the bent stand is worth another $30.

I still haven’t gotten to the Xbox yet because of all this (and some other annoying legwork type stuff for a research proposal that is due this week).  It also turns out that I got the wrong RCA to mini-stereo adapter and will have to try to exchange that so I can plug in the Xbox sound to the line in on my PC.  The whole thing is kind of funny because part of the reason I went with an Xbox was to avoid dealing with putting together a new system and troubleshooting the whole thing when a bunch of stuff doesn’t work.  Instead, I got more than I bargained for.