Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Frequency Measurement

  • Please log in to reply
6 replies to this topic

#1 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 28 December 2005 - 04:27 PM

We will discuss 3 typical techniques for measuring frequency:

1. Counting over time. At this time, all LabJacks have at least one counter. The counter simply increments an internal register whenever an external pulse is detected. By looking at the change in count over a change in time, frequency can be calculated.

This method is generally better for high frequencies, rather than low frequencies, as the resolution is determined by the amount of time between counts as follows:

Time (ms) Resolution (Hz)
100 10
1000 1
10000 0.1

You can see that if you are trying to measure a frequency from 0-10 Hz, with 0.1 Hz resolution, you must wait 10 seconds between counter reads. If however you are reading a frequency from 0-1 MHz, and require 10 Hz resolution, you can get updated readings every 100 milliseconds.

Another thing to consider is the error due to time measurement jitter. A common technique is to retrieve the current count from the LabJack hardware, and when the read is complete note the current millisecond timestamp from Windows. The jitter error in this case arrises from any inconsistancy in the time between the counter read and timestamp read. If this jitter is estimated as +/- 1 ms, and a measurement is done every 1000 ms, this jitter could cause up to +/- 2 ms of error (two readings involved) out of 1000 ms total or 0.2%. If you count for 10 seconds between readings, this error would drop to about 0.02%.

1A. The U3/U6/UE9 can reduce this time jitter error by getting a timestamp from hardware rather than Windows (timer mode 10). The timestamp can be retrieved in the same function call as the counter/firmcounter read, reducing the timing jitter to less than 10 microseconds. Note that the U3 clock is only 1.5% accurate, though.

1B. Rather than reading the counter using software timed command/response mode, you can read the timer in stream mode. Stream mode is hardware timed at a specified interval. For example, if you stream the counter at 100 scans/second, then you know that every 100th scan is exactly 1 second apart (to the accuracy of the LabJack's clock).

2. Timing individual pulses. By timing individual pulses, you can determine frequency with rapid updates, and with low frequencies this might be the only practical option.

The LabJack U12 does not have timers, so the best option for pulse timing is to use retrieve analog or digital inputs in stream/burst mode and find the time in software. The smallest time resolution available on the U12 is from a burst of a single analog input. In this case the sampling rate can be up to 8192 samples/second, meaning that the time resolution is about 122 us.

The LabJack U3/U6/UE9 have timers that can be used to measure the period of individual pulses. Timer mode 2, for instance, continuously measures the number of clock ticks between rising edges and stores that value in a 32-bit register. Whenever this register is read, you get the period of the most recent pulse. If the timer clock is configured as 1 MHz, the period measurement resolution is 1 us.

3. Frequency to voltage converter. There are various commercial signal conditioning devices available to convert frequency to an analog voltage signal. These typically make it easy to measure voltage with an analog input on a LabJack. Check out the 5B45 or 5B46 from Analog Devices:



... or for a lower level solution check out the LM2917 from National Semiconductor:


#2 Wheeler

  • Members
  • 6 posts

Posted 25 February 2009 - 08:19 PM

Ok not sure I quite understand this post, the manual or the examples. At least not in my application. I need to determine the elapsed time it takes to reach a predefined number of pulses. Elapsed time needs to be in at least the precison of a 100th of a second. Like recording the elapsed time of a running race. Only the the race is to obtain a certain number of pulses, not distance. Pulses will be anywhere from 2Hz to 125Hz and will vary through the elapsed time. I need to "check in" on the progress (count) of the pulses at least every 1/3 of a second so, I can display progress on the GUI that will display this data. So, I am thinking a timer makes the most sense for this application. If stream the timer with a sample rate of at least 500Hz, I can read it every 1/10th of a of a second to display progress. For each read, I'll write a loop to read though the samples in the stream. 0 or < than a tolerance to handle debounce should mean no pulse has been received. Anything greater means a pulse has been received, the count should be incremented by one and the total time should be updated. Something like the following psuedo code should work. declare elapsedtime = 0 declare counter = 0 declare debounce = .5 ' Made up number declare endofrace = 3000 start timer stream timer at 50Hz 'If timer is read every 10th of a second. 10 reads of 50 a second should be 500Hz. While counter <= endofrace For i in NumberofSamples in stream If time(i) > debounce elapsedtime = elapsedtime + time(i) 'Assuming timer value is not cummulative counter++ End if Loop Display elapsedtime 'obviously some conversion & math to do here. wait 100ms loop end timer display elapsed time My struggle is that a counter still seems an easier solution here. I just can see how to accurately record the elapsed time. I could start a timer in my software and then sample the counter every 100th of a second. Seems like and easier approach. Just don't want to miss counts or get extra counts from bounce from my sensors. Thoughts?

#3 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 26 February 2009 - 08:08 PM

I do think a counter should be a better way to do this. Lets try to address the bounce problem first. What is the nature of your sensor/signal such that bounce might be an issue? Do you expect bounce only after rising or falling edges, or potentially both? Do you have any feel for the max time the signal might bounce after a transition, or do you think it could just bounce up to the total period of 8 ms (1/125)?

#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 07 January 2010 - 01:05 PM

Another way to measure frequency: 4. Collect a waveform of analog data using stream mode (or maybe burst mode on a U12). Then process the data (consisting of at least 1 cycle) in software to determine frequency. The processing could be done with an FFT. Another way to process it is to find 2 consecutive peaks or midpoints and then just note the time between them. Perhaps just looking for when the signal passes from below to above some threshold, and then finding the next time it does that again. This technique is good when the signal does not comply with LabJack logic levels. For example, with a counter/timer on a U3/U6/UE9, the signal needs to go below 0.8 volts to be low and needs to go above 2.0 volts to be high. Using the analog technique you can work with arbitrary signal levels in software.

#5 Samuel Goodall

Samuel Goodall
  • Members
  • 17 posts

Posted 26 November 2013 - 09:33 PM

Would it be possible to measure slower pulses using the LabJack over a long period and then analyzing the data from say a 10 minute period as an analog waveform and running it through FFT? Not sure on the exact coding that would be required to achieve that though.

#6 Samuel Goodall

Samuel Goodall
  • Members
  • 17 posts

Posted 26 November 2013 - 10:24 PM

Gaargh didn't read the post right at the bottom. :P 


For 4) with collecting the waveform of analog data using stream mode, how would one gather the data for long-ish periods of time, say ten minutes? FFT does seem like the way to handle it for more complicated multi-frequency signals. 

#7 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 27 November 2013 - 09:20 AM

How to collect 10 minutes of data depends on what you are using for software, but for example it would be very easy with LJLog or LJStream.  I would consider using command-response mode (LJLog) first, as stream mode will give you gobs of data over 10 minutes.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users