KALTECH · the self-diagnosing sensor · one document, six tabs

A sealed box, bolted to a machine,
that knows when the machine is dying.

No prior knowledge needed — every technical word on these pages is either explained in place or has a dotted underline you can hover for a plain-English meaning. Start here, then use the tabs above.

This is what the sensor hears — live

each ▾ marks a ball striking the crack — ~76 impacts every second

Every rotating machine — a pump, a fan, a train axle — vibrates. A healthy machine hums smoothly. A machine with a cracked bearing ticks: every time a rolling ball passes over the crack there is a tiny metallic impact. Those impacts start months before the machine actually fails — if something is listening.

The invention in one sentence: a battery-powered sensor that diagnoses the machine inside its own chip — and then uses that diagnosis to decide, by itself, when to wake up next, how long to listen, and when to raise an alarm. Diagnosis controls the hardware. That closed loop is the patent.

Why that loop matters

Battery life
A healthy machine is checked rarely — the sensor sleeps, sipping from a battery that lasts 5+ years. No wiring, no mains.

Early warning
The moment degradation starts, the sensor itself shortens its own check interval. Weeks of warning instead of a surprise breakdown.

No cloud needed
The whole diagnosis runs on a chip that costs a few dollars. No internet, no server, no data scientist on call.

Why nobody else's approach works as well

The traditional method sets a single loudness threshold — "alarm when vibration exceeds X." But measured on public test data, a single extreme reading on a healthy machine crosses such thresholds 36.6% of the time — transient bumps, a passing forklift, a tool dropped nearby. Alarms that cry wolf get ignored, and then the real failure is missed. This design's core rule: nothing alarms alone. Every accusation needs two independent pieces of physical evidence — and the worse the accusation, the more agreement it demands. That drops false alarms to under 1% while keeping the early warning. Tab 4 shows the receipts.

The apparatus · six modules · every algorithm ends in a hardware action

One device, six blocks. Click any block.

Reference numbers (110–160) are the patent drawing numbers. The teal ring is the loop: the diagnosis (130) sets the schedule (140), and the schedule controls the microphone-side (110) — the device runs itself.

Why this survives "it's just software" objections: no block here is a computer program floating in the cloud. Every algorithm's output is a physical act of this box — a timer programmed, a sleep state entered, a memory sector written, a radio transmission made or withheld.

110Sensing unit — the earexpand

An accelerometer pressed against the machine converts vibration into an electrical signal, captured in short recordings (~0.17 seconds each). It deliberately keeps the very high frequencies — above 1 kHz — because that's where metal-on-metal impacts appear long before the machine gets audibly louder.

Hardware tie. When and how long this block listens is set by block 140 — the loop's input side.

Claims6 — the apparatus14 — speed-adaptive capture

ReadDetailed Description → System Architecture

120Processing — turns sound into numbersexpand

The chip reduces each recording to a few hundred numbers, each answering a different physical question:

121Spikiness (kurtosis) — is the vibration smooth, or is something knocking?
122Loudness in the units the international severity standard (ISO 10816 zones A–D) is written in.
123The rhythm check — from the bearing's geometry and speed, the chip computes exactly how many impacts per second each kind of crack would make (outer ring ≈ one rate, inner ring another, ball another, cage another). Then it listens for a rhythm at exactly those rates. See the live demo in Tab 3.
124The magnifying glass — automatically finds the frequency band where impacts hide best, and re-runs the rhythm check there (catches faults months earlier).
126Speed, with no speed sensor — the chip works out how fast the shaft is turning from the vibration alone, and discards recordings taken while the speed was wobbling.

Hardware tie. All of it runs on the battery chip in a fixed memory budget. The identical arithmetic runs on the chip and on the server, held identical by automated bit-for-bit comparison tests.

Claims241618·19 — tachless speed

EvidenceExperiments 6, 11, 17 (chip = server, bit-for-bit)

130Fault decision — the juryexpand

Several independent judges look at the same numbers, and the device only accuses the machine when judges that cannot share a bias agree:

