SparkFun Forums

[Russel]

Does anyone make a chipset for radio range measurement?

Or something hackable to that effect?

[riden]

No, not really. There are so many factors that determine the range of a transmitted signal including frequency, obstacles between the transmitter and receiver, time of day, and even atmospheric conditions (on earth as well as the sun). For example, there are conditions where a transmitter that can reliably transmit a signal to a receiver 10 miles away may be unable to do so, but a receiver many hundreds of miles away can receive the signal.

However, it is possible to estimate the range by way of measuring the output of the transmitter (using a watt meter). You can also use a field strength meter or spectrum analyzer (a bit of an overkill) and measure the radiated signal a fixed distance from the transmitter. This has the advantage of factoring in the performance of the antenna as well.

Google on "radio propagation calculation" for more information.

[leon_heller]

There are wireless networks that can calculate the relative positions of each transceiver from the signal strength, but they are quite complex and are only experimental at the present time.

Leon

[stevech]

on a professional level, there are vendors selling products for device location tracking indoors or where GPS won't work. The two techniques they use are
1) RF Footprinting: with WiFi access points with heavily overlapping coverage, survey the building, note RSSI (signal strength) in a statistically valid manner. Henceforth, use the relative (not absolute) readings for an unknown client with this survey data and estimate location. I've tested this and it can yield about 10m accuracy in a walled office building. It doesn't do well at estimating floor number, unless you use some clever history of movement data with a wire-frame CAD drawing of the building (which some vendors do). Doesn't do well outdoors due to lack of steep attenuation gradients as is the case indoors due to walls/floors. Vulnerable to physical changes such as large furniture, changes of Access point calibrations, etc.

2) Time difference of arrival (TDOA). Exotic receivers report time of arrival of an unknown's pulsed transmission, which can be an IEEE 802.11 signal such as its beacons. Well known TDOA math principles estimate the location. Need 3+ receivers to estimate and eliminate ambiguities. Doesn't work well indoors due to multipath and outdoors, it needs near line of sight.

Some vendors
AeroScout
Wherenet
Ubisense and TimeDoman (Ultrawideband)

[Russel]

Let's add three requirements.

1. Range 100m+ (Preferably 250m+)
2. Works between mobile units
3. Requires no fixed infrastructure

I think I came across a product that does this but I've neglected to bookmark it. Price was a little horrendous ~$500 per unit.

Its quite interesting that the sort of complexity you need to do this is already implemented in a $5 gps chip. I'm sorely tempted to do just that (just use 2.4ghz instead, since I'm fairly sure they'd get upset if I actually used the gps frequency )

[Russel]

There is a similarity between the receiver in a typical zigbee radio and a GPS receiver. And it goes like this..

RF front end.
Down converter (usually to a low IF)
A/D converter

And lets stop there. At this point a GPS does it's correlation thing. And what makes that work is the sample clock driving the A/D.

If you could take a zigbee apart and use the raw A/D data you would have a timebase with which to measure time of arrival of incoming data packets (relative to the local clock).

Now, if you *could* do that all you then need to do is use the zigbee transmitter itself as the means to (separately) transmit packets used for time of flight measurement and later a packet describing the time of transmission. Again relative to the local clock of the transmitter.

You can see where this is headed. Once you've bounced a couple of packets from A to B and then back from B to A, then A can establish the relationship between its clock and B's clock. Once you have that then the distance calculation is (like it is with GPS) a matter of iteration.

Now, unfortunately, you can't get at the digital data stream and the sample clock of a zigbee receiver. Correct me if I'm wrong there btw

So, why not build a separate special purpose receiver. 2.4ghz front end. (chip suggestions, anyone?) down to a low IF. Then an A/D. build your own clock. Do a bit of DSP and you've got your distance.

I should explain, what happens here is you deliberately craft a timing packet that you transmit via the regular zigbee. Meanwhile your local, special purpose receiver picks up this packet, decodes it and establishes it's timing. Later that timing information is transmitted via a separate zigbee packet. Then you listen using your special purpose receiver for the reply timing packet from the other end and then the corresponding data packet which gives you the clock relationships.

Yes its a bit messy, and yes, it'd be nice if the zigbee people latched onto this idea and you could just read out the respective time intervals. But hey, its worth a thought

Tell me if I'm mad.

[Krogoth]

If you're going down that path, you may want to look in to software defined radio development boards - essentially they're what you just described (RF front end, down converter and very high speed A/D). And they usually have FPGAs on board, which would help immensely if you want to do TOF measurements (where a 10ns difference will give a 3 metre position error).

That only works for the receiver, so ideally you'd want a two-way system with communications on top like you suggested - imagine a Zigbee transciever not only capable of mesh networking but trilateration in dynamic 3D spaces...

[stevech]

let me beat my old drum here... "ZigBee" means the network layer protocols. IEEE 802.15.4 means the MAC and PHY layers.

ZigBee is to 802.15.4 as TCP/IP is to IEEE 802.3 (or 802.11).


----------

As to GPS equivalents, of course, the principle of GPS is that (a) the satellites transmit signals simultaneously with each having the same idea of absolute time to a super high precision - like atomic clock accuracy (b) the receiver is told where all the satellites are in 3D to high precision, (c) the receive can correlate 3 or more (typ. 12) spread spectrum codes simultaneously and find the time differences among the correlations.

This is not at all like receiving a simple 802.15.4 spread spectrum signal. All '15.4 radios use the same spreading code, unlike GPS where each satellite uses a different code (C/A mode).

[Krogoth]

Stevech, your statements on GPS requirements are true, but a Zigbee (or 802.15.4 or whatever takes your fancy) transciever has one distinct advantage over the GPS network - the ability to communicate bidirectionally.

As Russel mentioned, with an accurate enough signal clock trilateration would be as simple as bouncing packets between two radios - if both run the same algorithm, the frequency of 'bounce' will be inversely proportional to the distance between them. That way you do not require 'absolute' time (atomic clocks), only 'relative' time (measured by the crystal). Of course, that all depends on how fast you can sample your ADC - at 1MSPS you are accurate to +/- 300 metres...

[stevech]

Stevech, your statements on GPS requirements are true, but a Zigbee (or 802.15.4 or whatever takes your fancy) transciever has one distinct advantage over the GPS network - the ability to communicate bidirectionally.

As Russel mentioned, with an accurate enough signal clock trilateration would be as simple as bouncing packets between two radios - if both run the same algorithm, the frequency of 'bounce' will be inversely proportional to the distance between them. That way you do not require 'absolute' time (atomic clocks), only 'relative' time (measured by the crystal). Of course, that all depends on how fast you can sample your ADC - at 1MSPS you are accurate to +/- 300 metres...

I am skeptical that you can find a suitable signal available externally on 802.15.4 modules, and one that does not have lots of jitter due to programmable devices internally that generate such signals. What would be ideal is access to the DSSS correlator's signal, but of course, that's not possible.