Support and Documentation

Data Acquisition (DAQ) over WiFi: Technical Considerations


Considerations for the T7-Pro

WiFi on the T7-Pro works well for a specific set of applications. The key constraints are:

  • SSID and Password are limited to alpha-numeric characters only

  • The network security must be set to WPA2 or None.

  • Data rates are limited. For application that need to take a measurement once a second or once a minute, the T7-Pro's WiFi works well. While higher speeds are possible they require special application considerations, discussed below .


Considerations For All Devices

While WiFi offers convenient wireless data transfer for DAQ devices, its inherent instability poses unique challenges for real-time data collection. Understanding these limitations is critical to designing a robust system.

Key Technical Challenges

  • Lower Sustainable Throughput: The sustainable data rate over WiFi will usually be much lower than standard wired connections like USB or Ethernet.

  • Connection Instability: WiFi devices can occasionally drop off the network. When this happens, rejoining typically takes 2 to 3 seconds. While a smartphone user might only notice a slight delay in a webpage loading, a DAQ system can lose thousands of data points in that brief window.

  • Network Congestion: High traffic from multiple devices communicating simultaneously can cause significant bandwidth throttling.

  • Latency Spikes: Standard communication overhead is generally 3–7 ms, but network congestion can cause unpredictable spikes reaching 300+ ms.

When designing a DAQ system that relies on WiFi, you must account for these inconsistencies. Two proven strategies include:

  1. Implementing a Buffered System (Recommended)

    • How it works: The DAQ device stores data locally in a buffer during network slowdowns or disconnections. Once a stable connection is re-established, it transmits the backlog of data.

  2. Designing for Data-Loss Tolerance

    • How it works: Build the system to gracefully handle missing "chunks" of data without crashing or throwing critical errors.

    • Best suited for: Slower sampling rates or simple, non-critical monitoring applications where absolute data continuity isn't mandatory.