Propogation time measurement

[BeNoM]

Hello!

How can I measure a propogation time of the signal sent by zigbee tranciever?
I mean, if I send a signal from tranciever A to B, I want to measure the time the signal travels in the air from A to B. How can I do it?

Thanks,
BeNoM

[Wings]

This is interesting, and I think it's doable. I'm assuming that the poster is attempting to get some measure of distance from point A to B. If you sent a stable repetitive signal from point A to B and had device B lock its oscillator to that signal, then sent the same signal back to A in phase with the signal it had received, a fast running timer could measure the phase shift of the received signal with enough resolution to get a fairly accurate measure of the distance. It takes 10.8 uS for a radio transmission to travel 1 mile (5280 feet) and back. If your timer was running, say, at 10MHz then your resolution would be just under 50 feet. A stable oscillator at both A and B would be essential, but easily obtainable. Doing a little quick math, if the 2 oscillators were within 10ppm of each other and you completed the measurement within .01 seconds then the error caused by oscillator differences would be under 50 feet (100ns).

I don't know how much control you have over a ZigBee transceiver, but I have used a ChipCon CC1100 for a while, and it (or something like it) could be be made to pull this off. What I would do is to provide the transmitter chip with my own data (of just alternating 1s and 0s), and pump out a short stream long enough for the B transceiver to acquire a good lock on the edge of that signal and set up its timer to match that of the signal. Then transceiver B would do the same back to A, and A measures the difference in its own data clock reference to the incoming data clock edges. Beforehand I would measure the time difference at zero distance and use that measured interval as my zero distance reference, and probably go a little further and determine if there was any appreciable shift in the timing as the signal strength changed and compensate for that too in the final application.

[rocco]

Ahh . . . Now I understand.

If you are talking about distances near a kilometer, then you could indeed measure it. I was assuming you were within the 30 meter range.

I don't think the Freescale transceiver gives you enough low-level control to take the approach that Wings suggested, but I think that technique holds your best chance of success. I think the firmware turn-around time is not deterministic enough to extract a time period as small as 3 microseconds. Heck, the interrupt latency alone can be more than that.

The only suggestions I can offer require additional hardware, and aren't very practical:
1) Add GPS, which has it's own accuracy issues and adds significant costs.
2) Add additional transceiver hardware that allows you to implement Wings' phase-shift technique.
3) Ship each system with a long tape measure.

[BeNoM]

---

rocco wrote:
The only suggestions I can offer require additional hardware, and aren't very practical:
1) Add GPS, which has it's own accuracy issues and adds significant costs.
2) Add additional transceiver hardware that allows you to implement Wings' phase-shift technique.
3) Ship each system with a long tape measure.

---

The problem is that I must use a Freescale tranciever and build a star network.

---

rocco wrote:

I don't think the Freescale transceiver gives you enough low-level control to take the approach that Wings suggested, but I think that technique holds your best chance of success. I think the firmware turn-around time is not deterministic enough to extract a time period as small as 3 microseconds. Heck, the interrupt latency alone can be more than that.

---

I don't understand why do you say that the firmware is not deterministic enough if I going use

the same firmware and the same trancievers and same message/frame on A and B spots.

I will take in acount the interrupt and other effects as "parasite time".

Moreover, the firmware on A and B won't do nothing except of receiving and trancieving a frame

with "time information". 

Thanks,

BeNoM

[rocco]

---

I don't understand why do you say that the firmware is not deterministic enough if I going use the same firmware and the same trancievers and same message/frame on A and B spots.
I will take in acount the interrupt and other effects as "parasite time".

---

Hi, BeNoM:

My concern, which may be unfounded, is that the latency may not be repeatable. I don't know about the firmware you are using, but the SMAC firmware that I experimented with had interrupts blocked for various amounts of time, typically greater than a few microseconds. I would suspect that your "measurement" packets would arrive asynchronously, and therefore the response could be delayed by an arbitrary amount of time.

It's just a concern, it may not be reality.

[BeNoM]

---

rocco wrote:

My concern, which may be unfounded, is that the latency may not be repeatable. I don't know about the firmware you are using, but the SMAC firmware that I experimented with had interrupts blocked for various amounts of time, typically greater than a few microseconds. I would suspect that your "measurement" packets would arrive asynchronously, and therefore the response could be delayed by an arbitrary amount of time.

It's just a concern, it may not be reality.

---

I gonna use MC13211 (SiP) with SMAC firmware.

It's not a problem if the interrupts can block for greater than a few microseconds,

but it will be a real problem if there are "unreapetable" procedures.

Could you tell me more about SMAC and what problems you expect?

Moreover, I have to send a "stream" of data and only one frame per data "measurement".

