[martinwinlow]

Hi All,

Firstly, I have posted this on this forum as it sounds like an identical fault to Rupert Burbidge's one on his C-Zero, also on this forum.

I also first reported this on the 'myimiev' forum.

Background:- I bought my first i-MiEV (an i0n) in Jan2014, used, from Somerset and I lived in E Herts at the time. I was very taken with the car and EVs in general having first got into them by converting a Daihatsu HiJet van from petrol to electric in 2009. The i0n was sold on to a friend 2 years ago who lives (owns, actually) the Hebridean island I now live on (with my ever-expanding) collection of EVs. My current i-MiEV was bought earlier this year from a chap who lived north of me on the west cost of Scotland (who has since emigrated) with an existing fault with the battery that was getting steadily worse. This manifested itself by the car dash showing a fault (I never did get a precise description from the previous owner) but it was eventually taken to a 'local' Mitsu dealer to get fixed. In the meantime he left for Australia and as Mitsu wanted £X,000's to replace the battery, I ended up paying a very low price for the car that was otherwise in very good condition, especially so considering it was one of the first to come to the UK (in 2009) and is still in its SSE livery. It has a 'dumb' charging cable - so won't charge from a 'proper' charge point (without an adaptor) - 13A socket or CHAdeMO only.

So, when I eventually got it onto the island, here, I had a go with Cani0n using the LX dongle and identified a few issues (see screenshots below). I actually wanted to use the MUTIII clone I bought in 2014 but I had, in the meantime, leant the thing to someone and when I went to use it on the i-MiEV, I couldn't find the software. I eventually managed to get some new software and got the MUT working.

So - original Cani0n/MUTIII screenshots done about 6 months ago...

Other matters have got in the way of progressing things but I have now a workshop to work in so onwards and upwards (hopefully).

I tried again with Cani0n a week or so back and now get this when I try to look at the battery info page... (ODO reading etc correct - but note the 'Volts' and SoC readings)...

 

[martinwinlow]

(Cont from 1st post due to image limit... and I discovered the 'look for all DTCs at once' button this time...)

So, before I clutter up the workshop with a disassembled i-MiEV and to minimise the likely fix time can anyone confirm or otherwise that this looks like a failed LTC chip issue (like Rupert's) that the CMU PCB at fault is '05' and that that is the one I should order to fix my battery? I'd like to try to avoid having to get into swapping ICs if possible (let alone reprogramming EPROMS).

Worth noting that the BMU page on the MUTIII shows the cell with the highest voltage as 51 (4.060V) and min as 38 (3.535V) with max and min internal resistances being the same at 2.3mR.

 

[G.a.r.y]

Yes 100% that is a failed ltc voltage monitoring chip. I had exactly the same voltage graph in Canion.

Looks like it’s 05, best way to confirm is to drop the pack, take off the lid, disconnect all the comms leads to the CMUs apart from 05, put the pack back into place and connect the comms leads, then fire up Canion again and you should still get the same voltage graph showing the same cells, then you know you have the right CMU and can get the ltc xhip replaced.

I have done this repair myself.

Cheers

 

[G.a.r.y]

Your first screenshots of canion could also indicate a couple of failed cells, but you'd need to fix the ltc chip and see how the cell perform to confirm.

Cheers.

 

[freddym]

Hi Martin, good luck with the ongoing diagnosis and repair. I suspect MUT gives slightly better diagnosis than Diagbox.

 

[martinwinlow]

Thanks, Gary.

Has anyone done a step-by-step description of the proceedure involved (I'd refer to the manual but it's bound to be full of 'elf n safety' stuff that will make pinting it impractical... thoughts?).

 

[martinwinlow]

I just checked on the 2 cells I bought back in June and see that I also ordered a CMU PCB! Of course, what I don't know is which one it is. Is there anyway to tell - either by looking at it or plugging it in to something?

 

[DBMandrake]

Over on myimev there is some speculation that the CMU identities are programmed by the BMS at the factory when the battery pack is mated to the car. In other words all CMU's start out the same but are assigned an ID number during this mating process, and that there is some sort of daisy chain wiring between CMU's that helps them organise their numbering in a deterministic order within the pack.

Since this mating between BMS (which is under the seat in the car) and CMU's (which are in the battery pack) must also be performed when an entire battery pack is replaced, it seems reasonable to assume that the "battery replacement" operation of the diagnostic tool would trigger this CMU numbering process so that the BMS learns of the addresses of the CMU's.

I've seen this process in Diagbox and have in fact performed it on my Ion (but without swapping any CMU's) and the other thing it does is resets the Ah capacity to 45.8Ah, so it would be very important to run the battery calibration process after that to re-measure the actual performance of your battery otherwise the car would try to run the cells down too low.

