Spurious Spikes in CompactRIO FPGA Measurements

Updated May 22, 2018

Reported In


  • CompactRIO Controller


  • LabVIEW

Issue Details

I use a CompactRIO FPGA VI to continuously measure the period length of a sine wave. In the measured values I receive spurious spikes that seem to occur at regular timing:

I used an oscilloscope to verify that the voltage signal itself does have a constant period.
The LabVIEW FPGA measuring takes place in a loop that captures other data as well:

When I change parts of my FPGA code that are not directly connected to the measuring, the spikes change in amplitude and/or rate, and sometimes even vanish completely. What is the reason for these spikes, and how can I get rid of them?


Both the NI-9225 and NI-9238 have delta-sigma ADCs, which means that each of them has its own independent hardware clock. To solve the issue described above, the clocks of the different input modules need to be synchronized to each other.

To do so, the internal clock's signal of one of the CompactRIO modules used shall be exported so the other module(s) can use this clock signal instead of their own ones. The second part of the page titled Configuring the Master Timebase Source for a Module (FPGA Interface) from NI CompactRIO Device Drivers Help explains how to define a master module, and how to share its master time-base source with other, slave modules.

Additional Information

The cause for this issue is the natural drift of clocks relative to each other and the behavior of the Analog Input (AI) node in FPGA.

As mentioned, each c-series module with a delta-sigma ADC uses its own hardware clock. Even if two of them are both configured to run at 5 kHz, they will still drift compared to each other. This is due to clock accuracy, which is e.g. ±100 ppm for the modules used in the example above. This value can be found in the data sheet of each module.

During execution the FPGA I/O Node waits until a new value from hardware is available. As the "Analog In loop" in the example above has FPGA I/O Nodes reading from two different analog input modules, this loop is running at the rate of the "slower" module's clock. Due to this the other FPGA I/O node will miss a sample of the "faster" module once in a while.


Not Helpful