Hand Hygiene

In recent weeks, the development of the Polhemus project has come a long way.  We have been able to test the device and figure out how it works and have been creating programs in python in order to analyze the data we will generate from the experiment.  The following is a summary of how we propose the device will be used during this experiment.

The first leg of the project involved figuring out how the Polhemus device works and getting a feel for its limitations and its features.  After a lot of testing, we concluded that we would not use it for its actual coordinate positioning features because there was too much variance in measurements that were further than 6ft from the source.  We also felt that measuring each object in the exam room in relation to the source could become extremely tedious and time consuming, and also leave us with a lot of room for error.  The device did not have very good accuracy far from the source, but the measurements had high repeatability.  Because of this, we decided it would be best to use the Polhemus device to calibrate each object in the room.

We designed a program called calibration.py that allows us to map out different objects in the exam room, and save them as separate files.  The movements while calibrating replicate those of a regular motion with each of these objects, making sure to do these movements at every angle possible, and at every hand position possible, as not to disclude any possible movement.  Since these calibration files will be quite large, we came up with a cleanCalibration.py program, significantly decreases the size of the calibration files.  This program essentially takes the first point in the calibration file, draws a sphere around it with a radius of 1 inch, adds it to the cleanCalibration file, and tests the rest of the points in that file against the sphere.  For example, if the second point is inside the sphere, it gets discarded.  However, if the point is not inside the sphere, the second point gets added to the new cleanCalibration file and also gets a sphere around it.  The third point would then be tested against points one and two in a similar manner.  This program allows us to eliminate repetitive calibration points that slow down the analysis process.  With the addition of the clean.calibration file, we were able to reduce analysis time by about 75%.

The readPol.py program allows us to collect experiment data instantaneously from the PiMGR, which is the program that came with the Polhemus device and is responsible for collecting the motion capture data.  This program utilizes a pipe to take the information from the PiMGR, and writes it to a file.  This program produces one file per sensor, which means that we have the ability to do comparisons between the left and right hands if we so choose.

Preliminary analysis of the collected data is done with the closeToFiles.py program, which calculates the closest Cartesian distances between the raw files and the calibration files.  Those distances from each object in the room are calculated for each point in the raw data and are written to one master file.  The master file contains a column for each object in the room, and in those columns are the distances to the object at each time data was collected during the experiment.  The file also contains a timestamp, so we are able to tell exactly when the doctor was close to each object.

In order separate out the touches from the non-touches, the program touchSummary.py only takes distances from the master file that are 6 inches or less from any object and writes range of time for the touch to a file.  The summary is organized by object, with the time ranges and total touches under each object.  The total touches throughout the experiment are calculated at the end of the summary.  This program also outputs one file for each sensor.

At this point, we have done preliminary testing inside the lab and are ready to move to the experimental exam room in the hospital.  Future work might include a program that creates a timeline summary of the events during the experiment, which would make it easy to decipher what the doctor did during the exam and at what time, without actually being in the room.

Redesign Points:

