Hand Hygiene

I discovered a trivial error in my timeline (using an older version of the clean 8 data) that was making the synchronization with the ground truth data.  Unfortunately, in the process I discovered that the doorminder for room 7 ran out of power around 8:30 pm on 12/18/10.  Consequently, not much of the ground truth data will correlate with all four doorminders.

The SIMILE timeline widget appears to be a useful tool for visualizing the different processing operations I’ve been performing on the data.  I’ve developed some python code that translates the data text file into an xml file that can be read into a timeline, which I’ve tweaked to be relevant to our last experiment.  Here’s a sample screenshot:

There are 4 horizontal bars.  The top bar displays the content of 5.clean.txt, the first step after processing the raw file.  The second bar displays 5.unique.txt, the processed file with redundant data removed.  The bottom two bars show the time of day (above) and date (below) that the data on the top was collected.  The label on the top two bars show the minute of the hour that the date was collected.  General hand hygiene events are marked with an open hand icon.  Door minder events (only from doorminder 5 in this case) are marked with a door icon.  The triggers inside and outside this particular door are marked with a thumbs up icon. 

The display above indicates that trigger 155 was pressed 3 times between 9:35 and 9:36 on December 15.  The top row shows that the 5.clean.txt file includes 3 signals for each trigger event, as expected.  The 5.unique.txt file shows only event for each of the 3 nearly-simultaneous signals, also as expected.  Using similar logic, it is clear that the hand hygiene dispenser 171 (in the room) was used, someone passed through the door, then the 124 dispenser outside the room was used.

The figure also demonstrates a trouble I discovered with my filtering process.  Do I really want to remove closely spaced door events?  Perhaps there are multiple hits because of swinging arms or some other reason that one pass through the doorway could cause multiple doorway events.  On the other hand, perhaps the person ran back inside to check something quickly, then came out again.

The figure above shows a slightly more complex example at around 9:26 on the same day.  Should each of the doorminder events here be treated as one event or as several events?

I’ve put the code for this display below the bump.
(more…)

I conducted some experiments with the tilt sensor in the lab. The first was started on December 22 and ended a week later on the 29th. The following table summarizes the angle changes made during the experiment.

Since this experiment was informally conducted, I changed the angles whenever it was convenient, which happened to be on the 27th. The data file obtained from this experiment was very encouraging. The sensor recorded an integer value representing the angle reading in degrees every ten seconds. The following is a sample of the data when the angle was set to 30 degrees.

30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30
30

That’s right, it the recorded angle matched the expected angle with no visible noise. I checked the times based on the number of entries, and they all matched within a minute of the expected times, except the last one which was within four minutes. I am assuming this was due to an error I made in recording the time. The full data file can be downloaded here: https://docs.google.com/leaf?id=0B2GN0bxAc29yNTY1NWRiZGYtN2YzZi00YzdhLWE0YmYtZmQyZTkxMmQ3N2Q0&hl=en&authkey=CNSM_NMC

Note that -120 is the value the tilt sensor records when it is turned on. I am not sure why there are multiple -120′s in a row.

Since the data entries are so consistent, it would probably be more efficient to record the angle and mote time whenever the angle changes.

The second experiment took place on the 29th and lasted about an hour. I did it because I had just added a calibration routine to the program and wanted to test that. The following table summarizes the experiment.

Results were similar to before, although some angles were one degree off, but I would consider this acceptable. The data file can be found here: https://docs.google.com/leaf?id=0B2GN0bxAc29yZWFiMDExNzEtMTQyNy00YzM4LThiNzMtZGM5YzljOTdjMjkw&hl=en&authkey=CN3Xzo4F

Note that since I downloaded this data in a different format, the -120′s show up as 136. Also note that there is nothing to indicate when the sensor was recalibrated. I will change this.

Here’s the summary of the unified event file, made by adjusting the clocks for all the doorminder data in the peds unit for the 5 days of data:

Trigger    Number of      Minimum    Maximum
Observed  Observations      Time       Time    Mote Location/use
  155          189          154       386600     out of room doorminder 8
  154           36          220       299757      in room doorminder 8
  137           20       175137       351845   Deepti’s synch on 12/17 am
  117            1       386604       386604    unknown (and confusing because of 171)
  118          115          161       456391    in room doorminder 6
  171           74          140       456645    Probably in room doorminder 5, mislabeled as 117
  138            4       300816       446798   second regular pod
    5          929         -112       518866      doorminder self
    4            1       646456       646456      unknown
    7         1009          -25       386578     doorminder self
    8          817            1       452615       doorminder self
    6         1161          -69       580941     doorminder self
  148            9         1002       456524    Tina’s synch and Deepti’s synch on 12/15
  149          145          193       299747     in room doorminder 7
  109           30        86135       300912    Deepti’s synch 12/16 am 12/17 pm, 12/18
  124          377          167       522963    out of room doorminder 5
  125          208         1046       445344    out of room doorminder 7
  127          324          244       646654     out of room doorminder 6
  160           18       386644       386869   late synch
  161            9       300825       455126    unknown  (pod 2?)
   32            1       386653       386653     unknown (pod 2?)
  133           49       300848       446671  unknown (pod 2?)
   95            1       459857       459857     unknown
  111           80       301324       456787   unknown (pod 2?)
