openinverter forum

In order not to destroy Damien's thread, I am making a new thread here to use the original Model 3 Battery Controller. Collin has described that the controller can be used as a bms when using all 4 modules. I have tried that and can confirm that after applying the supply voltage on 0x401 96 values (Voltage ?) ​​are sent and 16 on 0x712 (themperature ?), In the next step, i will connect the modules and write a test program that will display the values ​​on the screen.

muehlpower wrote: ↑Wed May 19, 2021 8:13 am In order not to destroy Damien's thread, I am making a new thread here to use the original Model 3 Battery Controller. Collin has described that the controller can be used as a bms when using all 4 modules. I have tried that and can confirm that after applying the supply voltage on 0x401 96 values (Voltage ?) ​​are sent and 16 on 0x712 (themperature ?), In the next step, i will connect the modules and write a test program that will display the values ​​on the screen.

It sounds like an simple test to do, got my battery all rigged up, just connect power to HV controller and canbus sniff.

Would be great if someone had a model 3 that can mount an inductive canbus reader to battery canbus, like Damien did with that charging intake.

There really should not be so much communication needed to start active balancing, right?

Will have my pack connected up this weekend to join in. Found some useful info in these:

https://github.com/joshwardell/model3dbc

https://docs.google.com/spreadsheets/d/ ... 1426009388

A potential problem you all might have is that Tesla decided to really switch things around between firmware versions. For instance, both 0x401 and 0x712 are not found on recent (last year or two) versions of firmware. This is not a problem at all so long as the pack you have is still reporting on those IDs. But, if you were to source another pack it could have firmware where those IDs don't appear. In that case, investigate 0x312 and 0x332. I think you might find some interesting data in there.

collin80 wrote: ↑Thu May 20, 2021 12:27 am A potential problem you all might have is that Tesla decided to really switch things around between firmware versions. For instance, both 0x401 and 0x712 are not found on recent (last year or two) versions of firmware. This is not a problem at all so long as the pack you have is still reporting on those IDs. But, if you were to source another pack it could have firmware where those IDs don't appear. In that case, investigate 0x312 and 0x332. I think you might find some interesting data in there.

Thanks for sharing Collin

Just a check, did anyone already have the pin numbering for the pins in the HV controller connector?

nkiernan wrote: ↑Thu May 20, 2021 7:25 pm Just a check, did anyone already have the pin numbering for the pins in the HV controller connector?

20.gif

You mean like a list of which pin is which? I didn't/don't but I do have something kind of similar. I took a picture of the backside of the board and it is numbered. So, just rotate all those numbers back around to be the top of the board.

Just a check, did anyone already have the pin numbering for the pins in the HV controller connector?

20.gif
[/quote]

does that help? The white is CAN L, grey CAN H. Already terminatet with 120 Ohm. The other big terminal is another 12V+, maybe kl30?.

nkiernan wrote: ↑Thu May 20, 2021 7:25 pm

muehlpower wrote: ↑Fri May 21, 2021 8:48 am does that help? The white is CAN L, grey CAN H. Already terminatet with 120 Ohm. The other big terminal is another 12V+, maybe kl30?.
20210521_103434.jpg

The other big terminal powers the shunt system on the far side of the board. It is not required to be powered to get the BMS to function and monitor the cell voltages.

Thanks Collin and Muehlpower, that's exactly what I was after

collin80 wrote: ↑Fri May 21, 2021 4:25 pm

muehlpower wrote: ↑Fri May 21, 2021 8:48 am does that help? The white is CAN L, grey CAN H. Already terminatet with 120 Ohm. The other big terminal is another 12V+, maybe kl30?.
20210521_103434.jpg

The other big terminal powers the shunt system on the far side of the board. It is not required to be powered to get the BMS to function and monitor the cell voltages.

Is a CAN message necessary to activate the balancing or is it enough to apply a voltage to the +12V/GND pins?

