Talk:Acoustic Tape Measure: Difference between revisions

From OLPC
Jump to navigation Jump to search
(More ideas)
 
(11 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== Question about this activity from Peru ==
Hi Guys,

Looks like they tried to use this activity in a class in Peru. They ran in to problems when 6 groups of 2 students each tried to use it. See: http://wiki.laptop.org/go/Lambayeque#Inconvenientes

Have you tried this with more than two pairs of XOs at the same time?

You have school interested and ready to give real world feedback if we can resolve their issue.

Thanks,

[[User:Gregorio|Gregorio]] 15:35, 8 May 2008 (EDT)

: I am the author of this activity. As I speculated on the development mailing list, I believe this may be a manifestation of bug #6463. Distance uses stream tubes, which are based on a TCP connection, and it appears that there is a problem with TCP connections on mesh networks. There is an additional problem that multiple simultaneous pairs in one room are likely to give wrong answers (there's no magic to keep sound from being heard by all listeners), but this does not seem to be what they are referring to. [[User:Bemasc|Ben]] 16:42, 11 May 2008 (EDT)

==Some ideas==
==Some ideas==


Line 9: Line 24:


idea 2: Have one computer broadcast a continuous square wave, and the other one just count beats (using some reasonable assumptions about possible accelerations to throw away bad data). This would tend to get progressively out-of-sync, but it would be fully real-time. Maybe have an intermittent transient to resync...
idea 2: Have one computer broadcast a continuous square wave, and the other one just count beats (using some reasonable assumptions about possible accelerations to throw away bad data). This would tend to get progressively out-of-sync, but it would be fully real-time. Maybe have an intermittent transient to resync...
:What you're describing sounds a lot like a Phase-Locked Loop. Something like that might indeed be able to measure velocity. Why do we want to measure velocity of laptops? Sounds like a great way to trip and break your most valuable possession. [[User:Bemasc|Ben]] 18:29, 15 October 2007 (EDT)


The point is, doing a whole deconvolve or whatever to match a known sound is computationally much heavier than just binning against a known frequency - sine or square, either way it's even easier than an FFT.
The point is, doing a whole deconvolve or whatever to match a known sound is computationally much heavier than just binning against a known frequency - sine or square, either way it's even easier than an FFT.
Line 19: Line 35:


ps. speed of sound depends on altitude as well as temperature. I think that asking people to guess the temperature is more accurate AND educational than just guessing it using time/location.
ps. speed of sound depends on altitude as well as temperature. I think that asking people to guess the temperature is more accurate AND educational than just guessing it using time/location.

:That was my first thought as well, but it is wrong. Except to the extent that air is not an ideal gas, the speed of sound does not depend on altitude. We often say that it does, but that's mostly because high-altitude air is cold. Humidity has a bigger effect, but you can ignore that too. Temperature is what matters. See wikipedia for the numbers and math. [[User:AlbertCahalan|AlbertCahalan]] 22:40, 6 October 2007 (EDT)

::OK, my bad. But about my other points:
::1. I was thinking further about ideal waveforms - you want something with well-understood shortcut algorithms to recognize it in spite of noise, and the algorithms should be very specific in the time domain. FFT and friends are good algorithms, but they are particularly bad at time distinctions. It's been ages since I "studied" this stuff (and I never understood it any better than I had to to make my HS math teacher believe I was doing my independent study), but, have you thought about wavelets?

:::He's using phase angle of a non-repeating noise AFAIK, so I think things are fine in that respect. Audio chips with different speed clocks would get him, as would any motion. [[User:AlbertCahalan|AlbertCahalan]] 12:41, 13 October 2007 (EDT)

::2. I still think that a human guess at temperature - that is, if you don't have a dongle for use with the "measure" activity - is the best, and most educational, answer. Using the stereo speakers, aren't you going to have problems because of the speed of sound in the laptop plastic? (problems that are avoided if the laptops are more-or-less facing each other head-on). [[User:Homunq|Homunq]] 08:01, 13 October 2007 (EDT)

:::As long as the speed of sound in the plastic is significantly different from the speed of sound in air, the sound arriving through the plastic can be ignored. (take the first peak or second peak, whichever one is the air) [[User:AlbertCahalan|AlbertCahalan]] 12:41, 13 October 2007 (EDT)

::: I find this idea intriguing. Maybe there should be some option to input air temperature and relative humidity, possibly hidden in an "Advanced Settings" tab. I've been trying to figure out how to provide the simplest possible interface, but that might not be a bad compromise. It might also provide an educational benefit: punch in the air temperature and humidity, and it tells you the speed of sound. [[User:Bemasc|Ben]] 18:29, 15 October 2007 (EDT)
:::: Done. [[User:Bemasc|Ben]] 00:46, 15 January 2008 (EST)


==More ideas==
==More ideas==
Line 24: Line 54:
You have 2 speakers. That can pretty much let you determine angle, given a few minor assumptions about a flat world and similar. Maybe you place the laptops on hyperbolas.
You have 2 speakers. That can pretty much let you determine angle, given a few minor assumptions about a flat world and similar. Maybe you place the laptops on hyperbolas.


:With two laptops, it's not clear that we can really talk about placing the laptops on hyperbolas. However, it is true that, in principle, one could determine the angle at which they face each other. The measurement would not be terribly accurate, and it would at least double the amount of time required for a measurement. It might be possible, but I haven't seen a reason to do it. [[User:Bemasc|Ben]] 18:12, 15 October 2007 (EDT)
The speakers are a known distance from each other. With stereo, you can get the speaker-to-speaker distance. (they share the same start-up lag) From the error, compute temperature.

The speakers are a known distance from each other. With stereo, you can get the speaker-to-speaker distance. (they share the same start-up lag) From the error, compute temperature. [[User:AlbertCahalan|AlbertCahalan]] 04:31, 6 October 2007 (EDT)

:This might be possible. The first problem is acoustics: because the speaker and microphone are both somewhat directional, an appropriately placed object might provide a stronger path than the direct path through the air over the screen. Additionally, to achieve even 5 degree C accuracy, the distance must be known and measured to better than 1% accuracy. The speakers are less than 20 cm apart, so we are talking about 2 mm of position accuracy. Even if the speaker placement is that precise, 48 KHz samples are spaced 7.5 mm apart in air. Thus, an extremely accurate sub-sample positioning measurement algorithm is required. This may also be possible (and I am looking into it) but it is edging into the realm of algorithms research. To get 1 degree C requires sub-mm speaker placement and 20x superresolution in the positioning. [[User:Bemasc|Ben]] 18:12, 15 October 2007 (EDT)

::Never mind 1 degree C. The air temperature range is something like -15 to 65. A mid-range hard-coded temperature could be wrong by 40 degrees C. [[User:24.110.145.202|24.110.145.202]] 00:12, 16 October 2007 (EDT)

::Pick the lowest measurement that is a definite peak and not in the range of measurements that are known to be plastic. In case the path is not a simple line, a correction factor may be desirable. [[User:24.110.145.202|24.110.145.202]] 00:12, 16 October 2007 (EDT)

==Setting the correct parameters==
The program should be able to accept certain input. It should be possible to aceept input like temperature and altitude. Depending on the given input it should be possible to make a more correct measurement.

If the user is unable to measure the temperature there should be some questions which give a hint what approximate temperature is given in that moment. The questions should be based on every day experience that everybody can make. An example: "Is your breath freezing if you breathe out?".

Another possibility could be to give instructions for an experiment e.g.
:1) "How old are you?"
:2) "Take a water glass, fill it with water as high as your little finger is (finger length depends on age), deposit it, until it is freezed. How long does it take until the water has been freezed?" (time to freeze can be measured by the XO).