131The physicist — rules grounded in mechanics: impacts, rhythms at the computed rates, repeating patterns.
132The pattern-matcher — a trained model that names the most likely fault from the same numbers.
133The humility check — measures how unfamiliar this machine looks compared to everything the model was trained on. Too unfamiliar → the model is demoted to advisory. The device prefers "I don't know this machine yet" over a confident wrong answer. No commercial competitor does this.
134The impact watch — tracks the high-frequency peaks against this machine's own history; even catches the end-of-life signature where impacts get quieter while the noise floor rises.
135Commissioning — the first ~10 healthy check-ups become this machine's personal "normal", stored in the box. From then on, abnormal means abnormal for this machine. When a technician later marks an alarm right or wrong, the thresholds move — the box learns from repairs, never needs retraining.
136The verdict ladder — the ordered rules you can operate yourself in Tab 3.

Hardware tie. Baselines, latches, and history are physical state in the box's permanent memory; the verdict drives the schedule and the radio. A decision changes what the device does — it is not a report.

Claims78 — strongest, no prior art91120-22 — honest "uncertain"23242527

Figures28 · 29 · 30 · 31

EvidenceExperiments 8–16, 18

140Adaptive sampling — the loop headexpand

Converts the verdict — and how fast it is changing — into urgency, and urgency into the device's own behavior: when to wake, how long to listen, whether to take one long deep recording, how often to transmit. Healthy → checked rarely (years of battery). Degrading → checked often (weeks of warning).

Hardware tie — the headline claim. The output of this block IS a hardware schedule: real-time-clock alarms, sleep states, recording length, radio duty.

Claims1 — the loop5101415

EvidenceExperiments 1–4, 9–13 (weeks of lead time on run-to-failure data)

150State memory — it remembers this machineexpand

The box's permanent memory of the specific machine it is bolted to: the learned "normal", adjusted thresholds, impact history — and a lifetime health archive: tiny 48-byte records, room for ~39 years of check-ups. The machine's whole health story is recoverable from the sensor alone, even if every server is gone.

Hardware tie. Every "per-machine" behavior is a physical state in this memory — not a row in someone's cloud database.

Claims26 — lifetime archive827

160Comms — speaks only when usefulexpand

Radio is the biggest battery cost, so the device batches routine news and transmits immediately only on events. It can also receive: a technician's "that alarm was right/wrong" comes back down this link and adjusts the box's thresholds.

Hardware tie. Radio duty cycle is a controlled output of the diagnosis — part of the loop.

Claims17153 · 12-13 — fleet knowledge, via this uplink

Two live demonstrations · no background needed

Demo 1 — hearing the rhythm of a crack

The trick that finds bearing damage months early: don't listen for loudness, listen for a rhythm. From the bearing's geometry, the chip knows a crack on the outer ring will be struck ~76 times a second at this speed. Left: the raw vibration (grey) and its envelope (teal). Right: the rhythms found in that envelope. Flip the buttons.

on the damaged bearing, one bar stands up at exactly the predicted rate — that's the fingerprint

The subtlety that matters (and that this design gets right, measured in Tab 4): sometimes an innocent machine hum happens to sit at that exact same frequency. Rhythm alone can lie. So rhythm evidence never convicts by itself — the jury below demands impact evidence too.

Demo 2 — operate the verdict ladder yourself

This is the actual decision logic (simplified to its core conditions, real ordering). Drag the evidence sliders — the first rule whose conditions hold, fires. Try the presets — including “the innocent-hum trap”, the failure mode that fools single-threshold systems and that this ladder is built to refuse.

loudness zone (ISO) B

spikiness (kurtosis) 2.8

band spikiness (SK) 1.5

physics evidence 0.20

model says Outer Race

model confidence 0.60

unfamiliarity (d²) 300

loudness shift vs normal 0.10

machine commissioned

its healthy spikiness 3.0

—

What the box does next — the verdict IS a schedule (Claim 1)

Next wake — sleep length

Capture

Radio

bar length = relative sleep before the next check-up (illustrative — the real mapping is the exponential interval curve, drawing 4)

