Data Acquisition (DAQ) and Control from Microstar Laboratories

Knowledge Base: Processing

  • See the list of other topics for category Processing

Q10035 Synchronizing DAP and application timing

Tags: Help, DAP, DAPL, application, timing, synchronization

Applies to: All DAP and DAPL, all real-time PC host applications

I am doing a kind of stimulus-response test. Each stage of the test takes two seconds. My application sends a stimulus signal for the DAP to output, and this begins a new test cycle. My sampling rate is 1000 samples per second, so I delay my application two seconds, and then read a block of 2000 samples. Things seem to work fine at first... but they soon deteriorate, with the responses having no clear relationship to the stimulus. What is happening and how do I fix this?

You need to redesign your system so that it does not depend on two sources of timing simultaneously.

In the secenario you described, the DAP sampling operates on its own separate clock. Every second it grinds out 1000 new samples. If the host application is delayed for any reason (the software is running under an extremely complex Windows system!), the DAP continues measuring and its sample values accumulate in memory. This automatic buffering is useful, but it can be very confusing when your host system starts getting old data from memory, thinking that it is fresh data from current measurements.

When an application uses a delay function, that function will guarantee that the application does not continue during that interval. But it does not guarantee that the processing will awaken promptly. The differences can easily cause several samples of skew between DAP activity and the PC host.

There are basically two strategies you can use to coordinate the DAP measurements and the host system: a "push strategy" or a "pull strategy."

  • Push strategy. The DAP timing determines when activity happens in the host system. The host system provides extra "stimulus data" with plenty of lead time. The DAP system disregards this data until the previous cycle is over. Then it loads the next stimulus value, initiates the next data collection cycle, and soon delivers the completed data block. In the PC host, after the processing for the previous cycle is completed, execution arrives at the thread for fetching new acquisition data. There it waits for data arrival. The data fetch operations of the DAPIO32 interface do not continue execution until the expected data arrive.
  • Pull strategy. The host timing determines when activity happens in the DAP system. The DAP system uses a software triggering scheme. When the host is ready, it sends a message to the DAPL processing. The arrival of this message triggers DAP activity. When enough new samples are ready, the results are transferred to the host. The host uses a DAP data fetch operation to receive the data block, and this operation does not continue execution until the expected data block arrives.
  • Most recent block strategy. This is a variant of the pull strategy. It is very effective when the requirement is to measure "a sufficiently long time" after a stimulus change. Under this strategy, the PC host immediately sends a new excitation value after reading the results from the previous measurement cycle. On the DAP side, the new excitation is used immediately. Samples are captured, but maintained as a history of "pre-trigger data" in memory, not delivered to the host system. "After a sufficient time" determined by the host application, it sends a message for the DAP to release the "most recent block". The samples come from memory, and arrive very quickly. The last sample in the data block is the most recent one measured. This strategy is very time-efficient, because the host does not wait for new data collection.

Whether the host initiates the activity, or the DAP does, only the DAP clock can determine when the results are available. So it is essential to wait for the data to arrive from the DAP, and not use host timing for this purpose.


The DAPIO32 Reference Manual describes the timing features of the DAP functions that send data to host applications from the DAP board.