Is it possible with the SMAC?

Thanks,

BeNoM

[rhinoceroshead]

Also, using a timer severely restricts the granularity of your distance measurements.  With a 25 Mhz timer clock, the resolution is already 12 meters.  Plus there will be +/- 12 meters of error just from having unsynchronized clocks at the transmitter and receiver.  Then there's a potential deal breaker coming from the frame protocol itself, which is bit stuffing.  Each transmitted bit has a duration on the order of microseconds - which translates to a speed-of-light distance of something in the range of 300 meters!  If your distance measuring packet is exactly the same every time except for recipient address, and your software can calculate the CRC, determine exactly how many stuff bits are there, then you could possibly account for this source of error.  But you also need to have a gaurantee that the channel is open before you attempt the measurement.  All in all, I believe the measurement will be very crude and perhaps unusable.  I think the absolute very best you could accomplish would be a very rough estimate of distance like this:

0-24 meters
12-36 meters
24-48 meters
36-60 meters
48-72 meters
60-84 meters
72-96 meters
84-108 meters

Does Zigbee even work at a range of 100 meters?  I'm guessing that in reality, the results would be twice as bad as this.  Anyway, I like Wings's method much better, but you can't do that using Zigbee equipment.  You could do it cheaply with a pair of analog transceivers and a PLL:  Get a crystal oscillator, modulate that on a frequency of your choice, demodulate at the receiver and remodulate and retransmit on a different frequency.  Then at the source you can compare the original crystal oscillator signal with the received signal using the phase discriminator from the PLL.  Low pass filter the output, scale, digitize and calibrate, and I believe you will have a much more accurate measurement.

[BeNoM]

I'm afraid of problems like "channel is closed" (tranciever uses CSMA protocol) and

it waits until the channel is clear... But I don't think the tranciever "informs" when it become clear,

so in fact I'll get the "wait time" as an error in the general calculations. Moreover, the fact that the channel may clear or not is a random variable.

Unfortunately \ Fortunately, today, I've been informed that a water acts like a "shield" for 2.4MHz frequency that ZigBee tranciever uses. In other words, water "kills" the transmition on 2.4MHz.

Because my project is itended to be able to transmit signals from the "water surface" and at wet places,

this will cause significant problems with the lost of "range".

I like the statistical method of rhino... 

Thanks,

Ben Omelchenko

[rhinoceroshead]

Yep, water readily absorbs 2.4 GHz energy - hence the microwave oven.  But I would think it would still work as long as you aren't trying to transmit through a waterfall.  The energy that strikes the water surface would certainly be absorbed, but the radio waves that are line of sight to the receiver should still propogate - unless perhaps if the antenna is really close to the water.  I don't know too many details about how many wavelengths away from the surface it would have to be in order to not be considered a ground wave...  How high off the water's surface is the transmitter?

You could easily test this, by the way.  The 802.11 wireless network card in a laptop or PDA could be placed in the position of your Zigbee receiver and you can test the distance that the 802.11 can go by monitoring the signal strength with another laptop.  Zigbee and 802.11 both use the same frequencies, generally.

[BeNoM]

What about the frequencies that less affected by the water?

I mean other ISM Bands (lees than 2.4MHZ) : 315KHZ, 433KHZ, 868KHZ, 915KHZ.

Thanks,

BeNoM

[BeNoM]

Inetresting method... but I have a laptop without a wireless card so I can't perform such test...

But, dont they have many differences except the same 2.4MHz freq. ?!

The transmiter is should be on swimmer's hand and won't use a standart

"line" anenna, however, a circular one.

I assume that, because of the interaction with the water it will cause unpredictable

differences in "range". Problem...

BeNoM

[peg]

Hmmm...

I doubted this was going to work based on the fact that you don't have direct control of the tranmitter/reciever but only telling it to "send this" and "I have this packet for you"

Now you tell us you are going to spin the antenna around in a 2 metre circle, invert it, push it 1 metre under the water and then lift it 0.5m out of the water all at a couple of Hertz.

I don't ever like to throw cold water (pun intended) on a clever idea before it gets of the ground (or into the water) but this won't be easy (or accurate) or even possible.

Regards David

[rhinoceroshead]

Ouch...  No, I don't think this is going to work.

[BeNoM]

I have a new idea about measuring the distance. (Forget for a moment about water :smileyhappy: )

Assume, I have a receiver that has constant stable range in most of the conditions.

The equation for the range is:

D = lambda / 4*pi * sqrt((Ptx * Gtx * Grx) / Prx)

D    = Distance ("range")

Ptx  = Transmit Power (Sensitivity)

Prx  = Receiver Input Power (Sensitivity)

Grx  = RX Antenna Gain

