[LAU] jdelay

[Robin Gareus]

thanks, this is great! and with a morning-coffee all those hypot and
atan2 begin to look familiar... but i'm struggling to re-engineer this
for() {atan2 } loop back into an integral ;) - I need to carefully read
thru your post, probably not today..

Fons Adriaensen wrote:
> On Wed, Apr 11, 2007 at 01:44:29AM +0200, Robin Gareus wrote:
> 
>> BTW. would it be unreasonable to "fix" jdelay to work with an amp&mic ?
> 
> It will work via speaker an mic if both are linear phase (very unlikely
> for speaker) and there are no significant reflections (echos) in the signal.
> It can't be 'fixed' to work in other conditions - you need something
> different. But jdelay is meant to measure sound card latency and not
> delays in arbitrary channels.
> 

not that it had any straight forward audio apps. I was amazed how much I
could do in just 5 minutes! -

using jdelay as black-box that produces numbers. i can report success to
use it to measure distances down to cm accuracy. between a headphone and
mic. walking around in a room.

the current implementation is obviously not tailored for that, but this
old satellite-idea seems to be versatile... - Do you know who "invented"
it ?

robin



(sorry for top-posting; seemed appropriate here:)

>> Does the phase-measurement depend on electrical characteristics that get
>> "blurred" in mid-air? - Is there documentation for the algorithm used in
>> jdelay ?
> 
> That will be difficult to find. The algo used is one developed some 40
> years ago - and still used today - to measure the round-trip delay (and
> hence distance) between a satellite and a ground station.
> 
> It requires a transmission channel with a linear phase characteristic
> (same delay at all frequencies). This is easy to have on a space link.
> On the other hand it can be made to work with very weak signals and
> lots of noise, and with delays that are not constant but a function of
> time. The equipment I designed while at Alcatel will operate reliably
> with an input S/N ratio of -40 dB (yes, _minus_ forty) and will provide
> an accuracy of a few centimeters (depending on how long you measure).
> 
> The algo uses a number of tones with frequencies F0, F1, F2, ...
> and measures the phase difference between input and output for each
> of them. Let P0, P1, P2, ... be those measured phases, expressed in
> _cycles_. Let D (in seconds) be the delay we try to measure, and let
> {x}, 0 <= {x} < 1  be the fractional part of x, i.e. x - floor(x).
> The algo calculates V = D * F0, the delay expessed in cycles of F0.
> 
> Clearly we will have Pi = { D * Fi } for all i.
> 
> V = P0 
> 
> This is the first estimate. The accuracy depends only on how good
> the phase measurement is done, but it is of course ambiguous if the
> delay can be more than one cycle. 
> 
> The other tones will be used to resolve this ambiguity. We select
> F1 so that
> 
> gcd (F0, F1) = F1 / 8.
> 
> Now consider the value N1 = 8 * P1 - P0. This will be an integer
> in the range 0 to 7, plus some fraction due to meassurement error.
> So we set
> 
> V = V + round (N1)
> 
> If the delay can be longer than 8 cycles of F0 then this is still
> ambiguous. We select F2 so that
> 
> gcd (F0, F2) = F1 / 64.
> 
> Now consider N2 = 8 * P2 - P1. Again this will be an integer in
> the range 0...7 plus some measurement error. So we set 
> 
> V = V + 8 * round (N2)
> 
> We now have a measurement range of 64 cycles of F0. The other
> tones are used in the same way to multiply this range by 8 for
> each tone used. until the ambiguity-free range is large enough.
> 
> In jdelay F0 is Fsample / 8. The '??' are printed when the distance
> between Ni and the nearest integer is more than 0.2, which indicates
> that the signal is not reliable.
> 
> 

Fons Adriaensen wrote:
> On Wed, Apr 11, 2007 at 01:27:27PM +0200, Fons Adriaensen wrote:
>
> some typos...
>
>> gcd (F0, F1) = F1 / 8.
>> gcd (F0, F2) = F1 / 64.
>
> should be:
>
> gcd (F0, F1) = F0 / 8.
> gcd (F0, F2) = F0 / 64.
>
>