Cell Cross Referencing, PID to Physical Cells

Mitsubishi i-MiEV Forum

Help Support Mitsubishi i-MiEV Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Joined
Mar 2, 2024
Messages
11
Location
Saskatchewan, Canada
Hello everyone.

Could someone help me relate the PID position to the physical cell? I am referencing the attached cell map created by kiev and the data from OBDZero but I am not sure that I am correctly cross referencing the voltage position in the OBD PIDs, 6E1,6E2,6E3 and 6E, to actual cells on the map.

Through my research I understand in each PID group, for example 6E1, the first byte, byte 0, converted to decimal is 1-12 and then each of these lines contains the voltage data for 2 cells calculated from bytes 4&5 and 6&7.

Lines 6 and 12 on 6E3 and 6E4 are all zeros. So 24(6E1)+ 24(6E2) + 20(6E3) + 20(6E4) = 88 cells.

Are the cells consecutive in the PIDs? For example is 6E1 byte 4 and 5 cell "A" on CMU01 and 6E1 byte 6 and 7 cell "B" on CMU01?

Thanks
 

Attachments

  • CellLayout.JPG
    CellLayout.JPG
    106.9 KB · Views: 1
  • Screenshot_20240830-063104.jpg
    Screenshot_20240830-063104.jpg
    47.1 KB · Views: 2
  • Screenshot_20240830-091519.jpg
    Screenshot_20240830-091519.jpg
    54.1 KB · Views: 0
I think I was able to partically find my answer in this post by CZeroOwner. He indicates that this would be the formula to calculate the voltage of cell "A" in module "1"

"volts = (6E1[4] * 256 + 6E1[5] + 420)/200 This is the voltage for cell A in module 1. 6E1 is the PID and [4] means byte 4."
This would seem to imply that the cells are listed consecutive 1-88 as shown in the cell map by kiev.

I am trying to identify specifically cells CMU09 Cell B and CMU11 Cell B, I made a spread sheet and according to that these cells would be:
9B = 6E3[6]&[7]
11B = 6E4[6]&[7]

Could someone confirm this is correct? I really appreciate everyone's help.

https://myimiev.com/threads/fault-codes-in-drive-battery.5543/post-48865
 
Last edited:
I think I was able to partically find my answer in this post by CZeroOwner. He indicates that this would be the formula to calculate the voltage of cell "A" in module "1"

"volts = (6E1[4] * 256 + 6E1[5] + 420)/200 This is the voltage for cell A in module 1. 6E1 is the PID and [4] means byte 4."
This would seem to imply that the cells are listed consecutive 1-88 as shown in the cell map by kiev.

I am trying to identify specifically cells CMU09 Cell B and CMU11 Cell B, I made a spread sheet and according to that these cells would be:
9B = 6E3[6]&[7]
11B = 6E4[6]&[7]

Could someone confirm this is correct? I really appreciate everyone's help.

https://myimiev.com/threads/fault-codes-in-drive-battery.5543/post-48865
The CMUs are transmitting cell voltages and temperatures using the same PID, see detailed info below:

https://www.evmonitor.info/2018/07/mitsubishi-miev-battery-pack.html

Btw voltage formula is wrong, use the one you quoted above.

Out of curiosity, what are you actually trying to achieve?
 
I recently did an NMC swap. I have two cells that are showing 0.00 for voltage but good temperatures and these show on OBDzero in positions 11B and 11C (see below) however when I look at the PIDs I only see issues with 6E1 6&7 showing "FF" and 6E2 4&5 show "FF"(see 2nd image).

I have dropped the pack and pulled CMU11 and checked all the cells and they are all currently 4.012-4.020 so perhaps something is going on with the CMU unless I am looking at the wrong cells.

