I need to measure nanoseconds with a PIC

[Compeek]

Hello. I've been into electronics for about 4 or 5 years now, and I have a decent understanding of analog electronics. About two years ago, I got into microcontrollers. I chose PICs for cost and ease of use. But now to the point...

I've only learned by example and experimenting, so a lot of times I don't get a good understanding of what's happening "behind the scenes" when I run my code, if you know what I mean. So I don't really have a good knowledge of how timers (such as the timers on a PIC) work and what they are capable of.

For my next project, I need to measure nanoseconds. I could explain what my project is, but it's really irrelevant to my question and so I'll keep it simple. Can I use a PIC, such as the 18F4550, to measure nanoseconds? If not, what type of timer IC would I need to be able to do this?

If more details are needed, I can definitely provide them. However, I think this question is simple enough.

Thanks much in advance for the help!

 

[Sceadwian]

The question was not simple at all.

What's the range? There's juuusstt a bit of difference between 1-5 nanoseconds and 900-1000 nanoseconds, and you also don't mention what resolution you need, picoseconds or just single nano second units? What you're measuring and explaining your project is NEVER irrelevant. I'm also going to go out on a limb and asume you mean measuring the time constant between two events? Or would it be possible to say simply count 100 rising edges and determine the time between the first and 100th one, it's called sample decimation and can increase your resolution dramatically if you can sample enough events. Even with a 4x PLL clock multiplier for a PIC at 20mhz (not sure if that's possible I use AVRs) The time constant is only 50ns, and the async counter I don't think is good for much more than 50mhz or so.

 

[Compeek]

Hey thanks for the quick reply.

I guess this just shows me how much I have to learn still...

Okay, the range is relatively large. It's anywhere from about 5 ns to about 5,000 ns. The resolution is 1 nanosecond. And yes, you are correct. I need to know the amount of time elapsed from the beginning of an event to the end.

Here are more details so it's more clear. Simply put, there will be two devices communicating via a wireless connection. I will be using Nordic nRF24L01 chips for this. The micros controlling them will be 18F4550s. In essence, I need to know the time it takes the signal to leave one device and arrive at the other. I am going to use this value to determine the distance between the two devices. My theory is that if I can start a timer, send a message from device A, have device B receive the message and send a response to A, then have A stop the timer when it receives the message, I should be able to subtract exuction time of the code that was necessary to do that, and then divide the value by two to get time for the transmission in one direction. From this I could determine the distance. However, since this would be a very small value (probably too small to measure and deal with), I figure I can I just have the sending of the message repeat, say, 10,000 times with the timer counting the whole time. This would allow me to measure in microseconds, which I know is possible with these PICs. Then, after subtracting the time for the code to execute, I would be left with a value that I could essentially divide by 10,000 and then 2 to get the time for the transmission one way. Multiplying this by the distance travelled in so much time would give me the distance between the two devices. The only problem with this is that the total amount of time it would take to send and receive a message 10,000 times (when you count execution time and everything) would be up to a half a second or more, which is way too much. I need to have the whole distance-measuring process take about 1/100 of a second at most.

Hopefully that makes my question more clear. And thanks again for the help.

 

[Oznog]

The basic resolution of a counter in PIC18 would be 100ns. That includes external T0CLKI as a timer source if I'm reading correctly. 1ns seems unachievable.

I'm not sure your plan is realistic. The Nordic nRF24L01 is not going to be that critical. The receiver has a filter on its freq input and doesn't read in a single cycle but a level from many cycles. As such the intensity of the RF signal will probably change the exact time it takes to recognize. The nRF24L01 will then align the 1/0 serial RF data with its own internal clock cycles which, like the PIC, could be 100ns periods or whatever. Same thing happens when it receives the signal for re-transmission.

Actually the same thing happened when it received the PIC data to transmit. Just like the PIC, the nRF24L01 has an internal clock and doesn't instantly, asynchronously transmit with the SCK input. No, the SCK triggers a shift into a buffer and the nRF24L01 transmits based its internal clock cycles when the buffer has a full byte or word or whatever.

So there's an unknown loss of resolution due to alignment with tx/rx transceiver clocks. I can't tell you how much but far far above 1ns. And the receiver delays based on signal intensity are also going to vary by much more than 1ns. Even the exact point where data clocks in- a question of rise/fall times and the threshold voltage- are more inaccurate than 1ns even from cycle to cycle.

You'd need a purpose-built transponder for this and as well as a more accurate timer. The timer would need to be a very fast counter, 1GHz here.

 

[Compeek]

So is it basically impossible to measure a distance within the range of 1 to 40 feet by timing the transmission of packets in a 2.4GHz sytem? That's essentially what this comes down to.

What are some ways I could measure distance like this? I don't want to do ultrasonic signals, so RF is the way I need to go. Is there a way I could determine distances like this?

Thanks again everyone.

 

[Oznog]

Good question! This sort of positioning question has plagued the robot world... for decades! Literally. There is no straightforward, reliable answer. You haven't described the environment or the actual accuracy requirement (accuracy and resolution are two different things). 1ns=1ft though. Or what you're actually trying to do. Assuming that you don't need to post these details about the end goal, or thinking it's too "secret", is a common mistake. It's hard to help without knowing this.

One thing you need to consider is that most environments have some degree of multipath reception. That is, if there is a building nearby, the target will get the original wave along with a reflected version. There are delay and intensity differences. It can create constructive or destructive interference and make the delay appear different than it should have been.

You may not want to rule out ultrasonic when you see how difficult this problem can be.

 

[Torben]

Hi Compeek, and welcome to the site!

I was going to say much the same things as Oznog just said. Perhaps if you explain exactly what you're trying to do, instead of how you think you need to do it, someone can come up with an alternative and more workable solution.

Also, it might be helpful to know how much time you have before this has to be working, what the budget is, how large it can be, what kinds of power supplies will be available, and so on.

I'd say in the 1-40 foot range that ultrasonic would be your best bet, except that it will be tricky to get readings 0.01 second apart (if it's even possible).