Gtx  = TX Antenna Gain

lambda = Wave Length

Now, assume that we have a tranciever with a "programmable output power" (up to 1 dBm).

In other words, we can change the the Ptx as we wish.

According to the equation if we'll change Ptx in quadratic way (Ptx = x^2) so we'll get

a Linear change in "range"!

So if we want to discover a distance between the tranciever A and B we do the following:

1. Tranciever A sends message with Ptx 1dbm (max) to tranciever B ( A writes in message what Ptx it was used to send the message + "number of message" in the sequence).

2. If Tranciever B received the message it sends to A "I was able to receive your message, try again".

Because now we know that the distance is less than assumed before.

3. Tranceiver A decreases ((x-deltaGain)^2) the Ptx and sends again to B.

4. If Tranciever B didn't received a message from A for a reasonble time, A understands

from privious message from A that it was a limit of Ptx, so if one put this Ptx in the equation

for "distance" we get the distance from A to B!

The idea could be optimized...

What do you think?

BeNoM

[Wings]

BeNom - I've had a fair amount of experience in range testing low power transceivers and can tell ya ... receive signal strength is probably the most unreliable way to determine distance. About all you can say from that is that it's 1. close, or 2. not close, or maybe even 3. far away. With the additive & subtractive reflections hitting your receive antenna the signal strength will vary all over the place. Under ideal conditions you may be able to do better than 1, 2 or 3 but from what you describe your receive signal strength is going to be changing a lot, and all the time.

What about this.... since you're in the water why not use sonar? I did a diver navigation system many years back and it had 3 transmitters along the shore spaced at around 100 meters (could have been less). The receiver, worn on the divers wrist, was a purely passive device and could tell the diver his position relative to the transmitters. To just do range you could have the swimmer's unit both Tx and Rx to the shore transceiver and do it with just one shore unit.... assuming you could deploy some kind of apparatus in the water at the shoreline. Would that work?

And Rhino, yes, my Wings handle comes from flying, not music. I started using it on American PeopleLink (300 baud modem chat) in the mid 80's and have held onto it ever since. Been flying (mostly weird aircraft) ever since I was 16. And I believe that DME uses a straight time delay from an interrogation pulse and a reply pulse.

Do you fly?

[rhinoceroshead]

'Flew' would be a better word since I haven't done it for years.  I've been meaning to get back into it.  I never flew anything fancy - just the Cessna 150, 172, and also the Piper Cherokee.  I've never done anything but VFR flying, personally, but I've been up with other pilots on top of the clouds.

I completely agree that Transmitter range would be an extremely unreliable method for measuring distance.  Especially when the receiver is moving and changing its orientation and the permeability and permittivity of the surrounding space is variable due to the water.  The antenna will never be perfectly omnidirectional either, so depending on the angle of the receiver relative to the transmitter, there will be a large amount of variability in perceived signal strength.  Then you have reflections which are sometimes additive and sometimes subtractive.  If every part of the system was static, then maybe this method would be feasible, but that is very far from reality in this case.

Using sonar, why would you need to synchronize the clocks?  The only advantage I can see to using this method would be that you would not need a transceiver on the swimmer - just a receiver.  But if you implemented a sonar transponder on the swimmer, then it wouldn't matter if the clocks were synchronized - and the accuracy would be superb since the speed of sound is so slow.  The question would be - what frequency to use?  Low frequencies would be omni-directional, which would be highly favorable, but low frequencies take too much power to produce.  Ultrasound would be more reasonable, but it is highly directional.  If it's pointed the wrong way then you wouldn't be measuring the line-of-sight distance.

[Wings]

"why would you need to synchronize the clocks?"

The receiver would have to be synced with the transmitter so it can measure the delay due to distance from the transmitter. If it wasn't in sync how would it know when a pulse was due to arrive?

That's what I was saying about using a transceiver on the swimmer - it wouldn't need syncing then. But it's a lot simpler (and cheaper) to only need a receiver on the swimmer.

The transducers I used operated at 50KHz. The transmitter had a fairly wide beam angle, like 120 degrees if memory serves. It still had an adequate amount of power even beyond the spec'ed beam angle. The receiver was omnidirectional, and although I only used it for receive it was also a fine transmitter. (It looked a lot like that "thing" in orbit talking to the whales in that old Star Trek movie.) It takes a fair amount of power to get a pulse to reach way on out there but the pulse width was so short it wasn't that big of a drain. Also, the pulses had to be sent with a long delay between pings (like 1/2 sec or so) in order for the echoes to die down, or the receiver could easily pick up an echo from something and go bananas. At least that was one of my big problems.

C'mon, BeNoM. We're waiting for you to report back.

