Hand Hygiene

We’re getting a bit behind on the blog.  I just reinstalled Scribefire to make things easier again.  I also wanted to update a bunch of links that Ted has sent to me over the past month or so, so they are not lost:

4/12/11
If we ever need a mote-phone device …http://www.sparkfun.com/products/10585
This might be one way, building off the IOIO board.

4/10/11
http://sing.stanford.edu/swat/
I haven’t tried this myself, but it might be an interesting tool to measure conditions in
a clinic, hospital, lab, etc.  Didn’t read enough to know what hardware/software is needed.

3/15/11
http://blog.makezine.com/archive/2011/03/mini-home-fablab-for-around-4000.html
Well, not in a garage, but this is the modern update on the home workshop.

3/11/11
(not for Epidemiology/hospital, but just shows that lots of hardware/sensing can be thrown into the picture.)
http://www.springerlink.com/content/34568uu53758qg37/
We constructed informational support system based on massive sensor data in a room. In the room, called “Sensing Room”, approximate 600 sensors are distributed. Pressure sensors are embedded in a floor, a table, chairs and bed. Switch sensors and electric current sensors are attached on furniture and electric appliances. RFID tag readers are embedded into room planes. The room monitors human activities without restriction of occupants. Information support system includes steerable active projector on the ceiling. The projector displays information on all planes of the room. The occupant watch information wherever he/she exists in the room without restriction. Based on captured activities, information support system decides timing, position and contents fitting the occupants’ activities. In this way, massive sensors data achieves attentive support. We demonstrate notification, decision support and navigation by informational support system.

3/11/11
http://www.sensorsmag.com/product/wireless-mesh-radio-zmd
I’m not serious – about this being the new mote.  But, the general idea is out there.

1/16/11
While searching for papers about the tiny CC2430 SoC, I ran into this, which might be of interest to you (they use the same chip for their system). 
http://dcis2009.unizar.es/FILES/CR2/p31.pdf

1/16/11
http;//mobed.yonsei.ac.kr/~sukwon/paper/secon-cc2430.pdf
The above paper could be useful to consult along the way.  At least it will tell us how far others have gone, even if not TinyOS (it’s some weird Korean OS called RETOS;  at some point there was/is even a Korean company selling Telosb knock-offs, but the price was no better, so I never explored their platform).

I’ve spent some time getting acquainted with our noise monitoring friend and the possibility of interfacing a mote with it. The microcontroller and several other peripheral IC’s are encased in opaque epoxy, so this limits the depth of the analysis somewhat. There is a quad op-amp chip left exposed, however, which appears to be the heart of the sound level processing.

Signal:

IC4 drives the actual LEDs (encased). IC5 is the microcontroller (encased). IC6 is the audio driver for the speaker (encased). IC7 is the audio encoder for recording messages (encased). IC8 is an LM124 quad op amp. Two of the op-amps appear to be used as comparators, one which goes high if the yellow level is reached and the other if the red level is reached. The output goes to the microcontroller which is implementing a delay to avoid being triggered on single, short duration noises. The comparator outputs are NOT filtered in this way, and go high and low with each loudness event; more frequently than the device actually lights its yellow and red lights.

On IC8: Pin 7 is the yellow condition output and pin 8 is the red condition output. Both are positive logic with 0V as a 0 and 3.6V as a 1. Pins 5 and 10 are the amplified analog input which could be read by an ADC on a microcontroller to get real time relative sound level information. Pins 6 and 9 are the yellow threshold voltage and red threshold voltage respectively. These voltages increase logarithmically from 0 to about 3.8V as higher  dB thresholds are selected by the user.

The output to the actual LED’s can be taken as a “filtered” indication of yellow and red conditions, and would be the physically easiest signal to access. The yellow would have to be compensated for the fact that the yellow light flashes several times at each yellow condition. There would also need to be some form of buffer used between the LED outputs and the logic inputs. It may be possible to locate the “filtered” logic level signal, but this signal exists only on PCB traces and would be physically very difficult to utilize.

The audio input seems to be band pass filtered and sensitive to a 1.65 kHz tone, which I used for testing. My guess is that the actual center frequency is near to 200 or 400Hz and the filter is responding to the third or fourth harmonic at 1.65kHz.

Power:

The DC adapter puts out 9V, and the battery compartment seems to be designed to achieve this voltage with 6 AA’s. IC1 on the mode/record PCB attached to the back of the device is a 6V linear regulator which leads to a protected and regulated 5V power supply. This voltage leaves the small board and goes to the main board. It is labeled +5V at each end, either of which would be an ideal place to pick up power for a mote directly or via a 3.3V regulator.

IC8: http://www.national.com/ds/LM/LM124.pdf

A first piece of the development mote for the CC2431 has been assembled and successfully programmed with a blinky program using the same tool chain used for the TT2430 demo board we were working with previously. The CC2431.h file defines the location engine sfr’s and then just calls the CC2430.h, so with the exception of the location engine, the chip is in fact identical to the 2430.

And yes, I got the red and blue LEDs backward again… sigh

Above is a table summarizing the experiment conducted over the weekend in the hospital. “Expected angle” is the angle according to the ball bearing on the bed. The experiment was disrupted when the bed was put into use on Saturday around 8:00 pm. The sensor was retrieved on Monday, and the data collected.

The following is a link to the data collected

https://docs.google.com/leaf?id=0B2GN0bxAc29yMWM3M2Q4NjktOTY0MS00ZTU4LWJiNWUtNGY2ZDRjZjdlYzZj&hl=en&authkey=CKG0kp4I