In hot regions the program should ask "How long does it take until the water in the glass has been evaporated?"

Based on the resulting information the program can calculate a certain temperature range.

The altitude
:1) can be measured by another easy experiment or
:2) there should be a list for all towns that includes the town's altitude.

The barometric pressure can be measured by asking some question on special cloud formations or questions like "Is today a typical summer day?". (I know that these questions must be based on local information, but it should be possible to implement such questions).

Eventually it is possible to implement some country sayings to determine more or less accurate temperature or barometric pressure. I suppose that some rangers or boy scouts know some more tricks to find out temperature and barometric pressure.

[[User:89.56.49.220|89.56.49.220]] 12:29, 23 December 2007 (EST)

== Mistake in measurement algorithm description? ==

I think there is a mistake in the Measurement Algorithm section.

It says "The difference between their measurements is twice the propagation delay"


I think it should read "The '''sum of''' their measurements is twice the propagation delay"
[[User:AlbertCahalan|AlbertCahalan]] 04:31, 6 October 2007 (EDT)
<br />
Consider:<br />
X = first transmit time<br />
E = delay between first transmit and second transmit<br />
D = propagation delay<br />
<br />
XO A hears:<br />
First tone: X<br />
Second tone: X+D+E<br />
<br />
Difference: (X+D+E)-X = D+E<br />
<br />
<br />
XO B hears:<br />
First tone: X+E<br />
Second tone: X+D<br />
<br />
Difference: (X+D)-(X+E) = D-E<br />
<br />
Summing the two: (D+E)+(D-E) = 2*D<br />
<br />
The difference between the two measurements is the delay between the two XOs transmitting

