TI's RSSI vs TOF

Adam,

I find the wording very curious...

Siew Heng, Adam Ngern said:

The JN5148 provides the ability for an application to obtain the Time Of Flight (TOF) between two network nodes.

Providing the ability and actually implementing it are two very different things.  The problem with TOF is you need to have a coherent clock between the two systems.  If you cannot run a wire then you need to do something else.

I have been working with SimpliciTI to generate a network wide PLL application for the upcoming release of FHSS but it doesn't have the accuracy to manage coherency for TOF calculations.  Partly because I do not utilize the hardware to detect the frame so there is much more sample jitter in the algorithm than needs to be.  For the FHSS this is acceptable but for TOF it is not.

That said, our radios have the ability to generate an event when the sync word is found and this can be used to trigger a capture on a timer or other mechanism.  Thus, our radios also provide "The ability for an application to obtain the Time Of Flight", it's just a SMOP (small matter of programming).  Just as it is with the JN5148 part.

Jim Noxon

Hi Jim

Thank you for the reply.

So you mean that TOF is just merly a software thingy that can also be done on our CC2530?

Is there any apps notes on a discussion on this?

Thank you!

Adam

Yes, it is a software thingy and the CC2530 is capable of it.

I took a closer look at the NEC part and sure enough there is no other mention of how to implement TOF so all I can assume is they have a similar hardware event that can be used to capture a timer or cause a DMA to do the same.  I couldn't find any particular register in the radio peripheral to support any finer resolution solutions.

I didn't take the time to search the NEC website to see if they have any code to actually implement TOF.  I know of no such code to offer from TI so if NEC has this code then you may have to overcome our shortcoming in that regard.

One alternative to accomplishing this without a coherent clock would be to use time stamp information on a round trip packet where the return packet is the autoacknowledge packet.  The 802.15.4 spec requires this packet be returned in a specified number of bit periods and should be pretty deterministic for our radios.  Note that you get about 30cm of travel for every nano second but since you will be measuring the distance there and back, the resolution is 15cm per nano second.  The fastest the clock can count in the CC253x parts is 32MHz so on clock period is 31.25ns which translates to a resolution of around 4.7 meters.  You can do better by averaging over the noise and most likely that will be required anyway to get consistent results.  At least that's the theory you can present to them.

Jim Noxon

Please note that the accuracy for the time capture of received frames in CC2530 is not limited by the resolution of Timer 2, but on the internal operation of the modem. The theoretical resolution there is 125 ns, giving an error of +/-62.5 ns. In practice the error may be somewhat larger due to noise on the received signal.

By hec's response, this will push your resoluton out to 9.4 meters.

Jim Noxon

Hi Jim,

Thank you for the reply.

From the calculations you gave, means that our device is good up to about 10Meters?

what is the resolution like beyond 10 meters?

With regards to TOF, how can we improve our resolution beyond 10 Meters without using extender?

Thank you so much!

Adam

For TOF, resolution is a constant.  This is because the resolution is dependent upon the sampling period which measures the TOF.  Thus, for a single sample, you will have a resolution of about 10 meters regardless of how far away the other node is.  With RSSI, because the resolution gets logarithmically worse with distance, close in measurements may be better but as soon as the resolution of the RSSI gets to be less than the TOF method, TOF will be better.

The only way to increase your accuracy with a fixed sampling period is to average over multiple samples.  Note that this depends upon two things.  1) there is enough noise in the measurement that you don't get the same value for each sample, and 2) you have the time and energy to make multiple samples.

Having enough noise in the system is effectively using the noise as a dithering mechanism.  If we assume it to be relatively random, then averaging samples will provide greater accuracy.  Note that accuracy improves proportional to the square root of the number of samples in the average  Thus if we claim a single sample has 10 meters of resolution then taking 4 samples will provide an effectivel resolution of 10 / sqrt(4) = 5 meters.  16 samples would be roughly 10 / sqrt(16) = 2.5 meters.  This can be rearranged to determine the number of samples necessary to achieve the required resolution as

samples = ( 10 / R )²

Thus if you are looking for a resolution of 10cm you get ( 10 / 0.1 )² = 10k samples required.

Obviously this implies a trade off between number of samples and resolution which can only be determined by the requirements of the system.

Jim Noxon

It seems a mix of RSSI based estimation distance measurement for "short" distances and a TOF method for "long" distances when RSSI are so low that error is greater than 10 m (becasuse of the log function of distance vs rssi ) may achieve best results.

