According to wikipedia data frames contain 8 bytes of data, and the CRC is not a part of those 8 bytes.peterperkins wrote: ↑Jan 14, 2018 3:54 pmI'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.
Now wether the canbus is this raw adc data or some sort of cleaned up/manipulated data remains to be seen.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).
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)?peterperkins wrote: ↑Jan 15, 2018 3:08 amPerhaps 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?
What did you get for 30V and 40V?peterperkins wrote: ↑Jan 15, 2018 3:20 am
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)
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
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.
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.peterperkins wrote: ↑Jan 15, 2018 12:00 pmI 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 =
40v = 4v per cell =
Then I think you need a better pot. It jumps right off the end of the scale initially:
Code: Select all
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