Cells_V in CAN publication message

[xsider]

bms-firmware/src/data_nodes.cpp

Lines 211 to 212 in be7f58a

	TS_NODE_ARRAY(0x80, "Cells_V", &cell_voltages_arr, 3,
	ID_OUTPUT, TS_ANY_R, PUB_SER),

What would be the better solution to publish the individual cell voltages over CAN

• create a DataObject for every cell voltage
• create a CBOR array with all voltages (one array is implemented in text mode) and expand the publication message for multi frame messages?

[martinjaeger]

This is a very good question.

Don't really like to generate a dedicated DataObject for each cell voltage, as the objects are created at compile time and a BMS should be able to detect the actual number of cells at runtime. So the array is much cleaner in my opinion.

However, 8 bytes for classic CAN is definitely too small for up to 15 voltages, no matter how good the compression of the data is...

A previous version of the ThingSet spec had something called TinyTP for splitting longer publication messages. But it was never actually implemented, so I abandoned it to make the protocol not too complex.

At the moment the only good option to retrieve the cell voltages via CAN would be polling. With request/response messaging the maximum message size is 4095 bytes, which should be plenty.

[xsider]

I will consider polling over ISO-TP also. At the moment i am not mastering ISO-TP at all. But that could be a solution. The goal for the next year is, to replace an existing logging facility from volkszaehler-OBIS-messages (over isolated UART) to CAN, because one CAN could serve all chargers/bms at once. To use publication messages would be more straight forward because the host computer needs to listen only, and there could be multiple listeners for redundancy. Maybe thats a subject for [(https://learn.libre.solar/system/)], because it adresses not the component but the whole system.

[martinjaeger]

Yeah, makes sense to use CAN for that. If you're familiar with the ESP32: Quite a bit of that functionality is already implemented in https://github.com/LibreSolar/esp32-edge-firmware, including ISO-TP implementation and a web interface running on the ESP32 itself. It even supports over-the-air firmware upgrades for some STM32 microcontrollers.

I'm currently using it to push data to an MQTT broker, store it in an InfluxDB or VictoriaMetrics database and visualize it with Grafana.

It will need a bit more documentation, though.

[xsider]

This is a proposal for binary data node Cells_V, which does not break current implementation, CBOR-conform and fits in 8 Byte payload of CAN:

• NodeID 0x80 is kept
• every cell voltage is published at the same NodeID
• data payload is a CBOR-array with two entries:

Byte 0: Mayor type CBOR-List, two elements (0x82)
Byte 1: Mayor type unsigend integer (cell number)
Byte 2..6: Mayor type float (cell voltage)

The complete CAN telegram for Cell 2, Voltage 3.502V, Cell 3, Voltage 4.00V would look like:

can0  1F00800A  [7]  82 02 FA 40 60 2E 9A
can0  1F00800A  [7]  82 03 FA 40 80 00 00

Decoded payload with cbor2.loads():

[2, 3.5028443336486816]
[3, 4.0]

It should be possible to calculate number of cells at runtime, and should be easy to implement at controller side.

[martinjaeger]

Mhh, I think this would kind of break the current implementation, as the data representation would be different depending on whether the ThingSet library is fed with a request in text mode or in binary mode. Or the data would have to be generated outside the ThingSet library and just for this particular CAN message, which is also not ideal.

I think such a problem has to be solved on a lower layer of the protocol stack, i.e. the transport layer. As ISO-TP is not suitable for broadcasting, one solution would be to get back above mentioned TinyTP and create a dedicated CAN ID for multi-frame publications.

Previously the DP and EDP bits (25 and 24) were chosen to avoid ID conflicts with SAE-J1939. However, the ThingSet bitrate is set to 500 kbit/s instead of 250 kbit/s, so both protocols can't run on the same bus anyway. So we might just want to use bit 25 set to 0 for multi-frame publication messages and use bits 8-23 of the ID for packet numbers etc..

What do you think?

[xsider]

So we might just want to use bit 25 set to 0 for multi-frame publication messages and use bits 8-23 of the ID for packet numbers etc..

If we use Bit 8-23 for packet number, we need to set the NodeId inside the payload? So we will need a CBOR-array which consists of: [ NodeID, data_value0, data_value1, data value2, ....]. Number of data_values is (CBOR_array_length -1)?

[pasrom]

Are there any current developments underway?

[martinjaeger]

Yes, there are :)

We have recently added a new packetized report format to the spec and to the implementation. See the pull requests below for further information:

ThingSet/thingset.github.io#24
ThingSet/thingset-zephyr-sdk#4

It's just a matter of updating to a new ThingSet SDK revision in west.yml to pull that into the BMS code.

[pasrom]

@martinjaeger, #37 pulls your mentioned changes from thingset-zephyr-sdk, so I think this issue is resolved?

[martinjaeger]

Yes, true. We can close this issue.