topic Re: Propogation time measurement in 8-bit Microcontrollers

Propogation time measurement

BeNoM — Thu, 03 Aug 2006 21:19:30 GMT

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

Re: Propogation time measurement

rhinoceroshead — Fri, 04 Aug 2006 01:43:09 GMT

You could run the timer on A and record the counter value and then send a frame to B and make B echo it back to A. Then A can record the timer counter again, subtract from the original and then divide the result by 2.

Re: Propogation time measurement

BeNoM — Fri, 04 Aug 2006 02:16:08 GMT

The problem is that by the method you suggest, I also measure the time it takes to

a transmitter to generate the message so the time I will measure in fact is:

t = T + t1

where T is an actual time the signal travels in the air

and t1 is a time that takes to transmitter to generate the message and to receiver to decode the message,

so, t1 is a prasite time.

Moreover, the mechanism of sending a message (at least in ZigBee) waits until the "channel" is clear

so I should take this time in acount.

Do you have an idea how can I solve the problem of "parasite" time?

Re: Propogation time measurement

RedMountain — Fri, 04 Aug 2006 03:15:16 GMT

Maybe I'm really confused, but isn't that whole equation thing you're using a very crude way of attempting to derive the speed of light? The propogation time through the air will be the speed of light multiplied by the distance of transmission. This will be very very tiny compared to the actual processing time of the signal (processing individual bits after they have gone through the 802.15.4 IEEE protocol, mcu operations, etc). I'd try the method rhino suggested to figure out what sort of time it takes to transmit, recieve, process transmit recieve, and divide it by 2 to figure out a rough idea of how long a transmission and its associated minimal processing (your "parasite time") takes.

Let me know if I'm completely off track.

Now that I think about it, you could figure out exactly how long an 802.15.4 packet would take by reading the IEEE spec and finding how long it transmits per byte of information. Is that the sort of thing you're looking for? I can look it up and/or point you to that information if that indeed is what you're interested in.

Message Edited by Red Mountain on 2006-08-03 01:19 PM

Re: Propogation time measurement

rocco — Fri, 04 Aug 2006 03:27:03 GMT

Hi, BeNoM:

I'm not sure what you are trying to measure . . . or why?

If you are trying to measure the time the signal actually propagates through the air, the microcontroller's timers are not fast enough. The signal will propagate at the speed of light through air, which is about one foot per nanosecond. No microcontroller that I know about has nanosecond resolution for its timers.

Is this measurement for testing purposes or is it part of the application?

If it is for testing purposes, you could try using a fast oscilloscope. But keep in mind that the signals will need to travel through the scope-probe leads, and that time will be close to the speed through the air. The scope will have it's own internal delay, but that should be called out in the specs. You could simply subtract out the scope and lead delays.

But when all is said and done, the measurement you will get will be the speed of light through air.

Message Edited by rocco on 2006-08-03 01:28 PM

Re: Propogation time measurement

BeNoM — Fri, 04 Aug 2006 03:55:22 GMT

First, thanks for help!

You are not confused , but my target is to find an efficient and simple way to measure the distanse between 2 trancievers.

I don't have the ZigBee trancievers so I can't do the tests by myself :smileysad:

I want to derive the distance from the equestion: D = C x T.

Where C is a speed of the signal (because we don't live in vacum it won't equel exactly to

speed of light but aprox. it does).

T - is an exact time the signal travels in the air.

I don't sure, but I think that times stated in IEEE 802.15.4 for frames proccecing are only in theory

but maybe you're right, it's worth to check this out...

It's intersting to know what are aprox. values of "parasite time" we are talking about...

I thought of the next method to calculate the real average "parasite time":

By placing 2 trancievers in 2 different places we get 2 equations:

time1 = T1 + "parasite time"

time2 = T2 + "parasite time"

I assume that average "parasite time" is the same and it's make sense because we

we use the same trancievers, the same firmaware and sending the same frames.

To decrease the error one may perform number of such measurements and calculate the average

of the "parasite time".

And now, when I have the "parasite time" I can derive the exact time T that the signal travels in the air,

and from the equation L = C x T we get the axact distance between 2 trancievers...

Sounds very nice in theory...

What do you think?

Unfortunately, I don't have a ZigBee tranciever to test it by myself :smileysad:

Re: Propogation time measurement

