Accuracy of frequency measurement/counter reading | LabJack

Accuracy of frequency measurement/counter reading

4 posts / 0 new
Last post
florian_BCD's picture
Accuracy of frequency measurement/counter reading


I am using a LabJack U3-HV to measure a frequency using the counter 1. For this, I am using the C code provided in the "exodriver" library in the u3Functions.c file. In that file, Timer 0, Timer 1 and Counter 1 are initialized; so I am simply plugging my frequency on Counter and doing the reading.

Here is my issue: I need to measure frequencies between 1KHz and 100Khz, and I am counting for 1 second. I am then expected to read 5000 on Counter 1 for a frequency of %KHz; but I am reading 5020, 5024, 5014 etc. If I increase the reading time, I get a bit closer to 5000; but still with an obvious lack on accuracy. And the higher the frequency is, the bigger the lack of accuracy is. For example, at 100KHz, I am reading counts on Counter 1 of 100200, 100300, etc.

So my question is: am I doing something wrong and I should be able to be way more accurate; or is this actually to be expected from the LabJack U3-HV for frequency measurement on counters?

I need to be way more accurate for the work I am doing (technically I should be reaching 30ppm...); so I need to know if I can achieve something highly reliable with this tool, or if LabJack isn't the man for this job?  :)

Thanks for your help!


LabJack Support
labjack support's picture
You will find some background

You will find some background information here:

The clock on the U3 is only 1.5% accurate as it is RC based:

... so any measurements you do that rely on the U3 clock will be subject to that error.

I'm not sure what the example you are using is doing, but it might be using a software clock to get readings once per second.  Now you are using a clock that is likely more accurate, but you are prone to jitter of milliseconds.  If you read over a long time, that jitter is negligible, but if you read once per second then milliseconds of jitter is noticeable.

You need to move to a device with a quartz based clock, which will be all our other devices.  I suggest the T4 as the least expensive recommended option:


florian_BCD's picture
Thank you for your reply.

Thank you for your reply. This makes sense.

FYI, here is the link to the exodriver repo I used:

And attached is the specific C file I used and built as is to count using Counter1



File Attachment: 
LabJack Support
labjack support's picture
To add, there is software

To add, there is software sleep accuracy and USB delay to consider between your counter reads. You can replace your eTCValues with a Feedback command with U3 hardware delays and counts to help with the 1 second accuracy by removing the OS sleep and USB factor. So one Feedback command with the following IOTypes:

Counter1 with reset bit set
WaitLong set to 61 (61 * 16384 us = 999424 us)
WaitShort set to 4 (4 * 128 us = 512 us)

Note that the hardware delay can only get within 64 us of 1 second, and the above delay is 64 us under (999424+512=999936). In the response, use the second counter reading for your ~1 second of counts.

Look at the u3Feedback.c example for a demonstration on using the Feedback command-response, and the Feedback and IOType links for low-level documentation.

Note that the command will delay around 1 second, and the USB timeout in the Exodriver defaults to 1 second. Use LJUSB_ReadTO to read the response so you can specify a timeout a little above 1 second.