If the cells are consecutive beginning with 6E1 01 Byte 4&5 being CMU01 Cell "A" then 6E1 0B 6&7 would be CMU03 cell "F" and 6E2 0B 4&5 would be CMU07 cell "A". If these bad cells or CMU points are indeed CMU11 cells "B" and "C" and I have somehow damaged the CMU during the conversion (I can't see any issues visually) then I could alter the program to put adjacent cell voltages in place of these two as long as I know the cells are good since I still have the temperature readings I can monitor. Of course this would not be the final solution.

By the way I have checked the voltage of each 8 cell module and they are all very close so it is most likely something with the CMU rather than bad cells.
 

Attachments

  • Cells.JPG
    Cells.JPG
    45.1 KB · Views: 0
  • PIDS.JPG
    PIDS.JPG
    54.3 KB · Views: 1
I think you’re looking at the wrong PID, I modify the voltage of the last cell (88) as it’s constantly reading 100mV too high and therefore need to correct CMU12 which is PID 0x6C2. (4 cell module)

CMU11 is transmitting on PIDs 0x6B1-4 and the cells you’re looking for (B & C) are on 0x6B1 (byte 6&7) and 0x6B2 (byte 4&5) respectively

Btw in order to fix this you need a second CAN bridge on the BMU/CMU bus
 
Given that these cells are right next to each other on the CMU but they are located many entries away in the 6E1-6E4 PID series, is there a formula or a mapping that you can share if I need to locate other cells based on cell voltages shown in the app? These were easy to find since they both had FF.
 
I figured it out the index bit 1-12 actually is the cell modules cmu1-cmu12. Then there are two cells on 6E1, 6E2, 6E3, and 6E4. This makes up the 8 cells in the battery module. Actually simpler than I thought. That is why 6 and 12 only have data in 6E1 and 6E2.

I disconnected CMU 11 and found this out. It also looks like FF or 255 indicated no data because when I disconnected CMU 11 all the voltages went to FF.
 
Good work to solve the mystery.

So it appears that you found that the cell numbering starts with the A & B cells (1&2) in 6E1?

Then the
6E2's are for the C&D (3&4)
6E3's for the E&F (5&6)
6E4's for the G&H (7&8)

The 12 index bytes make sense to identify the Module numbers.

Don't know if this was ever puzzled out before--seems like it would have been posted on the forum. But we have probably been quite spoiled with all the apps that report the data for us.
 
I figured it out the index bit 1-12 actually is the cell modules cmu1-cmu12. Then there are two cells on 6E1, 6E2, 6E3, and 6E4. This makes up the 8 cells in the battery module. Actually simpler than I thought. That is why 6 and 12 only have data in 6E1 and 6E2.

I disconnected CMU 11 and found this out. It also looks like FF or 255 indicated no data because when I disconnected CMU 11 all the voltages went to FF.
OBDZero has only access to the OBD (primary) CAN.

However the BMU will receive cell data via the secondary bus (different PIDs), verify it and then re-transmit (at least on older models) onto the primary bus.

If the BMU isn’t happy with the CMU data, a DTC is set, therefore any specific cell voltage (or temperature) correction needs to be done beforehand, thus requiring a CAN bridge between the BMU/CMUs.
 
The issue was a blown smd fuse on cell C on the CMU.

This was caused a a loose buss bar between cells B and C. When I assembled that module I failed to tighten that buss bar so they were only finger tight.

I have attached a few images of my battery modules and bus bars. The CMU boards are attached to the top uhmw mount with 3mm foam tape so they are not suspended only by the 3mm screws.

The long story:
When I first installed the new cells I charged the pack. When I backed out of the driveway these two cells dropped in voltage much more than the other 86. I drove it anyway watching the cells and these two consistently were showing much lower than all the rest. I only drove a few miles like this in "B" and noticed when I would brake and the Regen would really kick in the car would jerk. I made it back home with this happening everytime I would brake or stop and it seemed to get worse. I made it home with turtle going on and off and was able to park it and when I stopped for the last time it jerked a few times very hard.

We were leaving for the long weekend so I pulled the negative from the battery and left it. When we returned the ready light would not come on and there were no bars so I checked OBDzero and those two cells were showing 0.0 as I posted earlier.

I believe this poor connection was breaking contact and possibly arching which was causing the extreme jerking. I am pretty confident this caused the smd fuse to blow. I checked the smd fuse on cell B and it was Ok so apparently the blown fuse on cell C was affecting the other.

Temporarily I removed the fuse and bypassed it with a small price of wire from a resistor so I could see if it would fix the problem. I lightly installed the battery pack without the top cover and with only 3 bolts hand tight and now all the voltages read correctly and I have the ready light again. I still have it lifted up so I just ran the heater for an hour making sure all the cells were dropping consistently and they stayed +/- 0.01 volts. I am going to purchase a new fuse and replace it before finally fully installing the battery and taking it down to test drive it.

Since I found this loose buss bar I pulled the other 11 modules and double checked every buss bar and CMU connection.
 

Attachments

  • IMG_20240905_044224.jpg
    IMG_20240905_044224.jpg
    53.6 KB · Views: 0
  • IMG_20240905_044215.jpg
    IMG_20240905_044215.jpg
    83.4 KB · Views: 0
  • IMG_20240905_044212.jpg
    IMG_20240905_044212.jpg
    80 KB · Views: 0
Great catch to find the fuse issue, and thanks for sharing the troubleshooting story along with the pictures of your custom module.

i guess now we know why the OEMs put paint marks on bolt and nut joints after they are assembled and torqued.

What is the material and how were the bus bars cut to fit?
 
Last edited:
I disconnected CMU 11 and found this out. It also looks like FF or 255 indicated no data because when I disconnected CMU 11 all the voltages went to FF.
This is another good finding from your investigation.

So we think that the CMU will report 2.100 V on the BAT-CAN buss when the fuse is blown or there is no data, but then the BMU converts that to "FF FF" when reporting on the EV-CAN buss.

Some folks have reported seeing huge voltages for single cells on their phone apps, e.g. showing as >300 V (351) as a single cell voltage.
 
The buss bars were either laser cut or water jetted from 1/8" Aluminum in 2 shapes singles and doubles. I ordered these through Xometry.com for $345 including shipping for 26 singles and 78 doubles and then tapped the lasered holes myself to M3. I use Xometry for work because they are a great online source for all sorts of short run and prototype parts from 3d printed to low volume injection molding with an instant quoting tool. I could have used copper but looking at the increase in conductivity for this thickness of aluminum compared the 2.5X cost increase it wasn't worth it. I machined the top and bottom cell holders from UHMW myself on my home built CNC Mill with a 36" x 42" bed.

When I was having the issue, the total voltage being reported on CANzero for the pack was about 6557V with the "highest" cell showing 0.00 and the lowest 4.02V.

FF in Hex translates to 255 in decimal so if you apply that from byte 4 or byte 6 to the cell voltage equation you get a huge number since this is usually a 1...

volts = (6E1[4] * 256 + 6E1[5] + 420)/200
volts = ((255 * 256) + 255 + 420)/200 = 329.8
 
When I was having the issue, the total voltage being reported on CANzero for the pack was about 6557V with the "highest" cell showing 0.00 and the lowest 4.02V.
6557. looks close to
[255*256 + 255] /10

seems strange how it converts the data, which we don't really know without firmware or insight into the control system.

thanks for the info about the buss bars, that is a very clever build. (y)
 
seems strange how it converts the data, which we don't really know without firmware or insight into the control system.
Don’t think this has anything to do with the BMU, ‘no data’ is simply transmitter as 0xFF by the CMUs on BAT-CAN, the BMU interprets that accordingly and sets an error flag and then just re-transmits the data onto the main BUS.

How this is then interpreted by OBD apps seems to depend on their programming?
 
Back
Top