Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Frequency measurement clock timebase.

Hi there,

I am currently working on acquiring high frequency counter signals from rotary encoders, typically accurate to few nanoseconds. Previously I was using NI 9401 to acquire signals but it receives at a rate of 10 MHz, so it's necessary to get a higher value time base now. And for that, I would really like any assistance in this regard. Please help me, people! 🙂

 

Thank you.

0 Kudos
Message 1 of 4
(2,865 Views)

After reviewing a previous related thread of yours, I want to first take a step back to consider the big picture.  I'm concerned that you're chasing after timing *resolution* that's of little value because it may already exceed your sensors' *accuracy* and *regularity*.  I had the same concern back in the prior thread, that's why I chose to link directly to my "voice of experience" msg.

 

A low-res encoder such as yours at 360 cycle/rev is *very* unlikely to have impressive specs for accuracy.  Most such encoders are pretty poor in their "Pulse Width" spec, which relates directly to errors in semi-period measurement.  A quick look around the web and I see pulse widths spec'ed at 180 +/- 45 deg or 180 +/- 30 deg.   Unless you have a really unusual 360 cycle/rev encoder, I'd be *avoiding* the use of semi-period measurement.  

 

 So let's figure out what measurement you're making, for what purpose, and then figure out where to focus.

 

You mentioned measurement of transmission error.  The kinds of things you can see with your encoders will be cyclical speed variations due to tooth mesh and shaft alignments.   Odds are you've got something in the range of 15-40 teeth on the input and output shaft gears.  Your encoders are giving you 360 period measurements per rev.   So you can expect around 10-20 period measurements per tooth.  That's enough to see which tooth frequencies make the biggest contribution to speed fluctuations (which in turn drive instantaneous transmission error).

 

 So now let's suppose you do regular period measurement, 360 periods per rev, with a speed of 1200 RPM (20 rev/sec).  That puts you at 7200 Hz with periods of ~140 microsec.   Your 10 MHz timebase gives you a timing quantization error of up to 0.1 microsec.  This is less than 1 part in a thousand so < 0.1% error due to timing quantization.  That's *not* a significant part of your overall measurement error.   The encoder itself is undoubtedly much worse than this.

 

So what exactly is the big picture here?  Why are you striving to get greater resolution?  What specific purpose will it serve?   Have you grasped the important fundamental idea that improving your *resolution* has no bearing on your measurement *accuracy*?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 4
(2,840 Views)

Hi Kevin,

 

Thank you first of all for having an exact insight about my problem. You were absolutely right on the period of revolution at approx 1200 rpm. I'm now focusing on the period rather than the semi-period, so the latter no more an issue now. But as you said, it would take only 140 microsec approx., but I'm going for accuracy till nanoseconds since the microsecond values are pretty much constant and the exact profile of the error doesn't come out. 

 

Also, I agree that the grating on the 360 pulses encoder might be not accurate. This is just a trial setup, so once I get these readings approximately, we'll move to a better 6000 pulse LARM encoder. So at 4500 rpm and readings for every 0.06 degree, we definitely need better timers, right? Because I need atleast 5-6 digits of precision to be right about the finite nuances that I expect.

 

The above is my idea and thoughts about the measurement. Please let me know about your suggestion and thoughts.

 

Raghavendar Balaji.

0 Kudos
Message 3 of 4
(2,824 Views)

I'm not saying it's *impossible* that finer timing resolution may help, but I remain skeptical that it's the main thing to worry about yet.  Among the common DAQ boards you might consider are the X-series family that have a 100 MHz timebase and 4 counter / timers.

 

However, I would expect that even your current setup should reveal some shaft and tooth frequencies on a spectrum plot, once you've properly processed the raw period data.

 

Do you have a set of data with the "pretty much constant" ~140 microsec periods?  What methods have you used to process and analyze it?   

 

Do you have data for both the input and output side of the gearbox?   What kind of gearing is involved and what's the gear ratio? 

 

What "exact error profile" are you attempting to characterize?  How will you use that info?

 

I think you're assuming that timing resolution is the biggest issue, while I'm suspecting a combo of encoder accuracy and perhaps some part of your data processing or analysis.  A spectral plot with an inaccurate encoder will still tend to identify frequencies of interest, even if their amplitude isn't quite so trustworthy.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 4
(2,821 Views)