What is deliberately wrong with sensor-telemetry

What is deliberately wrong with sensor-telemetry.

8,000 rows, 8 columns, one row per sensor reading. Eight thousand readings from twelve machines across three sites, at ten-minute intervals, with drift, seasonal temperature, injected anomalies, and gaps where a gateway dropped offline.

There are two failure modes deliberately hidden in here: a slow bearing-wear drift on vibration_mm_s for two machines, and sharp single-reading spikes that are sensor glitches rather than real events. A good anomaly detector separates them. Timestamps are not evenly spaced — the gateway at site RIV drops out for stretches, so resampling before modelling is not optional.

Something to try: Detect the drifting machines with a rolling z-score; tune the window. The SQL playground has it loaded already, and the data explorer will profile every column in one pass if you would rather look before you query.

select *
from sensor_telemetry
limit 20;

The file is generated from a fixed seed, so the CSV you download today is byte-identical to the one from last year. That matters more than it sounds: it means a lesson can say "row 412 is the interesting one" and still be right in eighteen months.

Download it, break it, keep it. CC0 — no attribution required, no account, no email.