openinverter forum

Not much of the DBC is known. I've captured the internal can bus with the contactors closing (using the Key On capture on the hybrid can).
https://github.com/jamiejones85/GolfGTE ... losing.csv


When I replay the charging on the respective PT and hybrid cans I get the contactors closed for less than a second and immediately open.
https://github.com/jamiejones85/GolfGTE ... enOpen.csv

I can't put a charge in to the pack as it's on the garage floor and I don't have a spare charger, but I do have a load of spare slave boards. My plan was to get an internal capture with the charging replaying to the external buses, and then replay the internal capture to a spare board with nearly full but out of balance 18650s.

I have a hunch based on how the messages are built and the fact there are 12 cells per slave.
Having reviewed the logs to figure out which IDs are most likely from the pack master.
These are the first two ids that contain the same values for another 7 sets of ids.

Since there are 8 module with 12 cells each this sort of makes sense.

Then you see the behaviour, 16x 0xFE followed bij 12x 0x00 and 4xFE. So could this be an initialisation state and then 12 values (relating to 12 cells?) get set to zero, and remaining 4 are still in the init state due to not being used.

I would say try and spoof this behaviour onto the bus and then set the values to something else then 0x00 after the initialisation.

Not following I can get a capture of just the master on the internal bus it get ID's it sends. So far I think 0x0BA 3rd byte is contactor related, when it's 0x29 the contactors are closed. The normal IDs use a strange CRC so modifying might be difficult, 2nd byte 2nd nibble seems to be a counter on these. The extended IDs don't seem to have a counter. https://github.com/commaai/opendbc/blob ... /common.cc is all I can find on that.

My hunch is that the message ids: 0x1A55540A to 0x1A55541F

contain a balancing command, as the table below. As a vw gte pack with a SimpBMS does not use these messages getting them onto the bus should be straight forward and can be altered for testing.

I could also just code this experimentally into the SimpBMS code, I will have a look around localy and see if I can obtain one GTE module for testing.

Created a DBC file to decode the Golf/Passat GTE packs.

https://github.com/Tom-evnut/VW-bms/tre ... Golf%20Can

If anyone has anything to add please push to this file so we can get more info into the DBC

I see what you mean now I've looked in savvycan. I've got a few BMS slave boards if you want a couple posting. I believe rstevens81 is near to you and have 8 modules also.

Any guesses as to what value will kick it off? I can send some to a board with 18650s attached this week.

0xbb is likely from the contactor/shunt/isolation board, bytes 1&2 are thought to contain the current "It measures + or - and upto about + - 200 Amps . Value seems to be Amps × 160"

I have obtained a module and can probably also obtain a contactor box when I get to it. Any more captures of a full pack being used however is very useful.

Once I have more findings I will report here.

So my hunch looks correct. Turns out that the message that contains the temperatures also contains feedback.

I am still working on trying to verify it actually works, my module however is at 3.69 cell volts so causing a voltage delta utilizing balancing bleeders is hard.
The findings are updated in my github, also put a crude function to force balancing on module 7 and 8 in code and this is only meant for testing. If anyone has a test setup and wants to try something please let me know and I can tweak the code to match.

Ive got 1 pack in the car and one in the garage. I can test, ill take a look on your github and knock up something on the esp32.

The internal can logs are from my pack in thr garage, noy acutally checked on the reported delta, i know the car has 30mV delta at the min.

Nice work

I have had to run my testing for a prolonged period of time, 6+ hours due to the module under test being around 3.68V (thus the "fat" region in the SOC curve).

I can conclude no that the cells which are commanded to discharge have actually all droppen away from the rest of the cells. This is done with one module in a repeating pattern and another forcing a single cell to discharge.

This means I can commit to writing a section of software that determines which cells need balancing based on voltage, just like the Tesla Model S firmware.

Nice work.

Nice work, as I might be joining the golf battery pack group. I'm looking at Gte pack which I presume is a smaller version of the E golf pack.

Good news everyone,

VW GTE Balancing is confirmed to work after the work I have down in the past week.

The firmware has been updated, verified working and published to Github.

Note: VW E-Golf modules will still required to be verified if they are compatible with the balancing coding.

