RF Time of Flight Measurements using a PIC

[jfunkie]

Hi,

I've been trying to use a PIC to measure RF time of flight thru this method:

I start TIMER0 and then transmit my data over RF to another PIC. The other PIC processes the data and replies. Upon receiving the data, i stop the timer. Taking the difference between the timer0 readings, and taking away all appropriate processor delays, I should be able to find the time-of-flight.

However, TIMER0 increments every instruction cycle(ie 4 clk cycles). With a processor speed of 40MHz, that gives 0.1us per increment. Leading to a very low accuracy. Each increment in TIMER0 will mean a 15m increase in distance.

I'm trying to reduce this value.

Anyone has any suggestions? OR am i doing this wrongly?

Thanks!!

 

[Jay.slovak]

You may try to use external input to you counter/timer... This should improve accurancy, but the external frequency should be as fast as you can provide.

 

[jfunkie]

Yup. i've thought of that. But can the external oscillator be set faster than the internal processor?

 

[Jay.slovak]

As much as I found out from datasheet:
Timer 1 asynchronus external clock input should have 60ns+ period. So the maximum frequency is around 16Mhz..

 

[Oznog]

However, TIMER0 increments every instruction cycle(ie 4 clk cycles). With a processor speed of 40MHz, that gives 0.1us per increment. Leading to a very low accuracy. Each increment in TIMER0 will mean a 15m increase in distance.

I'm trying to reduce this value.

Anyone has any suggestions? OR am i doing this wrongly?

Thanks!!

What kind of accuracy are you looking for?
The simple solution would be to ping it back and forth 1000 times before stopping the timer, thus increasing your resolution 1000x.

It is a tricky circuit. You would need to know exactly how long the RX and TX take, as well as the RF-to-PIC circuit delays. Some of that will just be an ad-hoc calibration adjustment. You will need to be sure that it takes the exact same number of clocks every time, so the code cannot experience an interrupt, etc.

[edit] - Multiple pings won't change the fact that when the RF crosses in and out of the PIC domain that it will have to sync with the PIC clock, which still means there is a significant quantification error. i.e. it's either going to picked up on one clock or the other so the finer points of the delay through each cycle will be lost. Perhaps the averaging effect of so many pings will be able to increase the resolution again.