How one inventor used AI as a full-time co-engineer to design, wire, code, debug,
and iterate a CrossFit jump-rope counter — across weeks of real bench work.
The goal was straightforward: build a floor mat that detects single, double, and triple-under jump-rope passes and displays a live count on a screen. No team. No EE background on call. Just an inventor, an AI, and a lot of test rigs.
What follows is an honest account of where AI accelerated the work dramatically — and where it gave wrong guidance that cost real hours to recover from.
These are lightly edited excerpts from the actual working sessions. They show what the collaboration genuinely looked like — not polished demos, but live problem-solving under time pressure.
The architecture held. Every major component selected in the first session made it to the working prototype. No pivots on core parts — only refinement on configuration, thresholds, and wiring.
The patch-based v2.2 instructions were the direct cause of the crash. The mutex was referenced before it was created in setup(). The AI issued a patch to a file it had already broken with a prior patch — compounding the error. A full rewrite was faster than debugging the patch chain.
The AI presented a textbook EE recommendation (midpoint biasing) without accounting for project history. The inventor's question — grounded in actual bench experience — was the correct engineering call. Always cross-check AI suggestions against what you've already physically proven.
These weren't mistakes — they were the design process. Each pivot produced a measurably better outcome than the previous approach.
Started with A3144 digital Hall (on/off). Rope was too thin and too far away to consistently cross the threshold. Switched to A1324 linear analog — 5mV/Gauss, 16-bit ADS1115 ADC. Detection became a signal amplitude problem, not a binary one.
Arduino had no headroom for concurrent sensor sampling and OLED rendering. ESP32 FreeRTOS dual-core split: Core 1 = sensing loop (never interrupted), Core 0 = display + button. Display latency dropped to zero effect on count accuracy.
Maximum sample rate produced maximum noise. At 600 RPM (10 passes/sec), Nyquist requires only 20 samples/sec. Dropping to 250 SPS reduced RMS noise 5× per ADS1115 datasheet — free improvement, no hardware change, no firmware refactor.
Loose wires in hot glue caused intermittent spikes of 1–2 sample duration. Real rope passes at 600 RPM last 8–15ms (8+ samples at 250 SPS). Requiring CONFIRM_SAMPLES=3 consecutive threshold crossings eliminated wire-bounce false counts without missing real passes.
Defined full hardware architecture: A1324 sensors, N52 magnets, ADS1115 ADC, ESP32, SSD1306 OLED, AO3400 MOSFET drivers for coil design.
Tested A3144 digital Hall + 10kΩ pull-up. Detected inconsistently at 0mm clearance. Identified sensor sensitivity as the core failure mode.
Burned one A1324 sensor by leaving the A3144 pull-up resistor in circuit on the analog output pin. Safety protocol added: 100Ω VCC protection on every new sensor first power-on.
Confirmed rope material is ferromagnetic using N52 magnet attraction test. Detection physics validated — failures were sensor sensitivity, not material incompatibility.
Wrote RopeTest-Analog.ino for Arduino. First repeatable serial-output detection of rope pass with delta > threshold. Baseline calibration loop established.
Upgraded to ESP32 + ADS1115 4-channel array. Wrote hall_pass_counter_v2_0 with FreeRTOS dual-core, dynamic baseline, majority-vote detection logic.
Built custom 600 RPM steel-cord spinning test rig to simulate rope passes without an athlete. First hardware test rig inventor built independently of AI guidance.
Debugged I2C mutex crash (v2.1 → v2.2). Added RPM calculation to OLED display. Added ROPE_STEEL mode for 1mm uncoated cord with tuned thresholds.
Added WIRE_FAULT diagnostic — single-sample jump detector that identifies which channel has an intermittent connection before teardown. Identified hot-glue bracket as mechanical failure source.
Defined wooden platform rebuild spec: soldered pigtails, routed wire channels, press-fit magnet pockets, JST-PH headers to ADS1115. Began KiCad coil-cell schematic hierarchy for PCB electromagnet coil + Hall sensor tile.
AI can write firmware, produce schematics, and calculate field gradients. It cannot do any of the following — and every one of these proved to be a critical path item in this project.
This is not a success story with a bow on it. It's an ongoing engineering project. Here is an unfiltered scorecard of what AI-assisted development actually produced.
| Area | AI Performance | Verdict |
|---|---|---|
| Initial architecture | Correct sensor family, correct ADC, correct MCU, correct display — all on first suggestion. No pivots on any of these. | Excellent |
| Firmware structure | FreeRTOS dual-core split, I2C mutex, portMUX data protection, confirm-sample filter — all sound embedded-systems patterns correctly applied. | Excellent |
| Iterative debugging | Correctly diagnosed backtrace crash from serial output alone. Correctly identified Wire library deadlock as root cause without seeing the hardware. | Strong |
| Threshold tuning | Recommended thresholds required real-bench iteration. Starting values needed 2–3 adjustment cycles. The model had no physical reference for the actual delta magnitudes at this standoff distance. | Adequate |
| Patch-based code updates | Issued patch instructions that crashed the system (null mutex). Cumulative patches broke the code before a full rewrite fixed it. Patches are faster to write but riskier than full-file replacements in complex RTOS code. | Failed |
| Physical geometry advice | Recommended 22mm standoff to achieve textbook VCC/2 baseline — directly contradicted by bench-proven finding that stronger field is essential. Inventor correctly overrode this. | Wrong |
| Mechanical design | Described wooden platform cut list and assembly sequence accurately. Could not assess hot glue failure, Anderson connector vibration loosening, or wire routing in the actual physical space. | Advisory only |
| KiCad / PCB design | Generated working spiral coil footprint Python script (fp_line format for KiCad 9.0). Identified MCP server path for full agentic KiCad control. PCB schematic hierarchy defined but not yet executed. | In progress |
AI performs best on problems with a correct answer in its training data: firmware patterns, datasheet interpretation, diagnostic logic. It performs worst on problems that require knowing your specific physical context — geometry that worked, failures that happened last week, what your hands tell you when you tug a wire. Keep those two domains clearly separated in your mind.
MCU: ESP32 Dev Module, 240MHz, dual-core FreeRTOS
Sensor: A1324LUA-T linear Hall, 5mV/G, TO-92 UA package
ADC: ADS1115, 16-bit, 0.125mV/LSB @ GAIN_ONE, I²C 0x48
ADC rate: 250 SPS (final) — 5× noise reduction vs 860 SPS max
Display: SSD1306 OLED, 128×64, I²C 0x3C — same bus as ADC
I²C safety: SemaphoreHandle_t mutex serializes ALL Wire calls
Both cores were calling ads.readADC() simultaneously
without mutex → Wire deadlock → backtrace crash
Detection: CONFIRM_SAMPLES=3 consecutive threshold crossings
Real rope pass @ 250 SPS lasts 8+ samples
Wire-bounce spike lasts 1–2 samples — filtered out
Lockout: PULSE_MIN_MS=70 — blocks re-triggers within one pass
at 600 RPM (100ms period)
Magnets: N52, 15.875mm dia × 6.35mm thick, 12mm standoff
Baseline ~3875mV (south pole up) — manageable
PCB target: 50×50mm tile, 2-layer, 30mm spiral coil F.Cu,
Hall sensor at geometric coil center (25,25)mm
There are two questions every inventor asks when they first hear about AI-assisted development: Can it replace my engineer? and Is it worth my time to learn?
This project answers both. AI cannot replace the engineer because the most critical decisions in this build — which test to run, which geometry is physically proven, when the breadboard needs to be thrown out — required hands-on context that no language model has. But AI dramatically compressed the time between idea and working prototype by handling the parts of engineering that are lookup-intensive: library selection, firmware architecture, datasheet interpretation, debug logic, schematic hierarchy.
The inventor did not need to know FreeRTOS mutex semantics before this project. They needed to know that the AI wrote the mutex wrong and that the bench told them so via a backtrace. That's the skill: using AI for density, using your hands for ground truth, and knowing which is which.
"AI gave me the firmware for a sensor I didn't know existed, wired to a processor I'd never touched, in a framework I'd never used — and when it crashed, it told me exactly why. My job was to build the test rig that proved it was actually working."
1. Lock architecture first. Get AI to select your core components before writing a line of code. If the architecture is right, pivots are refinements — not rebuilds.
2. Always request full files, not patches. Patch chains in complex firmware compound errors. Ask for the complete updated file every time.
3. Cross-check against your bench history. AI has no memory of what hurt you last week. If a recommendation contradicts something you physically proved, trust the bench.
4. Use AI for the vocabulary, not the judgment. It knows what CONFIRM_SAMPLES means and how to implement it. You decide whether 3 samples or 5 samples is right for your noise environment.
5. Hire ChessTrees to accelerate the parts that matter. Structured AI prompting for hardware projects is a learnable skill — and having an expert set up the workflow saves weeks.