I think most of the unknown entries are from pod 2, but I don’t have Deepti’s notes to confirm.  Also there is a single signal from 117, which I thought was mislabeled as 171.  We’ll need to double-check that as well.

Otherwise the data are remarkably consistent from the summaries from the individual files to the combined summary, within 1% of what I would have thought would be the tally.  I need to find a way to plot the results to see if they all make sense before calculating the hand hygiene rates for each room.

I’m working on the analysis from the peds unit data for the experiment run from 12/15/10-12/21/10.  Three pods were involved: 2 in the regular peds unit and one in the bone marrow unit.  So far I’ve divided the data by doorminder and am working on the offsets for the clocks in the first peds unit.  There are 4 doorminders in that unit: 5, 6, 7 and 8.  I chose 8 as the master clock and looked for 8 different synchronizing events from the various experimenter triggers that we used to uniquely identify moments in the experiment.  I then plotted the approximate offsets for each event versus the time on doorminder 8 to get the following plot:

As luck would have it, doorminder 8′s clock was a bit slower than the others (by a factor of 1E-5).  I’ll use these offsets to correct the rest of the data.  Otherwise, things are looking very much as expected with no strange jumps or other weirdness.

There are two prongs of future platform research: The Texas Instruments CC2431 and the Atmel SAM3U. The CC2431 is a less powerful 8051 processor core and a 2.4GHz radio in a single very small chip, so the interest here is the possibility of doing a few peripheral devices which could be very small and have very simple functions. The SAM3U is an ARM Cortex M3 32 bit processor and is very powerful. This is a potential future platform base. The extra power could enable lots of real time data processing capability.

The CC2431 is currently being investigated with a set of clones of the CC2430, the older cousin of the CC2431. The CC2431 is the only version which TI considers to be “current,” however they are pin compatible with each other. The primary difference is that the CC2431 has a built in hardware location engine which it uses to triangulate itself from the RSSI values of messages from known location nodes. Despite it’s limited processing power, the interest in this platform is obvious. We have used a Keil toolchain to write a blinky program for the CC2430 clone and successfully programmed it using the TI SmartRF Flash Programmer software. Currently I am investigating the use of the radio and attempting to develop a simple blink to radio program to execute on the pair of CC2430 clones.

We have acquired a SAM3U evaluation kit from Atmel in order to begin looking into the use of this platform. There is no RF capability on the evaluation board, so I have designed a CC2420 (the radio used on the telos) break out board which can be interfaced to the SAM3U evaluation kit when the time comes.

The Blinky code:

/*
BlinkyUI
by Michael Ireland
Written for cc2430db to verify tool chain
Using Keil uVision4 8051 eval -> SmartRF Flash Programmer 1.6.2
*/

#include <CC2430.h>

int tcnt = 0;        //Initialize timer variable
int period = 10;    //Initialize speed variable
int updwn = 0;        //Speed up (1) or slow down (0)

void timer3_isr (void) interrupt 11
{
tcnt++;
}

void main (void){

T3IE = 1;            //Enable T3 interupt
T3CTL = 0xF8;         //0b11111000 – Configure T3
P1DIR = 0xFF;        //Set P1 as output
P1 = 0×99;            //Set initial state of P1
P0DIR = 0xFF;        //Set P0 as output
P0 = 0×99;            //Set initial state of P0
EA = 1;                //Enable global interupts

while (1){
if (tcnt > period){
P1 ^= 0xFF;        //Toggle outputs
P0 ^= 0xFF;        //Toggle outputs
tcnt = 0;        //Reset timer
if (period > 300){
updwn = 1;
}
if (period < 30){
updwn = 0;
}
if (updwn == 1){
period -= 20;
}else{
period += 20;
}
}
}// End while(1)
}// End main

The CC2430 clone with an 8-LED output added.

The CC2420 breakout board.

