BMS Canbus data

peterperkins

100 W
Joined
Jun 6, 2008
Messages
196
I'm working on a microcontroller project that might eventually get transferred to a micromite but I am struggling to understand a CANBUS crc and security type code formulae.
I sampled some repeating CANBUS data from a working BMS system.

I'm wondering how the two bytes at the end of the packet are generated.
I assume the last is a CRC and the penultimate one some sort of security check as it may not be data related.
Any leads would be appreciated. Sadly polynomials is not my strong point.

ID,D1,D2,D3,D4,D5,D6,D7,D8
203,0,0,0,0,0,0,0,9A
203,0,0,0,0,0,0,20,2F
203,0,0,0,0,0,0,1D,7E
203,0,0,0,0,0,0,0,8B
203,0,0,0,0,0,0,20,10
203,0,0,0,0,0,0,1D,6F
203,0,0,0,0,0,0,0,B8
203,0,0,0,0,0,0,20,1
203,0,0,0,0,0,0,1D,50
203,0,0,0,0,0,0,0,A9
203,0,0,0,0,0,0,20,3E
203,0,0,0,0,0,0,1D,41
203,0,0,0,0,0,0,0,9A
203,0,0,0,0,0,0,20,2F
203,0,0,0,0,0,0,1D,7E
203,0,0,0,0,0,0,0,8B
203,0,0,0,0,0,0,20,10
203,0,0,0,0,0,0,1D,6F
203,0,0,0,0,0,0,0,B8
203,0,0,0,0,0,0,20,1
203,0,0,0,0,0,0,1D,50
203,0,0,0,0,0,0,0,A9
203,0,0,0,0,0,0,20,3E
203,0,0,0,0,0,0,1D,41
203,0,0,0,0,0,0,0,9A
203,0,0,0,0,0,0,20,2F
203,0,0,0,0,0,0,1D,7E
203,0,0,0,0,0,0,0,8B
203,0,0,0,0,0,0,20,10
203,0,0,0,0,0,0,1D,6F
203,0,0,0,0,0,0,0,B8
203,0,0,0,0,0,0,20,1
203,0,0,0,0,0,0,1D,50
203,0,0,0,0,0,0,0,A9
203,0,0,0,0,0,0,20,3E
203,0,0,0,0,0,0,1D,41
203,0,0,0,0,0,0,0,9A
203,0,0,0,0,0,0,20,2F
203,0,0,0,0,0,0,1D,7E
203,0,0,0,0,0,0,0,8B
203,0,0,0,0,0,0,20,10

and a bit more with some data.

203,24,62,46,24,72,47,20,3C
203,24,92,46,24,72,47,2B,4D
203,24,A2,4B,0,0,0,0,99
203,24,62,46,24,72,46,20,2E
203,24,92,46,24,72,46,2B,7B
203,24,92,4D,0,0,0,0,89
203,24,42,44,24,72,44,20,15
203,24,92,44,24,72,4A,2B,6A
203,24,C2,4C,0,0,0,0,B4
203,24,22,42,24,62,3F,20,1
203,24,92,42,24,62,4F,2B,59
203,25,32,4B,0,0,0,0,AE

Grateful for any leads and ideas..
I have done a fair bit of googling and read some excellent articles but the maths is way over my head.
 
It's from an OEM lithium battery pack in a Honda Civic Hybrid.
 
peterperkins said:
I'm working on a microcontroller project that might eventually get transferred to a micromite but I am struggling to understand a CANBUS crc and security type code formulae.
I sampled some repeating CANBUS data from a working BMS system.

I'm wondering how the two bytes at the end of the packet are generated.
I assume the last is a CRC and the penultimate one some sort of security check as it may not be data related.
Any leads would be appreciated. Sadly polynomials is not my strong point.

ID,D1,D2,D3,D4,D5,D6,D7,D8
203,0,0,0,0,0,0,0,9A
...

According to wikipedia data frames contain 8 bytes of data, and the CRC is not a part of those 8 bytes.

And given that ID is 11 bits, and you're showing the ID as 203, that must be decimal (0xCB), but your D1-D8 are shown in hex; and should be the data itself. You are not showing the CRC in your post.
 
Perhaps I mislead you then. Apologies.

It's not the actual raw canbus bits crc, but a crc or security check related directly to the 8 data bytes.
One or more of the 8 bytes (i.e last two being a security/crc byte/s)
I suspect the last byte is a data bytes CRC.
The penultimate byte may be a security byte perhaps challenge/response?
 