Latest revision as of 23:51, 13 November 2011

Question about this activity from Peru

Hi Guys,

Looks like they tried to use this activity in a class in Peru. They ran in to problems when 6 groups of 2 students each tried to use it. See: http://wiki.laptop.org/go/Lambayeque#Inconvenientes

Have you tried this with more than two pairs of XOs at the same time?

You have school interested and ready to give real world feedback if we can resolve their issue.

Thanks,

Gregorio 15:35, 8 May 2008 (EDT)

I am the author of this activity. As I speculated on the development mailing list, I believe this may be a manifestation of bug #6463. Distance uses stream tubes, which are based on a TCP connection, and it appears that there is a problem with TCP connections on mesh networks. There is an additional problem that multiple simultaneous pairs in one room are likely to give wrong answers (there's no magic to keep sound from being heard by all listeners), but this does not seem to be what they are referring to. Ben 16:42, 11 May 2008 (EDT)

Some ideas

Measure velocity using doppler?

For something like the "dance revolution graph" activity - maybe you could take some shortcuts.

idea 1: Have one computer broadcast an intermittent square wave at a given frequency. I understand that the result would lack some high harmonics necessary for a true square wave - but I bet it would be good enough to make the calculation of when the thing starts pretty simple. Certainly less robust than full-spectrum white noise, but probably good enough after an initial calibration against white noise.

idea 2: Have one computer broadcast a continuous square wave, and the other one just count beats (using some reasonable assumptions about possible accelerations to throw away bad data). This would tend to get progressively out-of-sync, but it would be fully real-time. Maybe have an intermittent transient to resync...

What you're describing sounds a lot like a Phase-Locked Loop. Something like that might indeed be able to measure velocity. Why do we want to measure velocity of laptops? Sounds like a great way to trip and break your most valuable possession. Ben 18:29, 15 October 2007 (EDT)

The point is, doing a whole deconvolve or whatever to match a known sound is computationally much heavier than just binning against a known frequency - sine or square, either way it's even easier than an FFT.

I actually imagine that maybe you could find some good algorithms in use in GPS recievers for electromagnetic stuff - the problem is similar.

(I know - everyone can kibbutz, few will code.)

--Homunq 16:46, 5 October 2007 (EDT)

ps. speed of sound depends on altitude as well as temperature. I think that asking people to guess the temperature is more accurate AND educational than just guessing it using time/location.

That was my first thought as well, but it is wrong. Except to the extent that air is not an ideal gas, the speed of sound does not depend on altitude. We often say that it does, but that's mostly because high-altitude air is cold. Humidity has a bigger effect, but you can ignore that too. Temperature is what matters. See wikipedia for the numbers and math. AlbertCahalan 22:40, 6 October 2007 (EDT)
OK, my bad. But about my other points:
1. I was thinking further about ideal waveforms - you want something with well-understood shortcut algorithms to recognize it in spite of noise, and the algorithms should be very specific in the time domain. FFT and friends are good algorithms, but they are particularly bad at time distinctions. It's been ages since I "studied" this stuff (and I never understood it any better than I had to to make my HS math teacher believe I was doing my independent study), but, have you thought about wavelets?
He's using phase angle of a non-repeating noise AFAIK, so I think things are fine in that respect. Audio chips with different speed clocks would get him, as would any motion. AlbertCahalan 12:41, 13 October 2007 (EDT)
2. I still think that a human guess at temperature - that is, if you don't have a dongle for use with the "measure" activity - is the best, and most educational, answer. Using the stereo speakers, aren't you going to have problems because of the speed of sound in the laptop plastic? (problems that are avoided if the laptops are more-or-less facing each other head-on). Homunq 08:01, 13 October 2007 (EDT)
As long as the speed of sound in the plastic is significantly different from the speed of sound in air, the sound arriving through the plastic can be ignored. (take the first peak or second peak, whichever one is the air) AlbertCahalan 12:41, 13 October 2007 (EDT)
I find this idea intriguing. Maybe there should be some option to input air temperature and relative humidity, possibly hidden in an "Advanced Settings" tab. I've been trying to figure out how to provide the simplest possible interface, but that might not be a bad compromise. It might also provide an educational benefit: punch in the air temperature and humidity, and it tells you the speed of sound. Ben 18:29, 15 October 2007 (EDT)
Done. Ben 00:46, 15 January 2008 (EST)

