Summary
The GROK disk is a mote-equiped mostly plastic assembly that fits underneath a hand operated hand sanitizer bottle and allows the mote to detect when the pump has been operated. It is shaped so that all the force of operating the bottle is directed into an adjustable spring plunger. A leaf switch detects the deformation equivalent to operating force.
At the time of my departure for Massachussetts, we have yet to create a working prototype badge for the medical professionals to wear. (more…)
for this test we were interested in the effects of orientation on a second axis. we had one mote (fixed) laying flat, batteries down, with its usb pointed directly at the other mote. .55m away was the other mote, with the circuit board facing the first mote, with its usb facing the ceiling. this mote was rotated in 30 degree increments, such that the usb was always facing the ceiling, but the board rotated to be facing away from the first mote. a constant separation of .55 meters was used, and all possible broadcast strengths were used. rssi data was then recorded to give us an accurate picture of the radiation cloud at .55m in this particular direction of rotation.
the graph below gives rssi readings at power levels 3, 10, and 20 at each of the rotations. NOTE: these readings are only for one distance, at different power levels, not different distances at the same power level.

In order to test the interference effect of various objects, we set the motes up at a distance of .55 meters, with one horizontal, batteries down, usb pointing directly at the other mote. the second mote was vertical, with the board pointing at the first mote, usb pointing at the ceiling. we ran a control, a test with a person in the middle, a test with a person holding copious amounts of wire in the middle, and one with a modified roomba robot with attached camera assembly between the motes. (we had the roomba laying around the lab.) we found that the person and the wire had no significant effects, but the robot did.

there are three dots for each data point, a mean, one std dev up, and one std dev down.
while looking at the data from the preliminary “wolfpack” experiment, we noticed that at close hand washing range and far hand washing range, the number of dropped packets at power level 1 was close to 0 at extreme close range(.25m), around 50% at far (but believable) hand washing range(.55m), and 100% at wolfpack range(1.2m).

we think that this could be a viable algorithm for detecting presence in a wolf pack or not.
we further tested the rapid messaging capabilities of the mote, trying to figure out how many messages per second we could send. for this we modified the mote software to begin broadcasting a message as soon as it finished broadcasting the last message. we did two trials, one with a 13 byte packet length (5 bytes of data with headers) and a 26 byte packet (18 bytes of data with headers). we ran for 30 seconds with each test, and counted 3769 packets at length=13 for a rate of 125.6 packets per second, and 3254 packets at length 26 for a rate of 108.5 packets per second.
this looks promising to me.
today (aug 25, 2009) we did a number of experiments to determine the rssi from certain distances on all possible power levels on the mote. the first set of experiments were a pager body with a mote inside, usb port sticking straight up, lights facing towards the pole, pager facing straight at other testing mote. powered by usb extension from computer. other mote in purell unit facing straight at pager. these two are set up at a distance of two meters and allowed to gather data for 400 seconds, making 100 data points for each power level. we then moved them to one meter and a half a meter. the three dots for each point are the mean and one standard deviation above and below the mean.

we then turned the pager 90 degrees relative to its original position in the experiment above, to the right, and the purell unit 60 degrees to the left such that the mote and pager had 150 degrees relative offset from above, and redid the same experiment, with all power levels at 2m, 1m, and .5m. this was to see if orientation due to placement on belt or position around the purell unit matters. the control was a test with the purell and mote not turned at 2 meters, while the other readings are with the 150 degree orientation difference at the noted distances.

for our third experiment we moved the pager and purell unit as close as the bases would allow (.25m) and raised the purell to offset the mote by .3m. this is to test how the rssi compares at close ranges: at the front of the cleaning zone, the back of the cleaning zone, and in the “wolfpack.” we introduce the height offset in order to better simulate a hand washing environment: the mote will be on someone’s waist but the hand washing unit will be at a greater height than that.

the purpose of these experiments above are to demonstrate whether we can or cannot use the particular radio built into the telosb to determine who is washing their hands and who is not. we have included rssi data for all possible power levels, about 100 packets each power level in each configuration.
We were interested in how the orientation mattered for rssi readings for the telosb radio. we did two tests, one at power level 20 and one at power level 10. in each we set both motes batteries down 2m apart, usb ports pointing directly at each other. we then turned one mote in 30 degree increments and recorded data from both motes. this was to see if orientation was a significant factor in signal strength.
Once again each pair of the six test motes were placed 2m apart. They each ran the BlinkToRadio program and communicated with one another every 1/4 second and broadcast a report packet to the listener on the PC after each communication. The report packet contains the sender ID, receiver ID and the power with which the signal was heard. They ran in this mode for 30 seconds. After each 30s trial, the number of successful communications, averaqe signal strength and standard deviation was recorded.
In two cases the motes performed badly, but after some diagnostic work, the boys discovered that the batteries were not making a reliable connection to the battery holder. Thereafter the batteries were taped into the holder to ensure proper connection.
All pairs of motes communicated between 121 and 124 time each way in the 30s interval with a strength between 51.2 and 59.1. Standard deviations for each communication ranged between 0.7 and 1.6. Raw data are below.
And This graph compares the small differences between the motes.
Gray and Eric wanted a software program that could run the mote tests faster, so they modified the blinkToRadio demo program that came with tinyOS to broadcast when a message was received and the strength of the signal. This approach allows the motes to exchange 4 messages each second (compared to one every 8 seconds with the old approach). Also it removes a great deal of software complexity so we can concentrate on the radios. The code is after the bump.
(more…)
The six motes (numbered 2-7) were placed 2m apart with radios facing each other, at a height of 42.5″ from the ground on 2.5″ PVC pipes, level to about 1.5 degrees. The channel was set to 11 (2405 MHz), determined to be quite in the lab on that day. The motes were first synchronized. During each trial interval, each mote broadcast a signal at strength 20 and listened for a broadcast from its pair. The timing of each broadcast within the interval was randomized. After the broadcast interval, the motes rebroadcast at full power an acknowledgement of the signal received and the strength of the received signal. This acknowledgement was received by a listener. The number of packets acknowledged was recorded, along with the mean and standard deviation of the power of the received signal.
Here is the data.
Discussion:
The results do not support the idea that the motes have two separate groups that communicate within their group, but not outside the group.
We were surprised that the communication had either a poor or an intermediate level of reliability (1 in 6 or 1 in 2). We were also surprised that the reliability seemed to be, at best, around 50%.
We’re going to double check the code for errors, as a higher success rate seemed likely. Hopefully the software will also account for the inter-mote reliability.