Just some thoughts,

Torben

 

[Compeek]

Thanks again for the quick response. I'm sticking with this forum because you guys are helpful AND quick!

Okay, I've been doing a lot of thinking about this, and I've realized I've been making a significant mistake in my calculations. For some reason, I've had it in my head that 100ns is 1us, when in reality it's .1us. So that changes things for me quite a bit. In fact, it changes my whole desire for timing down to the nanosecond. Let me explain.

I set up an Excel spreadsheet to calculate this out, and I think I could make this work. If anybody is really interested, I could upload the Excel sheet for you to see. But what I'm going to say here is basically everything on the spreadsheet, so I don't see the need to upload it. But if somebody wants, I will. Anyway, I figure that at 590 half-cycles (will explain in a sec) I can be accurate to plus or minus 2 inches (which is great for what I need). More cycles obviously makes it more accurate. Assuming 15 addition microseconds per cycle for delays, code execution, etc, the entire distance-finding process would take 0.008850 seconds. That's even better than what I need, so even if there's actually going to be more than 15us additional time per cycle, I'll be okay.

Now, let me explain what I mean by cycle. Please excuse my poor terminology, if it is that. I'm defining one cycle as the sending of a packet from A, the receiving of the packet by B, the sending of a response packet by B, and the receiving of the response packet by A. The reason this cycle would constantly be repeated is to increase the total time to where it can be measured at a resolution of 100ns by the microcontroller. Understand what I'm saying? Because if I just did one complete cycle, the total time (after subtracting the time for code execution, delays, etc.) of the time 'on air' would be too small to measure with a timer with a 100ns resolution. So by repeating the cycle 295 times (590 half-cycles) and measuring the whole process in one chunk, I make it so I can pretty accurately measure the 'on air' time. Doing the proper calculations with this data would yield the distance.

So I really don't need to measure to the nearest nanosecond after all. I really just need to measure to the nearest 100ns. That said, my resolution is 100ns. My accuracy is a couple of inches, probably less than 6 to be more exact. I'm not sure what that would translate to in accuracy of nanoseconds, but it's not that critical because any flaws should even out, for the most part, over the whole process. But I'm not worried about inconsistent delays and what not at this point. I'll worry about that later.

So the range of distance I'll be measuring would probably be closer to 2+ feet at the lower end and up to around 40 or 50 feet.

Oznog, just like you said, I didn't really want to give away all the details because it's kind of "secret", but since specificity will help you guys help me, I'll go ahead and describe what I'm doing.

I'm going to have three RF devices in static positions around an area of about 30x30 feet. There will be an object within this area that communicates with the 3 "sensors". I'm going to be doing trilateration to determine the position of the object inside this area. So each of the three sensors will take turn going through the process I described above. Let's say it's sensor A's turn. It will go through the 295 cycles of transmitting and receiving with the object. The distance between the sensor and the object will be determined. Then the same will happen for sensors B and C. After all three distances are determined, the values will be used along with the known positions of the sensors to determine the location of the object. So speed is essential because the object will be moving. The more quickly the distances are calculated, the more accurate the position will be.

