Nissan Leaf BMS

[johu]

I haven't monitored the serial on mine but have found that limp mode kicks in as soon as the first cell drops below 3.2V - so the above fits with my experience.

Oh no, I was talking about the current sensor there

So whats a good stopping variable on charging ?
Obviously not the kW charging power request as it goes to zero too often and too early...

I never stop charging. The charger obeys the current limit and if it's zero it temporarily shuts down the PWM. When back to non-zero it resumes.
I recently added a maximum SoC that actually stops the charger for good because I don't always want to charge to full for some life time gain.

[prensel]

Yes, I will change my charging strategy also to provide 0 power when the LBC says so but keep being in the charging stage until either total voltage is hit or one cell's max voltage is hit or one cell goes below min voltage.

I vagely remember seeing a CAN datagram where the LBC says 'charge finished' or something.. not sure what triggers that but I'll look into it.
The strange behaviour around 20% SOC is still a mystery, for now its is solved by asking the mrsses to go outside and re-plug the car

[johu]

Yes there is a charge finished flag but I've never seen it go high. But I don't reach 100% as discussed before.

[Extremetaz]

I haven't monitored the serial on mine but have found that limp mode kicks in as soon as the first cell drops below 3.2V - so the above fits with my experience.

Oh no, I was talking about the current sensor there

Aha! Well that's a very different thing then.

[johu]

Quick update here: I'm running the stm32-car against the newer 40 kWh BMS and everything I need still works, most importantly SoC, SoH, voltages, power limits.

One thing though stopped working, the temperature display. I pulled that from message 5C0 when the "maximum" multiplexer (==1) is sent. No though the value is stuck at 0°C. I checked a log from Damien and here the multiplexer happily cycles. In another log it is constantly 0 and I think it also is in my case. Will probably pull the temperatures via 79b/7bb.
Anyone have info on this?

UPDATE: pulling the first temperature from 79b now, that works. Code as always in stm32-car.

[janosch]

Is your mapping for the inverter params documented?

I can see you building the 0x79B messages in leafbms.cpp of course, but is there a screenshot somewhere of your web interface for example? (Want to double check the gain parameter and so forth).

I can put it in the wiki if you post it here.

[johu]

It's not mapped via the usual CAN mapping. All I could post is a screenshot of it displaying "21"
The return value in 7bb has no offset or gain, it can be used as an integer. I assume signed.

[janosch]

It's not mapped via the usual CAN mapping. All I could post is a screenshot of it displaying "21"
The return value in 7bb has no offset or gain, it can be used as an integer. I assume signed.

I assumed:

1) Various messages are generated from the BMS
2) The messages are parsed in leafbms.cpp on the VCU, they end up in Params, e.g. dislim
2a) after some calculations dislim ends up in Param discurlim
3) How is it sent to the inverter board? I presume it is serialised in Can::AddSend in libopeninv
4) How does the inverter pick it up? Do you rely on variable name/Param id matching in VCU & Inverter and then pick it up automatically?

I am currently sending the throttle messages to the inverter board with can->send in Ms10Task but want to use a more elegant way if there is one.

[johu]

I use the mapping function. Mapping it (discurlim/chgcurlim) as TX in stm32-car and as RX in stm32-foc (idcmax/idcmin). They are both explicitly mapped, no matching between IDs of the two firmware is necessary.

[Cookie6000]

Concerning the 3rd temp sensor I think I've found the place where it forks off to the processor via a series resistor (R59). So I will remove that and bridge it over to the 4th channel behind R62. Now I hope the 4th channel is just copied onto the 3rd.

Hey johu. Just using your work on the Leaf BMS to swap from Grey to White block. Can you just explain from where to where you are bridging to from R59 to R64 and what needs to be left in place and what is removed? Thank you! Great to see the results of the 40kWh pack... you have me searching....

[johu]

So R59 removed and used to bridge R65 and R66

[Cookie6000]

Thank you! Should be able to get the bms in and cross my fingers this eve...

[Cookie6000]

Time flies when life is busy getting in the way.
Been a while but got back to the Leaf BMS. During the last few months, I had to replace a few modules and in the process, managed to get a 'grey' LBC into the deal, Perfect! I just had to rewire the grey plug back to its original format and away we go.
Triple checked everything and plugged it in. Tiny pop... argh!!

