New BMS for bq76PL455A based batteries

[Kelju]

I asume I do not have any check sum checking going on.
The basis of my code version originates from here: https://github.com/catphish/lg-daisychain
I was wondering about the updates being a bit old...
I did some digging and found this: https://github.com/catphish/ti-daisychain-bms
At least this version has the CRC checking. Can you confirm if this is the latest code and I should take this as my base?

[catphish]

I did some digging and found this: https://github.com/catphish/ti-daisychain-bms
At least this version has the CRC checking. Can you confirm if this is the latest code and I should take this as my base?

Yes, apologies for the confusion, the version at https://github.com/catphish/ti-daisychain-bms is the latest code. At some point I did a major redesign of the hardware and made a new repo for the new hardware and firmware.

[Kelju]

In my own experience the best results were achieved with a short twisted unshielded cable. In my own car I'm using the 5v version with an external transformer. It's still not perfect, but with checksum checking, the majority of the data is valid, and any bad frames are simply ignored.

I've now tested with the checksum checking. No problems in charge mode, but as soon as the motor spins in the drive mode, the bad frames start piling up. It seems that the Rasp is not able to get any measurement data through while the inverter is switching. I even increased my CAN receive watchdog trigger by a factor of 10 in the Zombie (my own addition to the code to make sure the connected devices are alive) to no avail.

I guess I'll have to start experimenting with the following:
1. Removing the shield from the cable between the first slave and the Rasp
2. Testing different wiring lengths of the twisted pair
3. Building a 3V3 to 5V level shifter on the board
4. Adding an EMC-filter between the inverter and the battery (Not simple at this current level)

[brendonshaw]

Sorry if this is contained somewhere within the post or GitHub and many thanks for the work to explain and demonstrate the interface to the battery BMS. Would you be able to share what is the pin out for the BMS?

Many thanks

[catphish]

Sorry if this is contained somewhere within the post or GitHub and many thanks for the work to explain and demonstrate the interface to the battery BMS. Would you be able to share what is the pin out for the BMS?

I actually don't have a good diagram to answer that question, and in fact I still use trial end error when connecting them up, but I will try to summarize.

Firstly, the 2 small 2-pin connectors that are connected in your picture are temperature sensors. The go to NTC thermistors inside the battery casing.

The 2 4-pin connectors are daisychain data connectors. The one of the positive side of the battery goes towards the BMS, and the one on the negative side of the battery connects to the positive side of the next battery.

On the 4 pin connector, the 2 pins to the very top left of the picture (pin 1 and pin 2) are the data pins that go to the BMS.

Similarly, the bottom-right 2 pins in your diagram (pins 1 and 2 again) go to the next battery in the chain.

The other 2 pins on the daisychain connector (3 and 4) are "alarm" pins, which essentially send out a pulse when everything is within configured limits. I do not use the alarm pins in my design.

Unfortunately I can't remember the polarity of the 2 data pins, I usually just connect them up buy trial and error. Sorry this is a little vague!

[catphish]

In this photo, the plug is upside down (release tab on bottom), and green/blue are the data pins.

[Kelju]

First of all, thank you Catphish for the great piece of equipment.

I've tested the balancing by sending the balance_threshold via CAN and noticed that some of the cell voltage measurement values started to fluctuate quite heavily. at first I was somewhat alarmed by the fact that the maximum cell voltage jumped from 4080mV to 4180mV, but I soon realized that something had to be off with the measurement and not with the actual cell voltage.
I managed to simulate the phenomenon with LTSpice (screen capture included). The Mercedes EQC modules that I am using have very long FPCs to route the individual cell voltages to the TI chip. As the balancing is enabled, the balancing current induces a voltage drop across the resistance of the copper track on the FPC. While the measured voltage of the balanced cell drops, the measured voltage of the adjacent cell actually goes up! This introduces a problem, that on the next measurement round this "high voltage" cell is erroneously chosen as the next one to be balanced.
Now wait a minute... in the code, the balancing is disabled before sampling the cells so why is this happening?
Well, apparently there is some delay in the hardware (maybe some low pass filtering on each channel).
Anyway, I inserted a busy_wait_ms(10) right before the sampling command and the balancing started working without any spurious back and forth switching of the balanced channel.
This all might be highly hardware related and I have not even checked (as of yet) how small a value for the delay I can actually get away with, but just wanted to share my finding.