I would still prefer not to use ultrasonic for a couple of reasons. One is that I would really like to get experience with RF, and I don't think ultrasonic would be much of a challenge for doing this. Another reason is that I don't want to have the ugliness and space of the ultrasonic sensors. That may sound like a dumb reason, but what it comes down to is I'm set on using, or at least attempting to use, RF for this. If it doesn't work, fine. But I'm not giving up on it until I know it won't work.

Now about the environment. The area where this will all take place will be on a wide open, flat space. There should be basically no physical obstacles for the signals to collide with. But even so, the nRF24L01 has good checking for repeated packets. So if the signal bounced off of something and arrived again at the receiver, it would know and just throw it out.

I realize that there are still plenty of things that could cause this to not work well. Interrupt latency, resent packets, etc are just some things. As the project progresses, I will work on solving these problems. But at this stage I'm just worried about working out the plan for doing this and trying it. I'm not going to say it won't work just because there's a possibility of that.

I hope this post made it a lot more clear what I need. Thanks so much for all the help so far!

 

[Oznog]

Now about the environment. The area where this will all take place will be on a wide open, flat space. There should be basically no physical obstacles for the signals to collide with. But even so, the nRF24L01 has good checking for repeated packets. So if the signal bounced off of something and arrived again at the receiver, it would know and just throw it out.

No, it won't. Multipath will not cause a repeat packet- it will cause a phase shift that results in a slightly different reception time. Consequently the packet recognition time will be off.

Let's look at the magnitudes of the plan. At 2.4GHz,a wavelength is 4.9" so you're looking for about 1 wavelength there.

Now this math is kind of a stretch, it doesn't quite work this way but here goes- a 1Mb/s stream at 2.4GHz is 2400 cycles. It takes the receiver's filter/demodulator 2400 cycles to decode a bit. It just seems unlikely that it would reliably respond at the same time within ~1 cycle regardless of intensity.

But anyhow I think your repeat packet plan will run into the same problem as single packet. The Nordic there can have at most a 20MHz Xtal, so every attempt gets placed on coarse 50ns cycles on both sides. That's not even counting the PIC time nor the packet processing logic, which may have some uncertainty of several cycles but it's hard to say, it could be certain. What's more is if the Rx and Tx are running at the same freq (but not exactly, since no 2 xtals are the same), there will be a beat between their clocks. That is, say there's no PIC delay and the Tx originates a packet every 100K clocks (n). The receiver will see it on the n+8 cycle there's an Rx latency of 100 cycles then the original transmitter gets the ping back at n+8+100+9. But then due to the Rx clock running slightly slower this may persist for 1 sec or 10 sec or 1 min, then the Rx jumps to recognizing it a cycle later so now it looks like n+9+100+9, a 49 foot difference. And that's long term quantization noise that can't readily be fixed by taking a lot of measurements.

There are RF transponder systems designed with this in mind, to measure the ping time. Google "rf distance transponder" or "rf telemetry transponder", or "rf positioning transponder".

The concept is certainly possible, GPS does exactly that! But the hardware must be very specialized and again multipath IS a problem. You'd think the signals originating locally would make it easier, but no what would make it easier is a slower speed-of-light but that's not going to happen. We still have the problem that submeter measurements come down to single cycles and phase shifts.

So you're thinking of an autonomous mower... we know.

 

[Sceadwian]

Does this have to be RF? 1-40 feet isn't that great a distance, if you have line of sight you could use time of flight of a single pulse of an ultrasonic transducer to measure distance, but that's nearly as plagued with details as the RF method.

 

[ericgibbs]

hi compeek,
This Trisponder system has been in operation for many years.

This is a company I have sub contracted for, in relation to position fixing.

**broken link removed**

Plessey also have a simliar system.

I would do some checking of existing patents before going too far with the project.

 

[philba]

there's another issue with your time-of-flight idea. You would need syncronized clocks. Radar solves this by timing an echo's round trip and thus has a single clock. In theory, you could have an echo transponder but you'd need to figure out all the latencies in the system so you could cancel them out.

Ultrasonics are much easier to use.

 

[Compeek]

Oznog, thanks again for the explanations and help. I didn't realize this would have so many complications. I'm still going to give it a shot, but I might end up using ultrasonics transceivers for simplicity, even though I would prefer RF.

So you're thinking of an autonomous mower... we know.