On a slightly different theme when i connected the BMS board to a fake battery it gave cell voltage readings in the CAN data.
The BMS reads ten cells per board and is based on the common LTC 6803/4 series chips.

Attached are the csv log files from the canbus with several voltages and variations.

I logged the following voltages across the fooler 0V, 10v, 20v, 30, 40 and 1-40v rising. (Divide by ten for cell volts)
So 0v, 1v,2v,3v,& 4v per cell respectively.

From that we should be able to decode the bytes.
It looks like the cell V data is sent as three consecutive/repeating canbus frames.

Each frame has header id byte decimal 203 and 8 data bytes.
We can ignore the last two bytes for the moment as they are a CRC/security bytes.

That leaves 6 data bytes per frame for a total of 18 data bytes (Three frames).
The last three bytes in the third frame are always zero.
So that means the voltage data for ten cells is likely being encoded into 15 data bytes, so it's probably 12bit data for each cell.
One byte and one nibble for each cell. (12 bits)

As the boards may have been originally designed to support upto 12 cell that helps explain the three (0) data bytes in the 18 available.
If all 12 cells had been implemented then the 18 data bytes would have been filled.

Anyway bearing in mind the cell voltages I used for testing. eg 40v / 10 = 4v per cell we should be able to work it out.

The voltages I logged may not be exactly to the 0.01% but if I say 40v (4v per cell) then it should be somewhere near in the data.

The data sheet for the LTC6804 chip makes clear the adc is a 12bit type so that supports my theory above.

ADC RANGE AND OUTPUT FORMAT
The ADC outputs a 12-bit code with an offset of 0x200
(512 decimal). The input voltage can be calculated as:
VIN = (DOUT – 512) • VLSB; VLSB = 1.5mV
where DOUT is a decimal integer.
For example, a 0V input will have an output reading of 0x200.
An ADC reading of 0x000 means the input was –0.768V. The
absolute ADC measurement range is –0.768V to 5.376V.
The resolution is VLSB = 1.5mV = (5.376 + 0.768)/212. The
useful range is –0.3V to 5V. This range allows monitoring
supercapacitors which could have small negative voltage.
Inputs below –0.3V exceed the absolute maximum rating
of the C pins. If all inputs are negative, the ADC range is
reduced to –0.1V. Inputs above 5V will have noisy ADC
readings (see Typical Performance Characteristics).

Now wether the canbus is this raw adc data or some sort of cleaned up/manipulated data remains to be seen.
The calculation above does not work on the recd data so something else is going on with it.

For a 20v (2v per cell) input we get the following hex data. (I have split it into 12bit chunks and omitted all the junk/check bytes)

4D2,4D2,4D2,4D4 = 20V (2v per cell)
4D7,4D2,4D4,4D3
4D7,4D6

For a 10v (1v per cell) input we get the following hex data.

246 246 247 246 = 10V (1v per cell)
249 246 247 246
249 24D

All very close indicative of the 1% tolerance resistors in the fake battery potential divider fooler.
So how do we get approx 2 or 1v per cell from this?

20180113_170955.jpg
 

Attachments

  • HCHBMSDATA.zip
    11.8 KB · Views: 25
peterperkins said:
Perhaps I mislead you then. Apologies.

It's not the actual raw canbus bits crc, but a crc or security check related directly to the 8 data bytes.
One or more of the 8 bytes (i.e last two being a security/crc byte/s)
I suspect the last byte is a data bytes CRC.
The penultimate byte may be a security byte perhaps challenge/response?

Update: most of this is redundant in light of your latest post that came after I started writing this. But you still give no indication of why you think you have a CRC (which it cannot be) or security bytes (which it could, but its hard to see why)?

I doubt it is challenge/response, as REMOTE REQUEST packets contain no data; presumably the ID is used to indicate what data is being requested. It would also have the RTR bit set for remote frames.

Given that you have multiple -- many -- packets with 7 zero bytes and different D8, it cannot be a CRC of the other data bytes. What makes you think the last one or two bytes might be CRC or security bytes? Do you have any kind of spec for the packet data?

In your first set of data, there are two obviously repeating sets of packets that you show repeating 3 times complete and the start of a fourth:

203,0,0,0,0,0,0,0,9A
203,0,0,0,0,0,0,20,2F
203,0,0,0,0,0,0,1D,7E
203,0,0,0,0,0,0,0,8B
203,0,0,0,0,0,0,20,10
203,0,0,0,0,0,0,1D,6F
203,0,0,0,0,0,0,0,B8
203,0,0,0,0,0,0,20,1
203,0,0,0,0,0,0,1D,50