[rhinoceroshead]

"why would you need to synchronize the clocks?"

I meant that you would not need them synchronized if you used the transponder method.  If the mobile station had no transmitter then I agree that they would need to be synchronized.  But with synchronized clocks, as you mentioned earlier, you would have to do a zero distance calibration every time, and the accuracy would constantly diminish with time as the clocks drifted.  To me, that's pretty limiting.

[BeNoM]

"BeNoM - I'm gonna bill you for bringing up such an interesting topic. " - Do you want my bank account number?

Demanded requirements:
1. The device on the swimmer have to be low powered and cheap as possible.
2. The base station must be able to discover the swimmer's distance when the swimmer presses a button on the device.
3. The device have to be small as possible because swimmers will wear it on their wrist (or leg).

An optional requirements:
1. Swimmer will be able to know his distanse from the shore.
2. The base station will be able to know at every second/minute the position of the swimmer at the sea.

To make it clear:
1. By saying "swimmer", I also mean "surfers" so the solution should be suitable for surfers too.
2. I talk about a swimmer in the sea (with or without salt).
3. The "base station" system may be expenssive and large (in dimensions).
4. Base stations will be located on the shore line (not in the water).
5. The distances between the base stations may vary but in most of the cases it's about 100 meters.

I didn't thought about sonar solution and it sounds very intersting solution to me but I have some problems with that.

The problems are:
1. Since swimmer is not a diver, most of the time he is on the surface of the water (even if he wears the bangle on the leg and not on the wrist).
2. The device won't be in the water all the time because swimmer's wrist may be out of the water for a while and then return to the water (when he surfes for instance).
3. According to requirements, on the swimmers wrist the device should be act as a transmitter or tranciever and because of sonar nature I have a limited beam angle during transmitions.
4. What about echoes from sonar transmitions? How to avoid echoe effects?

I have some questions:
1. What are the prices for sonar transmitter and receiver?
2. What companies produce sonar solutions?
3. What are the dimensions of such sonar chip?
4. For sonar transmition, do I have to ask for a license?
5. What frequencies are license free?

I thought about combining sonar and RF solutions for the case the device in the water (sonar system) and out of the water (RF) but it'll extremely increase the price for such device, something that I

should avoid.

Thanks,
BeNoM

[bigmac]

Hello,

The following considerations come to mind for the RF method -

1. It has previously been implied that the range should be of the order of one kilometre - what is the actual range requirement, and also the minimum resolution?  The base station might require an elevated antenna system for improved range, and to allow for lower transmit power at the swimmer's unit.
2. I presume that the equipment would need to communicate with more than one "swimmer" - but this has not been specifically stated.
3. To avoid complex timing synchronisation issues, the measurement portion of the transmission should use full duplex operation (simultaneous transmit and receive), rather than half duplex (simplex) operation.  It might be simpler to use "cross band" operation, with wide separation between transmit and receive frequencies.
4. Frequency or phase modulation should be used (not amplitude modulation or on/off keyed) to minimise delay variation with RF signal level.  I presume that this part of the transmission would be a square wave directly modulating the transmitter (no sub-carrier) - at the swimmer's unit there would be a direct analog connection between the demodulator of the receiver and the modulator of the transmitter.  The base station could average the received delay over many cycles of the measurement burst.
5. A transmission might consist of a data packet, followed by the measurement burst from the base station.  The data packet would determine which swimmer's unit should respond.
6. With this type of arrangement, all distance calculations would be done by the base station, therefore the swimmer's unit would also need to initiate a request for distance data to be sent by the base station.

Regards,
Mac

Message Edited by bigmac on 2006-08-07 01:48 AM

[Wings]

You mentioned shore stationS. Plural. So, you can have more than one? If so, you may be able to not only know the swimmer's range but their position as well. What about this....

2 shore stations with radio-direction finder abilities. RDF is not as complex as you may think, but its not a piece of cake either. I've seen designs using 4 antennas arranged in a square and 4 PIN diode switches ahead of the receiver. Direction is determined by switching in each of the 4 antennas in sequence at some audio rate, and the phase difference of the received audio (artificially generated by the artificially rotated antenna) relative to the antenna rotation yields direction. I think it stands a much better chance of success than either the transponder method or the phase shift method, or even sonar.

Shore station would sequentially interrogate all the swimmers in the system. Part of the interrogation packet would contain the range data (or even position) computed from the previous cycle. A swimmer responds to this interrogation with a data packet if needed, followed by a continuous carrier of some short duration. (CW because this simple RDF would have trouble if there was modulation on the carrier.) The two shore stations, linked by either wire or radio, would compute the swimmers position for readout at the shore station, continuously.

Does this method stand a chance?