Machine Sound Doctor
No app to install, no sensor to wire up — just a phone call and a phone's microphone standing in for a vibration sensor.
Role
Creator, solo project
Event
Africa's Talking Hackathon
Track
Predictive Maintenance & Equipment Monitoring
Status
Working prototype
How it works
Step 1
Call in
A technician calls an Africa's Talking Voice number and holds the phone near the running machine.
Step 2
Classify
MFCC audio features are extracted from the recording and run through a trained classifier.
Step 3
SMS back
A diagnosis — normal, bearing fault, or belt slip — comes back by SMS with a recommended action.
Under the hood it's a Flask app: Africa's Talking Voice and SMS APIs handle the call and the reply, an MFCC feature pipeline turns the recording into something a classifier can use, and a SQLite audit trail logs every diagnosis. The whole thing — training included — builds inside a multi-stage Docker image, so the model that ships always matches the code and dataset baked into it.
Why a phone call
Most predictive-maintenance tooling assumes a vibration sensor already bolted to the machine and a dashboard somewhere to read it. For a lot of equipment in the field, neither exists. A phone call needs nothing installed and nothing wired up — just a number to dial and a phone to hold near the machine, which is the point for the hackathon's brief: equipment monitoring that works with what's already in someone's pocket.
Honest about where it stands
The training set is small — 28 labeled clips across three classes, with only 6 examples of belt slip — so the 3-class classifier sits around 50% accuracy under leave-one-out cross-validation, barely above guessing the majority class. Collapsing it to a binary normal-vs-fault call does meaningfully better, around 68%, which is why the app defaults to that framing. It's a hackathon prototype proving the call-in-and-diagnose shape works end to end, not a production-accuracy claim — more labeled audio is the direct path to a better number.