Can standard components do rough distance measurement?

[rowan194]

I'm wondering whether it's possible to do rough distance measurement
by interrogating a remote device via RF and measuring the amount of
time it takes to reply (subtracting the known processing time, delay
to transmit a full packet of X bytes at Y bps) using a standard RF
module and microcontroller.

In theory the unknown period less known delays, then divided by 2
should be the time it's taken for the signal to travel one way.

If the speed of light is 299,792,458 metres per second then to measure
to a resolution of (say) ~300m would require a measuring precision of
1 microsecond, or a frequency of 1MHz if it was a free running
counter; 100ns / 10MHz for 30m resolution and 10ns / 100MHz for 3m
resolution.

A 100MHz microcontroller clock speed sounds impractical, but perhaps a
compromise could be using a dedicated high speed counter that the
microcontroller can read.

2am ramblings so apologies if I'm barking up the wrong tree. Thanks
for any assistance.

 

[Andy Wood]

I'm wondering whether it's possible to do rough distance measurement
by interrogating a remote device via RF

So far so good, but you are a bit late inventing that:

http://mp2mas26.eskom.co.za/heritage/museum.htm#telluroproto

and measuring the amount of
time it takes to reply (subtracting the known processing time, delay
to transmit a full packet of X bytes at Y bps) using a standard RF
module and microcontroller.

In theory the unknown period less known delays, then divided by 2
should be the time it's taken for the signal to travel one way.

If the speed of light is 299,792,458 metres per second then to measure
to a resolution of (say) ~300m would require a measuring precision of
1 microsecond, or a frequency of 1MHz if it was a free running
counter; 100ns / 10MHz for 30m resolution and 10ns / 100MHz for 3m
resolution.

A 100MHz microcontroller clock speed sounds impractical, but perhaps a
compromise could be using a dedicated high speed counter that the
microcontroller can read.

2am ramblings so apologies if I'm barking up the wrong tree. Thanks
for any assistance.

Andy Wood
[email protected]

 

[David L. Jones]

I'm wondering whether it's possible to do rough distance measurement
by interrogating a remote device via RF and measuring the amount of
time it takes to reply (subtracting the known processing time, delay
to transmit a full packet of X bytes at Y bps) using a standard RF
module and microcontroller.

It's been done before, so is possible.

In theory the unknown period less known delays, then divided by 2
should be the time it's taken for the signal to travel one way.

If the speed of light is 299,792,458 metres per second then to measure
to a resolution of (say) ~300m would require a measuring precision of
1 microsecond, or a frequency of 1MHz if it was a free running
counter; 100ns / 10MHz for 30m resolution and 10ns / 100MHz for 3m
resolution.

Those figures sound about right.

A 100MHz microcontroller clock speed sounds impractical, but perhaps a
compromise could be using a dedicated high speed counter that the
microcontroller can read.

Many micro's have an inbuilt hardware counter that can be externally
clocked.

2am ramblings so apologies if I'm barking up the wrong tree. Thanks
for any assistance.

You are up the right tree, but it's an old tree.
GPS is used now.

Dave.

 

[rowan194]

Many micro's have an inbuilt hardware counter that can be externally
clocked.

Phwoar, at 100MHz?

You are up the right tree, but it's an old tree.
GPS is used now.

Yep, I'm well aware of GPS, but I don't want to have to rely on it.
This would be used for sanity checking of GPS data (recently while
walking I apparently travelled east by 80m then back within 2 seconds)
or as a rough backup if the GPS lock is unreliable.

Getting the timing of packet sending and processing to be consistent
is going to be the fun part.

 

[David L. Jones]

Phwoar, at 100MHz?



Yep, I'm well aware of GPS, but I don't want to have to rely on it.
This would be used for sanity checking of GPS data (recently while
walking I apparently travelled east by 80m then back within 2 seconds)
or as a rough backup if the GPS lock is unreliable.

Getting the timing of packet sending and processing to be consistent
is going to be the fun part.

How on earth do you plan to use this while walking or doing any other
activity?
You need a transmitter and the receiver. Plan to walk 10km, place your
receiver, walk back, and then start your walk again?
The "backup" for a GPS is a map and compass, and with proper compass/
topo navigation techniques it is possible to get the accuracy you
require.

Learning how to use your GPS and knowing when to believe it is
important. Trail logs allow you to see if it's telling you the truth
or not, and there are lots of tricks for getting better accuracy under
marginal conditions.