Haha, well not exactly, but same idea. This is really as simple as I'm just trying an experiment. I will probably just make some sort of small robot and do this on my driveway, giving it a certain path to follow based on position.

Does this have to be RF? 1-40 feet isn't that great a distance, if you have line of sight you could use time of flight of a single pulse of an ultrasonic transducer to measure distance, but that's nearly as plagued with details as the RF method.

No, it doesn't have to be RF, I would just prefer it that way. Again, this is mostly just an experiment for me, so I'm not so much looking for practicality at the moment. Instead I really want to see if I can make this work with RF. That said, though, ultrasonic is probably going to be the only thing I'm going to be able to use anyway, due to the mentioned complications RF would give me.

ericgibbs, honestly, I don't care about existing patents right now because this is just for fun. As far as I'm concerned right now, I won't be selling this. But even so, can you really patent an idea as simple as trilateration? Or is it the specific way it's done? Either way, I think my resulting product would differ enough from those that it wouldn't be considered a copy. But like I said, that's not a concern right now because I'm just doing this to see if I can.

philba, I am already planning on doing exactly what you said I could do. I do have an echo transponder. So I don't need to worry about syncronized clocks.

Thanks everyone for the help. I really appreciate it.

 

[Sceadwian]

Depends on the exact wording of the patent, there are always ways around them, and patents don't last forever.

 

[Torben]

Maybe I'm betraying my software roots, but what about using computer vision to do the tracking?

You could use something like OpenCV. If I were doing it, I'd start by sticking a tennis ball or something else simple but different from the rest of the scene on top of the robot, and track its horizontal position in video streams from two or more cameras covering the field from different vantage points. If the positions of the cameras are well-defined and accurate then it should be just a bit of math to determine the location of the target within the field.

Just a thought.


Torben

 

[Diver300]

Could you just use a good GPS receiver and not bother with any fixed reference points?

**broken link removed** seems to be good to 40 cm with a bit of calibration and updates every 64 ms.

 

[shom_show]

Hi to all,

Myself Sumanta Kumar Show from IIT Kharagpur, Mining Dept. is forwarding the logic which I want to implement in the micro-controller. Its is as follows -

Suppose I have two ports name PORT1 and PORT2. Now the ports status will change by the following way:-

PORT1 PORT2 COMMENT

5 V or Logic1 5 V or Logic1 Initial condition

0 V or Logic0 5 V or Logic1 Timer Start

0 V or Logic0 0 V or Logic0 Timer Stop

Now the time gap between timer start and timer stop will be in nano-second range. I want to display this time delay on a display device. This will be done one time.

It will not be done in a continuous manner. If need another experiment will perform manually by pressing power on/off switch or pressing reset button. Please send me

your valuable suggestion (any device that makes it easy to attain the objective). If possible please Email or SMS me.

Thanking You.


Yours sincerely

Sumanta Kumar Show

Project Assistant, Mining Dept.

IIT Kharagpur


Email Id - (show.sumanta@rediffmail.com / sumanta.show@gmail.com)

Mobile No.- (9932582375)

 

[atferrari]

How they do it

Not that I am going to help you with a concrete solution. Just some food for thought:

There is equipment used in geodetic surveys where the the time elapsed for the emission going / coming back is compared against an internal loop of fixed / precise duration. Kind of an internal standard.

That loop is triggered when starting the transmission and will repeat until the echo arrives back.

I do not recall how much they assure you in every measurement but it is a quite high precision.

That means stable thus expensive components. Technique is laser.

 

[alec_t]

Because if I just did one complete cycle, the total time (after subtracting the time for code execution, delays, etc.) of the time 'on air' would be too small to measure with a timer with a 100ns resolution. So by repeating the cycle 295 times (590 half-cycles) and measuring the whole process in one chunk, I make it so I can pretty accurately measure the 'on air' time.

The problem with the repeating cycle is that you have to capture the reception time at A in each cycle so that you can get an aggregate time to divide by the number of cycles. You might be able to get round this by, instead of capturing the reception time, merely detect the reception by A and use it to automatically trigger the next transmission by A.

 

[Mr RB]

The problem with the repeating cycle is that you have to capture the reception time at A in each cycle so that you can get an aggregate time to divide by the number of cycles. You might be able to get round this by, instead of capturing the reception time, merely detect the reception by A and use it to automatically trigger the next transmission by A.

I don't think that is right. The total time after say 1000 back/forth cycles will be a total of all the fixed times and 2000 variable transit times. Simply by doing some tests at different distances you can measure the ratio of fixed:variable times and then just subtract the fixed time total from the overall total.