More ideas

You have 2 speakers. That can pretty much let you determine angle, given a few minor assumptions about a flat world and similar. Maybe you place the laptops on hyperbolas.

With two laptops, it's not clear that we can really talk about placing the laptops on hyperbolas. However, it is true that, in principle, one could determine the angle at which they face each other. The measurement would not be terribly accurate, and it would at least double the amount of time required for a measurement. It might be possible, but I haven't seen a reason to do it. Ben 18:12, 15 October 2007 (EDT)

The speakers are a known distance from each other. With stereo, you can get the speaker-to-speaker distance. (they share the same start-up lag) From the error, compute temperature. AlbertCahalan 04:31, 6 October 2007 (EDT)

This might be possible. The first problem is acoustics: because the speaker and microphone are both somewhat directional, an appropriately placed object might provide a stronger path than the direct path through the air over the screen. Additionally, to achieve even 5 degree C accuracy, the distance must be known and measured to better than 1% accuracy. The speakers are less than 20 cm apart, so we are talking about 2 mm of position accuracy. Even if the speaker placement is that precise, 48 KHz samples are spaced 7.5 mm apart in air. Thus, an extremely accurate sub-sample positioning measurement algorithm is required. This may also be possible (and I am looking into it) but it is edging into the realm of algorithms research. To get 1 degree C requires sub-mm speaker placement and 20x superresolution in the positioning. Ben 18:12, 15 October 2007 (EDT)
Never mind 1 degree C. The air temperature range is something like -15 to 65. A mid-range hard-coded temperature could be wrong by 40 degrees C. 24.110.145.202 00:12, 16 October 2007 (EDT)
Pick the lowest measurement that is a definite peak and not in the range of measurements that are known to be plastic. In case the path is not a simple line, a correction factor may be desirable. 24.110.145.202 00:12, 16 October 2007 (EDT)

Setting the correct parameters

The program should be able to accept certain input. It should be possible to aceept input like temperature and altitude. Depending on the given input it should be possible to make a more correct measurement.

If the user is unable to measure the temperature there should be some questions which give a hint what approximate temperature is given in that moment. The questions should be based on every day experience that everybody can make. An example: "Is your breath freezing if you breathe out?".

Another possibility could be to give instructions for an experiment e.g.

1) "How old are you?"
2) "Take a water glass, fill it with water as high as your little finger is (finger length depends on age), deposit it, until it is freezed. How long does it take until the water has been freezed?" (time to freeze can be measured by the XO).

In hot regions the program should ask "How long does it take until the water in the glass has been evaporated?"

Based on the resulting information the program can calculate a certain temperature range.

The altitude

1) can be measured by another easy experiment or
2) there should be a list for all towns that includes the town's altitude.

The barometric pressure can be measured by asking some question on special cloud formations or questions like "Is today a typical summer day?". (I know that these questions must be based on local information, but it should be possible to implement such questions).

Eventually it is possible to implement some country sayings to determine more or less accurate temperature or barometric pressure. I suppose that some rangers or boy scouts know some more tricks to find out temperature and barometric pressure.

89.56.49.220 12:29, 23 December 2007 (EST)

Mistake in measurement algorithm description?

I think there is a mistake in the Measurement Algorithm section.

It says "The difference between their measurements is twice the propagation delay"

I think it should read "The sum of their measurements is twice the propagation delay"
Consider:
X = first transmit time
E = delay between first transmit and second transmit
D = propagation delay

XO A hears:
First tone: X
Second tone: X+D+E

Difference: (X+D+E)-X = D+E


XO B hears:
First tone: X+E
Second tone: X+D

Difference: (X+D)-(X+E) = D-E

Summing the two: (D+E)+(D-E) = 2*D

The difference between the two measurements is the delay between the two XOs transmitting