In 2019, we built a stopwatch system for firefighter competitions.
It measured split times, water flow, pressure inside the hose, and engine RPM — all in real time — and displayed everything on a Raspberry Pi.
On paper, it made sense.
In reality, we learned something painful.
We used Raspberry Pi to capture time‑critical pulses over GPIO. At low frequencies, it worked. When the engine revved high and pulses came fast, the numbers started fluctuating.
±100 RPM on a steady 10,000 RPM signal.
Not catastrophic.
Not precise either.
Linux is not a real‑time operating system. Threads are scheduled. Interruptions happen. Tiny timing skews become visible when frequency rises.
We optimized. We buffered. We averaged. We made it “good enough.”
But the real lesson wasn’t UI polish or Python tricks.
It was architectural.
Since then, we separate concerns:
- A microcontroller handles precise data acquisition.
- A Linux device handles UI, storage, and interaction.
One measures.
One presents.
That project influenced many later design decisions — including recent ones.
If you’re building something where timing accuracy matters, don’t let convenience dictate architecture.
Raspberry Pi is fantastic.
It’s just not a real‑time system.
The full project is open‑sourced here (a small museum piece at this point):
JSC-electronics
Sometimes the most valuable lessons come from projects that almost worked perfectly.