203,0,0,0,0,0,0,0,A9
203,0,0,0,0,0,0,20,3E
203,0,0,0,0,0,0,1D,41

There is the hint of a pattern (3 line groups) in the second set, but you haven't supplied enough to say for sure. My guess would be that the D0 byte in the second set identifies the S groups 24 & 25; and each group of 3 lines represents one (set of) value(s) pertaining to that group;

But that's based on nothing more than "BMS" and a wild-assed guess; and working out how to interpret each set of values -- are they IEEE754 encoded flaots representing voltage; or delta changes in microvolts; or temperatures; or...

Without some clue as to what information is being communicated, you really don't stand a chance of decoding it.

Even if you can guess what some of the values are, you'd need to correlate the packets with something else to work out the representation.

For example; monitor the bus with: no load; some load; heavy load; during recharging; and take careful notes of what packets occurred when.

Also, measure the voltages (and change in voltages) across the groups and try to relate lower values with packets with smaller numbers etc.
 
peterperkins said:
For a 20v (2v per cell) input we get the following hex data. (I have split it into 12bit chunks and omitted all the junk/check bytes)

4D2,4D2,4D2,4D4 = 20V (2v per cell)
4D7,4D2,4D4,4D3
4D7,4D6

For a 10v (1v per cell) input we get the following hex data.

246 246 247 246 = 10V (1v per cell)
249 246 247 246
249 24D

What did you get for 30V and 40V?
 
peterperkins said:
It's in the attachment I posted.

Hm. So rather than post your results from 30V & 40V along with your results from 10V and 20V, you force anyone who wants to try and help you to download a zip of all your data and then write code to try and reproduce your results.

Good luck with that.
 
I thought it was more useful that it was all together in context and in the zip file, or perhaps you hadn't seen it.
Of course I don't expect people to dig around to help if they can.

30v = 3v per cell =
756,75C,75A,75C
75C,75E,760,761
76B,764,

40v = 4v per cell =
9DD,9E2,9DF,9E2
9E4,9E3,9E5,9E7
9F0,9EA
 
peterperkins said:
I thought it was more useful that it was all together in context and in the zip file, or perhaps you hadn't seen it.
Of course I don't expect people to dig around to help if they can.

30v = 3v per cell =
756,75C,75A,75C
75C,75E,760,761
76B,764,

40v = 4v per cell =
9DD,9E2,9DF,9E2
9E4,9E3,9E5,9E7
9F0,9EA

If I were you, I would repeat the 0-40 ramp test, but this time, leave it at 0V for at least 5 seconds -- according to your existing dataset, the ADC didn't notice any change for 2.2363 seconds -- and then ramp slowly over say 30 or even 60 seconds, rather than 7 seconds. I'd also go up to 45V.

It's also unclear to me what the meaning of the '!' character after the timestamp is? Perhaps a framing or packet crc error detected by your CANbus sniffer?
 
The delay at the beginning is the time between me pressing the capture button and me twiddling the knob on the variable output dc power supply. The ramp up and down detection is real time when watching it live. The delay was mine.
 
peterperkins said:
The delay at the beginning is the time between me pressing the capture button and me twiddling the knob on the variable output dc power supply. The ramp up and down detection is real time when watching it live. The delay was mine.

Then I think you need a better pot. It jumps right off the end of the scale initially:
Code:
 208,212,193,226,222,230,252,227,197,231,0,0
 208,212,193,226,222,230,252,227,197,231,0,0
 *3100*,365,415,414,416,3106,362,371,377,405,0,0
 *1735*,384,409,406,411,1748,355,397,369,407,0,0
 631,455,458,459,462,643,443,465,459,468,0,0
 526,533,540,539,544,544,542,555,556,555,0,0
 590,595,604,601,607,607,607,621,617,617,0,0

I still think that if ramped more slowly it might give a clearer picture.

My best guess is that the ADC is set up to read 0-5V mapped to 4096 range, and it has an ~200 leakage at the bottom end, but that could be from your BMS fooler or a non-precision pot?

If you ramped up in discrete steps and took precision meter readings at each step, you could discard the front and back readings at each step and have a precise value to try and match the middle against.
 
Thanks to all for the input.
I did have some errors in the voltage readings which made the calculation difficult.
Now resolved and that bit works OK.
 
Back
Top