Each data point is an angle measurement taken 10 seconds after the previous one. A value of 200 is recorded when the sensor is turned on, and a value of 222 is recorded when the sensor is calibrated. (Note that the data at the very end of the file, after the second power on was extraneous data taken in the lab ) These data are significantly different from their expected values because of a bug in the software which causes the sensor to loose its calibration if the power is cycled. (the sensor was turned off, then on again before the experiment).

Furthermore, there appears to be a time when the sensor stopped writing to memory, as we have no data after that time until it was taken into the lab. This appears to coincide with the time the bed was put into use (8:00 pm on Saturday). It is unknown what caused this. It could have been a faulty connection which was aggravated when the bed was moved. I don’t think it lost power, however, since it was on and flashing red when I retrieved it from Phil. (it toggles the red LED whenever the write to flash fails)

I have completed (but not yet tested) the generic front end module for the CC2420, so if anyone has a hankering to add 2.45GHz to their favorite microcontroller I can let you try one of these.

The successful working of the radio on the CC2430 mock-up has spurred increased interest in the smaller mote design. The direction of minimal size was chosen as this is really the greatest advantage of the platform.  I have been working on actually routing the second smaller mote concept. I have switched to a smaller crystal and in the end I had to resort to only placing a single LED. It won’t be as fancy as having three, but the single LED is still a valuable debugging tool. There is still some work to be done regarding the RF section. I am evaluating different antenna options as I would prefer a trace antenna over a chip antenna. If a sufficiently small 2.45GHz trace antenna can be found it will replace the chip antenna.

http://www.tte-systems.com/downloads/pttes_2010_07a.pdf

The following is a summary of my initial investigation into the Cortex M3 processor in preparing to work with the Atmel SAM3U Evaluation Kit. I have identified and located many useful pieces of literature on this processor.

Processor Core

The M3 processor is based on the latest version of the ARM processor core, ARMv7. In the past the various licensees of the ARM core would produce their own implementations for specific market segments. While this is still true, ARM has decided with v7 to try and improve interoperability between manufacturers by having 3 implementation profiles for licensees to choose from, and these are:

A – Application: These devices are based on a virtual memory system architecture and a memory management unit. This profile is aimed at high performance systems running full functioning operating systems.

R – Real-time: These devices are based on a protected memory system architecture and a memory protection unit. This profile is targeted at real-time operating systems and has optimizations for interrupt handling.

M – Microcontroller: From the ARM site: “The Microcontroller profile provides low-latency interrupt processing accessible directly from high-level programming languages. It has a different exception handling model to the other profiles, implements a variant of the PMSA, and supports a variant of the Thumb instruction set only.”

In working with the Atmel SAM3U, we are working with an ‘M’ profile of the ARMv7 processor core. There are a few important reference documents from ARM regarding this architecture:

ARMv7-M Architecture Reference Manual

Cortex-M3 Technical Reference Manual

Cortex-M3 Devices Generic User Guide

There is a possibility that all three of these could be contained in a zip here.

Device

The Atmel implementation of the ARM7-M is the SAM3 series of processors: SAM3N, SAM3S, and SAM3U. The SAM3U has been identified by the TinyOS community as a primary target for next generation devices. The SAM3U4E is the processor available on the SAM3U Evaluation Kit, and is therefore the processor we have available for use in the lab. You can find the data sheet here.

Some additional documents from Atmel:

Getting Started with SAM3U Microcontrollers

SAM3U-EK User Guide

These and other documents and development resources can be found on the SAM3U-EK page.

A little light reading, and we’ll be on to coding.

The progress with the CC243x devices got me interested in what could be done with them in terms of actual physical devices. I did some research and mocked up two concepts for a “smaller mote” based on a CC2431.

Concept 1:

Concept one is optimized for performance, but is smaller than the telos at about 22 x 49mm. It runs on two 10mm coin cell batteries and is non-rechargeable. The antenna is a balanced folded dipole from a TI application note. TI claims that the range of this antenna and this chip in combination is 300 meters. There are 3 LEDs and a reset button, and also room to add another peripheral or two if needed.

Concept 2:

Concept 2 is optimized for size at 12 x 33mm. I’ve used a balun and chip antenna to minimize the RF path. There is a single non-rechargeable 10mm coin cell on the back side. Again, the three LEDs and the reset button are present, although here I think it would already be a significant challenge to route this thing without adding extra peripherals. RF will suffer a few db from the balun and the chip antenna, but I think this is a good concept of what the limit of miniaturization would be with the CC2431.

Then again, if we didn’t bother with voltage regulation and skipped the LEDs and buttons… Well, maybe we could get a little smaller.

Hopefully a picture is worth a thousand words

Some notes on the data.  Presumably, 23 JPC corresponds to doorminder 6 and trigger 127 on the outside and 118 on the inside.  25 JPC corresponds to doorminder 5 and trigger 124 on the outside and trigger 171 on the inside.

Seven times the ground truth and doorminder data are in close agreement.  At 7:33 it appears that the observer may have missed a rub, or that the trigger outside the room was coincidentally used by someone else just as someone was going into the room.

At 7:53 the observer missed an in-room rub (although, in fairness, there is no way the observer can see the in-room trigger).
At 7:57 I’m pretty sure the observer missed a door event, but it may not have been a door event, perhaps someone lingered at the threshold and set off the alarm inadvertently.
After a long pause, there is another event at 8:09 that did not fit in this graphic.  That one corresponds.