# Main Traction Battery Upgrade i-MiEV

### Help Support Mitsubishi i-MiEV Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Hey David,

After my latest test drive I am wondering why we cut off the SoC volts table at 3.54912?

If volts = 3.053819 then SoC = 0 is this where NMC chemistry = 0? I thought it went to 2.75V.

In addition the car stops at 10% SoC.

So with the equation SoC = 12.096*volts -36.939, when volts meets the condition of < 3.54912 we are at 5.397% SoC.

I don't want to stop the discharge at 3.54912 volts which is what is happening.

In fact, doing the math now.... we go below 10% at 3.61536 Volts in the previous equation.

I think 3.6 volts is well above 10% SoC, am I wrong? I think 3.6 volts is over 50% SoC.

i think we should hit 10% around 3.4 Volts.

Here is the discharge curve of NMC LG E63 cells. She seems more suitable.

Last edited:
There are different chemistry mixtures of NMC batteries available, each with their own characteristics. David’s calculations are based on the diagram in post #85 where 3.6V is approximately 10% SoC. Frud is using a different ‘flavour’ so to speak but I gather David is confident Piev’s cells match the formula.

You’re experiencing the car shutting down @ 10% SOC, this isn’t happening on a ‘native’ car and therefore I recon that the EV-ECU (like the issue with range during standstill) still uses LEV50 data, maybe looking at the unchanged BMU values at this stage might give some clues on how to correct this?

There are different chemistry mixtures of NMC batteries available, each with their own characteristics. David’s calculations are based on the diagram in post #85 where 3.6V is approximately 10% SoC. Frud is using a different ‘flavour’ so to speak but I gather David is confident Piev’s cells match the formula.

You’re experiencing the car shutting down @ 10% SOC, this isn’t happening on a ‘native’ car and therefore I recon that the EV-ECU (like the issue with range during standstill) still uses LEV50 data, maybe looking at the unchanged BMU values at this stage might give some clues on how to correct this?

If I make the SoC static the car keeps driving.

The cars have always went into turtle at 10% SoC and the display goes to ---. It will let you drive in turtle mode for 10% more, so if you had a range of 65 miles it will let you drive in turtle for 6.5 more miles.

Somehow this equation is messed up since it goes to turtle but doesn't give me 9 more miles like it should so maybe turtle reverts to the original Lev50 capacity. I will have to make more observations but that so far has been my experience. Of course, I need to make better notes and in some cases I wasn't brave enough to try it because I didn't want to figure out how to get my car home.... but in this case the car would still move but in turtle and the GOM read --

As soon as I raised the SoC to 15% the gauge read 6 miles or so. I didn't write it down and the turtle went away.

I have a display from a wreck, I'm going to send it can message and see what triggers the turtle etc.

The specification for these says the can be discharged to 2.75 Volts. I imagine that there is only 2 or 3 % charge left when you hit 3 Volts though. I believe 3.1 Volts would be a safe cutoff.

We may run into a low voltage cutoff before then since I don't know what the vehicle does in that regard.

pid 346[3] bit1 - error
pid 346[3] bit4 - turtle
pid 346[3] bit6 - AC plugged

Last edited:
I have a confession. piev sent measurements of a NMC 93 cell that he did on the bench in his workshop two years ago. For some reason I chose to use the data from the scientific article in stead of piev's measurements. Now that we have data from the car I can see that this was a mistake.

piev bench data agrees very well with the recent data from his car.

So I have prepared a new version of the low amps voltage to SoC function based on piev's bench data. In the Arduino program this function is called storeSoC.

I haven't used all his data points but those that best describe the curve. I have also added 2.75v as 0% and 4.2v as 114% in order to cover the whole range of possible voltages. .

All this is included in Arduino_8 attached. Arduino_8 has not been tested yet.

Cheers
David

#### Attachments

• Arduino_8.txt
6.5 KB · Views: 4
There are always corrections.

#### Attachments

• Arduino_81.txt
6.6 KB · Views: 3
I am following this thread with a big interest. Good job everyone involved! Regarding the update of the battery max capacity due to degradation with time: can't the maximum capacity be updated from comparing the decrease of SOC between several measurements and how much energy was used according to coulomb counting?

