40  Acquisition Timing and Buffer Contracts

40.1 Start With the Story

Picture an IoT team using the ideas in Acquisition Timing and Buffer Contracts during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.

Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.

40.2 Learning Objectives

After this page, you should be able to:

• Explain why event time, receive time, and clock source must be recorded separately.
• Choose NTP, PTP, or hardware timestamping based on sensor timing tolerance.
• Design bounded buffers and backpressure policies before outages or bursts occur.
• Pass acquisition metadata downstream so analytics can distinguish real events from timing, drift, or queue artifacts.

40.3 Why This Follows Edge Data Architecture

Edge Data Architecture classifies IoT device categories, connectivity paths, data volumes, and acquisition strategies. This page narrows in on the deeper contract that makes those architectures trustworthy: how samples are timed, buffered, synchronized, and described before they reach analytics.

Use it when a gateway, sensor fleet, or analytics pipeline must combine multiple sources, survive link outages, or support post-incident review where the difference between event time and arrival time matters.

40.4 Analytics Inherits Acquisition

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.

Intuition: analytics is only as honest as its raw inputs. A brilliant model fed mistimed, poorly conditioned samples produces confident nonsense — garbage in, garbage out, dressed up in charts.

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.

flowchart LR
  A["Physical phenomenon"] --> B["Sensor or transducer"]
  B --> C["Signal conditioning"]
  C --> D["Sampling and source timestamp"]
  D --> E["Buffer and local validation"]
  E --> F["Gateway aggregation"]
  F --> G["Forwarded event record"]
  G --> H["Analytics pipeline"]

Overview Knowledge Check

Phoebe’s Field Notes: The Upstream Sampling Question Behind the 100 Hz Stream

Phoebe’s Why

The pipeline above starts at “ADC sampling,” and two physics facts are already locked in before the first timestamp is written. First, a sampler can only faithfully represent a signal if it samples at least twice per cycle of the fastest real content – sample slower and a fast component folds back and impersonates a slow one, indistinguishable from a real reading. Second, every ADC code is a rounded value; the rounding error is small but never zero. Neither problem is a timing-sync bug, and neither can be fixed downstream: a perfectly synchronized clock on a corrupted sample just timestamps the corruption precisely. That is why this chapter’s own framing – “garbage in, garbage out” – starts at the transducer, not at the buffer.

The Derivation

Faithful sampling of content up to \(f_{max}\) requires:

\[f_s \geq 2f_{max}\]

Sampling too slowly folds a true component at \(f\) back to an alias at:

\[f_{alias} = \left|f - n f_s\right|, \quad n = \mathrm{round}(f/f_s)\]

An ADC quantizes to \(N\) bits over a reference range \(V_{ref}\), with step and RMS rounding noise:

\[q = \frac{V_{ref}}{2^N}, \qquad q_{rms} = \frac{q}{\sqrt{12}}\]

\[\mathrm{SNR} = 6.02N + 1.76\ \text{dB}\]

Worked Numbers: Behind This Chapter’s Own Streams

This chapter reports “100 Hz vibration summaries,” but that summary rate is the output of the acquisition stage, not the raw ADC rate – industrial vibration monitoring commonly needs raw content up to about 500 Hz to catch bearing and gear-mesh harmonics (a catalog-typical condition-monitoring bandwidth, not this chapter’s own figure). Nyquist then requires the original ADC to sample at \(f_s \geq 2\times500 = 1{,}000\) Hz, with an anti-alias filter ahead of it, before any decimation down to the 100 Hz stream this chapter’s buffer math uses. Skip that upstream filter and the “100 Hz” record is already folded before the clock-sync problem this chapter is about ever gets a chance to matter.

• Quantization, using a catalog-typical 12-bit ADC at \(V_{ref} = 3.3\) V: \(q = 3300/4096 = 0.806\) mV; \(q_{rms} = 0.806/\sqrt{12} = 0.233\) mV; \(\mathrm{SNR} = 6.02(12)+1.76 = 74.0\) dB
• That 74.0 dB noise floor is a separate ledger line from this chapter’s own 50 ppm / 180 ms-per-hour clock drift: quantization sets how much any single sample can be trusted; drift sets whether two samples’ timestamps can be trusted relative to each other
• Put together on the 100 Hz stream: the chapter’s own drift math already shows an hour of unsynced drift misaligning 18 samples (10 ms apart) – an 18-sample phase error rides on top of, not instead of, the quantization noise floor every one of those samples already carries

Two independent error budgets, from two independent physical effects, both have to be closed before a “100 Hz vibration” record is trustworthy: correct timing does not fix a corrupted sample, and a clean sample does not fix a misaligned timestamp.

40.5 Why Timestamps Need Sync

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)

Worked example: a 50 ms clock skew wrecks a fusion

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.

The lesson is that time is data. An accurate value at the wrong time is a wrong value for any analysis that combines sources, so clock sync is not a nicety — it is part of the measurement.

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

40.6 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. 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.

Event time vs arrival time

Network and buffering delays make the moment data arrives an unreliable clock. Timestamp at the source (event time) so ordering and analysis reflect when things happened, not when they showed up.

Buffering and backpressure

A bounded buffer smooths bursty acquisition against a slower link. When it fills, you must drop, block, or aggregate — a deliberate policy, because an unmanaged full buffer silently loses data.

Clocks drift

Cheap oscillators drift by parts per million, so a one-time synchronisation degrades over hours. Clocks must be re-synced periodically to keep timestamps accurate over a long deployment.

The acquisition contract

Downstream stages assume samples are properly conditioned, sampled at a known rate, and accurately timestamped. Break that contract quietly and every later analytic inherits the flaw with no warning.

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

40.7 Release Checklist

Before shipping an acquisition timing contract, verify these records:

• Each record carries source event time, gateway receive time, clock source, sequence number, and sample rate.
• Clock synchronization tolerance is matched to the fastest signal being fused, and drift is monitored after startup.
• Bounded buffers declare what happens when full: block, drop newest, drop oldest, aggregate, or mark gaps.
• Store-and-forward replay preserves original event time and records delayed receive or replay status.
• Downstream dashboards and models can see quality flags for stale, delayed, summarized, dropped, or clock-uncertain samples.

40.8 See Also

• Edge Data Architecture for device categories, data volumes, and acquisition strategies.
• Edge Acquisition Sampling and Compression for data-reduction methods.
• Radio Budget and Gateway Aggregation Contracts for radio and gateway summary tradeoffs.
• Multi-Sensor Data Fusion for downstream fusion requirements.

40.9 Next

Return to Edge Data Architecture, then continue to Edge Acquisition Sampling and Compression to reduce data volume while preserving timing evidence.