1. Redesign the decoder portion to only trigger the MCU when the beam breaks instead of constantly telling it that there is a beam present. This is the main redesign goal as this is the cause of the large power drain.
2. Use a tripwire type design as seen here to determine if the doorway has been crossed. (http://www.instructables.com/id/Another-Arduino-Laser-Tripwire/)
3. Use a PIR (passive) to determine when someone enters or leaves a room (http://www.ladyada.net/learn/sensors/pir.html)
4. Using a 555-Timer in monostable mode would allow an LED IR receiver to be connected to the trigger line. If connected properly every time the receiver stopped seeing the signal from the LED then the 555-Timer output would pulse up to 5V for a time determined by C1 and then return to ground. (This is effectively acting as a 1 shot). This design uses a photocell to see when the IR stops receiving instead of a decoder. This would make the oscillation frequency of the IR irrelevant.
5. A 1Shot could also be used however the 555-Timer option allows for lower power than a 1 Shot.
6. Using a PLL would ensure that the mote was only triggered when the beam was broken but the PLL and the amplifiers to increase the signal all require dual power supplies. This could be implemented if a complete over-haul design process was warranted.
7. You could use an LED as a detector as shown below. Just use a small 5 mW red laser as the beam. Easily focused, low enough power ot not cause eye damage and will still allow the circuit to trigger. This will also “reset” itself once the beam is no longer broken.
8. Redesign the transmitter to have a current limiting circuit instead of current limiting resistors.
9. Redesign using a different encoder/decoder to draw less power. Or place an averaging circuit on the output of the decoder currently being used and set a thresh hold at which the mote would be triggered.

Each design has the potential to be lower power but depending on parts used, the size of the ducty cycle, power supply chosen and variation within parts the power will vary significantly. Digikey has several IR encoders and decoders with lower power applications. So does Mouser. The key to ensuring a low power design will be to actively monitor the power being used by each component.

Current Reciver:
22.3 mV – no beam: 17.1538 mA
19.5 mV – with beam: 15.0 mA
Max power: 55.2011 mW
Battery life: ~ 170 hours (7.3 days) to 130 hours (5.5 days) depending on how often the beam is broken.

The more the mote has to write the less the battery will last. This can be seen based on the RF transmit occur every time there is a break in the beam. This RF transmit causes a power spike of 121 mW to occur for a time. If the current draw on the mote was consistently at the power (3.188 V and 38 mA) then the battery life would only be 60 hours (2.5 days).

This points to the systems battery life being dependent upon the receiver instead of the transmitter. It also shows that the transmitter’s large power draw is occurring because of the RF transmission and flash memory write functions on the mote. As these functions are critical to the system developed and the end goals of the door minders it is not recommended to alter this portion of the design. The IR receiver/decoder also pulls a good deal of current while it is not receiving the IR beam, but it is significantly less than the mote and as the beam is only broken periodically, the average power draw off the decoder is low.

The test was started July 8th at 14:02.

The old design died at 23:27 on July 13th, lasting 5 days 9 hours.
The new design died at 16:00 on July 14th, lasting 6 days 2 hours.

Sam did the following research some time ago, but it was never posted to the blog. Her version is much nicer with formatting. Ultimately we bought one of the pico scopes and it is doing fine.

I have been looking into different audio level meters to be used to measure the volume in the MICU to determine whether or not the sound level in that area is high enough to cause problems for the patients when they are trying to sleep.

In looking at audio level meters, I have found three different categories which may be useful in our study. The first group can measure over a range of approximately 40 dB – 130 dB. This group has an approximate price range of $25 – $65. The second category measures over the range from 30 dB – 130 dB and have prices around $175 – $200. The final category measures approximately as low as 21 dB and up to 141 dB with prices from $ 2500 to $3133. The maximum of the range of any of these meters should be high enough for our purpose, but the minimum may not be what we need. On the next page is a list of 2 sound meters from each of the 3 categories, along with some specs and the prices.
(more…)

INTRO:

This post is designed to outline the functionality of the Door Minder as it is currently understood. As it is understood the system is powered by three batteries. There are three subsystems from the battery that use power, the 555 timer, the Tiny IR-II and the LED. The 555-Timer subsystem creates a pulse that drives the Tiny IR-II subsystem. This subsystem then drives the LED subsystem.

In Depth Details:

The 555-Timer is currently generating a 24 Hz signal in astable mode using R1 = 1k, R2 = 3M and C1 = 10n. On the rising edge of the 24 Hz signal the given channel line on the Tiny IR-II Encoder is pulled high. This triggers the Tiny IR-II to output a 38 kHz signal on the output line.

The output line on the Tiny IR-II controls a MOSFET, when the line on the Tiny IR-II goes high it turns the MOSFET on and in turn the LED. When the Tiny IR-II line is pulled low the MOSFET is turned off and in turn the LED is turned off.

POWER:

The power being pulled off the batteries by the current design is 21.21 mV RMS across a 1.3 Ω resistor. This is equivalent of 16.3154 mA. And a power draw of 78.34 mW from the 4.8 V produced by all 3 batteries. When the power across the individual systems was measured it was found that the total power from the individual systems was 78.5 mW which is within a 2% error. This error was deemed to be appropriate for the measures done.

Based on the battery data sheet, with a 16. 3 mA the battery should have approximately 200 hours of usable life (8 days).

Power After Redesign:

The power being pulled off the batteries by the redesign is 4.46mV RMS across a 1.3 Ω resistor. This is equivalent of 3.43 mA. And a power draw of 15.7 mW from the 4.7 V produced by all 3 batteries. When the power across the individual systems was measured it was found that the total power from the individual systems was 15.8 mW which is within a 2% error. This error was deemed to be appropriate for the measures done.

Based on the battery data sheet, a current draw of 3.43 mA will give a battery life of a little over 600 hours (25 days). This is at least 3 times the previous battery life.

Validation:

To validate the theory behind the change in design a model was made in MicroCap 10 and an analysis was run. The schematic is shown below:

The analysis was run by sweeping the value of the trim pot from 10 ohms to 500 ohms. The current and voltage across the diode was then graphed against the sweep. The output is shown below. Based on this graph the current and voltage will drop across the diode as the resistance is increased validating the data collected above.

Resources:

Tiny IR-II: http://www.rentron.com/remote_control/TINY-IR2.htm
555-Timer: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-1411-5-ND
Battery Life: http://www1.duracell.com/Procell/productdata/ (PC1500)

DNF, timeout, I/O and radio are errors I wrote, I think Bad sync must be something someone else was using. The first three are all errors which occur when attempting to program the mote, not sure about the last. I believe that we had lots of errors with the motes related to moisture infiltration of the ICs. If you attempt to replace any ICs on these motes, bake the components for 48 hours at a temperature of 125 degrees C before soldering them. In fact, bake the motes also before doing any IC replacement on them.

DNF = Device Not Found (i.e. did not appear in mote list).

Sometimes this is a problem with the USB connection. If you look at the telos schematic you will see that there are a few resistors between the USB connector and the USB/serial converter chip (FTDI). Check these connections with a meter. If they are all correct, your next target is the FTDI chip. First, use the schematic and a meter to ensure that you have ground and Vcc everywhere you are supposed to on the FTDI chip. If not repair the open circuit and try it again. If there is no power/ground problem the next thing I would tell you to do in a perfect world would be to check the resonator with a frequency counter to be sure it was working, but we don’t have anything which reads up to 6MHz. Next step is probably to replace the FTDI chip with a new one, and next the resonator. After that, if it still isn’t in motelist, your guess is as good as mine.

Timeout = Device appears in mote list but there is a timeout when trying to program it.

Suspect the processor. An interesting test would be to see if you can get the mote to program using the JTAG device in the TI box in the left cabinet. If you can’t program using JTAG, try reflowing the processor. If this still doesn’t work, assume the processor requires replacement, as JTAG is a direct line into the processor which is dependent on no other components on the board. If JTAG works but the mote still times out, follow the USB troubleshooting procedure above.

I/O = I think this was a separate error message which occurred when trying to program the mote.

Follow timeout procedure for lack of any better ideas.

Radio = Mote works but doesn’t pass radio test.

If the radio chip passes basic power and ground checks, bake up some CC2420′s and swap them in.

If all of the above fail, cast it in resin and use it as a really neat coaster for the lab. Keep in mind that there is a chance of fixing a USB problem only to find a processor problem, and/or fixing a processor problem only to find a radio problem.

Discovered by Ted:

http://www.youtube.com/watch?v=xiELOautbTI&feature=related

Very uplifting music, but no one gets under their nails.

Looks like there’s a whole series of them in the same place.