Since you have a MUT, you should be able to run both the battery replacement procedure and the battery calibration procedure. Can you have a look through the menus and see if you can find them ? (without activating them at this point)

Rather than messing around with eeprom swapping or swapping the LTC chip I wonder if it's worth trying to figure out whether we can re-number a CMU using the official diagnostic tool, in other words swap the faulty CMU for the one you have on hand and then perform the battery replacement procedure followed by the battery calibration procedure.

If you're willing to attempt this it would give us valuable insight into how the CMU numbering and communication works that we weren't quite able to figure out with the processes Rupert followed. It depends on how much hassle it is for you to potentially drop the battery pack more than once while figuring this out.

One thing Rupert discovered is that if you turn the pack around 180 degrees and lift it a bit on the side the cables come out you can actually plug the low voltage data lines (can bus etc) into the car while the pack is out of the car, and thus interogate the CMU's using a diagnostic tool when the pack is out on the floor and still relatively accessible.

As long as you only turn the key in the car to ON without attempting to go fully to READY it doesn't matter that the high voltage lines are not connected, the diagnostic tool will be able to communicate with the CMU's and read the cell voltages. (You may need to reconnect the safety link plug though - not sure)

So here's what I'd suggest if you're up for the extra leg work -

1) Drop the pack out and swap the whole faulty cmu board with the one you've obtained.

2) Instead of refitting the pack turn it around and prop up one side so you can connect all the data connectors but leave the HV cables (which won't reach) disconnected of course. Refit the safety link plug.

3) Turn the key only to the ON position and try querying the CMU's in MUT and/or look at the cell voltages in Canion. If they all look normal, great! However I suspect unless you're lucky and the CMU was from the same position you'll still see no voltages for that board due to the CMU colliding with the address of another board.

4) At that point it might be worth trying to unplug the data cable from all CMU's except the one you just swapped - not sure if that's physically possible, but if it is rechecking the cell voltages should identify which CMU numbering the replacement CMU currently has.

5) Reconnect all CMU's and then run the battery replacement procedure - the MUT should tell you that this process is to be run when the entire pack is replaced.

6) Re check communication with the CMU's in MUT and cell voltage readings in Canion - if they are now all good then you have successfully renumbered the CMU and can proceed to reinstall the pack properly, assuming all voltage readings etc look good.

If there still seems to be an identity clash between two CMU's you're going to have to go ahead with replacing the LTC on the original board and refit it.

7) Assuming you did the battery replacement procedure and the car is charging and working normally you'll need to do the battery calibration process so the BMS re-learns the true capacity of the battery. Until you relearn the capacity the car will work but the claimed range remaining will be hopelessly optimistic and there is a risk of running the cells down so low that the turtle mode kicks in without warning leaving you stranded. (Nearly happened to me - crawled home the last 500 metres limited to 7mph!)

 

[martinwinlow]

Always up for a challenge, me! In the meantime I have emailed the guy I bought the CMU PCB from in case he happens to know which one it was off...

 

[richi]

In case it helps, there's an updated service bulletin that describes the BMU Initialise procedure, formerly known as BMU Reset, which you're calling "battery replacement." It's MSB-14EXML00_54-001 (la GOOG is your friend); see Sheet 14.

However, you're strongly advised to then do a manual rewrite of the odo and age values, then do a DBCAM. Otherwise, expect weird range behaviour until the BMS has relearned the pack health.

 

[DBMandrake]

Diagbox and MUT must handle this differently. There was no opportunity to manually enter odometer or age values into the BMS when I ran the battery replacement. Having a look at the following bulletin that you reference:

http://mmc-manuals.ru/msb/BASE/2014/MSB-14EXML00_54-001/E/MSB-14EXML00_54-001.pdf

Do not reset "Battery capacity estimated info" unless you replace the drive battery.  If you did inadvertently, carry out the procedures for writing BMU learning value, and then execute the drive battery capacity automatic measurement (Refer to GROUP 54DBattery Management Unit (BMU) and Traction Battery).

What this is saying is don't perform the BMU reset if you are not replacing the battery with a new battery, however if you did "by accident" then perform the battery capacity measurement afterwards.

This is what I was refering to earlier - the reset will reset the Ah to 45.8Ah however if you follow it up with a battery capacity measurement it will correct it to the proper value.

