Main Traction Battery Upgrade i-MiEV

[MickeyS70]

​

​

​

​

​

​

I checked the codes today.
U1116 KOS CAN Timeout
P1A30 Cell Low EV-ECU (BMU)
U1161 EV-ECU message lost (BMU)
P1AC5 MCU message lost (BMU)
U111C BMU Can timeout
P1A58 CMU07 Cell low <2.3V
U1111 which I couldn't find but i believe it's a can loss message

I must have an intermittent BMU bus problem.
Hard to tell because the only active one was U1116 which I believe is the Key
The rest were stored
I suspect the low cell is what gave me the turtle though I didn't find it in the data.

According to the service manual U1116 & U1111 can be ignored??
Agreed, a cell voltage below 2.75V will shut down the car immediately, IIRC OBDZero logs data every couple of seconds, therefore easy to miss a 'blip'.
Might help to read the DTCs immediately when this happens again...

 

[CZeroOwner]

How should this be read?

OBDZero stores two files PID_..txt and PIDint_..txt. In PID_..txt all of the number are in hex apart from the time and date. In PIDint..txt the bytes are converted to integers while the PID is still hex. This save a step when working with the data.

In the data piev posted above the PID 346 byte 3 has at different times the integer values 0, 2, 32, 48, and 95 where 32 is by far the most common.

When I convert 2 to binary using Excel I get 00000010. 32 gives 00100000, 48 gives 00110000 and 95 gives 01011111. I couldn't find a standard for numbering bits in a byte but it appears that most agree with Excel that the 1st bit from left to right is the msb = 127 and so on. As 32 is the value of byte 3 almost all the time then the third bit is probably the ready light. Byte3 was 48 at times 16:37:11, 16:39:34, 16:39:36, 16:46:37, 17:31:55, 17:31:57, 17:32:00 and 17:33:16. At these times the 4th bit was 1 and this was probably the turtle light. Byte3 was 95 at times 16:39:40, 16:39:48 and 16:46:59. At these times the ready light was off and the turtle was on and probably the other lights on the dash as well. Here is one series:

16:39:28​	32​
16:39:31​	32​
16:39:34​	48​
16:39:36​	48​
16:39:38​	0​
16:39:40​	95​
16:39:42​	0​
16:39:45​	0​
16:39:48​	95​
16:39:50​	32​
16:39:52​	32​
16:39:54​	32​

The ready light was on (byte3 =32). The turtle light came on (byte3 = 48). piev turned the car off (byte3 = 0) then turned the car on (byte3 = 95). (maybe twice?) Then the ready light was on (byte3=32) and all was in order. Now comes the hard part figuring out why the turtle came on.

Cheers
David

 

[MickeyS70]

Now comes the hard part figuring out why the turtle came on.

Maybe not: a cell voltage under 3V will trigger tortoise and power reduction followed by a complete shutdown when reaching the lower limit (2.75V?).

It’s not realistic for an actual cell to drop and recover within seconds and the CAN bridge doesn’t alter any cell voltages, therefore the most likely cause seems to be a ‘dodgy’ CMU7 PCB (P1A58, P1A30).

 

[CZeroOwner]

Maybe not: a cell voltage under 3V will trigger tortoise and power reduction followed by a complete shutdown when reaching the lower limit (2.75V?).

Bingo!

Time	PID	int0	int1	int2	int3	int4	int5	int6	int7
07-05-24 16:46:37​	373	188​	50​	119​	163​	13​	147​	0​	6​

PID 373 byte1 is the lowest cell voltage. It's computed by: (50 + 210) / 100.0 = 2.6 volts. Unfortunately there is no information on which cell. I checked the cell data but the particular cell voltage wasn't captured at the time. OBDZero only captures about 20 cells in any one data recording time. It is also possible that this is just noise somewhere else in the system.

 

[kiev]

Is it a real cell voltage, a weak or low cell dropping under load?

Or as Mickey suggests, a dodgy CMU, e.g. a loose connection of the wire between the cell and the CMU?

These are new cells so hopefully not a defect this soon.

 

[piev]

Is it a real cell voltage, a weak or low cell dropping under load?