I spoke with Pavlo Krokhmal about the problem of synching the trigger with the master clock.  He suggested a simulated annealing algorithm, or something similar, although I think he was focusing on the fact that some events are not heard and other are heard.  In any case, I downloaded the pygsl toolkit (gnu science language for python) and implemented the simulated annealing package.  A scale and offset is applied to the timestamp of each event in the doorminder file.  Then I search through the master file and find the closest corresponding event (i.e., an event with the same sender ID).  I then apply a cost function equal to the square of the integer number of seconds difference between.  The advantage is that with this technique I can adjust the scale factor to account for the clock being slow or fast relative to the master clock.

Here are the results compared to what I got by hand, in each case using the optimization

Door Minder / Opt. Offset / Opt Scale / Std. Offset / Std. Scale

96a / 271.896755313 / 0.999976281323 / 267 / 1.0
96b / 8446.25734285 / 4.31567629206 / 187605 / 1.0
97 / 59.0971568776 / 1.00000267838 / 59 / 1.0
98 / 289.188992543 / 1.00000490606 / 290 / 1.0
99 / NA / NA / 0 / 1.0

The results look great, except for 96b.  I didn’t clip the master file (99) before running that, so apparently it could find a better score by shrinking time radically.  Probably I should change the cost function to include a penalty for changing the time scale by very much.

I now have a program for the tilt sensor which uses the battery voltage as the reference voltage, rather than an fixed voltage. I experimented with it using a variable power supply, and gave consistent angle readings at different voltages above 2.7v. Starting at 2.6v, the readings became less reliable. 2.7v is also the minimum supply voltage for using the flash memory according to the telosb user guide.  Thus, I think 2.7v is the minimum supply voltage at which the tilt sensor can operate reliably. This new program should solve our drift problem, although this still needs to be verified with an experiment lasting a few days like the last one.

Even though the angles read in the new program are consistent between different power supply voltages, they are no longer accurate. More data will have to be collected so that a new equation can be made relating the accelerometer output voltage and the angle.

This may have to be done anyway. So far, we have been thinking of hardware changes to make the tilt sensor work reliably. These include mounting the accelerometer at an angle on the breadboard and including multiple accelerometers so that it can work on different beds in which it will have to be mounted in different positions. Now my opinion is that the best option is to create a new equation in the software in the form of a piecewise polynomial. If we can ensure this is accurate for the entire range of angles, we can use the accelerometer configuration in the current version of the board.

There is one unrelated hardware change which should be implemented, however. I have added capacitors to the current tilt sensor to reduce noise on the output of the accelerometer. These include a 0.1uF capacitor between power and ground, and a 0.68uF capacitor between the output of the accelerometer and ground. These have greatly reduced the noise and should be implemented in the final design.

Edit: the 0.68uF capacitor has now been changed to a 4.7uF capacitor to further reduce noise.

In my first analysis of the doorminders, I allowed multiple doorminder events to be recorded, even when they were closely spaced.  On reflection, I think this is unfair, since we only allow one trigger event every 5 seconds.  To correct the error, I reanalyzed the logs and removed the redundant doorminder events.  Now we have

Doorminder 96a
Trigger    Number of      Minimum    Maximum
Observed  Observations      Time       Time
  154          116          289       186527
  127          229          277       187027
  138            6       177280       177309
  161          248          235       176934
  162          165          216       185585
   96          812            0       187210

Doorminder 99
Trigger    Number of      Minimum    Maximum
Observed  Observations      Time       Time
  154          145          560       213155
  127          283          549       213168
   99         1243           13       213206
  138           11       177547       213242
  161          249          506       213177
  162          182          488       213189

(more…)

I made a histogram of all the trigger presses relative to the door entries. The histogram goes from -15 s to +15 s seconds after a door opening. Each trigger press is associated with the closest door event. The data show a clear correspondence between the trigger events and the door events:

Each box contains the number of trigger events for each trigger (in columns) for a particular door minder. For example, the box at (top) left is for door minder 96 and we can see that 3 of the 281 trigger events from trigger 127 came 4 seconds before a door minder event occurred.

From these figures, it is clear that the data are not uniformly distributed. The data in the columns highlighted in green are from triggers close to the door. Trigger events were much more likely to occur near a threshhold crossing when the trigger was close to the door. In three cases, 82-93% of the trigger events came at a time close to a threshhold crossing. One of the door minders does not follow this pattern. For doorminder 98, only 45% of the data were followed by a threshhold crossing.

The data highlighted in yellow are for triggers that are adjacent rooms to the door. These triggers are easily accessible to someone entering or leaving a room. In many cases nearby triggers have higher values than distant triggers, suggesting that some people used nearby triggers. Trigger 154 is often used close to other threshhold crossings. Perhaps it was in a particularly convenient spot for multiple room accesses.

To gain more insight into whether or not a trigger event was associated with a particular threshhold event, we need to allocate each trigger event to only one threshhold event, across the experiment, which will require another program, for another day.