Low power distance detection

[ziggyfish]

I am looking for some possible solutions to detect how far a transmitter is away from a reciver. my current thoughts are to have a counter that increments at 300 mhz (1 meter wave length) which is sync'd with both transmitter and receiver. i than transmit this number. The receiver than takes its current number and compares it with the received number to calculate the distance.

The advantage of this approach is that the transmitter can be in a ultra low power mode for much longer (thus saving on battery life).

My question is can you see a problem with this solution? If not can you recommend an IC to implement the 300 mhz counter?

 

[(*steve*)]

What distances are you contemplating?

Bluetooth 4 implements a tour of distance measurement based on signal strength. There are many devices exploiting it to help you find your keys etc.

It's pretty unreliable in determining an exact distance but it may do what you're after if you just want to know if something is nearby.

 

[(*steve*)]

Oh, your technique will work if you can fit an atomic clock at both ends of the link. It may not be exactly "low power" though.

 

[AnalogKid]

At 300 MHz, one cycle is 3 ns. The time it takes for chips to decode a number and compare it to anything will be what, 100 times that - and not constant - only if it is all done in random logic (no processor). I suppose you could take a snapshot of the local counter and external signal and then process them offline, but even then I think propagation delay variations in the chips will swamp the timing information you are trying to extract.

Also, as pointed out above, "its current number" would have to be maintained inside the receiver to within a fraction of 3 ns in order for 3 ns ticks to mean something. That is Stratum III level stability, which is what a Rubidium Standard is good for. The one I used in a MIL radio project is 2"x3"x4", has a 50 W heater for the physics package, and cost $1500. There is a cute new vdevice based on a vertical cavity laser that draws under 1 W and is tiny, but it is less accurate and the same $1500.

ak

 

[ziggyfish]

Oh, your technique will work if you can fit an atomic clock at both ends of the link. It may not be exactly "low power" though.

GPS only has an atomic clock on one side of the link (i.e the satellite) and works very similar to the way I am suggesting in my OP.

What I am trying to implement is a ground-based GPS (after researching more last night).

 

[ziggyfish]

At 300 MHz, one cycle is 3 ns. The time it takes for chips to decode a number and compare it to anything will be what, 100 times that - and not constant - only if it is all done in random logic (no processor). I suppose you could take a snapshot of the local counter and external signal and then process them offline, but even then I think propagation delay variations in the chips will swamp the timing information you are trying to extract.

Also, as pointed out above, "its current number" would have to be maintained inside the receiver to within a fraction of 3 ns in order for 3 ns ticks to mean something. That is Stratum III level stability, which is what a Rubidium Standard is good for. The one I used in a MIL radio project is 2"x3"x4", has a 50 W heater for the physics package, and cost $1500. There is a cute new device based on a vertical cavity laser that draws under 1 W and is tiny, but it is less accurate and the same $1500.

ak

The chip I was planning on using is the AX8052F143 at the 915 MHz frequency.

