Hand Hygiene

Preliminary test results in a mock FSR sensing setup are promising in some ways. The first test setup was the FSR blanketed by a 1/8″ rubber sheet compressed under a disc that is pin-guided on top of the bottom disc. Fairly static loads were applied at different points over a wide area on the load-bearing disc and corresponding sensor resistances measured.

The primary purpose of this test is to determine a baseline correlation between applied force to the test mechanism and output/sensor resistance.

The secondary purpose of this test is to determine whether or not our mechanism will provide sufficient clarity to discern between completely downward forces (eg, someone pressing straight down on a bottle), or partially ‘torqued’ forces that create uneven pressure distribution at the sensor (eg, someone pressing down and slightly pushing back on a bottle).

In this particular setup, the primary purpose is explored by this plot of applied force vs. resistance. A 3rd order curve has been fitted to the data, giving R2 on the order of 0.80. Under illustrated confidence/probability intervals, it may be inferred that we could, for example, tell fairly reliably the difference between 2kg  and 5kg load. (In rough testing, I found that the average hand pump will fall somewhere between 3.5-4.5kg — but further consideration is due).

The secondary purpose seems to have been satisfied: after taking approximately 80 measurements over different forces and displacements, and fitting these as predictors of resistance, applied force is much more correlated to resistance than position. (((f-test values?))

To be taken into consideration: we need a better construction of our intended model. Although, by indication from position testing (if I am interpreting the data analysis correctly), the pin mechanism to relieve torques may not be as important as previously perceived. Worth exploring differences between rubber materials and/or FSR sizing/geometry.

I was attempting to install Eagle 5.7.0 on the TinyOS computer through http://packages.ubuntu.com/. This website downloads self-installing packages to the computer. The installer for eagle complained about the version of libfontconfig1 being out of date, so I downloaded a later version of that, and attempted to install it. This complained about libfontconfig1-dev being out of date. I downloaded this package, and attempted to install it. This complained about libfontconfig1 being out of date again. I used Sympatic package manager to uninstall the current version of libfontconfig1, and intended to reinstall them from the downloaded packages.

The uninstalled packages were:

libfontconfig1, libfontconfig1-dbg,libfontconfig1-dev.

In the last parts of the uninstall, the computer froze, and I had to reboot. Upon rebooting, it said there was a file system mount error, and a maintenance terminal was started. Everything that was there previously seemed to be in place, so I did not want to reinstall the operating system, which would probably result in all of that being deleted. If there is a way to reinstall these packages via a utility shell, please let me know.

I believe this is the final variation on the door minder circuit. Because there wasn’t sufficient current from the encoder chip, we must drive the LED directly from the batteries, using a BJT, in this case, the 2N3904. The new LED, SFH4511, has a smaller half angle and higher radiant intensity than the TSAL6200, and better serves us at the distance we need to transmit the signal. Because we only need to see if the signal is interrupted, we will only transmit one bit, D0.

I am currently testing the circuit with the LED on top of the receiver, inside a black heat shrink tube in an orientation something like this:

The heat shrink tubing is needed because the receiver can still pick up infrared waves from the LED just being turned on. Another possible problem is that at distances of about 2 feet from the circuit, the receiver can pick up reflections off of skin and clothing.

An equivalent circuit to LED driver (driven from output of encoder chip) when on:

We use 0 for the resistor between ground and the emitter node. The power dissipation of the LED is 165mW, and the current through the LED is given by:

i_led=1.5v/R_led

Therefore, because P=vi, and we know the forward voltage drop for the LED is about 1.3v, R_led must be around 12 Ohms:

P=vi => 165mW=(1.3v)*(1.5/R_led) => R_led=1.95/0.165 Ohms = 11.8181 Ohms.

The base current can be calculated as (3v-1.5v+0.7v)/100Ohms=8mA. The emitter current is the current through R_led, 1.5/12=125mA. Adding these, the circuit uses 133mA when on.

The signal takes 27-28ms to be sent (see previous posts), so we should leave the encoder toggled for around 30ms, just to be safe. If we repeat this every 100ms, the encoder will be on 30% of the day. The batteries we use claim to provide 1500mA hours. Because 133mA is being used 30% of the time , we can use 30% of 133mA to calculate the circuit’s life. This is 1500mA*h/39.9mA=37.594h, about one and a half days.

We could turn on the LED every 200ms, and double the life to a little over three days (75.188h), but we will need to make sure the decoder receives every signal.

The new LEDs will arrive soon, it may be possible to get reliable results with less power, but previous experiments do not suggest this.

We set up this experiment according to the plan shown below. Someone wearing Pager 239 stood at all the places indicated by numbers 1-11. In the rigged trial, they stood in a manner that would collect the best data. In the natural trial, they moved around and tried to act natural. Lots of good data was collected. And here’s the report-

(more…)

I have attached a wiring diagram for the new pucks as reference. The orientation of the batteries is a top view of the puck with the USB pointed ‘up’. The triangle represents the circuit board with the switches, with the momentary switch at the bottom of the diagram and the two position switch at the top of the triangle. The green box represents the mote facing downwards (eg, as the mote will be mounted in the puck, with the buttons downwards)

Last night (March 2, 2010), I ran a test with the door minder circuit. The separation between the encoder and decoder was 365cm (approx 11.98ft), and the encoder was being toggled at 20Hz. This means the expected signal from the decoder should be around 10Hz because the decoder changes every time the encoder sees a high signal. A signal was produced, but it was not nearly a consistent 10Hz. Unfortunately, in trying to adjust the LED, I broke one of the wires off, and, of course, lost the signal. Eyeballing it, I would say the decoder picked up 3 or 4 in every 20 toggles from the encoder.

Previously, the experiment was ran with both chips on the same board with both the LED and transceiverpointing towards a mirror. A signal was produced, but last night, I realized this was a reflection of of my shirt/hand. I believe the LED is not focused enough. The current through the LED in both cases was around 45mA (I didn’t have a chance to test it with anything lower before I broke the LED). I am, of course open to any ideas on how to proceed.

Program:
(1)Clock (prog Clock 1 Run#)
(2)Base Station (tiny-os → make telosb install.0)
(3)Pagers (prog Pager ID#)
1.Check batteries are present + have enough charge
2.Label and program correct number of pagers
3.Check that labels match computer program + programmed as pagers
(4)Anchors (prog Anchor ID#)
1.Check batteries are present + have enough charge
2.Label and program correct number of anchors
3.Check that labels match + programmed as anchors
(5)Hand Cleaners (prog HandCleaner ID#)
1.Check batteries are present + have enough charge
2.Calibrate them in wall bracket
3.Label and program correct number of hand cleaners
4.Check that labels match + programmed as hand cleaners

Practice In Lab
(1)Make sure Base Station picks up signals from all pieces
(2)Make sure everything syncs + shows up on the demo run as its supposed to
(3)Get all supplies in tool box
(4)Pack up all programmed motes

Set-Up In Hospital
(1)Unpack all parts
(2)Check that everything is still in working condition
1.Batteries still working
2.Hand cleaners properly calibrated
3.runsfb again and see that everything shows up
(3)Put all parts in their specific locations

Mike’s comment on my previous post:

It may be useful, instead of oscillating the input to the encoder, to have the mote toggle the input to the encoder. This should cause a code to be sent once and received, which will then cause the corresponding pin on the decoder to toggle. The mote can then verify this toggle to indicate that the beam is uninterrupted. The mote can run this routine every 5ms or so. Two or three failed transmissions in a row could be considered as an activation, and the mote could then broadcast it’s “my beams been broken” signal.

This seems like a good idea, but we must also account for a 27ms delay between when a pin on the encoder is toggled, and the corresponding changed is noticed on the decoder. Here is a screen from the oscilloscope:

The output from the pin on the decoder is on top, and the toggle for the encoder is on bottom. An oscillating toggle was used so we could view this delay on the scope. Notice the 27ms gap, shown by the cursors, between when the encoder is toggled again from being off, and the change in the decoder pin.

To be clear, a “broken signal” in Mike’s comment means there is no change in the output of the pin on the decoder. Notice on the scope, it only changes when the LED is on, goes off again, and then comes back on. If the second on, in this example is interrupted, and the LED goes off before the signal reaches the transceiver, the decoder pin will not change.

Here is a picture of the current circuit, as it is wired. For testing, I plan to put both on the same board.

I did another battery test using a modified version of Ted’s code which makes the pagers broadcast their battery readings, and turn off automatically at a reading of 1600.  The modified versions of sampADcC.nc and sampADcP.nc can be found here:

http://docs.google.com/Doc?docid=0AWGN0bxAc29yZDdqZG5zd183aGI4bWgyZjk&hl=en

http://docs.google.com/Doc?docid=0AWGN0bxAc29yZDdqZG5zd182ZnZ2cXpnZzU&hl=en

The following table and graph summarize the data

The motes exhibited some strange behavior after the test. mote 244 ended at a reading of 1607, which should correspond to a voltage of about 2.5v. When I measured the battery voltage, however, it read 3.2v. I turned it on again after the test, and it broadcast a reading of around 1980, which sure enough corresponds to 3.2v. I’m  certain it was not plugged in between the time the test ended and I read this voltage. In the last test, both motes exhibited the same behavior, but I let it slide since they had been plugged in for some time (1-2 minutes) before I checked their voltages.

Both of the other pagers in this test had a battery reading of 0v, suggesting the automatic shut down didn’t work for them, and they drained their batteries overnight. The test results seem to suggest they turned off at the right time, however, and I don’t know why the automatic shut down would work for one pager but not the others.

I did a quick experiment to find out how close the settings of the puck need to be adjusted for it to record data properly.

I started with the screw in so that the pushes could not be recorded. I recorded the start linux time and the finish linux time for each trial. During the trials, the gel sanitizer was pushed ten times with a one or two second gap between presses. After each trial, the screw was adjusted a quarter of a turn.

The first two trials showed that the puck was not activated at all. The next four showed that the puck was pretty much activated when it was pushed. (There was one dispenser press where the puck was not activated, but that could have been not pushing hard enough.) The seventh trial showed that the puck was activated by some of the presses, but it also stuck between presses. In the eighth trial, there was one activation where the gel sanitizer was sitting on the puck so that the pressure pad was always stimulated.

What I found was that the screw needs to be adjusted to within one turn to give the proper readings.

Data for each individual trial is at: http://spreadsheets.google.com/ccc?key=0Ajml4qs0jKAXdHY0aUw2TkFBNFlhOGQ4NS00bWg3NWc&hl=en