Nice one, thanks, ill merge imto my fork and test. Going to grab some more internal logs over the weekend of the pack loosing HV isolation, i know the contactor board can measure it, ive seen vcds reporting the isolation resistance.

I know it can also report the state of the fuse, and contactors, which might also be useful.

tom91 wrote: ↑Fri Feb 25, 2022 7:50 pm Good news everyone,

VW GTE Balancing is confirmed to work after the work I have down in the past week.

The firmware has been updated, verified working and published to Github.

Note: VW E-Golf modules will still required to be verified if they are compatible with the balancing coding.

I can test this with The Samsung e-golf modules if you want.
If one module set is enough, I can do it Tonight or Tomorrow.
(1 module with bms + the interconnected modules)

I also have the contactor box from e-golf.

tom91 wrote: ↑Fri Feb 25, 2022 7:50 pm Good news everyone,

VW GTE Balancing is confirmed to work after the work I have down in the past week.

Great work Tom. I have a full ID.3 pack available as a test rig. Do you believe your work would work with MEB modules too?

raine wrote: ↑Sat Feb 26, 2022 7:19 pm Great work Tom. I have a full ID.3 pack available as a test rig. Do you believe your work would work with MEB modules too?

ID3 is possibly different interms of balancing but the reading of temps and voltages work I believe. Best things to do is capture canbus of it, and grab one with balancing being broadcast and one with balancing not being broadcast.

It looks like 0x15B 2nd byte contains some state info, when the contactors are open it is 0000, briefly goes to 0001 then when the contacts are closed and the fuse is in place the first nibble is 0101, removing the connection after the fuse this becomes 0001 for 2 messages and then 1111 (error state?) it returns to 0000 if contactors are closed due to external bus messages stopping.

It looks like the 2nd bit could be the fuse state.

More internal logs on my fork https://github.com/jamiejones85/GolfGTE if anyone is interested.

Had a customer test the VW Egolf pack and it works in the same way. So Balancing now works for the VW modules.

I have 2 of the 36kWh eGolf packs and a SimpBMS on the way and am wondering whether there is some flexibility in reconfiguring them to a combined pack.

I could use the two packs in parallel but I'm not sure that I have the weight budget for that yet, in any case that would probably mean that I need two SimpBMS to cover them both?

The other option I would like to explore would be to add modules from the other pack to go from 88s into say 108s or similar. Has anyone tried that, would it work?

Do the modules need to be in their original ordering as well?

Thanks!

jnsaff wrote: ↑Fri Mar 25, 2022 8:03 am I have 2 of the 36kWh eGolf packs that would probably mean that I need two SimpBMS to cover them both?

The other option I would like to explore would be to add modules from the other pack to go from 88s into say 108s or similar. Has anyone tried that, would it work?

Do the modules need to be in their original ordering as well?

I've tried using a CAN-bridge to shift addresses in the past with the older (panasonic) packs, that hat unexpected results (not nice...heavy unbalance). So best to use two SimpBMS

where the older panasonic 'master' modules (with the CMU's) could handle 12s per CMU, the new (Samsung) packs are not flexible, and the CMU's with less than 12 cells total have to be connected to the same number of cells as in the original packs (or you have to find a way to change the firmware settings in them)

boekel wrote: ↑Fri Mar 25, 2022 8:52 am I've tried using a CAN-bridge to shift addresses in the past with the older (panasonic) packs, that hat unexpected results (not nice...heavy unbalance). So best to use two SimpBMS

Was they really out of balance or just reported as such? I'm going to be attempting this soon.

Bigpie wrote: ↑Thu Mar 31, 2022 12:43 pm

boekel wrote: ↑Fri Mar 25, 2022 8:52 am I've tried using a CAN-bridge to shift addresses in the past with the older (panasonic) packs, that hat unexpected results (not nice...heavy unbalance). So best to use two SimpBMS

Was they really out of balance or just reported as such? I'm going to be attempting this soon.

they were -very- out of balance.

Can't see how the BMS could have caused that, any ideas?

Bigpie wrote: ↑Thu Mar 31, 2022 1:41 pm Can't see how the BMS could have caused that, any ideas?

well it did...

modules that weren't connected were fine, bms somehow actively unbalanced them. And this was years ago, without any known balancing commands.

Not saying it will happen to you (these were panasonic modules...) but just beware.