I traced the tracks back to Cell 75/76, which was one of the ones I replaced. All the existing cells I measured at ~3.983v and the new ones were ~3.964v. Would a difference of 30mV cause this diode and R560 to run into problems? R587 to the left does not look too good either. I have spares to replace the damaged components so, I'm ok about that but, would like to know your thoughts.

[Isaac96]

A difference should not cause problems, as the BMS is built to measure and handle exactly that.
A nice little pop is usually a result of missing or reversed wiring. Double check?

[Cookie6000]

A difference should not cause problems, as the BMS is built to measure and handle exactly that.
A nice little pop is usually a result of missing or reversed wiring. Double check?

Thanks Isaac. Good to know. I think it's a quadruple check

[paaa]

Just curiously was the bms powered at this point when you connected the cell taps? That damaged 30kwh had something similar but wiring was untouched. I assume previous owner connected cell taps while unit was powered.In my case I was the ic that fried.

[johu]

Now we have a rather curious problem here as well. Talking about the 30 kWh Leaf pack

We have half the pack in box 1 residing in the trunk behind the rear axle including BMS, contactors and service disconnect I believe this to be cells 1-48 (positive most cells). Another 1/4 pack is underneath the car in box 2 and the negative most 1/4 is in the engine bay in box 3. Should be cells 72-96.

1. We noticed that half of the cell voltages became 0 as soon as the service disconnect, separating the 2 halfs was plugged in. Nevertheless the BMS calculated valid charge and discharge limits
2. We then tried to charge the battery and then the BMS went haywire. Charge/Discharge limits are now zeroed and 3 cell voltages display implausible values (1.5V fluctuating between 1.2V and 2V, next two cells 3.75V while all others sit around 3.6V)
3. We then measured the actual cell voltages and they were all in proximity of 3.6V. But while checking we noticed that the cable connecting box 2 and box 3 was NOT tightened. So I assumed that while charging, current flowed via the BMS instead of via the cable and thus damaged the BMS
4. We got a new BMS and before running any current, we checked the voltages. No change, still as above! Also zeroed power limits. SoC, SoH, DC current and temp readings are valid.

So today we went over all cell taps, measured all voltages of box 2 and 3 with a multimeter and even plugged them into the BMS and found valid voltages arrived on its pins. Also in both the old and the new BMS we could not see any physical damage to sense chips or bypass diodes.

What an earth is going on? Did we get a new BMS with the same fault? I'm sure we didn't damage the new one as all voltages are in correct order.

[Cookie6000]

Just curiously was the bms powered at this point when you connected the cell taps? That damaged 30kwh had something similar but wiring was untouched. I assume previous owner connected cell taps while unit was powered.In my case I was the ic that fried.

Nope. Unpowered at the time. I did find the issue however. I began to check the incremental voltage across each pin in the 40 and 16 way molex connectors and it became apparent, there were anomalies. About 70% of the way, values started jumping and once I had noted everything down and a little reverse engineering, I found stupidly I had wired the 2nd line on the LB7 in reverse. All now de-pinned and re arranged in the correct order. Now hopefully, the smoke will stay in the components. I feel like a moron now as I was convinced I checked this a number of times... Can never check enough times I guess.

[johu]

Now I checked that BMS that has faulty values on cells 73-75. Turns out the small front end diode had blown on the 1st channel of IC28 (cell 73 tap). I assume that channel of the acquisition IC is blown as well but it shows no blowhole.

[johu]

Finally this mystery is solved! The GND connection to each 4-channel IC is connected to the lowest cell via a 10 Ohm resistor (R698 in this case). That resistor was blown (measured 30k). Replaced it and we're back in the game!

So maybe swapping in that sense IC from that donor BMS wasn't even necessary.

[jerrykco]

Finally this mystery is solved! The GND connection to each 4-channel IC is connected to the lowest cell via a 10 Ohm resistor (R698 in this case). That resistor was blown (measured 30k). Replaced it and we're back in the game!

So maybe swapping in that sense IC from that donor BMS wasn't even necessary.