BeNoM — Fri, 04 Aug 2006 04:13:02 GMT

Again, thanks for help.

This is the most important part of my application. I don't want involve GPS in my project.

The target is to find the distance between 2 trancievers.

According to my calcultions I get the following:

Max range I'll get from ZigBee is 1km (with low noise aplifier).

C = 300,000 km/s

T = L / C = 1km / 300,000km/s = 3.33 micro seconds

So, we are talking about of microseconds...

So a microcontroller that works on 12MHz does a "tick" every aprox 0.1 micro second.

So, at least in theory I will be able to measure the propogation time...

Re: Propogation time measurement

Wings — Fri, 04 Aug 2006 04:21:08 GMT

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.

Re: Propogation time measurement

BeNoM — Fri, 04 Aug 2006 04:50:57 GMT

Thank you Wings! You've understood what I'm trying to do...

You gave me some interesting ideas...

What is the price of Evalution Board of the chip from ChipCon?

How much trancievers it contains?

Do they have a support with examples and code?

Thank you,

BeNoM

Re: Propogation time measurement

rocco — Fri, 04 Aug 2006 04:51:20 GMT

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.

Re: Propogation time measurement

BeNoM — Fri, 04 Aug 2006 05:11:38 GMT

hhhhhh... I really don't want to choose the 3 option...

Thanks everybody for help...

Re: Propogation time measurement

BeNoM — Fri, 04 Aug 2006 05:36:32 GMT

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

Re: Propogation time measurement

Wings — Fri, 04 Aug 2006 06:09:58 GMT

If my memory serves me, you get 2 900MHz transceiver development boards for $500. Their intention is for you to connect one to one PC and the other to a 2nd PC. When I got mine I got one of the first they ever shipped, so I was plagued with many problems, mostly software issues and some chip issues. If I had that to do over again I would just invest my time in going over the data sheet a few extra times and dive right into the chip. Their development system cost me more in time than it should have. The boards are fairly easy to connect directly to your own microcontroller. The design I did uses a QG8 and a 2nd piggy-back board that contains just the transceiver chip and its magical components. If you follow their reference design it should work well - it did for me. I get over 1 mile range using just a 3-inch 1/4 wave whip under ideal conditions (the shoulder of an interstate highway, on a 12 foot pole). The chip's maximum power is 10mw and it has excellent sensitivity.

As far as example code, I don't really know. They didn't have anything I could use at the time I got into it. But now I've got my own frequency hopping spread spectrum mesh network running and I'm pleased with the results.

Re: Propogation time measurement

rocco — Fri, 04 Aug 2006 06:14:29 GMT

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.

Re: Propogation time measurement

BeNoM — Fri, 04 Aug 2006 06:35:28 GMT

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

Re: Propogation time measurement

rhinoceroshead — Sat, 05 Aug 2006 00:33:58 GMT

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.

Re: Propogation time measurement

rhinoceroshead — Sat, 05 Aug 2006 01:09:07 GMT

Oops, I see that you're using an LNA. Maybe this resolution is acceptable for you then.

One more thing - if the channel is open most of the time, you could get around the problem of variable lag times by taking very large numbers of measurements and averaging them. Hopefully the sources of random error will cancel out and you will be left with only the predictable error. In fact, taking a statistical approach, you could forget about all the error sources and lump them all into one random variable. If you make 100 measurements, you can calibrate against a known distance and statistically determine the accuracy of the instrument.

Re: Propogation time measurement

Wings — Sat, 05 Aug 2006 02:57:35 GMT

Rhino - wouldn't a 25MHz timer clock give you half that resolution? (6 meters vs 12) He would be measuring the round trip time, correct?

I kinda wish I had an application that needed this. But then again I should have never read BeNom's post - I've got other things to think about and this problem is stealing cycles from my project.

Re: Propogation time measurement

BeNoM — Sat, 05 Aug 2006 03:43:22 GMT

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

Re: Propogation time measurement

rhinoceroshead — Sat, 05 Aug 2006 04:18:37 GMT

Yeah, you're right, Wings. I should have said 6 meters. Hey - is your moniker in reference to aviation? Isn't the phase difference distance measuring method what they use in aviation for the DME instrument?

Or maybe you're a Paul McCartney fan...

As for stealing cycles in your project, couldn't you do some kind of a clock stretch? :-P