Site Search:

Synchronized Data Acquisition Options


Sometimes you need to acquire data from several different locations that are separated far enough from each other that they cannot be acquired by a single, multichannel system. This defines the need to synchronize readings from two or more data gathering systems. In situations like that, how you solve the problem is dependent upon the nature of the data you need to acquire and the time frame that you need to acquire it.

In a previous post I talked about clock accuracy in the form of a parts per million (PPM) specification. It’s possible to rely only on clock accuracy to effectively synchronize measurements from geographically separated data loggers. For example, if we assume that temperature measurements from two different locations need to be acquired over a period of two months using a low cost data logger product like this, we can easily determine the worst case accumulated error over that time frame. That figure can be compared to the requirements of our unique situation to determine if the approach is feasible. If the data logger’s clocks are speced at ±20 PPM, then we know that worst case drift of any single logger will be ±104 seconds (60 · 24 · 60 · 60 · ±20 ÷ 1,000,000). Since the PPM spec is a plus and minus number, then worst case separation will occur when one logger runs at the high end of the spec and another at the low end, or 208 seconds (3 minutes and 28 seconds). If you determine that temperature cannot change significantly between multiple locations within this time frame then you may be justified to use a low cost approach and rely solely upon clock accuracy for synchronization. Should you determine that the approach will not work, you can seek a logger with better clock accuracy as measured by its PPM spec to tighten the time difference, or you might need a solution that guarantees data acquisition synchronization to the microsecond level.


Follow Us

 Categories: Data Acquisition

 Bookmark the permalink

 RSS Feed (comments for this post)

 Post a comment

 Trackback URL


  1. Avatar
    Mo sharif
    Posted July 27, 2023 at 10:55 am Permalink


    I have run a test using 2 x DI-2008 with 16 thermocouples connected across. I am using Windaq for data logging into a .WDH file and later exports to CSV. Both boxes are running from the same hub (recommended by UK distributor). The data is logged every 10th of a second giving a total of 160 samples/ second across both devices. The test ran for a duration of approx. 5 hours, but the majority of the time the thermocouples were measuring room temperature up until the beginning of our process and then the temperature measurements started to increase as expected. the duration of the measured temperature bump is approx. 10 minutes. When analysing the data; we could see a time shift in the measured temperatures between the two devices, this difference is approx. 13.9 seconds. When plotting the data, it was clear that the data is split into two groups based on the source of the acquisition device. Mapping the position of the thermocouples to their measured temperature further confirm this time shift effect; where thermocouples adjacent to each other but wired to two different devices tend to show the 13.9 seconds shift in time, and thermocouples positioned at different height wired to the same device seems to show almost a simultaneous rise in the temperature. My question is, what is the expected synchronisation error considering my test set up. Please feel free to ask me for more details on the test.

    Many thanks

    • Posted August 29, 2023 at 9:20 am Permalink

      Are you using WinDaq channel streatch to sync between the two units? We don’t expect any sync error at this sample rate. Please submit a support ticket so that we can resolve the issue, thanks!

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>