Skip to content

SNUADC stamp arithmetic

Between corrections the SNUADC block stamps run −0.95 ppm against the sample count: each 0.2 s increment is about 0.19 µs short. This, not clock drift, is the "about −1 ppm" seen in frequent-correction mode.
Date 2026-10-17
Status current
Methods Reading the stamps
Clocks SNUADC sample clock, Recorder PC clock
Devices SNUADC, Vital Recorder
Variables ECG lead II (SNUADC)

Data

Six short-to-medium files (1.4–2.6 h), chosen at random; consistent with the frequent-correction rows and the paced recordings in the rest of the atlas. Then a census of the record stamps of all 6,388 files (17 October; tools/snuadc_stamp_census.py): 12,583 stretches of at least 10 minutes between corrections, 19,706 recording hours, in the 6,321 files with SNUADC whose records do not overlap throughout.

Method

For each record, the stamp minus the time given by the sample count, e = (stamp − start) × 500 − samples so far, was fitted for slope within each segment between corrections.

Results

  • −0.954 ppm in every segment of the six files, the same in step and frequent-correction mode.
  • Frequent-correction mode is not drifting. Its "about −1 ppm" of stamps against the count is this arithmetic; the real drift in that mode is under about 1 ppm.
  • The census holds it, with exceptions: the median slope is −0.9535 ppm, and 89.5% of the recording hours lie within 0.05 ppm of −0.954. But 747 files (12%) sit elsewhere, from about −0.90 to −0.55 ppm (median −0.85), with no trend through the release.
  • Stamp-based loaders lose about 1.6 samples per hour (32,020 in all): one about every 37 minutes, as predicted.
Histogram of stamp slopes in ppm; a sharp peak at −0.954 holds most recording hours, with a tail towards −0.70.
Slope of record stamp minus sample count within each stretch between corrections, weighted by recording hours, for every file in the release.
Parameter Value Status From
SNUADC stamp arithmetic −0.954 ppm (n = 6321; census of 6,321 files (17 October): median −0.9535 ppm; 89.5% of recording hours within 0.05 ppm of −0.954; 747 files (12%) between −0.90 and −0.55 ppm) measured SNUADC stamp arithmetic

Discussion

The likely cause is fixed-point arithmetic: a 0.2 s increment held at a resolution of 2⁻²⁰ s. That is unproven. The vitaldb package places blocks by rounding their stamps up to a sample, so it overwrites one sample about every 35 minutes; placing samples by count, as the TimeNet import does, avoids it. Rates read from stamps carry the −0.95 ppm, which is negligible beside their spread.

Observations it supports

Observation Status Summary
SNUADC stamps run −0.95 ppm against the sample count established Between corrections each 0.2 s record stamp increment is about 0.19 µs short: stamps run −0.95 ppm from the sample count in 88% of files (both SNUADC modes). It is arithmetic, not clock drift. The other 12% sit between −0.90 and −0.55 ppm.
Stamp-based loaders lose samples at overlaps likely Loaders that place samples by their stamps onto a grid overwrite samples where stamps overlap: about 0.48 s at every SNUADC reset, and one sample about every 35 minutes from the stamp arithmetic.

Limitations

What sets the slope in the 12% of files that differ is not known (a different recorder build, or a different increment), and the cause of −0.954 itself (fixed-point arithmetic) is unproven.

Open questions

  • How far does the SNUADC drift in frequent-correction mode? (conflict between studies). Between corrections the frequent-mode stamps show only the −0.95 ppm of stamp arithmetic, which is why the real drift in that mode is put under about 1 ppm. But the small forward corrections that keep those stamps on the PC add up to more: about one an hour of +5 to +15 ms (SNUADC frequent-correction steps), and the correction scan's per-recording drift for the 82 frequent-mode recordings it could fit has a median of +2.7 ppm (10th percentile −0.9; Clock corrections in every file). The drift against the PC is what the corrections remove, so it may be a few ppm rather than under one. Not reconciled.
  • Why 12% of files run at a different slope (unexplained phenomenon). 747 files sit between −0.90 and −0.55 ppm instead of −0.954, with no trend through the release. A different recorder build or a different stamp increment are the obvious candidates; comparing these files' header version, device list and correction mode with the rest would test it.
  • A fixed-point stamp behind −0.954 ppm (weakly supported hypothesis). A 0.2 s increment held at a resolution of 2⁻²⁰ s fits, but is unproven; the recorder's source or one controlled recording would settle it.