Taking real, in a mesh network with cc2530 devices Z-Stack firmwared I have doubts how to accomplish TOF measurements. Steps:

 1) Transmit a dummy emission from one node to the other. Here we should start Timer2 when actually data frame is sent OTA. Taking a look into Z-Stack this would be, in library call to APSDE_DataReq in AF.c?

  2) Receive the ACK from node. Then stop Timer2 and we have a round trip. Keeping count that real accuracy from time measurements is from modem. In Z-Stack this would be rxStartIsr ISR in mac_rx.c? 

Iterate 1) to 2) to get several samples (time and power consumption matter how many).

Would this be the best way to get software TOF measurements for Z-Stack? Would be new errors due to it (firmware delays ...)

Victor

Software latencies will cause you problems if you attempt to manage this entirely within the ISR structure of the z-stack.  You will have to implement this via a hardware timer mechanism if you intend on being able to obtain 10 meter or less resolution.  There are a couple of options.

1. This would be the best option but I'm not sure if it is capable as I don't know how the z-stack configures the timer.  If it implements the timer in up mode wher it counts to 0xFFFF and then rolls over, all is good as you can configure one of the DMA channels to simply capture the timer value when the RF event is seen.  You will want to set the DMA to the highest priority and make sure all other DMA's are at lower priority to guarantee a constant latency in capturing the timer count value.  You can also have the DMA transfer the timer value into a ring buffer continuously so you can relax the timing for code to go into the buffer and determing the TOF period.
2. If method 1 gets too complicated or is not capable, the next option would be to setup one of the 8 bit timers and create your own ISR to count rollovers.  Note that you will want to make this ISR __idata_reentrant otherwise the overhead of using the software stack will be too much for the system.  Note that in this case, the timer will be interrupting the system at 62.5kHz.  Since the resolution of the modem is only 16MHz, you can prescale this counter by 2 otherwise it would interrupt the system at 125kHz.  You may also want to hand code this ISR to merely increment a counter and return.  IAR should be able to create a fairly efficient ISR from C code but sometimes it doesn't do so hot of a job.  In either case, this variable will act as the upper bits of the timer.
   
   You will need 2 DMA channels.  On the RF event the first one will read the 8 bit timer and the second one will read the upper bits of the timer from the variable managed by the ISR.  There will be some issues where the upper bits will lag slightly the counter rollover value so you will need code to identify and correct this condition.  (if you are making multiple samples, you could simply test for an outlier and toss the sample).
3. If the above methods do not provide enough resolution due to latencies caused by the DMA architecture, you will need to set up a GDO pin to output the RF event and then run that signal back into the timer pin and operate the timer in a capture form.  In this fashion, you can use an ISR to both read the capture value and manage the upper bits in the variable.  This will complicate the ISR and garner significant CPU time so you will probably want to create a function to turn on and off TOF measurements.

Note that the resolution you choose, based on the number of samples you can afford to take, will dictate the point at which you cross over from RSSI detection to TOF detection.  This point will be roughly at the following distance

R = 16.877 k, assuming 1/2 dB resolution of RSSI

R = 8.195 k, assuming 1 dB resolution of RSSI

where k is the resolution of your TOF measurement.  Although the CC2530 RSSI register provides 1/2 dB resolution, I beileve the z-stack function that returns this value truncates it to 1dB resolution.  Note also this is for ideal conditions so probably dividing the results by 4 is a reasonable (yet still optimistic) assumption.  Thus if you expect to use 10 meters as your TOF resolution, then the ideal cross over distance would be 168.77 meters if you can use the full 1/2 dB resolition of the RSSI register but probably more like 40 meters or less in reality.  Using the z-stack resolution it would be 81.95 meters ideally and more like 20 meters or less.  Finally, if there are any walls inbetween the two radios, there is no way to account for this additional attenuation wich will equate to a delta in distance.

Another thing to understand is that RSSI is notoriously a poor measurement of distance in any environment which is not ideal.  This is because there will be standing waves creating local minima and maxima in the local RF field.  Since the wavelength of 2.4GHz is ~12.5cm, this means you will pass through a local minima and maxima in the short distance of only 6.25cm.  The difference in field strength between these local minima and maxima can be as much as 40dB and 6dB is almost guaranteed.  Thus in order to use RSSI to make distance measurements you must utilize frequency diversity techniques so you can measure the envelope of the RF field.

If you over sample by 4 the the TOF resolution is 5 meters and if you use the z-stack resolution you would be at 40.98 meters and probably more like 10 meters for the RSSI/TOF crossover point.  What all this is telling me is if you take the time to implement TOF, don't worry about implementing RSSI measruements unless you need high resolution close in and where the distance between the antennas is much much greater than any reflected RF path distance.

Jim Noxon