Engineering data that is properly collected will help you make better decisions in the design, integration, and testing stages of your system. Timing and synchronization are a very important aspect of collecting valuable data. Some of these strategies are general purpose, but others and specific to NI DAQmx.
Determine if your data acquisition should be hardware or software timed
- Timed by interaction of software to the hardware
- Good for simple single point acquisition
- High jitter and low time resolution
- Timed by physical clock
- Low jitter and high time resolution
Hardware buffer management
If you are sampling continuously on hardware timing, then the built-in hardware buffer is filling up while the data is being acquired. Each read function that you call will remove from the front of the buffer. If you add more often than you remove, you will run into a buffer overflow error at some point. One option to minimize buffer overflow issues would be to run an unthrottled read when possible. Using a read timeout would allow safe exit conditions in the case that the read doesn’t work.
Synchronizing to other data being acquired
Oftentimes, a system needs a most or all of the acquired data to be time synchronized. This will be easiest to accomplish with hardware timing. Multiple modules within the same chassis can be synchronized in DAQmx by including all of the modules on the same task. Some situations require the clock to be physically routed between different hardware modules or chassis and there is often synchronization and timing code that needs to be added.
It gets further complicated when the data is collected over a network connection without physical connections. In this case, a common synchronization method would be to use Time Sensitive Networking (TSN) or other timed networking protocols.
Synchronizing outside of the data acquisition
Synchronization gets trickier when the data acquisition needs to be synchronized to something else that is not data being acquired. This will be done using triggers and can be input or output triggers. An example of an output trigger is when a camera needs to be timed up to the data acquired and you can write an output that triggers the camera. An input triggered synchronization would be when data is acquired from an external stimulus. This data is not intended to be recorded or analyzed but can be used purely as a trigger to begin the data acquisition related to the stimulus.
FPGA for software timed, quick turnaround data
Even if your hardware is capable of very high speed data collection, the rates on the specifications sheet are usually for continuous data sampling. If you use software timed data collection and expect high precision timing, you will not be able to get what you are looking for. There are latencies inherent in triggering data acquisition in that way. In order to get the tighter time tolerances, you should consider using FPGA for your data acquisition loop.