V1=4V and V2=4V are the simulated cell voltages. Resistors R1, R2 and R3 represent the series resistances of the FPC copper tracks. As the balancing is enabled across V1 at 1s, the measured V1 drops below 3650mV while the measured V2 rises above 4180mV.

[catphish]

Well, apparently there is some delay in the hardware (maybe some low pass filtering on each channel).
Anyway, I inserted a busy_wait_ms(10) right before the sampling command and the balancing started working without any spurious back and forth switching of the balanced channel.
This all might be highly hardware related and I have not even checked (as of yet) how small a value for the delay I can actually get away with, but just wanted to share my finding.

Thank you for the information! I have no such delay in my own code and have not noticed this problem in the form you describe, but I do notice that the choice of cell to balance usually changes on each pass, so it certainly seems that adding a longer delay between disabling the discharge and measuring the voltages would be a good idea. A 10ms delay certainly isn't going to have a detrimental impact on anything, so that seems ideal.

The slave modules I use have very short PCB paths between the cells and the discharge resistors, so I suspect the effect isn't as dramatic.

Did you have a look at the newer firmware at https://github.com/catphish/ti-daisycha ... mware-pico

It gets rid of using CAN to command the balancing, and adds a deep sleep mode that allows the BMS to consume almost no power (600uA) once balancing is finished. Hopefully you can pick and choose what you want from the old and new versions to meet your needs.

I'm glad to hear it's working for you overall. The latest version with the transformers still seems to be somewhat susceptible to noise, but now I only see this when using certain inverters and actually driving, so it's not been a problem.

[Kelju]

I have cloned the newer firmware, but when I tried to make it I get a couple of errors referring to missing include files.
I was able to generate a .uf2 by commenting out the deep sleep functionality.
Anyway, I have made quite a bit of my own changes to the older version, so am a bit reluctant to start over.

I have, however, done some cherry picking from the newer version. I also already modified the code to not need the CAN message to enable the balancing. I might introduce some new parameters to the web interface of the Zombie to change the balancing threshold and number of balanced cells. I was even thinking about introducing a special "maintenance balancing" trigger.
The idea would be that during the maintenance balancing, the cells would be sampled less frequently to allow for a higher balancing duty cycle.
When ever the Zombie is in run-mode, the "maintenance balancing" would be disabled and the cells would be sampled as frequently as possible.

About EMC issues. I experienced heavy interference whenever the Leaf Gen3 inverter was driving the motor. The communication was completely blocked as non of the CRC checks were passing. The problem was solved by including the EMC filter that was originally inside the EQC battery. The filter seems to have a common mode choke and some X- and Y-filter caps. With the filter in line between the battery and the inverter, I have not experienced any loss of communication.

[catphish]

I might introduce some new parameters to the web interface of the Zombie to change the balancing threshold and number of balanced cells. I was even thinking about introducing a special "maintenance balancing" trigger.

If you're using Zombie, you might want to investigate my work in progress: https://github.com/damienmaguire/Stm32- ... 2-vcu:bms2

This code is essentially aimed at allowing the zombie to stop charging when cells and temperatures are outside of their allowed limits.

[catphish]

About EMC issues. I experienced heavy interference whenever the Leaf Gen3 inverter was driving the motor. The communication was completely blocked as non of the CRC checks were passing. The problem was solved by including the EMC filter that was originally inside the EQC battery. The filter seems to have a common mode choke and some X- and Y-filter caps. With the filter in line between the battery and the inverter, I have not experienced any loss of communication.

This is good news and extremely interesting! My design already includes common mode chokes, and I saw significant improvements by adding an Ethernet transformer, but I guess the OEM did it better! If you have any more detailed information about this filter I'd be interested.

[catphish]

