Comments for Hand Hygiene

Comment on TinyOS computer broken by Elektrische Zahnbuerste

Elektrische Zahnbuerste — Mon, 28 Nov 2011 02:43:21 +0000

… [Trackback]…

[...] Find More Informations here: groklab.org/handhygiene/2010/03/08/tinyos-computer-broken/ [...]…

Comment on Initial current draw results for Grok Mote by tedherman

tedherman — Wed, 09 Nov 2011 20:37:16 +0000

Can you use the same methodology to test a known case of 1 microAmp draw? That would validate your testing.

Comment on Update on Future Platforms Research by gthomas

gthomas — Wed, 29 Dec 2010 13:54:56 +0000

This is great stuff, Mike. The Keil toolchain code looks very low level. It would be tough to write anything sophisticated with this, but, given it’s limitations, we wouldn’t want to

Comment on To Program Triggers and Doorminders by gthomas

gthomas — Wed, 10 Nov 2010 21:31:15 +0000

I tried with the equipment you left (doorminder 097 and trigger 113). 3 interruptions of the trigger, 3 presses of the door minder. Followed the steps and found the memory empty.

Reprogrammed doorminder and tried again with 12 interrupts (I think) and 3 triggers. The file had 14 and 2.

Cleared doorminder flash, reprogrammed and did 5 interrupts, 5 triggers, 5 interrupts. Found 14 interrupts, 2 triggers, 5 interrupts, 11 triggers 14(2)5(11)(representing probably 4 distinct events). I conclude that the flash was not really cleared and the end of my experiment was cut off.

Reprogrammed. Forgot to clear flash again. Ran clearAndReprog.py again. This time decided to deal with the error. Added the following line to the motes/motes.csv file:
DOORMINDER097,97
Reran clearAndReprog.py and it appeared to work in the first part, but died with the following error: “could not parse mote: DOORMINDER097,/dev/ttyUSB0,Grok Lab TelosB Mote”
Manually programmed doorminder as described in the post. Reran 5 interrupt, 5 trigger, 5 interrupt test 5(5)5. The memory holds the following: 14(2)5(11)5(11)

Further inspection suggests that each test adds only 16 records to the end of the flash. Also, the flash appears not to have been cleared, despite fixing the motes.csv file.

Searched a bit and found that the motes.csv file had a blank line at the end, which caused a premature termination of the script. I added a check to avoid this problem and now seem to be able to run the clear flash script.

Reprogrammed, ran 5(5), and read flash. See 5(11). Conclude that clear flash now works, but only store 16 records in a row.

Repeated last experiment, except ran 2(2)14. Got 2(6)8, as expected. (Note, each trigger event creates 3 records, so the file is correct as far as it goes.)

Started to read the code for the doorminder software. Notice that it commits to memory every 5 minutes, if the memory is at least 1/2 full. Thought I might be able to force the save by committing lots messages. Reprogrammed and pressed trigger 11 times, to generate 33 message. Still only 16 messages in memory.

Tried again. hit the trigger 15 times (should be 3 pages of data. Waited over 5 minutes from the last press (@16:14). Interesting result. Got 32 trigger hits. In the first page (16 messages) got three every 5 seconds, as expected, then one more. Then a break of 7 seconds, as if the second 2 messages of the 7th broadcast were lost. The same pattern occurs with the second page of memory.

I initialized the variables and the problem went away. Here’s the test. Clear flash. Patter of trigger and 4 doorminder events, repeated 10 times, should create 70 events. I got 64 events in the expected pattern (more or less, sometimes I did 3 interrupts rather than 4).

Repeat just to be sure. Same procedure. Just like clockwork. Problem solved!

Comment on Tiltsensor experiment 1 by gscranton

gscranton — Tue, 09 Nov 2010 22:48:31 +0000

The experiment is now complete and the data file is /home/grok-user/Desktop/TiltSensor/WithMemoryNoSound/ReadFlash/exp1data.txt on the south ubuntu computer.

Comment on Changes to make for the next generation of door minders by gthomas

gthomas — Mon, 16 Aug 2010 14:54:45 +0000

Talk with Deepti to find out if there were other issues in the hospital that we need to consider.
Check the doorframe width to see if a wider, shallower profile would help.
In context, would more rounding improve the aesthetics of the design?
Measure the power draw from both devices and consider other battery arrangements. We like the 2 week lifespan, but can the batteries be smaller?
Add a low power LED on transmitter as feedback for when the transmitter is broadcasting.
Remove the channel, because it doesn’t do anything.
Write a manual. Include a section on the properties of the infrared beam, based on stuff you look up in books and little experiments to see what the beam reflects off of and shines through (e.g., the doctor gowns, jeans, laptops, plastic, dark-colored clothes). Perhaps use TelosB user guide as a reference.

Comment on Battery Test/Collisions by tedherman

tedherman — Tue, 20 Jul 2010 00:03:18 +0000

It might be good to know, from the data in the records, how many of each unit there are; for instance, if a pager got 106,000 records, how many of these are from anchor 1, anchor 2, and so on. That way we will see if there is some systematic pattern, like a weak connection between some pager and some anchor. — Ted

Comment on Debugging some early mote tests by tedherman

tedherman — Fri, 25 Jun 2010 16:38:55 +0000

Deepti/Geb: if the flash software is suspect, then we might consider bypassing the TinyOS file system and writing to flash directly. This would have benefits and possibly also some disadvantages to consider.

Comment on Antenna Testing by Antenna Data « Hand Hygiene

Antenna Data « Hand Hygiene — Thu, 17 Jun 2010 18:52:34 +0000

[...] with pin [...]

Comment on New Antennas by Antenna Data « Hand Hygiene

Antenna Data « Hand Hygiene — Thu, 17 Jun 2010 16:26:06 +0000

[...] without connection [...]