LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

High precision Time measurements

Hi LabVIEW comunnity,
I have been programing with labview for a while, but I have a problem that i can not solve and i was thinking that maybe somebody has faced it before, so:

PROBLEM: I am generating a train of pulses (delay: 100microseconds, widht: 100ns, using 80MHz internal timebase)with a counter using a 6602 card, which allows you to choose between 1MHz, 20MHz or 80MHz internal timebase. The pulses are created using a small progam using the "advance counter" comands of the graphical interface. What I "just" need is to know the time elapsed since the rising edge of the pulse, with a precicision of less then 100ns. In theory, with the 80MHz timebase, i should be able to get up to 25ns resolution, but for some reason, the program complains about the timebase, and just allow me to use the 1MHz timebase (while doesn't complain to generate the pulses).

The PC used is a Pentium 4(3GHz), with 1G of RAM. Is a good machine, so i don't think the problems are comming from there.

Anyway, I have try to exposed clearly the problem and it would be really helpfull any help, because I just can't understand why it is not working !!!

Thanks, Jofre.
0 Kudos
Message 1 of 6
(4,252 Views)
Jofre,

See the knowledge base article listed below...
http://digital.ni.com/public.nsf/websearch/145AF8BCC51C925386256874005EC9C7

Chad
0 Kudos
Message 2 of 6
(4,238 Views)
Thanks for trying but, as i said in my post, i know that information, i am already generating the external pulses. What i can not manage is to use the 80MHz internal timebase as a time scale to measure the time pass from a specific origin of time.
0 Kudos
Message 3 of 6
(4,222 Views)
Jofre,

I think I can probably help you, but first need to be sure I understand clearly.

1. You mention "advance counter" commands -- this means you are using traditional NI-DAQ rather than DAQmx, right?

2. Offhand, I can't think of any good reasons why you wouldn't be able to use the 80 MHz timebase. Can you post the portion of configuration code that produces an error when you try? Also, aren't the timebase choices 80 MHz, 20 MHz, and 100 kHz? I don't recall a 1 MHz timebase...

Quick thought: when setting up the timebase, are you choosing the "maximum internal timebase" option? I think that's the one you need...

3. When you need to "know" the time elapsed since a rising edge, what exactly do you mean? While it's possible to use software calls to inspect this time while the pulse is being generated, the accuracy will be limited by the software execution speed and priority. You would need a hw signal and a separately programmed counter task to perform true measurements at resolutions below 100 nanosec.

That being said, I also had an app where I generated a pulse train and then queried the internal count to get an estimate of "time since last pulse." I used the "Counter Get Attribute" vi and requested the "count" attribute.

As I recall, the driver call to read the count value took about 1-3 microseconds to execute (Pentium 3, 1.2 GHz). However, our pulse train was only 1 kHz and we were running under the LabVIEW Real-Time OS. (Our real-time loop was driven by the 1 kHz pulse train, and the "time within the pulse" estimate helped us characterize our software execution time.)

If you're running under Windows, the operating system may cause many more milliseconds of uncertainty, during which time several pulses will occur. It's not clear to me that you can get a useful software-call measure of "elapsed time within a particular pulse" if you can't be sure which particular pulse you're in the midst of.

Can you describe the function of your "time within a pulse" measurement? How often do you need to make this measurement? What is it used for? Is there a hardware signal to associate with the instants you wish to characterize? If not, could you make one?

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 4 of 6
(4,212 Views)
Thanks Kevin,

Sorry you are right, it was 100KHz, not 1MHz. Apart from that, i manage to solve the problem, last week was a hard one, and for friday my brain was not 100% (I was kind of a zombie for friday!!!).
But after a refreshing weekend, I solve the problem this morning in couple of hours, but thanks anyway for the effort (that was a long post!!!).

Thanks again, Jofre.

(By the way, the answer to my problem was to use a continious buffered period measurement)
0 Kudos
Message 5 of 6
(4,204 Views)

Hello,

 

Just a quick question:

 

How did you come up with the accuracy figures that you mention:

 

25ns for 6602 card using the 80Mhz timebase

 

As far as I see: 80Mhz*50/1,000,000 = 4,000 Hz -> 0.25 ms

 

I am facing a similar problem to the one you had. In my case, I am trying to calculate how accurate frequency measurements I can do with 6602.

 

Regards.

0 Kudos
Message 6 of 6
(3,753 Views)