Try "the innocent-hum trap": a machine hum sitting exactly on the predicted crack rhythm convinces the physicist AND the pattern-matcher at once — and the ladder still refuses to confirm, holding it at DEVELOPING until something actually knocks. Push unfamiliarity past 572 and the humility check demotes the model. "Rotor imbalance" confirms WITHOUT spikiness — correct, because imbalance physics is smooth, not impacting.

Blind validation · public datasets · labels applied only at scoring

Measured, not claimed

Everything was tested blind — the engine never saw the answer key. Test material: the gold-standard public bearing datasets (bearings run until they actually died, from labs in the USA, China and France) plus 529 recordings of certified-healthy machines. Every verdict was traced to the exact rule that produced it.

Question	Result	Meaning
Does it catch real failures?	12/12 bearings run to failure detected	11 confirmed + the cage failure correctly tracked as "developing" with the right name (94% vote)
How early?	57–99% of life remaining	On one 7-day test the commissioned device confirmed at 17% of life — vs 72% for the traditional threshold. Weeks of extra warning.
Does it name the right part?	6/7 documented elements	Outer ring, inner ring, ball — correctly named on natural (not staged) failures
False alarms on healthy machines?	0/5 never-failed bearings	The true-negative test: bearings that ran healthy for the whole trial, zero false confirmations
Does the humility check work?	100% outer-ring precision retained	On a bearing family the model had never seen, the model alone collapses to 3.9% accuracy — the physics fallback keeps working
Chip = server?	360 scans · 0 mismatches	The sensor's chip and the server produce bit-for-bit identical verdicts

How early the commissioned device confirmed — % of each bearing's life already consumed at the first sustained CONFIRMED