muehlpower wrote: ↑Fri May 21, 2021 6:12 pm Is a CAN message necessary to activate the balancing or is it enough to apply a voltage to the +12V/GND pins?

I don't believe any CAN traffic should be necessary. The biggest things needed seem to be not being in drive (won't balance while you're driving), not heavily charging or discharging (seemingly less than 20A?), and detecting that the pack is out of balance. It seems this imbalance will need to be larger than 0.005V to trigger balancing. You might need to send messages that let it know it's currently "idling" and not "driving" but I think it will probably default to thinking it's not driving so no CAN traffic might be OK. Before balancing it will, however, check that it could enable the balancing resistors. So, my assumption would be that if you don't have all four modules hooked up it would find that it couldn't enable some balance resistors and then refuse to work.

However, I don't have a full Model 3 pack to test with so this is all just the result of dark arts and guessing. And, of course, the firmware version of your pack might make a difference. However, the good news is that it sure looks to me like the BMS will automatically do balancing based on the pack being in a good state to do so and the modules being out of balance.

And, if anyone wants to capture logs and send them to me, I'll run them through interpretation to see what's going on. There are two CAN ids where logging of the BMS status is done: 0x374 and 0x3B2. Unfortunately, it seems like 0x374 is not output by default. But, it looks like 3B2 is so theres still some data there to look at. It is heavily multiplexed.

This isn't super interesting but if you send a CAN frame with ID 0x500, length 2, bytes 05, 01 it will put the BMS system into extended debug output. It seems like you have to send every 100ms or so for a while to make this happen. But, it only seems to enable two extra IDs, 0x7D2 and 0x7F2. 0x7F2 is gateway CAN log but only gives seemingly unimportant statistics. 0x7D2 seems interesting but I don't have any reference for what is stored in there. It's multiplexed seemingly. So, at the moment I don't know what good it would do to enable this. But, something happens if you do it.

Now I got my hvdc controller connected, crazy amount of traffic




Unfortunately there are not many messages that you guys had, my battery is from 2019

fredd90 wrote: ↑Sat May 22, 2021 12:49 pm Now I got my hvdc controller connected, crazy amount of traffic


Unfortunately there are not many messages that you guys had, my battery is from 2019

why not? You have 0x401 and 0x712, just like mine from 2018.
your cell voltage is 3,7496V, temperature shows 1710, maybe 17,1 C°?

Also got the HV controller connected up today and first CAN captures. Attached a capture with the full pack BMS connected (55kWh short range pack, modules not connected) and a capture of the vehicle CAN (just because I had a look). Have the 401 and 712 messages here too, but haven't looked at the detail yet to check voltages...but I do believe this pack definitely needs balancing.

muehlpower wrote: ↑Sat May 22, 2021 3:26 pm

fredd90 wrote: ↑Sat May 22, 2021 12:49 pm Now I got my hvdc controller connected, crazy amount of traffic


Unfortunately there are not many messages that you guys had, my battery is from 2019

why not? You have 0x401 and 0x712, just like mine from 2018.
your cell voltage is 3,7496V, temperature shows 1710, maybe 17,1 C°?

Yes you are right, my mistake very good news, is there by any chance any messages that tell us the least and most charged cell-voltage, had been easy to make code to stop charger/regen if voltage by any cell reach max/min

The actual measured voltage of the battery package is 377vdc.
Total pack voltage if i take 3.7496 x96 is approx 360vdc, it will be needing a good amount of balance, good test to se if all the battery cells gets balace

fredd90 wrote: ↑Sat May 22, 2021 8:46 pm Yes you are right, my mistake very good news, is there by any chance any messages that tell us the least and most charged cell-voltage, had been easy to make code to stop charger/regen if voltage by any cell reach max/min

ID 0x332 sends the min/max values. It is multiplexed and switches between min/max temperature and min/max voltage. For voltage find frames where the first byte has its lowest 2 bits set to "01". Voltages are sent as 12 bit numbers (little endian) in 2mv precision. Max voltage starts at the third bit in byte 0, Min voltage at the first bit of byte 2.