Care to explain exactly what it is you are trying to achieve here?,
because quite frankly it's sounding very silly indeed.

Dave.

 

[rowan194]

How on earth do you plan to use this while walking or doing any other
activity?
You need a transmitter and the receiver. Plan to walk 10km, place your
receiver, walk back, and then start your walk again?

The "receiver" (they're really transceivers) will be mounted on my
car, so it should be able to track correctly from the moment I move
away. Here's how it would work:

- car sends TX packet, noting the point at which the very last bit was
completed
- mobile device receives complete packet, then resends it
- car receives TX packet noting the point at which the very last bit
was received, then deducts known delay to calculate effective round
trip time.

Another idea I had was for the mobile device to receive on one
frequency and transmit on another, which literally repeats a stream of
data that the car mounted transceiver can use to calculate distance
(averaged on a per bit basis, rather than per packet). This would not
require any fancy counting of MPU cycles in order to figure out the
software delay between receiving a ping packet and retransmitting it.

The "backup" for a GPS is a map and compass, and with proper compass/
topo navigation techniques it is possible to get the accuracy you
require.

Learning how to use your GPS and knowing when to believe it is
important. Trail logs allow you to see if it's telling you the truth
or not, and there are lots of tricks for getting better accuracy under
marginal conditions.

Care to explain exactly what it is you are trying to achieve here?,
because quite frankly it's sounding very silly indeed.

As I said earlier, supplementary data for sanity checking of the GPS
output, and a rough backup for when GPS isn't functional. I should
make it clear that I want to track where I've *been* - once I get home
- not where I'm going.

 

[David L. Jones]

The "receiver" (they're really transceivers) will be mounted on my
car, so it should be able to track correctly from the moment I move
away. Here's how it would work:

- car sends TX packet, noting the point at which the very last bit was
completed
- mobile device receives complete packet, then resends it
- car receives TX packet noting the point at which the very last bit
was received, then deducts known delay to calculate effective round
trip time.

Another idea I had was for the mobile device to receive on one
frequency and transmit on another, which literally repeats a stream of
data that the car mounted transceiver can use to calculate distance
(averaged on a per bit basis, rather than per packet). This would not
require any fancy counting of MPU cycles in order to figure out the
software delay between receiving a ping packet and retransmitting it.




As I said earlier, supplementary data for sanity checking of the GPS
output, and a rough backup for when GPS isn't functional. I should
make it clear that I want to track where I've *been* - once I get home
- not where I'm going.

Forget it, you'll be wasting your time trying to turn this into a
practical working system. The devil will be in the detail, and you'll
never get it working anywhere near the accuracy of your GPS (even when
it "plays up").
Get a second GPS if you really are that worried about having a backup,
perhaps one with a different antenna system (like Helical and a SiRF
chipset). Or simply get one with an external antenna connection and
attach a better antenna onto your pack or whatever.

But like I said, learn to use your GPS properly and you'll be able to
ignore those occasional "80m jump" errors. And when you get back and
upload your track log you can simply remove those points from your
track log manually because they are really obvious. I use my (bottom
of the range patch antenna) GPS for tracking inside canyons and deep
gullies and I still am able to get very usable track logs by removing
only a couple of bogus data points. So in practice it's a trivial
problem you are trying to solve here.

Dave.

 

[Friday]

Forget it, you'll be wasting your time trying to turn this into a
practical working system. The devil will be in the detail, and you'll
never get it working anywhere near the accuracy of your GPS (even when
it "plays up").
Get a second GPS if you really are that worried about having a backup,
perhaps one with a different antenna system (like Helical and a SiRF
chipset). Or simply get one with an external antenna connection and
attach a better antenna onto your pack or whatever.

But like I said, learn to use your GPS properly and you'll be able to
ignore those occasional "80m jump" errors. And when you get back and
upload your track log you can simply remove those points from your
track log manually because they are really obvious. I use my (bottom
of the range patch antenna) GPS for tracking inside canyons and deep
gullies and I still am able to get very usable track logs by removing
only a couple of bogus data points. So in practice it's a trivial
problem you are trying to solve here.

Dave.

I have a Garmin Edge 305 GPS and it's accurate to within about two
metres, much more accurate than my old GPS72. It very rarely loses
contact with the satelites and is very stable. Cheap on eBay.

Friday