Ampline is retired. Its firmware has been pulled into Solstice, and the Solstice module now reports both solar harvest and battery shunt data over CAN. Your build just got one module shorter.
What changed
Ampline was a Victron BMV battery shunt serial-to-CAN bridge. Solstice was a Victron MPPT solar charge controller serial-to-CAN bridge. Both ran on an ESP32. Both used a UART serial connection to a Victron device. Both reported their data to Headwaters over the same CAN bus using nearly identical firmware patterns. The difference between them was which serial port they read from, and which CAN message IDs they published.
That is not enough of a difference to justify two separate modules. Solstice now handles both connections. Solar harvest and battery shunt data arrive on the same device, reported to the bus the same way they always were. Headwaters does not care. Farwatch does not care. The data is the same. There is just less hardware in between.
What it means for your BOM
This is the most direct impact. A full TrailCurrent build previously needed a Solstice module and an Ampline module to cover the energy picture. Now it needs one Solstice. That is:
- One fewer ESP32 microcontroller
- One fewer custom PCB to fabricate or assemble
- One fewer 3D-printed enclosure to design, print, and mount
- One fewer CAN node drawing power on the bus
- One fewer firmware binary to flash and maintain
For a project that prides itself on being something you can actually build, every component that disappears from the list matters. This one was the right call, and it is the kind of simplification that only becomes obvious after you have lived with a system long enough to know which parts are pulling their weight.
Wiring reference
Solstice connects to a Victron MPPT controller and a Victron BMV battery shunt via separate RS-485/serial lines. Both devices talk to the same ESP32, which bridges everything to the CAN bus. The ribbon cable diagram below shows how the connections are laid out on the board.
Nothing is lost
The full shunt data set is still there: voltage, current, state of charge, time-to-empty, and the rest of the BMV telemetry. Solar harvest data is still there too. If you were relying on Ampline for battery monitoring, that capability has moved to Solstice. The CAN messages are the same. Headwaters picks them up the same way. Farwatch displays them the same way.
If you have an existing Ampline module in a build, it will continue working until you are ready to migrate. When you are, you replace Ampline with an updated Solstice, flash the new firmware, and the data keeps flowing.
A note on direction
This kind of consolidation is something we will keep doing. The goal has always been a system that is as capable as possible with as few parts as possible. More capability in fewer modules means lower cost, simpler installs, less to go wrong, and more of the budget available for the parts of the build that actually matter to you. When two modules share enough DNA to become one without losing anything, they should become one.
The Solstice build page has been updated to reflect the expanded functionality. The Solstice repo on GitHub has the updated firmware.