Acoustic Tape Measure

Please copy/paste "{{Translationlist | xx | origlang=en | translated={{{translated}}}}}" (where xx is ISO 639 language code for your translation) to Acoustic Tape Measure/translations

HowTo [ID# 70143]  +/-

Acoustic Tape Measure Status alpha—under development sources in projects/acoustic-measure-activity TST {{{1}}} POT | es  Benjamin Schwartz

Acoustic Tape Measure determines the physical distance between two XO's by measuring how long it takes sound to travel between them.

Measurement Algorithm

Normally, distance measurements that use audio transit time work by first synchronizing the clocks on the two computers. The receiver starts recording, and notes the wall-clock time at which recording started. The sender then plays some sound, noting the wall-clock time at which playback was initiated. The distance is then determined by the amount of time between the start of playback and the receiver hearing the pulse.

The speed of sound is over 300 meters per second, so 1 cm accuracy requires synchronization to within about 30 microseconds. This is very difficult to achieve, even with advanced tools like NTP, over an unreliable wireless network. Moreover, determining at what time recording or playback started is very difficult. The audio function calls typically take several millisecond to return, and recording or playback could have started at any point during that interval. Accurate timing is especially difficult on a multitasking, non-realtime operating system like the XO's Linux kernel, and even more so due when writing in a high-level language (Python) on an overtaxed, underpowered processor. On the XO, this would a be a futile approach.

Acoustic Tape Measure sidesteps the synchronization issue entirely. Instead, it uses the fact that the XO's microphone can hear the output of the XO's speaker. Therefore, the algorithm works by turning on both XO's microphones, and then having each XO play a distinctive sound. Each XO will hear its own sound almost immediately, but there will be a delay before it hears the other XO's sound, due to the propagation delay. The XO that plays a sound first will hear its sound immediately, but it will hear the second XO's sound delayed by the propagation. The XO that plays second will hear the first XO's sound delayed, but hear its own sound immediately. Therefore, the first XO will measure a longer distance between the two sounds, and the second XO will measure a shorter distance. The difference between their measurements is twice the propagation delay. In this way, Acoustic Tape Measure computes the distance between two laptops by taking the difference between two measurements of the same interval.

Development notes

In testing, accuracy was 1 cm or better at 2 m. At a distance of 10 meters, measured distance typically fluctuates no more than 1 cm, with sporadic errors up to 4 cm. However, there is likely a systematic error of a few cm, depending on temperature.

The measurements seem to be extremely accurate, under controlled conditions. In fact, accuracy seems to be limited by variation in the speed of sound with air temperature. The variation is approximately 0.2% per degree C. Code currently assumes an air temperature of 25 C, which means ± 3% over the whole range of reasonable temperatures.

Location+date+time might be enough to get temperature estimates? Is there another way?

Perhaps a known-distance measurement? Physically adjacent XO's? Could this be used as a air thermometer (Aa)ctivity? MitchellNCharity 15:45, 3 October 2007 (EDT)

Full-spectrum white noise is used to maximize accuracy.

The system only seems likely to work well when the laptops are facing each other and have uninterrupted line of sight. However, early performance testing suggests that it is more tolerant to these disturbances than initially estimated. The measurements are unlikely to work well if the distance is changing during measurement.

Each measurement cycle requires about 8 seconds.

Stability is not perfect. Typically the program runs for a few hundred measurements before hitting a networking bug. This corresponds to about 15 minutes of continuous measurement.

Now uses aplay/arecord rather than gstreamer for recording. Incorporates a delay to compensate for amplifier weirdness, bug #3813.

Ideas for use

2D Position determination

Even given full knowledge of the distances, determining the locations is a nontrivial nonlinear optimization. And the laptops have to face each other. And computation takes a long time.

Position graph matching game

The Boston Museum of Science has an exhibit which measures user distance from a computer along a long mat. The computer then horizontally scrolls a graph with a pattern, along with your current distance. Idea is you have to scurry back and forth to try and match your position to the pattern. Vaguely Digital Dance Revolution-like. I'm not really sure the concept works, but it could be easy to try, and with music added, and kids able to draw their own patterns, it might be interesting.

The algorithms would have to be greatly accelerated before something like this would be possible. Children would have to move with one laptop in hand, pointed at the stationary laptop. Also, the measurements are unlikely to work well if the distance is changing during measurement.

One possibility would be for the computer to say "go N meters away" and then have a competition to see how many tries it takes to get within, say, 5%. This could be a good distance-sense training exercise.