5 Acquisition Timing and Buffer Contracts

5.4 Analytics Inherits Acquisition

This section: Analytics Inherits Acquisition — Every analytics result rests on the data acquisition pipeline that produced its inputs.

Every analytics result rests on the data acquisition pipeline that produced its inputs. That pipeline runs from the physical phenomenon to a clean, timestamped, buffered stream: transducer → signal conditioning → ADC sampling → timestamping → buffering → local processing → transmission. Each stage can quietly corrupt the data, and downstream analytics will faithfully compute on the corruption.

One stage is deceptively critical: the timestamp. A value without an accurate time is nearly useless for correlating events or fusing sensors, and accurate timestamps require the devices' clocks to be synchronised. Getting acquisition right — especially time — is the unglamorous foundation of trustworthy analytics.

Worked example: a greenhouse controller reads a soil-moisture probe through an ADC, a Modbus temperature sensor through a gateway, and a camera through Wi-Fi. If the ADC channel is sampled every minute, the Modbus poll runs every five minutes, and the camera reports only motion summaries, the analytics layer must preserve those differences instead of pretending all evidence is equivalent. The acquisition record should say which device produced the value, how it was conditioned, when it was sampled at the source, what local filter or aggregation was applied, and whether the gateway forwarded a raw value, a rolling average, or an event record.

That record is what lets an engineer debug a bad recommendation later. If plant-stress alerts appear ten minutes late, the fault may be the sampling interval, gateway buffering, clock drift, or a cloud model threshold. Without the acquisition contract, every downstream component can look correct while the system still acts on stale or misaligned measurements.

Overview Knowledge Check

The mathematical gist. A catalog-typical 500 Hz vibration band needs at least 1,000 raw samples per second before it becomes this chapter’s 100 Hz summary stream. A 12-bit, 3.3 V ADC adds a separate 0.806 mV step and 0.233 mV RMS rounding noise. The chapter’s 50 ppm clock then drifts 180 ms in one hour, equal to 18 intervals in the 100 Hz stream. Sampling, quantization, and time alignment are independent ledger lines: fixing one does not repair either of the others.

Math Bridge · guided foundationsHow can a clean sample still arrive at the wrong time?Let Data Dora keep sampling, ADC rounding, and clock drift in one visible ledger. Learn the maths

5.5 Why Timestamps Need Sync

This section: Why Timestamps Need Sync — Worked example continuation: imagine the same gateway also receives pressure samples at 10 Hz and vibration samples at 100 Hz.

To compare or fuse data from multiple sensors, their timestamps must share a common time base, which means synchronising clocks:

NTP (Network Time Protocol): syncs clocks over a network to ~milliseconds
PTP / IEEE 1588 (Precision Time Protocol): sub-microsecond on a LAN with
                                           hardware timestamping
Timestamp at the SOURCE (event time), not on arrival (arrival is delayed)

Two sensors each sample a shared 100 Hz signal
(one sample every 10 ms). Their clocks differ by 50 ms.

  50 ms / 10 ms = 5 samples of misalignment.

When you fuse or correlate them, features line up 5 samples
apart -> the fusion sees a phantom lag, cross-correlations
peak in the wrong place, and event matching fails.

NTP (~ms) may be borderline here; PTP (sub-microsecond)
removes the skew entirely for tight multi-sensor work.

Worked example continuation: imagine the same gateway also receives pressure samples at 10 Hz and vibration samples at 100 Hz. If the system stores only arrival order, a network burst can make an older pressure sample look newer than a vibration sample that was actually captured later. A practical design stores source event time, clock source, sampling rate, and gateway receive time for every record. Then the fusion job can resample onto a common timeline, reject stale values, and flag when the clock source is outside tolerance instead of silently correlating the wrong measurements. The operator view can also show a clock-health badge, so a maintenance engineer knows when a strange correlation came from the plant rather than from the timing system.

Practitioner Knowledge Check

5.6 Event Time, Buffers, and Drift

This section: Event Time, Buffers, and Drift — The acquisition layer should store two times when it can: event time, captured as close to the sensor as possible, and receive time, recorded by the gateway or server.

The acquisition layer should store two times when it can: event time, captured as close to the sensor as possible, and receive time, recorded by the gateway or server. Event time orders the physical process; receive time diagnoses network and buffer delay. When both are present, a later analytics job can tell whether a point was genuinely late, delayed in transit, or replayed after an outage.

Clock drift turns into real alignment error quickly. A modest 50 ppm oscillator can drift about 180 ms in one hour because 3600 seconds times 50 / 1,000,000 equals 0.18 seconds. For a slow temperature trend that may be tolerable. For a 100 Hz vibration stream, where samples are 10 ms apart, the same one-hour drift is 18 samples of timing error. That is enough to break correlation, phase estimates, and event matching even when every value is numerically correct.

Buffers need the same explicit design. Suppose a gateway receives 100 Hz vibration summaries at 48 bytes per record, or 4.8 kB/s. A 64 kB buffer holds only about 13 seconds of that stream before it must block, drop, or aggregate. During a two-minute cellular outage, the raw backlog would be about 576 kB, far beyond that small buffer. The architecture therefore needs a declared policy: keep newest raw samples, downsample older data, emit min/max/RMS summaries, or mark gaps.

The contract passed downstream should include the sample rate, source timestamp, clock source, sequence number, gateway receive time, buffer policy, and quality flags. These fields are not bureaucratic metadata; they are how a dashboard distinguishes a real plant event from clock drift, link congestion, gateway reboot, or silent packet loss.

So the acquisition architecture is a contract, not a formality: condition the signal, sample at a known rate, timestamp at the source on a synchronised clock, and manage the buffer explicitly. Honour it and analytics can trust its inputs; break any clause — especially time — and the most sophisticated model downstream is computing on data that never meant what it claims.

Worked example: a gateway with a 1,000-record ring buffer receives vibration samples faster than its cellular link can upload during a network outage. A good architecture declares the policy before the outage: keep the newest second of raw samples, aggregate older samples into min/max/RMS summaries, and mark any dropped intervals in metadata. A weak architecture just overwrites records silently. Both systems may show a smooth dashboard later, but only the first one tells the analyst which evidence is complete, summarized, or missing. That distinction matters when a post-incident review asks whether the vibration spike was absent, averaged away, or lost during backpressure.

Under-the-Hood Knowledge Check