Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Edge Count measurement error when using external sample clock

Solved!
Go to solution

Hi,

 

I am trying to measure the number of edges (Rising) on a square wave at 5 kHz from a function generator on an NI PCIe 6363 device. I have configured a counter input edge count channel with the input from the Function generator at PFI8. I am using an external sample clock that is supplied from the counter output channel of an NI USB-6211. If I acquire for 10secs then ideally I expect to see a total of 50000 edges measured on the counter input channel. However my measured value is anywhere between 49900 and 50000.

 

When I use the internal timebase clock to measure the edges, the measurement is accurate and almost always exactly 50000. I understand that when using an external sample clock, the measurement accuracy is subject to noise level of the clock signal. However I have verified that the clock signal is stable and not very noisy. Any reason why there is a error in measurement and what tolerance should I expect when using an external sample clock as compared to when using the internal timebase clock?

Also what is the recommeded clock frequnecy (in relation to the input signal frequency) when using an external clock?

 

Thanks,

Udith

0 Kudos
Message 1 of 9
(3,582 Views)

OK lets see some code.  There are too many variables to guess exactly what is causing the trouble


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 9
(3,566 Views)

Hi,

 

I am just using NI Max to configure a counter output task from a NI USB-6211 to generate continuous samples which is the clock signal for the NI PCIe6363. I have configured a Counter Input Edgecount task for the PCIe6363 which receives the clock externally from the 6211 and an input signal of 5kHz from an Fgen. I have set the rate of acquisition for the PCIe6363 the same as the external clock frequency and set to acquire samples worth 10secs. Hope this helps.

 

Thanks,

Udith

0 Kudos
Message 3 of 9
(3,548 Views)

Udith

 

I agree with your initial intuition that this might be due to noise on the line. It sounds like you're getting less than 100 missed pulses over the course of 50,000. An error rate between 0.1% and 0.2% sounds reasonable depending on the external wiring. We could test it by connecting the DIO of the PCIe-6363 to itself and just running a pulse output into an edge count input. If we got better edge counting we'd know it was due to either the wiring between the devices or noise coming from the USB-6211.

Austin
Staff Software Engineer
NI
0 Kudos
Message 4 of 9
(3,529 Views)

Hi,

 

Thanks for the reply Austin and Jeff. Just to clarify, the 6211 is the source of the clock to the 6363. Howevever, the 6363 is counting edges on a 5kHz signal coming from a function generator. As per what you mentioned Austin, wiring the DIO of the 6363 to its edge counting input would not serve the purpose, since I'm assuming that the reference signal from the function generator is stable (since I am able to get exactly 50000 counts in 10 seconds when I use the internal timebase clock). 

 

Thanks,

Udith

0 Kudos
Message 5 of 9
(3,513 Views)

I think you're in the realm of the accuracy specs for the oscillators involved.  A lot of the NI DAQ boards are spec'ed for 50ppm at a fixed temperature, plus some additional tolerance for temperature changes.

 

This scales pretty straightforwardly.  50ppm means an interval that would nominally register 50000 counts might be off by 2.5 counts plus a little more to account for temperature effects.  The function generator must have a tolerance of its own, dunno what it is, but it would add a bit more to your measurement inaccuracy.

 

Your count numbers don't fluctuate quickly, do they?  On a given run, do you get count values that are near constant, maybe +/- 1 or 2?  But across several runs, the average value might shift a bit?

 

Finally, I'd be careful about *assuming* that the ref signal from the fn generator is stable.  Or dead-on accurate.

 

All in all, 10 counts off out of 50000 still strikes me as a little on the high side, but it seems in the realm of possibility that you might just be on the unlikely side of a tolerance stack-up.

 

 

-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).
Message 6 of 9
(3,498 Views)

Udith,

 

Thanks for the info, your application is clearer now. I think the concept of the test is still sound though. You could route one of the PCIe digital outputs into a digital input to replace the USB-6211 as the sample clock and see if you still see the issue. This will indicate that the problem lies with either the PCIe card or with the USB-6211 and wiring.

Austin
Staff Software Engineer
NI
Message 7 of 9
(3,492 Views)

Just for completeness of understanding your configuration, What are the frequencies of the external clock and the internal clock?  These would certainly effect counter resolution although, I doubt it is your problem, it would help us to attempt reproducing your problem.


"Should be" isn't "Is" -Jay
Message 8 of 9
(3,489 Views)
Solution
Accepted by topic author uhegde

Hi all,

Thanks for all your sugggestions. I was using an input signal from a function generator that had an amplitude of 8V. It turns out that reducing the amplitude to 5V solves the problem. I was able to get accurate counts with the external clock from the 6211. 

 

Thanks,

Udith

Message 9 of 9
(3,447 Views)