This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

A low-cost, offline machine-monitoring probe built around an Arduino, designed to bring predictive maintenance within reach of small businesses.

What I Built

Where I live in Kerala, many small businesses depend on machines to keep running. Think of the grinder in a batter-making business, the machinery in a flour mill, a water pump on a farm, or the machines in a small workshop.

When a machine starts to fail, the warning signs can go unnoticed until it breaks down. A repair technician might listen to the machine, feel its vibration and rely on experience to diagnose the problem. That experience matters, but what if they also had measurements to back it up?

Project Pulse is designed for both technicians who want to check machines periodically, like using a stethoscope during a routine inspection, and business owners who want to monitor multiple machines across their setup. Deploy multiple probes across a workshop, factory or farm, and each can learn the normal behaviour of its assigned motor and flag unusual changes. Instead of waiting for a breakdown, the goal is to spot warning signs earlier and make maintenance decisions with better information.

That's why I built Project Pulse: a stethoscope for small motors.

It's a handheld probe with a magnet at its tip. Attach it to a running machine, and it measures vibration while capturing sound. It estimates vibration severity, identifies possible fault patterns and explains what to investigate in language a shop owner can understand.

Everything runs on an Arduino UNO Q. No cloud, no account, no internet connection required.

It has two modes:

• Check mode, for repair technicians. Take a reading, see the severity zone, review possible faults such as imbalance or looseness, and generate a report. The report can be downloaded as a PDF and shared with the customer.
• Guard mode, for machine owners. Leave the probe on a motor. It first measures the motor while switched off, then learns that specific motor's normal running pattern in about three minutes. It watches for sustained changes and tracks an estimated heat/overload budget. An LED shows the state: blue for learning, green for healthy, amber for watch, red for stop, and off when the motor isn't running. A red stop state stays latched until a person clears it. At the end of the day, the device generates a short note.

Who would pay for it?

• Independent repair technicians could carry one probe between customer sites, check motors during routine maintenance, identify unusual vibration patterns and provide customers with a report backed by actual measurements.
• Small business owners could use Project Pulse to monitor the motors their operations depend on, helping them spot unusual behaviour before it leads to unexpected downtime.
• Factories and workshops could deploy multiple probes across their equipment, monitoring individual motors as a fleet rather than relying entirely on manual inspections. Each probe learns the normal behaviour of its assigned motor and flags sustained abnormalities.
• Agricultural and industrial operators could use the portable probe to inspect pumps, motors and other rotating machinery at regular intervals, even where internet connectivity is unreliable.

Industrial vibration-monitoring systems already exist, but many come with high hardware costs, cloud connectivity requirements and recurring subscription fees. These can make continuous monitoring difficult to justify for small businesses that only need to monitor a handful of machines. Project Pulse explores a more accessible alternative: an affordable, fully offline tool with no recurring AI or cloud costs. It can work as a handheld diagnostic stethoscope for periodic inspections or be deployed across multiple machines for continuous, individual monitoring. The goal is to make predictive maintenance accessible without the infrastructure and ongoing costs traditionally associated with industrial monitoring systems.

Demo

I didn't have access to an industrial machine for the demonstration, so I started with what I had at home: a fan. To test whether Project Pulse could detect unusual vibration, I taped a coin to one of the fan blades to introduce an imbalance and observed how the system responded.

It was a simple, controlled experiment using an everyday appliance, but it gave me a way to test the complete sensing and alerting loop with a real motor. The prototype detected the sustained induced imbalance during my test. It's an initial proof of concept, and testing across different motors and real-world fault conditions is the next step.

Here's the hardware before it went into the enclosure:

UNO Q, KX134, INMP441, RGB LED, three resistors, and the magnet that lets the probe snap onto a motor casing.

I don't own a 3D printer, so I made the enclosure from cardboard, cutting, folding and gluing it by hand. The magnet sits at the bottom, letting the probe attach to a motor casing. It's not a production-ready enclosure, but it contains the working electronics used for the prototype.

Red means stop. The heartbeat line was the only part of this build that didn't need debugging.

The probe's wiring, start to finish: KX134 over SPI, INMP441 over I2S, everything else just GPIO.

Check mode, live: severity zone, the raw numbers underneath it, and the button that turns them into a report.

The PDF a technician hands the customer. Every number in the paragraph above the table is checked against the table itself before it ships.

Code

How I Built It

Hardware

• Arduino UNO Q (4 GB): combines an STM32U585 microcontroller with a Qualcomm QRB2210 Linux processor.
• KX134 accelerometer: measures vibration over SPI.
• INMP441 microphone: captures sound over I2S.
• RGB status LED and button: provide a simple physical interface.
• Magnet: attaches the probe to a motor casing.
• XIAO ESP32-S3 + relay: planned as an optional stop plug; see the limitations below.

Sense: the microcontroller side

The STM32 samples the KX134 at about 1,600 Hz (measured: 1,623–1,627 Hz). Every second it runs a hand-written FFT and turns the raw samples into one small feature row:

• vibration velocity (mm/s)
• the motor's rotation frequency
• the strength of the first three harmonics (1×, 2×, 3×)
• band energies, kurtosis and crest factor

That row goes to the Linux side over the UNO Q's Bridge. It's about 60–70 characters, well under the Bridge's 256-byte message limit.

The INMP441 runs at the same time at 16 kHz (measured: 16,004–16,031 Hz). The UNO Q's Arduino core has no I2S library, so I drove the chip's SAI audio peripheral directly through its registers. That taught me two lessons:

• My first build read every sample as 0 or 32767, because the clock-edge bit (CKSTR) was left at its reset value.
• The KX134 delivered no samples at all until I set its data-ready enable bit (DRDYE). Its WHO_AM_I check passed perfectly the whole time, so the real bug was hiding one register away from where I was looking.

Decide: the Linux side, all open source

• Fault rules (rules.py): the vibration velocity maps to the ISO 10816 severity zones that technicians use for small machines. Textbook signatures then name the likely fault:
  • a dominant 1× peak means imbalance
  • strong 2×/3× harmonics mean looseness or misalignment
  • rotation slower than the rated speed means overload
  • high-band energy plus high kurtosis means bearing wear
• Learned normal (model.py, scikit-learn IsolationForest): in Guard mode it trains on the board from the motor's own healthy running rows. Both the anomaly flag and the rule faults are debounced: a condition has to hold for 5 consecutive rows before the light turns amber. The motor-off state reads from the same per-motor calibrated floor, not a fixed number. I tried a fixed "off" threshold first, and it broke the moment I tested it on a second, quieter fan. Every motor needs its own baseline; there's no shortcut around that.
• Heat budget (heat.py): there's no temperature sensor yet. Instead, a slow budget fills with run time and overload and drains at rest. When it's full, the stop latches.
• Gemma 3 1B via llama.cpp, running on the board, writes the Check report and the Guard daily note.

The rule I built Gemma around: the model never makes a decision. Pass/fail and stop/no-stop stay with the rules, the anomaly model and the heat budget. Gemma's only job is to turn a decision that's already been made into sentences a shop owner can read. A validator then checks every number in Gemma's text against the real measurements. If one doesn't match, it retries once, then falls back to a fixed template built from the real numbers. The report can be wrong in tone, never in its numbers.

Act

• The RGB LED and the web page (live readings, Guard state, report and note, PDF download) show the result.
• A red stop latches until a human clears it.

What I measured

Every number here is from a test I actually ran. The full details (date, setup and number of trials) are in docs/measurements.md in the repo.

Bugs that mattered:

• My number validator read the dash in "10–800 Hz" as a minus sign and rejected every correct Gemma answer. There's a regression test for it now.
• The llama-server was only listening on localhost, so the app's container couldn't reach it.
• With a 3-row debounce, the fan's normal variation made the light flicker amber. Five rows fixed it without hiding the real fault.

Why Does Open Innovation Matter?

• It has to work where there's no internet. A flour mill or a roadside repair stall isn't a data centre. An open-weight model on the board keeps working with the router unplugged.
• It has to cost nothing to run. A technician isn't going to pay a monthly AI bill to check a machine. Open weights on a one-time board are what make a ₹-priced tool possible at all.
• It has to learn one motor, not every motor. The anomaly model trains on the owner's own machine, on the device, in minutes. A general cloud API knows nothing about a 20-year-old grinder, and never will.
• I needed to control the model, not just call it. With an open model I can pick the size that fits the board, keep it out of the decision path, and check its output before anyone sees it. A closed API hands me a black box behind a network call I can't guarantee.

My Agent Session

I used Claude Code as a coding agent for the App Lab side: the web page and the Python app logic. Everything it wrote was reviewed and tested by me on real hardware before it stayed.

Who This Is For

Market and Business Potential

Small motors are everywhere in the informal and small-business economy: home appliances, small workshops, agricultural pumps, kitchen equipment, retail fans and mixers. This segment is usually the last to get any kind of predictive maintenance, because every existing vibration-monitoring product is priced, sized and documented for a factory floor, not a single shop owner with one machine.

Rental potential, in more detail: a technician who doesn't do enough vibration diagnosis to justify owning one can rent it for a day's rounds. A shop owner deciding whether a motor is worth repairing can rent it for a single Check-mode reading instead of buying outright. That's the group least able to justify buying specialist equipment, and renting gets it into their hands anyway.

Scalability:

SWOT Analysis

My First User

Prize Categories

Best Use of Arduino

• Runs models on the board: the fault rules, an IsolationForest trained on the device, and Gemma 3 1B through llama.cpp, all offline on the UNO Q.
• A physical agent that senses and acts: it senses vibration (KX134) and sound (INMP441), and acts through a status LED and a latched stop a human has to clear.
• Uses what makes the UNO Q different: the STM32 handles the real-time sampling, the FFT and the button/LED; Linux handles the learning, the language and the web page; the two talk over the Bridge.

Best Use of Gemma

• Gemma 3 1B writes every report and daily note on the board.
• It's kept out of the decision path on purpose, and every number it writes gets checked against the measurements before anyone sees it (8/8 passed).

Limits and what's next

• The stop plug (XIAO ESP32-S3 + relay, paired over Wi-Fi with signed "OK to run" permits, fail-safe on any lost signal) is coded but not yet tested on real hardware. That's the next step, so right now the "stop" is the latched red state, not a verified mains cut-off.
• Validated so far on two real motor (two desk fans(one new and one a old fan)). Induced-fault trials on more machines, bearing faults especially, are next.
• No winding temperature or current sensing yet. The heat budget is an estimate from run time and load.
• No 3D printer on hand, so the enclosure is a hand-built cardboard prototype. A printed or molded shell comes once i get access to a 3D printer.
• Power: the prototype runs off USB for convenience while building it. A real deployment doesn't need to stay tied to a cable. A handheld Check-mode probe makes more sense on a rechargeable battery, while a Guard-mode unit left mounted on one motor could just as well stay on mains/USB power full-time. The electronics don't force this choice either way; the power source is picked per use case.
• It's a diagnostic aid, not a certified instrument. The ISO zones are field indications.