For example: the MaxAh of the battery is 100 Ah. The car was driven and the SOC decreased from 80 % to 50%. During that period the SOC was updated several times based on cell voltages and the coulomb count was zeroed also. But we saved the total energy used in a separate variable every time the SOC was updated so that we know how much was used between 80% and 50%. Only after the SOC decreased by XX% we calculate the MaxAh. Say the total energy used according to coulomb count corresponds to 28 Ah. The decrease from 80% to 50% at 100 Ah should have resulted in 30Ah. It means that the real calculated capacity of the battery is 28/30*100=93.3 Ah. Since the coulomb count is not that precise, we can update only say 20% of the error. So we don't decrease the MaxAh to 93.3 Ah but to 98.7 Ah. In that way a sharp increase and decrease of the maximum battery capacity value can be avoided. The capacity will probably decrease during the winter and increase during the summer but that should be ok and anyway better than leaving the MaxAh constant for years.

Currently, I don't see a need for upgrading the battery in my C-Zero, but would be good if the upgrade process was well documented. Is there an intention to write a detailed instruction for the whole upgrade from removing the battery to installing and programming the CAN bridge?

Hot off the Press! Piev is showing 123.8 miles range and the car didn't shutdown, still in READY. [Air up the tires and probably go farther ] Fabulous result that will extend the life and range of the little jellybean.

I am following this thread with a big interest. Good job everyone involved! Regarding the update of the battery max capacity due to degradation with time: can't the maximum capacity be updated from comparing the decrease of SOC between several measurements and how much energy was used according to coulomb counting?

For example: the MaxAh of the battery is 100 Ah. The car was driven and the SOC decreased from 80 % to 50%. During that period the SOC was updated several times based on cell voltages and the coulomb count was zeroed also. But we saved the total energy used in a separate variable every time the SOC was updated so that we know how much was used between 80% and 50%. Only after the SOC decreased by XX% we calculate the MaxAh. Say the total energy used according to coulomb count corresponds to 28 Ah. The decrease from 80% to 50% at 100 Ah should have resulted in 30Ah. It means that the real calculated capacity of the battery is 28/30*100=93.3 Ah. Since the coulomb count is not that precise, we can update only say 20% of the error. So we don't decrease the MaxAh to 93.3 Ah but to 98.7 Ah. In that way a sharp increase and decrease of the maximum battery capacity value can be avoided. The capacity will probably decrease during the winter and increase during the summer but that should be ok and anyway better than leaving the MaxAh constant for years.

Currently, I don't see a need for upgrading the battery in my C-Zero, but would be good if the upgrade process was well documented. Is there an intention to write a detailed instruction for the whole upgrade from removing the battery to installing and programming the CAN bridge?
I think the better way to keep up with degradation would be to monitor charging. Once a month drive to empty and then charge to full and count AH in to adjust the capacity.

With experience it may be able to be done on any charge cycle. At this point I don’t think it matters because we are correcting the SoC based on Voltage.

Yes, the intent of this thread was to document what I did to reach this point but with limited time all I’ve been able to accomplish is testing the upgrade. Soon as we finish the project I plan to post more details.

The specification for these says the can be discharged to 2.75 Volts. I imagine that there is only 2 or 3 % charge left when you hit 3 Volts though. I believe 3.1 Volts would be a safe cutoff.

We may run into a low voltage cutoff before then since I don't know what the vehicle does in that regard.
Yes, I would certainly keep above 3V at least until you know the low voltage cut off is working. Easy enough to test though: set SoC to a high value when cell voltage is low and turn on the heat, keep an eye on cell voltages with OBDZero and see if there is ‘native’ low voltage protection.

If you have +1 cell you can hard test it to 2.7v 100-200 times and see how is work

There are always corrections.
Firstly, many thanks for this informative thread.
I have been working on the same issue for a couple of months. We had our i-miev upgraded with the OZ Diy blackbox but have had several failures with no current resolution. To help identify any potential problem I installed a DUE with Copperhill dualcan and managed to get the car up and running with the extended 220 km range. I was delighted when I came across your SOC code as that helped answer a lot of questions questions on a better way to determine SOC. Anyway, I used the code, and test drove the car for some kms with a nice and steady GOM that closely reflected the kms travelled. It even increased the kms when I did some extended regen down a hill. Thanks again.
The issue I've come across is after the car is off for at least an hour the CAN goes idle and then prevents the car from going to run when turned on. There are no DTCs just no SOC or KMs range. Resetting the DUE rectiifes the issue, but not a long term solution. Has anyone else come across this issue?
Regards