Hi Johannes,
I am continuing to work on my '70 MGB build with the Leaf Battery, BMS and EM57 motor. I purchased a 24 pack Buss Bar and the mounting hardware and made a 2ed 24 pack from the two 12's. My first attempt was incorrect - starting off with the wrong polarity. Smoked the original BMS board. 2ed attempt done correctly, I purchased 2 new Leaf BMS's with all white connectors (same as the original).
Before attaching the 24 pack bus bar I used the two 12's sense wire connectors as templates to rewire the two 24 pack connectors as if they were from the two 12s by removing the pins and placing them in the correct positions.

I have hit a snag using the pack sniffer 2 from Woftronix.
The new 24 pack I built was put on a purchased 24 pack buss bar.

However, When I do the initial power on of the PS2 it gives the following sequence.
As you can see in step 7 and 8. those readings indicate something is amiss.

Obviously on the HV side of things the wiring of the buss bars seems to be correct. I even was able to charge the pack. But because I cant see individual cell voltages in the Sequence I must have done something wrong in the sense wiring. As I am not a Electrical Engineer, merely an old technician, I asked a friend who is a EE to take a look and confirm what he could as to my sense rewire job. Here is his report:
Then as an additional verification I probed the voltage on the BMS board with everything connected (well technically we did it at two different times, one for each of the 24 packs). To verify the connections, I put my meter on the negative terminal on the battery and then probed the BMS board right at one of the decoupling caps going into each of the 24 ICs (C809 and C811 for instance).

I tested each side of the cap and subtracted the voltage to verify that each IC was being powered by ~15V (the meter was in 1000V range so easily measures 1V off). By doing this I not only verified that each IC was getting power, but that the voltage was increasing as I went up the chain. I checked the ICs on one side of the board, then flipped it over and did the other side. That means there was ~30V difference between Vcc rails of each IC as I went up one side of the board.

I haven't reviewed all the information about Wolf's CAN bus reader, and I'm not an expert on digital communications by any means, but I wonder if these two newer BMS don't play well with the CAN bus reader. As far as I can tell the battery monitoring chips are all powered and after double checking the wiring it leads me to think that there might be some other issue. Add to that the fact that you have actually charged this stack with the new cables successfully, as all the cells were above 3.5V each, and from the few I measured all the same too. I also did visual inspection of the board and saw no burnt parts and all the ferrite beads supplying power to the chips were intact.

The Original (burned up) board is version 3NA0B and the both new BMS boards I purchased for replacements are 3NA1B. These pictures show the differences of the numbering.

And this is my research into the Sense Wires of the rewired new 24 that should be identical to the original two twelve packs. I measured every pin.

Any thoughts?

[johu]

Sounds like you did your homework. I haven't seen any (relevant) differences in the CAN protocol over all BMS versions, starting at all white and then 30 and 40 kWh BMSses.
You could try and load stm32-car on any available STM32 board with CAN transceiver attached. That would give you a "second opinion". It is standard open inverter firmware with web interface, in case you have a programmed ESP module handy.

[jerrykco]

You could try and load stm32-car on any available STM32 board with CAN transceiver attached. That would give you a "second opinion". It is standard open inverter firmware with web interface, in case you have a programmed ESP module handy.

I ordered this but it will take some time to get and likely longer to learn what to do (Novice)

NUCLEO-WB55RG
497-NUCLEO-WB55RG-ND
STM32WB55RG Nucleo-64 series ARM® Cortex®-M4 MCU 32-Bit Embedded Evaluation Board

STM32WB55RG Nucleo-64 series 32-Bit Embedded Evaluation Board.jpg (38.64 KiB) Viewed 121236 times

[johu]

Sorry, should have been more specific: STM32F1 board - stm32-car doesn't compile for Cortex-M4. So look for Bluepill for example

[jerrykco]

Sorry, should have been more specific: STM32F1 board - stm32-car doesn't compile for Cortex-M4. So look for Bluepill for example

No issue. I can return it. Placed order for n Stm32F1. But it wont be here in USA until April 7th.
In the mean time I'll try and set up my build environment. for STM32-car.
Thanks for the info.