Skip to content

TimeNet VitalDB reader

The reader that loads VitalDB's .vital files with this atlas's corrections applied: records after each reset put back in order, every sample placed by its count, the corrected scale factors and the whole-file time zero.
Repository github.com/OpenTSLM/TimeNet
Branch main
Visibility public
Language Python
Documentation https://docs.timenet.ai
Related vitaldb-bench

What it is

The VitalDB reader is one of the dataset connectors in the open TimeNet project (timenet-connectors). It reads .vital files into records and tracks with exact sample times. The atlas uses it as the place where its findings about the files are applied on reading, so an analysis that loads VitalDB through it starts from corrected data.

Its part in the atlas

What the reader does about the atlas's observations:

vitaldb-bench checks what it reads against the source files. Changes to the reader made during this work may be ahead of the public repository until they are merged.

What is in it

The VitalDB reader
connector.py Reads .vital files into TimeNet records; import options, including the reset reordering.
resets.py Finds the reset clusters in an SNUADC track and puts their records back in sampling order.
test_resets.py Tests of the reordering rule, including the variant clusters.

Studies that use it

Study Code Summary
Records out of order at SNUADC resets, and where the lost time goes …/vitaldb/resets.py, …/tests/test_resets.py At every SNUADC reset the five records after it are written out of order: two continue the old timing and three start the new. Put back in order, the waveform runs on with no samples missing; the 18–20 ms lost at each reset goes missing inside the last old-timing record, and an extra zero sample follows.

Observations it handles

Observation Status Summary
Five records out of order at every SNUADC reset established At each step-mode reset the five records after it are written in the wrong order: two continue the old timing and three start the new, interleaved. Read in file order, or sorted by stamp, one second of signal is scrambled.
Primus waveform gains are wrong in every recording, for CO₂ or for AWP established Recordings store the Primus waveforms with one of three sets of scale factors. Checked against the Primus's own ETCO₂ and PIP numerics in all 6,388 recordings, CO₂ fits only 0.075 mmHg per code and AWP only 0.1 mbar per code with offset −20, so most recordings overstate CO₂ by a third, and the others overstate AWP by about 3% (950 recordings) or understate it about fourfold (26).
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.

Mentioned in

References

  • Maritsch M, Stoffregen T, Kaar T, et al. TimeNet: an extensible unified data infrastructure for next-generation temporal foundation models. arXiv:2610.04407. 2026. ↗