Firstly, many thanks for this informative thread.
I have been working on the same issue for a couple of months. We had our i-miev upgraded with the OZ Diy blackbox but have had several failures with no current resolution. To help identify any potential problem I installed a DUE with Copperhill dualcan and managed to get the car up and running with the extended 220 km range. I was delighted when I came across your SOC code as that helped answer a lot of questions questions on a better way to determine SOC. Anyway, I used the code, and test drove the car for some kms with a nice and steady GOM that closely reflected the kms travelled. It even increased the kms when I did some extended regen down a hill. Thanks again.
The issue I've come across is after the car is off for at least an hour the CAN goes idle and then prevents the car from going to run when turned on. There are no DTCs just no SOC or KMs range. Resetting the DUE rectiifes the issue, but not a long term solution. Has anyone else come across this issue?
Regards

Do you power your DUE directly from the 12V aux battery, i.e always on? Mine only starts up when I turn on the ignition, no issues so far..
Mickey

Do you power your DUE directly from the 12V aux battery, i.e always on? Mine only starts up when I turn on the ignition, no issues so far..
Mickey
Currently from the 12V always on, I followed the OZ DIY, which is always on.
I'll give a try using the ignition input to the BMU.

Driving styles etc play a part, but the oz electric black box gives you the below number on a full charge, in a minicab miev.
I'd suspect your code is being somewhat economical and gentle, which isn't a bad thing at all!
Following with a lot of interest and will probably install and start running your code very soon, I've got the same 93ah cells, and have just been running a shunt bypassing the current sensor for now to access more capacity from my cells.

#### Attachments

• 20220909_044041.jpg
46.9 KB · Views: 1
Driving styles etc play a part, but the oz electric black box gives you the below number on a full charge, in a minicab miev.
I'd suspect your code is being somewhat economical and gentle, which isn't a bad thing at all!
Following with a lot of interest and will probably install and start running your code very soon, I've got the same 93ah cells, and have just been running a shunt bypassing the current sensor for now to access more capacity from my cells.
If I remember correctly Graeme mentioned in one of the videos that they add extra range due to improved regen?

Squeezing ‘every last drop’ out of an NMC cells is counterproductive, it will accelerate degradation.

Firstly, many thanks for this informative thread.
I have been working on the same issue for a couple of months. We had our i-miev upgraded with the OZ Diy blackbox but have had several failures with no current resolution. To help identify any potential problem I installed a DUE with Copperhill dualcan and managed to get the car up and running with the extended 220 km range. I was delighted when I came across your SOC code as that helped answer a lot of questions questions on a better way to determine SOC. Anyway, I used the code, and test drove the car for some kms with a nice and steady GOM that closely reflected the kms travelled. It even increased the kms when I did some extended regen down a hill. Thanks again.
The issue I've come across is after the car is off for at least an hour the CAN goes idle and then prevents the car from going to run when turned on. There are no DTCs just no SOC or KMs range. Resetting the DUE rectiifes the issue, but not a long term solution. Has anyone else come across this issue?
Regards

Hey Blinks, yes I’m afraid it’s still a work in progress. If you leave the device powered it gets lost and has to be reset. I am working on a modification to connect to switched power and see if the issue goes away as Mickey says. But long term I want to use interrupt routines instead of continuous capture of frames. That may fix it as well butt then again it may just be something about how the arduino due operates. I’m also migrating to a different board but won’t post about that till I am up and running. Oh, it’s better to not power the due all the time since it will drain your 12v battery. Besides the BMU is on switched power. It has both switched and usswitched. Maybe it has some function it needs all the time but it’s not putting battery data on the bus when the car is powered off
Oh, I believe it needs power for charging

Last edited:
Hey Blinks, yes I’m afraid it’s still a work in progress. If you leave the device powered it gets lost and has to be reset. I am working on a modification to connect to switched power and see if the issue goes away as Mickey says. But long term I want to use interrupt routines instead of continuous capture of frames. That may fix it as well butt then again it may just be something about how the arduino due operates. I’m also migrating to a different board but won’t post about that till I am up and running. Oh, it’s better to not power the due all the time since it will drain your 12v battery. Besides the BMU is on switched power. It has both switched and usswitched. Maybe it has some function it needs all the time but it’s not putting battery data on the bus when the car is powered off
Oh, I believe it needs power for charging
Piev, I swapped it to switched power yesterday as Mickey suggested and no issues. Tried charging while off and no problems.
It just seems to lose the volt reading when off and gets itself into a catch 22.
I'll run it on switched power for now and see if there are any other issues.

Regards

Hi guys!
I am also folowing this battery upgrade, but i have a question. Could anybody show me how is Arduino Due wired in the car? I tried a lot of different options but I still cant get it.