Posts Tagged code
BCI Pulse Oximeter in TinyOS 2.1
Posted by Matt in development on June 15, 2009
After days of getting lost in TinyOS 1.1 and 2.1 low level hardware abstractions, the Harvard design BCI pulse oximeter now works in TinyOS 2.1.
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”.
MTS300/310 Sensorboard: Sampling multiple sensors simultaneously
Posted by Matt in development on May 14, 2009
My current project involves sampling data with the Crossbow Iris and MTS310 sensorboard. I wish to sample data at regular intervals, say 20ms, using all available modalities on the MTS310: x and y-axis accelerometer, x and y-axis magnetometer, light, temperature, and acoustic. Every 20ms, a timer fires and collects data samples from each sensor using the Read interface. As it turns out, the current TinyOS 2.x code for the MTS300/310 does not allow this.
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.
Recent Comments