Min and Max cell ID info truncated in GUI and VRM

Modifications
, , , ,
1

My battery (48V Fogstar) is connected over CAN to a cerbo GX. The lowest and highest voltage and cell temp info (found under Devices→Fogstar battery→Details) says ‘Pack-01#’ for the ID-part in all 4 cases. Clearly there should be an actual cell number on the end but it’s getting lost/truncated.

The ‘BMS min/max voltages’ widget in VRM similarly displays “Pack-01#” for ‘Maximum/Minimum Cell Voltage ID” when one hovers over the graph. This is very annoying as I’d really like to know which cells were higest and lowest and whether it is always the same ones.

Is there a way to fix this (on the Victron end - there is no easy way to change what the pack (Seplos v3.0 BMS in this case) is sending SFAIK)?
If I log onto the Cerbo and look with dbus-spy, and look under com.victronenergy.battery.socketcan_can0 we find:
System/MaxTemperatureCellId
System/MaxVoltageCellId
System/MinTemperatureCellId
System/MinVoltageCellId
and they are all showing “Pack-01#”

What controls how these dbus parameters get assigned from can messages? Can it be changed to take more characters?

OK. so lets go look at the underlying can messages.

If I run
candump -c can0 -c -a
then I get
can0 370 [8] 42 4D 53 31 36 53 32 30 ‘BMS16S20’
can0 371 [8] 30 41 2D 53 50 31 31 32 ‘0A-SP112’
can0 372 [8] 01 00 00 00 00 00 00 00 ‘…’
can0 373 [8] 36 0D 3D 0D 26 01 27 01 ‘6.=.&.’.’
can0 374 [8] 50 61 63 6B 2D 30 31 23 ‘Pack-01#’
can0 375 [8] 50 61 63 6B 2D 30 31 23 ‘Pack-01#’
can0 376 [8] 50 61 63 6B 2D 30 31 23 ‘Pack-01#’
can0 305 [8] 00 00 00 00 00 00 00 00 ‘…’
can0 307 [8] 12 34 56 78 56 49 43 00 ‘.4VxVIC.’
can0 377 [8] 50 61 63 6B 2D 30 31 23 ‘Pack-01#’
can0 378 [8] EF 02 00 00 E1 02 00 00 ‘…’
can0 379 [8] 22 01 00 00 00 00 00 00 ‘"…’
can0 35A [8] AA AA AA 02 AA AA AA 06 ‘…’
can0 351 [8] 40 02 00 00 08 07 D0 01 ‘@…’
can0 355 [8] 63 00 61 00 E8 26 00 00 ‘c.a..&..’
can0 356 [8] 29 15 F7 FF DE 00 00 00 ‘)…’
can0 35E [8] 56 69 63 74 72 6F 6E 20 'Victron ’
can0 35F [8] 00 00 00 01 22 01 00 00 ‘…"…’

Which I think is a whole frame? Does that mean that the ID is truncated in the original CAN message, so the cell ID is simply never being sent to the Victron system (and this can only be fixed at the BMS end? Does candump show every byte (I presume so)?

The BMS in this case is a Seplos BMS v3.0

Are there other things I can do to understand what is going on here?

I would actually really like to track all 16 cell voltages and log them in a widget. They are certainly being sent out over Bluetooth BLE and over the RS485 serial interface, as they can be viewed in the Seplos software. But maybe they are not in the CAN data. How do I check? Does the Victron comms protocol dictate that only min+max IDs are sent?

2

Yes, The ID is limited to 8 characters by definition. Manufacturer should adopt a clearer method of passing ID’s. ‘Pack’ is redundant and wastes space.
No there is no easy way to fix this. Limited by the can bus protocol - max data length per packet is 8 bytes.

So would I. However, the number if CAN Bus ID’s for the BMS range is limited - very much in the standard mode.

Does the Victron comms protocol dictte that only min+max IDs are sent? >> Yes.

If you have the data on RS485, then you could use a simple interface on a small processor like a raspberry Pi to display these.

1 Like
3

It is quite common that BMS report only the “Pack” where the respective cell is in.

Knowing the exact cell is of no value to the majority of users - if you would attempt to manual balance with a dedicated charger, you’d balance the whole pack, not open it and pull out cells.

Pylontech for example does 0103 and means: STACK 01, PACK 03 - so, you could well have 0103 beeing reported for the highest and lowest cell at the same time. For Pylontech without a Hub (most common usage) it’ll therefore always be 01xx and confuses a lot of people as well.

1 Like
4

OK. Thanks for explaining that. I hadn’t realised CAN bus messages topped out at 8 bytes of data.

It should be possible to use a USB-serial device to take the BMS serial stream and munge it into something useful on the cerbo without getting a whole other computer just to do that. However so far I have failed to read any serial data from the BMS from linux, even though there are a couple of bits of software out there. I think it may be a modbus-style query-response interface, as opposed to a continuous logging data stream, but there is no spec, only reverse engineering.
In theory these three codebases contain the necessary protocol info:

Similar data is available on BLE, and possibly the Cerbo bluetooth interface could talk to that to get the data.