Hand Hygiene

It seems that fully charged, each pager can last around 22 hours (86,000 seconds). This was found using the flash data from the weekend test of the pagers.

I just got done following these instructions from Kevin Klues on installing a XubunTOS (Xubuntu/tinyOS) virtual machine on my windows box. It was very easy, and took less than 15 minutes to be up and running (not including downloads).

Deepti set up an experiment with 2 badges and 3 anchors in one evening.  By the next morning, both badges had stopped working.  We set out to understand why they were failing:

Mote 219
- Started fully charged, 5pm June 22
- Stopped writing to flash after 44596 mote seconds,
which is about 12 hours.
- One of the anchors has data coming from mote 219 until 44760 (9 extra
broadcasts) and then no more data from 219.
- By that time the mote had acculumated 37120 bytes of data in flash
(at least that much had been committed).
- Read flash ran with no problem, suggesting that the data was
correctly written.
- Checked battery level 10 am June 23.  Battery level 3.67, so should
high enough to work.
- Then reset the mote, the mote went through the light cycyle, resynched,
but continued to not broadcast.
- Then cleared flash and reloaded program and it operated normally.
I suspect a bad pointer problem in writing to flash, possibly a
bad segment in memory, or a wrap-around problem when getting to the
end of address space.

Mote 227
- Started fully charged, 5pm June 22
- Last message recorded at 38373, about 10 hours into experiment
- Memory was not readable for 3 attempts.
- Used our program to write a few more bytes to memory, then repeated
TFlash and successfully read 32,512 bytes (including about 30 we
added to the end)
- The last message heard by the anchor occured at 38439
- We noticed that the broadcasts from 227 to the anchor were widely
spaced, sometimes a minute or more apart.
- On inspecting the device, we noticed that the battery conector was
loose.  We had measured the voltage on the board to be 3.25V, but the
battry itself had 3.9V. 
We conclude that the mote died because of a poor power connection.

We’re doing a project for a friend who needed a small channel.  We decided to try to etch something for him in copper.  Here’s the close up image of the result.  We’re going to try to clean up the edges.

Trial Implementation: 3 weeks from now

Talks: 4 weeks from now

Set-up in hospital: 5 weeks from now

Full Implementation: 6 weeks from now

Here is the calendar for the full implementation:

http://www.google.com/calendar/embed?src=edt02408squifrc7tnp8qicfqs%40group.calendar.google.com&ctz=America/Chicago&pvttk=b6f8f00a91d360a391cc4fc745792801

We still need more details about the trial implementation (when/where/how much) and the full implementation. It would be nice to be able to test out the trial implementation location before the actual trial.

We also spoke about renting a mac laptop for the full implementation:

The University rental rates are:

http://www.uiowa.edu/~fusmm/rent/rentstok.html

I’ve found recently that the way I organize Pro/E files (eg, not very much) really upsets Pro/E. I have been naming files fairly arbitrarily, usually with some sort of vaguely descriptive name (rx_lid, top, etc). I have also been using the “name” field and neglecting the “common name” field. This has caused a lot of problems because if there are two different files in different projects with the same name, Pro/E will see them as the same file when it stores them in memory. For example, the FSR assembly will have a top to the discs which may be named “top”, and the doorminder assembly will have a top to the box which may also be named “top.” If the two assemblies get opened in the same session, you may close Pro/E and come back later to find that when you open the doorminder assembly, the “top” file will be replaced with the “top” file from the puck assembly. In other words, it seems like Pro/E creates a trail to the file that is identified only by the name and not by the folder or assembly you put it in. This also causes problems when we have separate revisions of the same part file, or when we delete a file that is bunk and start it over with the same name.

So going forward, we need to make absolutely sure that every part we make has a completely unique “name” field, even if it is a different revision of the same thing. For example, the name field might follow the form of [Project]_[Part]_[unique ID], where the unique ID could be any sort of identifier, a string of letters/numbers, etc. This follows for any file we create: parts, assemblies, drawings, etc. The “common name” field can be more descriptive or the same as other parts.

If you must delete a file and start over, make sure the new file still has a unique identifier. Also, any file operations (copy/paste/delete/rename, etc) must be done in the Pro/E file dialog or with File>Rename, this can not be done in Windows Explorer: Pro/E uses this dialog to create it’s trail files. If you try to simply use Windows to copy a part file from one project or folder to another, there is a good chance that Pro/E will not be able to see/open it.

I did more power tests on the tall, thin D-Link antenna per Mike’s suggestion.

Power of 15:

Power of 10:

Power of 5:

The trend seems to be the same, but the signal strength is shifted a bit lower with each test. The test with a power of 5 seems to be more separated though. So, we could go lower with the power level, or maybe something else is causing the signals to be so close together.

I tested the tall, thin D-Link antenna with different powers. Here are the results.

Power of 28:

Power of 25:

Power of 22:

All of these graphs look pretty similar. The lowest power box-plot does look more messy though.

Phil brought our attention to a hand hygiene dance video, which seems like it would be a good training intervention to improve hand hygiene performance.

Here are the results for the same two D-Link antennas, this time with the correct connector.

D-Link tall, thin antenna:

These graphs look completely different from the previous trials. The data for this antenna is all over the place. There is almost no separation at all, so this antenna probably wouldn’t be good based off of this data.

D-Link square-shaped antenna:

This data looks better, but again the separation we are looking for isn’t there.

Links to previous data:

without connection

with pin

We decided to continue testing the tall, thin antenna with different power levels because it seemed that it was saturated.