I have cloned the newer firmware, but when I tried to make it I get a couple of errors referring to missing include files.

That's disappointing. I'm happy to help if you want to post the error and pursue this, but I understand you may be happy with what you have now.

The idea would be that during the maintenance balancing, the cells would be sampled less frequently to allow for a higher balancing duty cycle.
When ever the Zombie is in run-mode, the "maintenance balancing" would be disabled and the cells would be sampled as frequently as possible.

Assuming you're using a later version of the board (the ones with with molex connectors) it's a shame you didn't get the new firmware working. The way the new one works is that it has 2 "wakeup" lines. When either goes to +12v the BMS will wake up and balance until it feels that balancing is complete). By connecting one to ignition and one to the charger wakeup, you can ensure that the batteries are balanced whenever needed, but no power is wasted when the system is idle. Perhaps you can still implement something similar.

[Kelju]

This is good news and extremely interesting! My design already includes common mode chokes, and I saw significant improvements by adding an Ethernet transformer, but I guess the OEM did it better! If you have any more detailed information about this filter I'd be interested.

Sorry for not being clear on this, but the EMC filter that I am referring to is a big junk of HV passives cased in a sheet metal enclosure and potted in resin. The filter connects on one side to the HVB+ and HVB- and on the other side to the DC-link+ and DC-link-. The complete battery current runs through this filter.

In the first place I included a common mode choke and an ethernet transformer on the BMS board that you provided, but that did not help with the coms. At least not enough.

[Volkmar]

Hi Catphish,

thank you for your replay...

Now the things have changed...because my 2 Motenergy ME1616 motors were too weak I decided to change them into one Model S SDU. This was a lot of work, but now it is done and I have only a few things left to do...like reversing the oil pump and a few other things...

Now with the motor also the battery design changes. I got my hands on a second Volvo XC90 PluginHybrid pack and want to use it in parallel. so the new design of the the batterypack will be : 96S2P.

Each cell block contains 16 cells and on each block there is a BMS board. Do you know if it is possible to use the SimpBMS, which I have already and change thhe code to yours...so it runs with this setup?

I do not want an OBC - I only want to charge the car on CCS - I have already the BMW Lim...and I hope I will get it running...

I really hope you can help me...

Best regards

Volkmar

[catphish]

Each cell block contains 16 cells and on each block there is a BMS board. Do you know if it is possible to use the SimpBMS, which I have already and change thhe code to yours...so it runs with this setup?

If this battery has a bq76PL455A then it won't work with SimpBMS. Unfortunately special hardware is required. That's why I had to design this board.

[Volkmar]

Ahhh…ok…

I think you already told me, that I can purchase the hardware from you. Correct?

If yes, please send me via PM the price and where I have to send the money…Is it also possible to get a Display for reading the SOC, Temperature and momentary current?

Thank you and best regards

Volkmar

[PoloLbricolo]

Hi all,
I've just read through the thread and i have to say i'm impressed !
I have a bunch of mercedes EQC slaves board, advertised as 12s capable with the 76PL455AT-Q1 chip.