Or as Mickey suggests, a dodgy CMU, e.g. a loose connection of the wire between the cell and the CMU?

These are new cells so hopefully not a defect this soon.

It is happening now every time I drive.

I looked at the MUT yesterday, The P1A58 says CMU07 Cell Low
When I go to the CMUs. CMU07 says Cell H voltage overflow

When I look at the data on OBDZero it says Module 5 cells C and D 2.510V.

These are the same two Modules I had trouble with before. Looks like I need to pull the battery again. Maybe I need to replaces those CMUs.

 

[MickeyS70]

Maybe I need to replaces those CMUs.

Not much else left to do I’m afraid, especially if these CMUs were troublesome before the cell upgrade.

 

[CZeroOwner]

It is happening now every time I drive.

We may be able to filter this out in the 0x373 part of the bridge program:

if (incoming.data.byte[1]) < 60 incoming.data.byte[1] = 60;
Can1.sendFrame(incoming);

Remember to change the code later in the program to avoid sending 0x373 twice. Try it, it is easier than pulling the battery.

 

[MickeyS70]

We may be able to filter this out in the 0x373 part of the bridge program

If that doesn’t work, you could always add a second bridge and modify CMU cell voltage data on the other CAN bus like you corrected temp data before..

 

[CZeroOwner]

When charging PID 346 byte3 is 64. That's 01000000. It looks like the second bit is the charging light.

 

[piev]

So, I made changes to the code that CZeroOwner sent me. It did not fix the issue. I modified the code to just look for the one bad module the car said I had to see if it reduced the time the code operates since I am getting can errors now and a different error pattern. It also sets the value to the last known good value instead of 2.75 Volts like the code was doing. This morning I noticed that CZeroOwner was also modifying the min cell voltage to 65 in the code if it was below this value. I am thinking the car doesn't like large disparity in voltage between cells. So, I will modify the min cell voltage to the last good known cell voltage as well and see if that's the issue.

0x346[3] now equal 2 decimal 00000010 bit 6 set
0x346[4] now equals 64 decimal 01000000 bit 1 set

BMU errors
U111B MCU CAN timeout
U1100 EV-ECU CAN timeout
U1109 ETACS CAN timeout
U1108 Meter CAN timeout
P1AA7 EV-ECU timeout

EV-ECU Errors
P1A30 Cell volt low (BMU)
P1AC5 MCCU Message lost (BMU)
U1161 EV-ECU message lost (BMU)
U111C BMU CAN timeout
U1926 EV-ECU V-CAN error
P1A58 CMU07 Cell low
Then the U1116 and U1111 codes that Mickey says you can ignore.

I saw another thread this morning:
https://myimiev.com/threads/2010-i-...05-20&utm_content=daily_newsletter#post-48726

I am getting similar behavior with the same error codes apart from the cell messages. I'm wondering if it's something else and not the cell voltage. The latest data looked like all the cell data was good. i.e. that my code fix was working. That is why I was puzzled the car was still reporting cell issues.

19-05-2024 17:03:09.886	346	39​	16​	52​	2​	64​	0​	4​	59​
19-05-2024 17:03:09.886	373	255​	255​	127​	188​	255​	255​	0​	6​

This time I noticed that 373 had bad data and that was another clue that I have a CAN issue. Maybe my loop is too slow and that's causing timeouts. Or as I said another issue causing CAN problems like in the other thread I linked.

 

[MickeyS70]

​

This time I noticed that 373 had bad data and that was another clue that I have a CAN issue. Maybe my loop is too slow and that's causing timeouts. Or as I said another issue causing CAN problems like in the other thread I linked.

I think you have a CMU issue (the other thread seems more like an earth leakage problem on the OBC), two options to fix this: open up the battery to replace them physically or intercept bad data with a second bridge on the BMU <-> CMU CAN bus.

 

[MickeyS70]

Then the U1116 and U1111 codes that Mickey says you can ignore.

Just did a DTC scan with Car Scanner, guess what; U1116 & U1111 show up as active, however HobDrive doesn’t show them, I gather these are active because my IMiev is not equipped with the remote control option.