Propogation time measurement

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, BeNoM:
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".
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
'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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
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.
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.
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?
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?
BeNoM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
The following considerations come to mind for the RF method -
- 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.
- I presume that the equipment would need to communicate with more than one "swimmer" - but this has not been specifically stated.
- 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.
- 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.
- 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.
- 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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
