Engineering

Sampled Values: what a device has to do when the waveform arrives over Ethernet

2026-10-29 · 7 min read

SV looks simple on paper: a publisher sends a block of samples on a fixed schedule and subscribers use them. What makes it hard is everything around that sentence — the rate, the alignment, the loss handling, and the fact that a late sample is worse than a missing one.

The publishing side

A merging unit samples the analogue inputs and publishes blocks of samples at a fixed rate with a sample counter and a time reference. The rate is chosen by the application: protection-grade streams are far denser than measurement-grade ones.

Two things must be right at the source: the sampling must be periodic to within the tolerance the application needs, and the counter must be continuous so receivers can detect gaps.

The receiving side is where products fail

• Loss detection: a gap in the counter is the only signal that data is missing. A receiver that processes what arrives and ignores the gap produces a waveform with a silent discontinuity.
• Reordering: Ethernet does not guarantee order across paths, and duplicated messages occur. Handling both means sorting by counter within a window rather than assuming arrival order.
• Time alignment: if several streams must be combined (three phases, or two merging units), samples have to be aligned on a common time base. Without synchronisation, combining them is guesswork.
• Buffering: a fixed-size ring with a defined policy when it overflows. Growing queues turn a momentary network hiccup into a latency problem that outlives it.

Why synchronisation is not optional

SV carries a time reference, and combining streams from different merging units requires the receivers to share a time base. This is why process-bus deployments go together with PTP and hardware timestamping: without it, the samples are individually valid and collectively unalignable.

Testing SV properly

• Inject a known waveform through a merging unit simulator and verify the receiving device reproduces it within its stated accuracy.
• Drop messages deliberately and confirm the device flags loss rather than continuing silently.
• Duplicate and reorder messages, then confirm the output is unaffected.
• Step the time source and confirm the device marks the stream invalid rather than aligning to a wrong reference.

Questions that come up

Do we need a hardware-timestamping NIC?

For receiving SV at protection rates with meaningful accuracy, effectively yes. Software timestamping introduces jitter of the same order as the tolerance you are trying to meet.

Can SV and GOOSE share a VLAN?

They can be carried on one network, but the usual recommendation is separate VLANs with priority handling, because mixing a dense periodic stream with sporadic critical events makes the worst-case latency of both harder to bound.

Is SV relevant outside digital substations?

Its main use is the process bus. Elsewhere, sampled data usually arrives through a different mechanism entirely.

Keep reading