Main Traction Battery Upgrade i-MiEV

[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.

 

[piev]

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.

Thanks Mickey,

The MUT says not equipped on those I believe.

I did mod the code to correct any bad cell data. Alas, it did not fix the issue.

I haven't tried it with temperature data because I never saw any bad Temp data. However, the MUT says that I have a shorted temp sensor on CMU5.
Lookin at latest failure data so maybe I'll spot something.

I did notice that whenever I get this error Bit 6 set in 346[3] I also get a bit set in 5A1[2] which comes from the battery.
Maybe it's an error bit and that's is what triggers the shutdown.
16 decimal is 0001 0000 binary so normally bit 3 is set.
When the car shuts down I have a 48 decimal 0011 0000 binary so it's setting bit 2.

5A1	0​	16​	0​	0​	1​	64​	0​	0​
346	39​	16​	93​	2​	64​	0​	4​	140​
5A1	0​	48​	0​	0​	1​	64​	0​	0​

​

​

​

​

​

​

​

​

 

[MickeyS70]

Thanks Mickey,

The MUT says not equipped on those I believe.

I did mod the code to correct any bad cell data. Alas, it did not fix the issue.

I did notice that whenever I get this error Bit 6 set in 346[3] I also get a bit set in 5A1[2] which comes from the battery.
Maybe it's an error bit and that's is what triggers the shutdown

5A1	0​	16​	0​	0​	1​	64​	0​	0​
346	39​	16​	93​	2​	64​	0​	4​	140​
5A1	0​	48​	0​	0​	1​	64​	0​	0​

​

​

​

​

​

​

​

​

I think you’re correct, it’s the BMU that triggers the shutdown due to bad CMU info. Changing the cell values on the ‘other’ side doesn’t seem to make a difference as the trigger is already set.

Therefore you need to prevent that bad data from the CMU is arriving at the BMU.

 

[piev]

I think you’re correct, it’s the BMU that triggers the shutdown due to bad CMU info. Changing the cell values on the ‘other’ side doesn’t seem to make a difference as the trigger is already set.

Therefore you need to prevent that bad data from the CMU is arriving at the BMU.

Well, long run I will pull the battery and fix the CMU.

I was looking at temporary fixes. I put code in the BMU ~ EV-ECU bridge to modify 0x5A1[1]. It reads a static value of 0001 0000 until the car halts and then it reads 0011 0000. So, if it sets bit 2 my code resets it. I drove for 10 miles with no issues so I suspect that the EV-ECU is not looking at cell data but rather the status reported in 0x5A1.

When I am sure my fix worked I will remove the code that modifies cell voltage and see if it goes back to halting.

 

[MickeyS70]

Well, long run I will pull the battery and fix the CMU.

I was looking at temporary fixes. I put code in the BMU ~ EV-ECU bridge to modify 0x5A1[1]. It reads a static value of 0001 0000 until the car halts and then it reads 0011 0000. So, if it sets bit 2 my code resets it. I drove for 10 miles with no issues so I suspect that the EV-ECU is not looking at cell data but rather the status reported in

Temporary fixes have a habit of becoming permanent if a lot of time and effort is required to do it right.

There a risk though, that by clearing a generic error flag a real issue (i.e cell voltage drop <3V) will be ignored.
The pic below is of another NMC conversion, the error flag was set by the low voltage shutdown protection.


With the safety shutdown function disabled, the car will keep discharging essentially empty cells, with the BMU unable to stop them from drifting into the danger zone.

I would recommend to also lower the battery capacity to 80Ah as long as you’re planning to run with the temporary fix.

 

[Joel_1885]

I pretty much used one of the example in the dueCAN library.

I think I changed the Baud rate for CAN messages to 500kbps and removed the console logging print statements because it was causing bus errors too slow I suppose. maybe using interrupts would work better if that is desired.
I am sure there are some sophisticated programmers here but it's not me. I tried to post this code in an insert like I see all the time but couldn't figure it out. If someone can point me to instructions that would be helpful and I'll edit this post.

// Arduino Due - Displays all traffic found on either canbus port
// By Thibaut Viard/Wilfredo Molina/Collin Kidder 2013-2014
// Required libraries
#include "variant.h"
#include <due_can.h>
//Leave defined if you use native port, comment if using programming port
//This sketch could provide a lot of traffic so it might be best to use the native port
#define Serial SerialUSB
void setup()
{
Serial.begin(115200);

// Initialize CAN0 and CAN1, Set the proper baud rates here
Can0.begin(CAN_BPS_500K);
Can1.begin(CAN_BPS_500K);

//By default there are 7 mailboxes for each device that are RX boxes
//This sets each mailbox to have an open filter that will accept extended
//or standard frames
int filter;
//extended
for (filter = 0; filter < 3; filter++) {
Can0.setRXFilter(filter, 0, 0, true);
Can1.setRXFilter(filter, 0, 0, true);
}
//standard
for (int filter = 0; filter < 7; filter++) {
Can0.setRXFilter(filter, 0, 0, false);
Can1.setRXFilter(filter, 0, 0, false);
}

}
void loop(){
CAN_FRAME incoming;
if (Can0.available() > 0) {
Can0.read(incoming);
if (incoming.id == 0x653){
incoming.data.byte[2] = incoming.data.byte[1];

Can1.sendFrame(incoming);
}
Can1.sendFrame(incoming);
}
if (Can1.available() > 0) {
Can1.read(incoming);
}
}

Hi all

I'm new here but not new to arduino, codes, or electricity in general.

Just bought my first Miev today, range of about 40 miles in summer. I will be changing cells soon so I'm researching and found this thread and post.

I can tell you nowhere in this code does it specify a capacity, but it does recieve info from 7 " mail boxes". If we can identify which box holds what data, it can be spoofed.

 

[MickeyS70]

I can tell you nowhere in this code does it specify a capacity, but it does recieve info from 7 " mail boxes". If we can identify which box holds what data, it can be spoofed.

I think you’re looking at the wrong code, check out attachment in post #107

 

[piev]

Hi all

I'm new here but not new to arduino, codes, or electricity in general.

Just bought my first Miev today, range of about 40 miles in summer. I will be changing cells soon so I'm researching and found this thread and post.

I can tell you nowhere in this code does it specify a capacity, but it does recieve info from 7 " mail boxes". If we can identify which box holds what data, it can be spoofed.

What Mickey said!

My code definitely changes the capacity.

The latest version changes it to 83.7Ah

float capAh = 83.7;          //Battery Capacity

      if (flag == 0) {                        //check to see if this is a new power up
        if (j == 20) {                        //wait 20 0x373 frames until CMU is providing good data
          storeSoC2();                        //get battery SoC based on voltage
          remAh1 = (SoC2 / 100.0) * capAh;    //calculate the start remaining Ah in the battery based on voltage
          remAh2 = (SoC2 / 100.0) * capAh;    //calculate the start remaining Ah in the battery based on voltage
          flag = 1;
        }

    } else if (incoming.id == 0x374) {


      incoming.data.byte[6] = 2 * capAh;  //modify to 2 x the capacity


      SoC1 = 100.0 * remAh1 / capAh;
      if (lowMins > 10.0) {               //when battery current has been low for long enough for battery voltage to settle
        storeSoC2();                      //gets SoC based on battery voltage
        remAh2 = (SoC2 / 100.0) * capAh;  //correct remaining capacity based on voltage
      } else {                            //current has not been low, long enough to use the SoC based on voltage
        SoC2 = 100.0 * remAh2 / capAh;    //correct SoC bsed on the remaining Ah
      }


      //Serial.print("remAh = ");Serial.println(remAh);
      //Serial.print("volts = ");Serial.println(volts);


      incoming.data.byte[0] = 2 * SoC1 + 10;  //modify data coming from BMU
      incoming.data.byte[1] = 2 * SoC2 + 10;


      Can1.sendFrame(incoming);  //send the corrected SoCs and the correct 100% capacity to the ECU


      // end 0x374

 

[Joel_1885]

What Mickey said!

My code definitely changes the capacity.

The latest version changes it to 83.7Ah

Stuff

Yes i was quoting a different code.

This is interesting. So by changing the value in that code to whatever number i wish, i can change the capacity? This is with a CAN device between BMU and the car?

There is not reason not to upgrade the car to the latest battery technology, so this is very good. Thanks for your hard work so far