Sixth-Z / Audit

Instrumentation health audit

Which of your sensors is lying?

CH-04 stuck since

Illustration. CH-04 still reports a reasonable number, but it stopped measuring: the other channels moved and it did not.

Stuck readings, noise, drift and silent data gaps. We go through your sensor history and tell you which sensor failed, since when, and what data you can trust.

Request an audit Sample report (PDF)

Bad data looks normal.

False alarms

A gauge that comes loose or a logger that glitches triggers alerts nobody can explain, and someone drives out to the site to check.

Blind spots

A stuck sensor keeps reporting a reasonable number. Nobody notices it stopped measuring until something actually moves.

Hours of cleanup

Before every report an engineer scrolls through spreadsheets hunting gaps, spikes and jumps by hand.

What we look for

Six ways a sensor fails

its neighbours the sensor stop trusting it here

Real case

Ultrasonic flow meter

Real installation, two months, one reading per second. Data anonymized. This is an excerpt of the report the client got.

Sixth-Z · Instrumentation health audit Ultrasonic flow meter (RS-485) · Aug 18 – Oct 15
of expected readings arrived (from Aug 25)
93 %
long outages, 25 h in total
6
~3,500 L/h spikes lasting seconds
64
flow–totalizer match, hours without gaps
0.98
Readings received per hour, hourly mean flow and totalizer of the meter, Aug 18 to Oct 15, with the first week without data, the irregular reception and the 64 spikes marked
FindingWhat to do
1Aug 18–25: almost nothing was logged, only a few minutes of the totalizers. Flow and temperature start on the 25th at 22:24.Check the logger configuration at start-up.
2Sep 1–17: irregular reception (most days 70–88 % of readings) and a ~16 h outage on the night of the 16th. On the worst days, up to 6 in 10 readings arrived in delayed batches, stored with the time they arrived instead of the time they were measured.It is the acquisition system, not the meter: the totalizer kept counting. On those days the exact second of each reading can’t be trusted.
364 spikes of 3,500–3,635 L/h that last a few seconds and start and end at zero flow. The forward totalizer does not count them, but 12 of the 16 steps of the reverse counter happen right as a spike starts.They may be real backflow (water hammer, a failing check valve) or a meter artifact. Inspect the check valve and the meter’s settings; meanwhile, keep those readings flagged apart.
4Without those spikes, flow follows the totalizer hour by hour (r ≈ 0.98 in hours without data gaps).The meter measures forward flow correctly; most problems are in the data chain.

Many sensors

Which sensor
is it?

We tested the audit on a real array of 9 strain gauges (24 h, 1 Hz) with 2,560 simulated faults, one at a time. A regression between sensors finds the fault and points to the sensor; a second check, which looks at whether that sensor stopped moving in step with its neighbours, confirms it.

1,639 / 1,639 times both checks pointed to the same sensor, and it was the right one, every time.

Pointed to the right sensor Confirmed by both checks

Stuck sensor
100 %91 %
Noise
100 %88 %
Level jump
100 %90 %
Gain change
97 %84 %
Slow drift
88 %1 %

In the report, every faulty sensor is marked confirmed or probable. Slow drift is caught by regression alone, so it shows up as probable. With faults half this size, the right sensor still comes up 91 % of the time; drift drops to 58 %. Simulated faults on 24 h of one real array; every audit is checked against your own records.

How it works

Three steps

  1. You send the history

    CSV or Excel, as many channels and months as you have.

  2. We analyze it

    Every sensor checked against the others and against itself over time.

  3. You get the report

    Plus a short call to go through what we found.

What you get

  • Which sensors failed and how: stuck, noisy, level jumps, gain changes, drift. Each one marked confirmed or probable.
  • Since when, so you know which data to discard or re-check.
  • What share of each sensor’s data you can trust, and where the gaps are.
  • Whether the problem is the sensor or the data chain (logger, communication, power).

What to send us

  • One file per array or per sensor: CSV, Excel or your platform’s export.
  • A date-time column and one column per channel.
  • At least one month; better if it includes an event you already know about.
  • If you have it, the maintenance log: it helps us confirm dates.

Works with exports from any logger or platform: Campbell, Geokon, Worldsensing, InfluxDB and others. Nothing to install.

Your data stays yours

You can rename channels and sites before sending. We sign an NDA if you need one and delete your files once the report is delivered.

Send us one month of data.

The first audit, on a sample of your data, is free. If nothing is wrong, you will know that too.

Request an audit →