So if i want to make some boards, and if i understood correctly, I have to add an ethernet transformer on the comms line ? Could the transformer used on the EQC boards be used ? It looks to be EPCOS B82893 C474 N (https://www.reichelt.com/de/en/inductor ... 45781.html )

If I add that "all" should be ok ? I'm planing on using these in solar batteries, so far less inverter noise than in a car, but still if it improves reliability i'll make the modification.

I was expecting to do all the reseach myself but you did an amazing job, thank you.

[catphish]

So if i want to make some boards, and if i understood correctly, I have to add an ethernet transformer on the comms line ?

The latest version of the board includes the transformer on the board. See https://raw.githubusercontent.com/catph ... ti-bms.pdf

Please note that the bq76PL455A chip is now available to purchase. If I were building a BMS master now, I would use an STM32 and a bq76PL455A instead of this hacky implementation. With that said, my design is proven. It suffers interference with some EV inverters, but it works fine in my car and should likely work fine in a solar setup.

[PoloLbricolo]

Thank you, i'll give a try with your solution as i'm not super inclined with those STM32's and as a proof of concept / testing setup it should be more than good.

[PoloLbricolo]

I just got my boards ealier this week. I all new to the pico workflow, how am i supposed to use the firmware folder ? I've read that you can setup visual studio to compile the firmware, i that what i need to do ?

I'm not that handy with the fimware/code side of things if you couldn't tell.

[Volkmar]

Hello,

I just ordered the boards…the first time for me doing this I hope I did it correct.

Now my question is, how to measure the SoC. can I do this with the Raspberry Pico I use on this board or do I need another board, which takes the Voltage via CAN from this board.

Other option would be to use a Zombie, because I need it for the communication with the BMW LiM.

I hope my questions are clear…

[catphish]

Now my question is, how to measure the SoC. can I do this with the Raspberry Pico I use on this board or do I need another board, which takes the Voltage via CAN from this board.

My software does not currently calculate SoC. In order to maintain the simplicity and reliability, I would suggest taking the cell data from this BMS, and the current from a CAN current sensor, and combining them to calculate SoC elsewhere.

Zombie would be a perfect place to do this, but to the best of my knowledge, Zombie doesn't yet have the code to do so. Because Zombie now has integration with this BMS and with the ISAscale shunt I would definitely recommend adding SoC calculation there.

[cliftonarms]

Not sure if anyone is interested but I have a few of the newer "dual" volvo bms boards for sale here https://www.ebay.co.uk/itm/186171788958 which are for the 18s battery packs, I also have some of the misc volvo hybrid controller packs as well.

These are similar to the ones you have been developing with but have 2 chips servicing 2x8 cells no 1x14.

I purchased the newer 18s hybrid volvo batteries and was going to use the volvo BMS supplied as well, but decided to rewire with full 3rd party BMS's.

Using 10 batteries in a home Solar system so cant really contribute to your car thread .

[Volkmar]

Hi Folks!

I have ordered the master boards, and they have arrived. I uploaded the UF2 file, and behold, I get a reaction... unfortunately, it's the wrong one... countless CRC errors. So, thinking that I might have made a mistake in the configuration of the UF2 file due to my lack of coding skills, I hired a freelancer to obtain a correct UF2 file. But unfortunately, the CRC errors persist.

Unfortunately, I am unable to verify whether it is due to the board... perhaps I ordered the wrong one, or it could be the UF2 file. I am at a loss and have no idea what to do next...

I have already tried the following, but nothing has changed the CRC errors at all:

Used shielded and unshielded cables.
Twisted and normal cables.
120-ohm resistors at the beginning and end of the daisy chain, and both simultaneously.
Shortened the cable length from the master board to the daisy chain to just a few centimetres.
What if the new boards were ordered incorrectly, or the UF2 file is still not right? I have no idea.

Perhaps someone could send me an already functioning UF2 file or create one for me. My battery configuration is as follows: 2 parallel strings with 6 modules each.

I really hope someone can help me, and I thank you in advance!

Best regards,

Volkmar

[Volkmar]

Update:

After a Long Night with several tries, I can tell you…THE MASTER IS ALIVE!

As conclusion I can tell you what I did, that the master is running:
I compiled the code once more, now with ninja. I think there was a fault in the uf2 file.
Changed all cables to new one.
120 ohm resistor at the end of both battery strings.

Nex step: I need the communication cables to the master board with a length of about 1.5 meters. I will try how long they can be without errors and a stable communication.
After that I can implement the BMS into the CAN Bus network with the Zumbie VCU and hopefully charging will work with the BMW LiM.

I keep you updated

UPDATE:

I tested different cable lengths. There are no problems up to a length of about 1.5 meters. I measured a resistance of about 0.2 ohms. It becomes problematic as soon as there are plugs in the cable. Here I found out that a resistance of around 0.5 ohms leads to problems and CRC errors occur.

Since I have two battery blocks, I will now try to use a master BMS board for each block and establish communication with the ZombieVCU via CANbus.
Can someone tell me whether I have to assign different CAN IDs to the two master BMS boards?