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?
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.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?
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.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.
Firstly, many thanks for this informative thread.There are always corrections.
Hello BlinksFirstly, 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
Blinks.
Currently from the 12V always on, I followed the OZ DIY, which is always on.Hello Blinks
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
If I remember correctly Graeme mentioned in one of the videos that they add extra range due to improved regen?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.
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 offFirstly, 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
Blinks.
Piev, I swapped it to switched power yesterday as Mickey suggested and no issues. Tried charging while off and no problems.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
Enter your email address to join: