Loading sector data...
Loading sector data...
A side-project that became the main product
On a boat, the electrical system is everything. Your engine, navigation lights, bilge pump, radio — all of it depends on healthy batteries. The problem is, battery voltage is invisible. You don't know what's happening until something stops working.
I wanted to fix that. Not with an expensive commercial monitor, but with something I could build myself, understand completely, and deploy in multiple places — at the alternator, the fridge, the solar input and output.
The BatteryMonitor unit is intentionally simple: no display, just a Raspberry Pi Pico W that periodically powers up, reads the battery voltage, and sends it over WiFi to a configured server.
Keeping it headless minimises standby power draw — which matters when the unit is itself running off the battery it's monitoring. The plan was to deploy several of these across the boat, all reporting to a central access point running on another Pico W with an e-paper display acting as a dashboard.
E-paper is ideal here: low power, readable in full sunlight, and perfectly suited to 20-second refresh rates. Not real-time, but on a boat that's fine — and emergency routes for a quick refresh are easy to add.
Here's where it gets interesting. The Pico W's ADC can't read 12V directly — you need a voltage divider to scale it down. But voltage dividers aren't perfectly linear in practice, and the correction factors that work at 12V aren't quite right at 14V (charging) or 10V (discharged).
To tune this, I built a prototype with a small screen attached so I could adjust the software correction on the fly and immediately see the effect. Watching the reading converge on the multimeter value with each tweak was oddly satisfying.
That debugging prototype became the main product. It works well enough that I still use it on the boat — screen attached, sitting where I can see it.
This is a happy accident I've come to appreciate. The "production" headless unit is still on the roadmap, but the prototype taught me more about the calibration problem than I expected, and it's genuinely useful day to day.
WiFi reliability on the Pico W was a recurring issue during early development — the AP would need a restart after 5-10 minutes of operation. It's been a while since I last tested the latest MicroPython firmware, and this may well have been patched.
If not, Bluetooth is the natural alternative. The power budget is comparable, the range is more than enough for a boat, and it avoids the AP dependency entirely. Worth investigating when I return to this.
Source Code: View on GitHub