Nissan Leaf BMS

[Isaac96]

@prensel - are you using the BMS alone? I couldn't get mine working with Leaf Spy lite - as far as i remember, upgrading to pro fixed the issue.
-Isaac

[prensel]

Yes I'm using it without any other Leaf component, just the LBC and the batteries

It sometimes seems to connect with the el-cheapo BT dongle I have but most of the time it wines about not being able to control it using AT commands or something.
So i've ordered the advised LELINK BLE dongle from Amazon which should arrive tomorrow.
If that doesnt work with Lite I will upgrade to pro.

[Isaac96]

The mode has to be set to "BMS only" within Leaf Spy (I assume you know that, just making sure) I think I couldn't make it work like that in Lite, only in Pro. But the AT commands is definitely a dongle issue.

-Isaac

[prensel]

Ok got the Pro app and still nog go.
So I tried again with the OBDLink MX+ dongle and that one does work on both versions,
Lite and Pro. So its definately the el-cheapi BT dongle not working.

Any way checked the DTC's and Leaf Spy showed 2, well actually 4.
One U1000 some CAN error and the otherone/three is for each temp sensor.
Then I cleared the errors and the one for U1000 keeps coming back. That seems to be the DTC error 0x03 from the
0x5C0 datagram.

The otherone 0x60 (96) is gone now so that one was for the three temp sensor errors.
Cant figure how these numbers relate. 0x60 is 2 bits so cant relate that to three error codes.

[johu]

And Mr. LeafSpy won't reveal the decoding?

[prensel]

And Mr. LeafSpy won't reveal the decoding?

I wont bother him asking
And as always its more fun trying to find the 'flag' myself.

Anyway, I tried to trigger other faults by pulling the temp sensors and see what happens.
Funny thing is I still get one error per sensor, one error per 2 sensors or one error per 3 sensors.
So I will code some lines that spit all 256 possible errorcodes on the CANbus and see what Pcodes pop-up in the LeafSpy.
Maybe it is just an array of messages and number 96 is just this particular Pcode and there's no fancy coding at all.

During peeking and poking around I noted when requesting the LBC/ECU version number it is 'hidden' in the group 131 and 132, each group with 4 frames, within the 0x7BB response datagrams.
Not very usable but interesting to see how they use this 0x79B and 0x7BB request/response system.
And obviously there are a lot more groupID's then i have seen sofar in de DBC files.
Haven't looked at what happens when clearing DTC's but assume they use this in somewhat similar way.

Looking into the EVB manual it says U1000 error is caused by lack of some CANbus datagrams for at least 2 seconds.
I guess the LBC wants to see some datagrams from other components like the VCM. I can probably mimic some of these to get rid of the error but in the end it probably wont make a difference when just using the LBC and batteries.

[johu]

Looking into the EVB manual it says U1000 error is caused by lack of some CANbus datagrams for at least 2 seconds.
I guess the LBC wants to see some datagrams from other components like the VCM. I can probably mimic some of these to get rid of the error but in the end it probably wont make a difference when just using the LBC and batteries.

Yes. https://github.com/jsphuebner/stm32-car ... eafbms.cpp
See function Send100msMessages and Send10msMessages

[prensel]

Thanks, I allready looked at it and figured about the same datagrams.

BTW I've noted this in your code:

uint16_t LeafBMS::GetCellVoltage(int idx)
{
..
..
return -1;
}

How does this work, returning a negative value in an unsigned result??

[johu]

oh, funny. It would return 0xFFFF. It would only happen if you request a cell voltage that doesn't exist.

[prensel]

Ok I think got it how it works with the DTC error codes

It's like expected, they use the 079B 0x7BB system to request all DTC codes from the LBC.
The byte width errorcode in 0x5C0 is just for quick diagnoses or something.

Here's a piece of logging with just one error: 'U1000 004E':
ID: 79B DLC: 8 Data: 03 19 02 0E 00 00 00 00 (initial request)

The return is in 0x7BB datagrams and contains the actual codes.
ID: 7BB DLC: 8 Data: 07 59 02 4E D0 00 00 4E (response contains somewhat coded U1000 004E)

To request all subsequent data is with the familiar
0x79B 8 30 00 00 00 00 00 00 00
And then all codes come flowing in 0x7BB packets.

