This week Headwaters changed its reference hardware. The Raspberry Pi 5 is out. The Raspberry Pi Compute Module 5, running on a Waveshare base with a Waveshare CAN hat, is in. This was not a small decision, and it reflects a lot of the work that has been quietly driving the whole project: move to off-the-shelf components that anyone can buy and assemble themselves.
Why we moved off the Pi 5
We liked the Pi 5. We did not like what it was turning into for this project.
Availability was slipping. Pi 5 modules were getting harder to find in the quantities and configurations we needed. If a contributor can't actually buy the reference board, the reference board is the wrong reference board.
Costs were climbing. Between the Pi 5 itself, the NVMe base hat we needed for tileserver-grade storage, and the ribbon cable that connected them, the bill of materials kept getting taller.
The assembly was a nightmare. Anyone who has threaded a Pi 5 PCIe ribbon cable through a NVMe base and gotten the orientation right on the first try is welcome to disagree. Everyone else knows exactly what we mean. It was fragile, fiddly, and a bad on-ramp for new builders.
Why the CM5 on a Waveshare base is the right call
The Waveshare base for the Compute Module 5 solves every one of the problems above, and then some.
Broad CM5 compatibility. The base works with any CM5 module that has 4 GB of RAM or more. WiFi or no WiFi. Onboard eMMC or no eMMC. That flexibility matters enormously for availability. One variant alone has nearly 700 units easily available in the US right now, and broadening to the other compatible variants opens up even more. If your preferred variant is in stock somewhere, you can build Headwaters.
NVMe storage built in. Map tiles are big, and tileserver wants fast local storage. The Waveshare base gives us M.2 NVMe directly without a separate add-on board and a ribbon cable praying for alignment.
CAN on a proper hat. The Waveshare CAN hat lands on the same stack, so the bus that every other TrailCurrent module talks over comes in cleanly through a supported, documented, off-the-shelf part. No adapter jungle.
Everything is a catalog part. You can order the CM5, the Waveshare base, the CAN hat, and an NVMe drive from normal distributors. No custom PCB. No hand assembly beyond seating modules into connectors. Up until this week we were carrying a carrier-board EDA in the Headwaters repo. This week we deleted it, and the repo got smaller and the project got easier to build.
What changed in the code
A lot, most of it invisible. The image build got rewritten for CM5. The first-login experience gained a splash screen, a logo, and ASCII art that tells you which TrailCurrent device you just SSH'd into. The SSL cert generator got cleaned up. A module-registration bug where devices could be added twice was fixed. Cellular SMS notifications via the onboard router are now supported, so the system can reach you on a trip where WiFi can't.
Plateau calibration improvements
Leveling continued to mature. The calibration flow is more tolerant of noisy IMU data, and Plateau now communicates its calibration state back to Headwaters, so the PWA can show you when your reference level is actually set.
The bigger picture
This CM5 move is the clearest example yet of a pattern you'll see across the whole project: if a job can be done with parts you can buy from a normal distributor, we do it that way. Custom PCBs still make sense for modules that do specific jobs, where a purpose-built board is the only way to fit the sensor, the connector, and the power rail into one enclosure. But for the brain of the system, a catalog stack is the right answer. Every time we can delete a custom board from a repo, we do. Every time we can swap a hard-to-source part for one with 700 units in stock, we do. That's what it takes to make something other people can actually build.