So, if you have a frame like this:
0x332 bytes 95 9F E1 67 B2 16

it means:

Multiplexor: Voltage Values,
Min CellV: 4.034V,
Max CellV: 4.042V,
Min Cell Number: 23,
Max Cell Number: 51

Note that the cell numbers are only 1 to 128 and they're 7 bit numbers (thus you mask off the top bit of B2) and you add one. That's why 0xB2 yields 51 as an answer. I don't know why the top bit is set. I don't know that it means anything.

That is, perhaps, not quite as simple as you might have hoped but the data is in there.

Connected up the four modules to redo the CAN capture as full pack. Attaching two captures, the basic CAN output and then injecting the 0x500 Collin mentioned above. I didn't see the extra 0x7D2 or 0x7F2 ID's but will check again.

For reference, module and pack voltages measured with multi-meter:
- Module 1 (pack -) = 75.0V
- Module 2 = 75.3V
- Module 3 = 72.2V
- Module 4 (pack +) = 72.0V
- Complete pack = 294.5V

Thax for amazing knowledge Collin

Got a look at all the cells manually and it looks promising to be a healthy battery

ID: 0x332 will be easy to use but i cant really see it in my log, closest item is 0x14A (0x330)

would be grateful if you can look at my attached file

fredd90 wrote: ↑Sun May 23, 2021 7:35 pm Thax for amazing knowledge Collin

Got a look at all the cells manually and it looks promising to be a healthy battery

ID: 0x332 will be easy to use but i cant really see it in my log, closest item is 0x14A (0x330)

would be grateful if you can look at my attached file

i'm not collin, but i looked at your logfiles. It should be possible to find the highest and lowest value using an Arduino program. What I noticed is that byte 1 is a status byte. If all 3 values ​​are OK, it is 0b00101010. If only the third value (D6 + D7) is valid, 0b00100101 is displayed, if everything is invalid, it is 0b00010101. But maybe it means that it is at the moment balancing and therefore a dummy value is being sent!

Is it to do with the second CAN bus on the HV controller? 0x410, 0x712 and the same 0x14A show on my logs above from the CP CAN captures. 0x332 shows on the vehicle CAN captures.

Its looking like I probably should have mentioned that you should send 0x500 on the vehicle bus and also find 0x332 on the vehicle bus. The CP bus is just for comm to the charge port controller and I have no idea which messages are sent there as well but it's not all of them. The debugging output goes to the vehicle bus where it could be picked up by the central computer / ICE.

It might also be worth mentioning that in my above picture you can see that I soldered a resistor between the two CAN pins for the PT / vehicle bus. I think it is otherwise not terminated. So, if you hook up a CAN capture tool to those pins you need to ensure you have some termination, either on the wiring or inside the CAN capture tool. Most of them are not terminated. I was lucky that I could just cheat as the board in my picture has been dremel'd out from the housing so I can get at the back. The rest of you probably don't want to be that destructive.

fredd90 wrote: ↑Sun May 23, 2021 7:35 pm Thax for amazing knowledge Collin

Got a look at all the cells manually and it looks promising to be a healthy battery

ID: 0x332 will be easy to use but i cant really see it in my log, closest item is 0x14A (0x330)

would be grateful if you can look at my attached file

It may not do a lot of good as it sounds like you captured the CP bus and that doesn't have all the same messages on it. Probably some of the info is still here but perhaps on different IDs sometimes. It'll be easier to capture the power train bus if you could. Also, what program generated that log file? I don't currently have anything to open it and do analysis. I can write something to read it but I'd like to know what to call it.

Latest capture of the vehicle CAN with the four modules connected up to make full pack and a second CAN capture with 0x500 introduced after approx 10 seconds for comparison. As Collin said, the two extra ID's do show up here too