So here's logging with 4 DTC errors: 'U1000 004E', 'P33D7 004E', 'P33D9 004E' and 'P33DD 004E':

ID: 79B DLC: 8 Data: 03 19 02 0E 00 00 00 00 (initial request for DTC)
ID: 7BB DLC: 8 Data: 10 13 59 02 4E D0 00 00 (first reply contains part of 'U1000'
ID: 79B DLC: 8 Data: 30 00 00 00 00 00 00 00 (request more DTC data)
ID: 7BB DLC: 8 Data: 21 4E 33 D7 00 4E 33 D9 (this contains piece of previous DTC and subsequent DTC codes P33D7 004E and P33D9 004E
ID: 7BB DLC: 8 Data: 22 00 4E 33 DD 00 4E FF (this contains DTC code P33DD 004E )

Some data in the first reply causes the subsequent 0x79B to fire or not.
The FF on the last 0x7BB is probably a trigger that this was last error data.

And this happens on clearing DTC's:

ID: 79B DLC: 8 Data: 02 10 C0 00 00 00 00 00 (clear DTC's ?)
ID: 7BB DLC: 8 Data: 02 50 C0 FF FF FF FF FF (??
ID: 79B DLC: 8 Data: 04 14 FF FF FF 00 00 00 (do something else ?)
ID: 7BB DLC: 8 Data: 01 54 FF FF FF FF FF FF (command executed ?)

Then the first read DTC command returns zero errors like this:

ID: 79B DLC: 8 Data: 03 19 02 0E 00 00 00 00 (read DTC's)
ID: 7BB DLC: 8 Data: 03 59 02 4E FF FF FF FF (zero DTC's returned)

Added:
If the first response starts with 0x07, this is the number of databytes.
But if the first byte of the response starts with 0x10 then the second byte contains the total number of following databytes without each first byte of the following responses

[johu]

You rock maybe will add it to stm-car project

[prensel]

Ok here's something to think about what i've observed:

The normal cell volt return packets are in datagram 0x7bb and in the first return datagram in group 0x02. But the 'read DTC' and 'clear DTC commands' are also using the 0x7bb datagram and also the SAME 0x02 group !

The only difference is the second databyte. When returning cell volt values this byte is 0x61. Whereas the DTC return packets are using value 0x59. So by just filtering on the group number is not enough.
What could happen when you try to read and clear DTC's is that these return values are regarded as valid cell values and mess up or trigger some limit settings.

[mdrobnak]

This is probably because it sounds like you're doing an active query to the BMS for voltages, rather then it just spitting out the data. In which case, this sounds like J1939 (but not quite) OBD-II query and response...

[prensel]

This is probably because it sounds like you're doing an active query to the BMS for voltages

The Leaf BMS doesnt provide cell related data on its own, you have to query for it.
One option to prevent this mixing of reply packets could be using something like a semaphore type of access so only one process can access the CANbus per time and releases it when all return packets have arrived or after a certain pre-set timeout.

[evcar]

Regarding the SOC there are two 'locations' that this value is available. On is 'static' and used on startup and probably a copy of the last known 'live' value which starts to be available after all cell values have been polled. LeafSpy is using these values this way.

Very interesting! I've been reading the SOC with address 55b, so maybe that's why I get a stationary value.

[prensel]

For some reason I cant get rid of the U1000 error.

I'm tx-ing all the six datagrams (0x1D4, 0x1F2, 0x1DA, 0x390, 0x50C and 0x54C) with what I believe are correct values in the data bytes but the U1000 keeps coming back.

Does anyone have some logging or capture of these forementioned datagrams so I can mimic and compare to see whats going wrong ?

[johu]

Very interesting! I've been reading the SOC with address 55b, so maybe that's why I get a stationary value.

I also read from 55B (first byte + 2 bits of second byte, BE) but the value is no longer stationary these days. Driving the battery down to empty (well, 10%) and charging back up fixed it I believe.

For some reason I cant get rid of the U1000 error.

I'm tx-ing all the six datagrams (0x1D4, 0x1F2, 0x1DA, 0x390, 0x50C and 0x54C) with what I believe are correct values in the data bytes but the U1000 keeps coming back.

Does anyone have some logging or capture of these forementioned datagrams so I can mimic and compare to see whats going wrong ?

Sorry I don't. Is there any drawback from this error? I don't think my LBC is DTC free but all functionality is there so I didn't care

EDIT: some messages need a "PRUN" i.e. 2 bit upcounter and some need a CRC - see my stm-car code. Are you doing that?

[prensel]

Yes, I have all the 2bit upcounters and crc's in place. At least I think so, but that'ss why I want to check on some 'real' captured Leaf data.
I did try some different settings on requested and reported torque values but that didnt change anything.

It should work good as it is, but it must be possible to get it 'error-free'...

[johu]

Ok I see.
Just tried my luck at obtaining the "remaing charge time" on 5BC. So when the multiplexer is 0 (=quick charge) I obtain the value in byte 7 and additional 4 bits in byte 6. Unfortunately it is always 8191 meaning unavailable.

[prensel]

I did notice this briefly yesterday using savvycan with interpreted DBC from Dala and I noticed the alternating values regarding remaining times etc.
Havent looked into it further yet, which DBC are you using ?

[johu]

Uh well lets just say I "found out"

Flag Byte6[7:5]+Byte5[1:0] << 3
00000b = Quick charge
00101b = Normal Charge 6kw Full charge
01000b = Normal Charge 200V Full charge
01011b = Normal Charge 100V Full charge
10010b = Normal Charge 6kw long life charge
10101b = Normal Charge 200V long life charge
11000b = Normal Charge 100V long life charge
11111b = Invalid value

Time in minutes: Byte7[7:0] + Byte6[4:0] << 8

[mdrobnak]

Uh well lets just say I "found out"

Sounds like someone has a Nissan equivalent to a Funktionsrahmen.

[prensel]

Ok so made some changes to the processing of the 0x79b/0x7bb datagrams to prevent mixing up lost or wrong frames.
First I parse the incoming 0x7bb datagrams according CAN-TP. Missing or unordered dataframes are skipped.
The result is a clean struct containing the length and the total number of received data bytes. According CAN-TP this can be max 4096 bytes.
Then the struct is processed according the first two bytes. First byte is most of the time 0x61 and the second byte is the index or group. 0x02 is the group for cell values (or DTC in case first byte is 0x59).

[starpancake]

hey all,

i'm fooling around with what appears to be a grey/black BMS (2015) and a white wiring harness (2011). i'm planning to install this BMS in my leaf's trunk as an extender with a home built 21700 NCA pack. around 48 Ah, 96S. i'm aware of all the wiring differences and will do my best to get the harnesses sorted correctly, but it's possible i'll blow up my unit. all the cheap LBCs aka BMS are gone from ebay, so if that happens i'll probably just scrap the project and put the cells on ebay.

more of a learning project than anything else. but it'd be neat to double my car's range before i spend 5 thousand bucks on a main battery swap! basically a total clone of the dutch project; i'll switch the pack in parallel with the main one after the car's started up and then close it whenever the car's off. eventually, maybe i'll do some logical checks inside the canbridge - max/min the battery temperatures, make sure things are balanced, etc. and yeah, i understand the risk of fire. but there will be some cooling on the pack and thermal loads should be under a thousand watts at full throttle. i'll have a fire extinguisher and quick eject strap, too

i have contactors, 150A fuse hardware, 3-port can bridge, a cabin 12V switch for enabling the aux pack connection, the BMS and the wiring harness. only thing that i'm missing is a current sensor. i'm seeing them on ebay for around $130; does anyone know of a cheaper source? are they just a fat resistor or is there some amplification going on? ultimately i do want current sensing but i'm not sure it's critical just yet.

regards
starpancake

[starpancake]

Yesterday I did the famous 'blue smoke' trick on one of the (all white ports) LBC's by accidently connecting the rear 48S battery stack WITHOUT the interconnecting cable causing some fumes and burned diodes

I have created a conversion cable for connecting a second 48S stack to the last 2 connectors that normally connects the two side battery stacks.

Looking at the diagram and comparing with the wiring loom I discovered some unregistered wiring on the LBC. Presumably these are for the 'winter edition 'Nissan Leaf for enabling pack-pre-heating for Scandinavian countries.

do you have any links describing this? i have a grey/black LBC and a white cable, but i don't really know what would cause that kind of burn out. what is the interconnecting cable you mentioned?

i only have this one LBC so if i burn it out my project is toast :/ thanks