I agree, you do have a lot of corrections that need to be applied, such as the time it takes to send the 102 bits of information needed (80 headers + 32-bit number), or the time it takes for the receiver to read and store its current number (although using a Raspberry Pi with 1.2 Ghz CPU, it's not that much of a problem).

 

[ziggyfish]

Anyway thanks for your replies, it seems I need to rethink how I am going to do this.

 

[(*steve*)]

GPS only has an atomic clock on one side of the link (i.e the satellite) and works very similar to the way I am suggesting in my OP.

Yeah, the advantage of GPS over your proposed method is that accurate clocks are not required at the receiver end.

 

[AnalogKid]

GPS only has an atomic clock on one side of the link (i.e the satellite) and works very similar to the way I am suggesting in my OP.

No, it doesn't. GPS requires reception of independent signals from at least *three* atomic clocks, plus a butt-load of computation. Since the receiver does not have a reference, the only thing it can do with a single signal is tell you the time of day. It takes the triangulation of three signals to determine location, and if you log the data continuously you can calculate movement distance. What you are suggesting is distance as a function of propagation delay using only one transmitter and one receiver for a simple straight-line calculation. Nothing wrong in theory, but that delay has to be with respect to some kind of time mark. No matter how or why, a distance calculation *always* needs two numbers of some kind, and one receiver listening to one transmitter gets you only one number.

ak

 

[hevans1944]

My question is can you see a problem with this solution?

Lots of problems. First one is this: how do you maintain synchronism between the transmitter oscillator and the receiver oscillator that is doing the counting? Others have made reference to an atomic clock (rubidium or cesium or whatever) and that would work for awhile until the two clocks drifted apart by a few microseconds. You need a common reference that is "seen" at the same time by both the transmitter and the receiver. Perhaps the "easiest" way to do this is with a GPS receiver that both the transmitter and the receiver can lock onto. There are many examples of using the GPS signal to obtain a synchronizing signal for an already stable voltage-controlled crystal oscillator. The transmitter would have to send its signal at a precise, agreed on, instant in time and the receiver would then measure the propagation delay from that instant to when it received the transmitter signal. This is true no matter what the transmitter frequency is. It is the speed of light that determines the delay based on distance from transmitter to receiver... plus or minus any errors caused by anything (other than vacuum) between the transmitter and receiver.

Anyway thanks for your replies, it seems I need to rethink how I am going to do this.

Yes, please do. And come back here with questions. It would not be easy to phase-lock an internal clock in the transmitter to a GPS signal and thereby very accurately "set" an internal transmitter clock. An independent receiver would have to do the same thing, so both transmitter and receiver were working from the same identical reference "clock". One this is done, the transmitter can transmit a message saying (for example) this transmission will began at tu:vw:xy.z0000000 UTC. The receiver compares their local time at the instant it receives the transmission to determine the one-way time-of-flight.

 

[davenn]

It would not be easy to phase-lock an internal clock in the transmitter to a GPS signal and thereby very accurately "set" an internal transmitter clock.

GPS disciplined oscillators is the least of the problem, Us amateur radio operators use GPS disciplined 10MHz reference oscillators often for working
in the microwave bands. it keeps TX and RX frequencies accurate ie .... stopping freq drift due to temperature being the main use ....

http://www.qsl.net/zl1bpu/MICRO/SIMPLE/SimpleGPS.htm

http://www.trimble.com/timing/thunderbolt-e.aspx

http://vk4ghz.com/wordpress/wp-content/uploads/10MHz-GPS-Disciplined-Oscillator.pdf

http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm ----- I have personally build and used

I have also used a 10MHz rubidium standard available off eBay ... for voice and data comms they are great

the highly accurate timing of signals is still the major problem


Dave

 

[hevans1944]

the highly accurate timing of signals is still the major problem

Yep. Without a co-operative signal returning to the transmitter (think RADAR), distance measurement is very difficult. Heck, GPS is basically just a distance measurement between a very accurate clock in three (or more) transmitters and a passive but intelligent receiver.

 

[ziggyfish]

Yep. Without a co-operative signal returning to the transmitter (think RADAR), distance measurement is very difficult. Heck, GPS is basically just a distance measurement between a very accurate clock in three (or more) transmitters and a passive but intelligent receiver.

Could i use a carrier signal as a the clock source? i.e count the rising edges of the signwaves. this would keep both devices sync. the only problem would be to sync the time to begin with.

If both devices know the time its being sent. To work out the distance it would simply be a matter of counting the rising edges. (You could increase the accuracy, by counting the falling exges as well).

The reason i want to avoid a cooperative solution is that you could have thousands of these devices in one location. And there isn't enough bandwidth to support that amount of traffic. its like if you were at a football game and everyone one had a tracker on them.

 

[(*steve*)]

Could i use a carrier signal as a the clock source? i.e count the rising edges of the signwaves. this would keep both devices sync. the only problem would be to sync the time to begin with

The problem is that drift in the clocks would be indistinguishable from them moving with respect to each other.

Also, if you have many of these devices, you're far better off having a few independent transmitters than each one of these devices transmitting to each other.

In theory, if you have three transmitters on the edge of your field, each transmitting the same signal (i.e. clocked from the same source) then you could look at the phase differences between them to determine your position. Practicality may be an issue.

 

[BobK]

If both objects have a transceiver, you could send a signal from one and have the other respond with a known built in delay. When the original transmitter receives that response signal, it has a time difference that is that known delay + twice the distance x the speed of light. No synchronization required.

Bob

 

[ziggyfish]

The problem is that drift in the clocks would be indistinguishable from them moving with respect to each other.

Maybe I should explain the theory of operation a bit better. So the transmitter has a number n (the number could represent time, or in this case the number of rising edges). While the transmitter is transmitting its carrier wave it increments n every time it has a rising edge. This would is the "clock" for the transmitter.

When the receiver receives the signal, it also increments its number n on the rising edges. Thus the number n is always in sync with each other.

The transmitter would then change the carrier in some unique fashion (either by changing its amplitude or frequency) when n is divisible by X. As both numbers are in sync with each other, the distance is the number of rising edges between when n was divisible by X and when the receiver received the signal, multiplied by the wavelength i.e.

Distance = dn * λ

This way the only drift that would occur is between when syncing.

Also, if you have many of these devices, you're far better off having a few independent transmitters than each one of these devices transmitting to each other.

My plan is to have 3-4 fixed transmitters, which I know the exact position of.

In theory, if you have three transmitters on the edge of your field, each transmitting the same signal (i.e. clocked from the same source) then you could look at the phase differences between them to determine your position. Practicality may be an issue.

This would only work if the frequency was low enough, for the wavelength to be long enough to calculate the required distances. i.e I would need a frequency of around 100 kHz (3km wavelength) which would mean I need quite a large antenna. So yeah even if I could work out the phase shift, it would only work for small distances.

 

[ziggyfish]

If both objects have a transceiver, you could send a signal from one and have the other respond with a known built-in delay. When the original transmitter receives that response signal, it has a time difference that is that known delay + twice the distance x the speed of light. No synchronisation required.

Bob

That's my backup plan if this doesn't work.

 

[(*steve*)]

Much of your theory is wrong. Especially that part concerning the effect of frequency drift and the required wavelength. I'll expand later when I'm not on a phone.

 

[ziggyfish]

Much of your theory is wrong. Especially that part concerning the effect of frequency drift and the required wavelength. I'll expand later when I'm not on a phone.

Please do, I would be interested in how I am wrong, and how I can solve those problems.

Although there is going to be frequency drift, it will be within spec of my intended accuracy (i.e within 1 meter). To elaborate a bit further, let's say the real frequency it transmits at is 900 Mhz rather than 915 Mhz. And it takes 1000 rising edges to reach its destination, then:

Calculated distance (based on 915 MHz):
Distance = dn * λ = 1000 * 327.86885245901635 mm = 32786, or 32.78 meters.

Actual distance (based on 900 MHz):
Distance = dn * λ = 1000 * 333.3333333333333 mm = 33333, or 33.33 meters.

Because I am essentially frequency counting, I can update the frequency that I divide by on the fly to correct for any frequency drift.

In terms of Phase Shift, I didn't think you can detect shifts of more than 360 deg. Maybe I am wrong.

 

[(*steve*)]

A 1MHz difference in clock speeds at 900MHz is indistinguishable from a relative velocity of about a million kilometres per hour. Of course that velocity is unlikely, but even tiny changes in frequency can introduce huge errors.

How will you know it takes 1000 rising edges to reach the destination? If your common clock is the oscillators running at different speeds you cannot agree on any form of simultaneity that you require to determine the one way duration of a signal.

Let's assume you are able to synchronise your clocks. If they differ by 1MHz, then there will be an accumulated error of 1000 counts per millisecond.

If you're expecting a path duration of 1000 counts and you want an error of less than 10%, then you need to synchronise the clocks 10,000 times per second!