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)...
(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.
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.
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.
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?).
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?
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!)
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.
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:
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 54DBattery 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.
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.
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.
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.
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.
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.
I always do one and although the car to me looks perfect, I’m already looking for things to do to it....
anyway - the starting point
pug e208 GT Line in Faro Yellow
looks great from all angles :)
some nice design points
Subtleness on the front facing radar
the “nod” (albeit...
If you are in the market for a 7-seater EV the choices are very limited. Obviously the four cousins (or 5 with the Opel) are all essentially the same but with small differences. They look very slightly different but what about equipment?
I know we do not know the prices for the UK currently but...
Evening All,
Just dropping in to say Hi, I'm newly registered here. We've got an e-208 GT in Faro Yellow arriving on Tuesday. Ordered back in Feb through Drivethedeal who offered the best price I could find at the time - but it was delayed slightly due to Covid. The car was built on June 10th...
After a lot of indecision and mucking about, finally took the plunge and ordered the wife an e-2008 today.
Found a pretty amazing lease deal on the GT which despite misgivings about the car’s range, made it too cheap to say no.
Basically works out £34 more than the cancelled Zoe 50 it...
A community for enthusiasts of all makes and models of EV from BMW to Tesla, Renault, Nissan, Mitsubishi and more. Join the electrifying discussion today!