Derived from the 2026-08-07 blind two-act run: the first point where two consecutive check-ups returned CONFIRMED or worse (the campaign's sustain rule), commissioned device. Everything right of a bar is warning margin. The thin dark tick is the day-one (uncommissioned) device — on the IMS bearings, commissioning buys dramatically earlier confirmation. FEMTO's failed elements are undocumented by that dataset.

The two things this campaign fixed (patent Figures 30–31)

The innocent-hum trap
A machine hum sitting exactly on a predicted crack-rhythm fooled the rhythm judge and the pattern-matcher at once — they were reading the same line. Found on certified-healthy machines confirming 30–100% of the time. Fix: rhythm agreement can no longer convict without impact evidence from the same recording. False confirms: 4/5 → 0/5. Every real detection kept.

"Impulsive" now means impulsive for this machine
Some healthy machinery (gearboxes, reciprocating) is naturally spiky — fixed thresholds accused it for being itself. After commissioning, the thresholds rise to 1.5× the machine's own healthy level. Healthy rough-rig false confirms: 88–95% → 19–69%, quiet machines untouched, all real detections kept.

False confirms on certified-healthy rigs — day-one defaults vs after commissioning (the Fig. 31 mechanism)

529 certified-healthy recordings, blind. MAF = the MAFAULDA desktop rig; K001–K006 = Paderborn healthy bearings (K001/2/3/6 naturally rough, K004/5 quiet). Bars = % of check-ups falsely CONFIRMED. The remaining rough-rig residual is a named, tracked item (uncapped per-machine robust statistics) — not an unknown.

One engine, four places: the logic you operated in Tab 3 runs identically on the sensor's chip (flashed and byte-verified), in the production cloud platform, in these blind benches, and as the patent's blocks 130/140. The chip and server versions are changed in the same commit and held identical by automated tests — what the simulator shows is what the silicon does.

For counsel · the 100 pages in one map

Six independent claims. Two of them carry the story.

The application is ~100 pages: 27 claims, 8 innovations, 31 figures, 20 experiments. The story lives in two of them: Claim 1, the loop (the diagnosis schedules the device's own next measurement), and Claim 6, the self-governing check-up cadence. Four more independents (2–5) each stand alone, and 21 dependent claims refine their parents — an objection to any branch never fells a trunk. The map below is drawn from the claims text itself.

15 minutes Summary of the Invention → Tab 2's diagram → Claims: read Claim 1 and Claim 6 only → Experiment 14 (the consolidated 7-dataset table).

The evidence 20 numbered experiments; each names its claims in its title. Fastest: Exp 14 (all claims) → Exp 16 (the humility-check collapse story) → Exp 17 (chip = server).

The drafting rule that holds it together: no claim without a hardware anchor. Every algorithm's output is a physical act of the apparatus — a timer programmed, a sleep state entered, a flash sector written, a radio transmission made or withheld. That is the Section 3(k) defence, module by module.

The map — six trunks, every dependent hanging on its written parent

no dependents — stands alone

Dependencies as literally written in the claims ("the method of claim N"). Claim 21 is an auditable-classifier system claim that incorporates the sensor node of claim 5. Click any claim to jump to its row below. An objection to any single branch prunes that branch — the trunks stand.

Claim	What it protects	Hardware anchor	Block	Figs
1 ★	Independent — the loop: rate-of-change urgency controls the device's own schedule	RTC alarm + deep-sleep state set per scan	140	22 · 26
2	Spikiness/loudness divergence as a multi-purpose signal (K_ratio)	computed on-chip per window; drives stage → interval	120
3	Anonymised fleet knowledge retrieval	payload assembled on-device, radio uplink	via 160
4	Complete on-device detection pipeline	entire pipeline on the battery chip, fixed memory	120+130
5	Closed-loop hardware control	urgency programs the RTC timer and sleep state	140
6 ★	Independent — the apparatus (all six modules)	the device itself	100	24
7	Tiered verdict — corroboration scales with severity	verdict sets alert, radio cadence, next interval	136	22
8	Learns from repairs, not retraining — strongest; no prior art found	threshold updates written to permanent memory	135+150	20 · 22 · 23
9	Machine-state check before scanning	gates the ADC — a skipped capture is a hardware act	130
10	Cross-axis rate-of-change trending	3-channel ADC trended into the schedule	140
11	Stage-adaptive evidence weights	weighting alters verdict → schedule + transmission	130
12–13	Fleet refinements; commissioning from fleet	fleet baseline received by radio, stored on-device	via 160
14	Speed-adaptive capture duration	sample count / timer set per estimated speed	140→110
15	Server shadow validation + bidirectional control	server verdicts alter device config by radio	140+160
16	Cross-axis features on-device	3-channel arithmetic on the chip, no raw uplink	120
17	Rare transmission with on-event escalation	radio duty cycle is the controlled output	160	25
18–19	Speed estimation with no speed sensor + quality gate	fixed-point, <50 ms/window on-chip; wobble triggers TX	126	27
20–22	Two-judge cascade with an honest UNCERTAIN output	UNCERTAIN triggers immediate TX + on-device audit record	131+132	28
23	Graceful degradation on unfamiliar machines	fallback runs on-device — no server, no retraining	133
24	The humility check (Mahalanobis interlock)	statistics in device flash; demotion changes behavior	133
25	Physics-supervised training labels	the trained head is deployed into device flash	130
26	Lifetime health archive (~39 years in flash)	append-only flash region, persisted cursor	150
27	Speed-squared imbalance verification	per-speed-bin records persist across power cycles	130+150

Behavioral modules (the earlier brief) → structural blocks

Module	Home
A — nothing alarms alone	136 (131/132 as witnesses)
B — two opinions + an honest "don't know"	131 + 132 + 133
C — learns from the repair, not retraining	135 + 150 (via 160)
D — speed, with no speed sensor	126

Prepared by the inventor · reference numerals are drawing proposals · hardware nouns intentionally generic (accelerometer; low-power microcontroller; non-volatile memory) · evidence: dated firmware ledger with checksums, device/server bit-parity suite (59 fixtures incl. a 5000-case randomized sweep), blind validation on public run-to-failure and certified-healthy datasets.

The official drawings · exactly as they stand in the specification · claim references in the titles

All 31 patent drawings, browsable.

These are the actual figures from the application text, untouched. Pick a number, use the buttons, or the ← → arrow keys. The title is the official caption; the line beneath each drawing is a plain-language gloss added for this page only.