Entering odometer and age values probably just calculates an "estimated" Ah based on the age and cycle count degradation models in the BMS - an actual measurement is preferable.

As far as I can see as long as the battery capacity measurement process is performed it shouldn't be necessary to enter any age and mileage figures - and at least when I performed these two procedures I did not see anywhere to enter them anyway.

Lots of bulletins here btw:

MMC-Manuals.ru - Mitsubishi Service Bulletins Catalog

mmc-manuals.ru

 

[DBMandrake]

Looking through the manuals.ru manuals I came across a little gem:

[W/M]i-MiEV (HA#)

Click on 54D-ELECTRIC MOTOR UNIT AND TRACTION BATTERY
then BATTERY MANAGEMENT UNIT (BMU) AND TRACTION BATTERY
then DIAGNOSIS FUNCTION

Part way down on the page on the right you'll see:

NUMBERING CMU ID PROCEDURE

Because done at the factory, numbering the CMU ID is not necessary.

This is the first confirmation I've seen that there IS a procedure to number the CMUs in the diagnostic tool however it is saying its not neccessary as it's done at the factory - which is true, as dealers don't perform individual board/cell swaps, so would not be in a position to need to use it.

But if they tell you its not necessary to perform it it implies to me that the function is actually there in the diagnostic tool. (Otherwise why tell the technician it's not necessary ?)

Have a read through the diagnostics page I linked to and compare it to the functions you can find in the MUT and see if you can find it ? Maybe the CMU's can be renumbered without doing a full BMS reset ? This would be a breakthrough if we can confirm that any CMU could be fitted and renumbered with the diagnostic tool.

 

[DBMandrake]

And here is the battery capacity measurement process:

MAIN BATTERY CAPACITY MEASUREMENT

 

[richi]

But you missed the steps in between the Init and the DBCAM.

That warning text includes the phrase, "carry out the procedures for writing BMU learning value," which refers to either rewiting a cache of previously-stored values, or manually rewriting just pack odo (km) and pack age (months).

If you skip this, the BMU logic gets confused and tries to use its pre-programmed, "fresh off the boat" assumed-deg curve.

We see the same issue in the Outlander PHEV community, but it's more visible there, as a low SoH estimate causes the engine to cut in early.

 

[DBMandrake]

But you missed the steps in between the Init and the DBCAM.

That warning text includes the phrase, "carry out the procedures for writing BMU learning value," which refers to either rewiting a cache of previously-stored values, or manually rewriting just pack odo (km) and pack age (months).

Maybe I'm wrong but that's not how I interpretted it. To me "for writing BMU learning value" means putting the BMU into a capacity measurement (learning) mode so that it will update the Ah figure after the next full charge.

When I did the capacity measurement with Diagbox it asks you to discharge the battery to 3.775 volts per cell then put it back on charge again, however during the charge phase the diagnostic tool does not have to be connected, and at the end of the charge the Ah figure is updated. Therefore the BMU has been put into a special learning mode to achieve this.

The learning mode will accept any (within reason I suspect) measured Ah figure and update immediately whereas the normal slow learning process with battery degradation over time will not accept large changes in measured Ah within one charge cycle as might happen due to a cell replacement.

If you skip this, the BMU logic gets confused and tries to use its pre-programmed, "fresh off the boat" assumed-deg curve.

Which is ?

We see the same issue in the Outlander PHEV community, but it's more visible there, as a low SoH estimate causes the engine to cut in early.

If you're just performed a full measurement of the SoH (Ah) how is the estimate low ?

I'll be doing my cell swap soon so I'll take extra care to try to find where I can enter the age and mileage of the battery, however I don't recall finding anywhere to enter this last time. Keep in mind the Diagbox and MUT interfaces are very different to use and are not like for like for all settings.

 

[richi]

The workshop manual, plus every MSB and campaign bulletin I've read are all tragically badly translated from Japanese. Trust me, it means you should do an auto or manual rewrite of the BMU values.

If you read that text in context with the rest of the workshop manual, it would be clearer. But even many Mitsubishi Master Techs get this wrong. Some even believe they don't need to do anything if they replace the pack.

 

[martinwinlow]

Well, thanks for all that. I'll report back progress in due course. I have a 2-post lift to install first...

 

[G.a.r.y]

2 post lift, that is cheating !!!

You've not done it properly unless you end up with a bad back for 2 months afterwards.

 

[martinwinlow]

Well, the lift is now installed (at last) and I am about to commence car and battery separation...

 

[martinwinlow]

Has anyone done a step-by-step description of the proceedure involved in dropping the pack?