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 modern wireless competitors moved the intelligence off the machine instead — into a
cloud subscription, or into teams of human vibration analysts — leaving the sensor itself a scheduled
microphone whose measurement cadence an operator sets by hand. This design moves the diagnosis
into the sensor, and lets the diagnosis set the cadence.
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. We have found no commercial system that 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
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.
Hardware tie. The arithmetic you are watching —
the envelope, the rhythm search — runs on the sensor's battery chip, held bit-for-bit identical to the
server implementation by automated parity tests (Tab 4, "Chip = server").
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.
—
What the box does next — the verdict IS a schedule (Claim 1)
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
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 |