Hand Hygiene

We now have 2 Irene motes (sans accelerometers and rtc) and 2 programmer/chargers completed, and have successfully installed Blink on them.

USER NOTE: To install to the Irene place the base switch into ‘prog’ position, and use: make epic install miniprog

Dev note – After multiple suppliers failed to ship the MIC5235, I substituted the MIC5205 for U8. This will have no effect on circuit operation.

RFID-based Hand-Hygiene System Prevents Health-care Acquired Infections

F Antenna:

F Antenna with Metal Backing:

The graphs are very similar at close distances (.5 m). At farther distances (2.5 and 3 m), there are differences in the signal strength. If we aren’t concerned about the farther distances, we could still put the bed motes on the metal panel.

The battery test for the door minder is finally done.  The total time has been 544 hours (that’s a little over 3 weeks!).  At the end of the test, the battery voltages were 2.88v for the receiver (2 AA’s), and 3.12v for the transmitter (3 AA’s).

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.