MegaCellCharger mods, tuning and reverse engineering

Announcement - Help us fight the BOTS! Please report all spam including stuff in your inbox!

Oleksii

Member
Joined
Mar 18, 2020
Messages
48
Hi all!

First of all I have a lot to share as for MCC, with photos of course, but currently I want to start from a topic to pay attention from developers ad possibly get a fix/improvement.
It's about charge and discharge current measurement precision an adjustments.
I've started from measuring current. First I've checked and my DMM measures current correctly by comparing it with lab power supply and YR1035+ measured 4.84R resistor and then measured voltage drop over it 1.687V - I got the same reading of ~348 mA current (Ohm's low 1.687/4.84=0.3485).Tried higher values - the same:
DMM-check.jpg
Then I made this simple "connector" from a small piece of material, used to produce 2 side PCB. It allowed me to "interrupt" cell circuit easily and quickly in any device and measure current in a stable way:
current-connector.jpg
Then I started "per slot" measurement, which looked this way:
checking-MCC.jpg
(yes, you have spotted those FANs of left :D, I know, I'll share info about them soon)

I noted current after 1 minute of started change/discharge, to get it stabilized as some resistor inside MCC getting more warm, possibly change resistance a little.
I've to note here what while on MMC current was INcreasing a little during the minute, on DMM it was opposite - DECreasing a little, but after 1 minute values were "in sync" and were slowly decreasing together with the same rate. So 1-2 minutes delay was a proper thing, I suppose.

I made 4 cycles (change/discharge and before/after correction of CcO/DcO).
CcO/DcO - are Charge correction factor (%) and Discharge correction factor (%) in MegaCellMonitor software
Here are results:

ch.png

disch.png

I spotted previously that MCC shows increased cells capacity measurement, so values of current was not surprising for me.
Also I know from other MCC users the same.

Summary: each slot has its own drift or precision for charge and discharge. Calculated average for all slots - probably an ideal way to find out what are the best correction factors for your own MCC.

‼️‼️‼️ What I dream of currently - that MCC have to provide a way to set CcO/DcO per slot basis. I'm sure its really possible and this way it's possible to adjust each slow and hopefully get were consist reading of capacity! ‼️‼️‼️


I saw that MegaCellMonitor sends some extended JSON when staring individual commands for slots (POST to /api/set_cell) where CcO/DcO were included together with CmD (command what to do). I was hoping that it can work this way, but unfortunately it's just extra data included to JSON, which probably is ignored by MCC. Used command like this:
Bash:
curl http://10.33.0.66/api/set_cell -d '{"cells": [{"ChC": false, "CiD": 0, "MaV": 4.25, "StV": 3.6, "MiV": 2.8, "DiC": 1, "CmD": "ach", "LmV": 0.3, "LcV": 3.6, "LmD": 1.1, "LmR": 90, "McH": 240, "LcR": 1000, "CcO": -50, "DcO": -50}]}'
but it does not set CcO/DcO in any way.

Also, default values in MegaCellMonitor for factors are 1. I've tried to set 0 (zero) using shell commands (see below) but looks like internally it's still set to 1.
And on reading an absolute step between 1% and -1% was ~20 mA (we work with ~1A current all the time) which confirms that it's 2% difference. Because between -1% and -2% the step is ~10 mA. The same for 1% and 2% - ~10mA step.
It means that correct default values for MegaCellMonitor and MCC should be 0 (zero) but not 1. But that's minor thing.

Btw, I changed CcO/DcO using this shell command, easily, event right during charge or discharge procedure on a slot, which caused updated/recalculated values reading immediately.
Bash:
curl http://10.33.0.66/api/set_config_info -d '{"LmR": 90, "CcO": -7, "DcO": -5, "LmV": 0.3, "LcV": 3.6, "LmD": 1.1, "ChC": false, "MaV": 4.25, "StV": 3.6, "MiV": 2.8, "DiR": 1000, "MaT": 45, "DiC": 1}'

Commands for start charge and discharge on all slots and monitor values (on another window) are:
Bash:
curl http://10.33.0.66/api/set_cell -d '{"cells": [{"CiD": 0, "CmD": "ach"}, {"CiD": 1, "CmD": "ach"}, {"CiD": 2, "CmD": "ach"}, {"CiD": 3, "CmD"
: "ach"}, {"CiD": 4, "CmD": "ach"}, {"CiD": 5, "CmD": "ach"}, {"CiD": 6, "CmD": "ach"}, {"CiD": 7, "CmD": "ach"}, {"CiD": 8, "CmD": "ach"}, {"CiD": 9, "CmD":
"ach"}, {"CiD": 10, "CmD": "ach"}, {"CiD": 11, "CmD": "ach"}, {"CiD": 12, "CmD": "ach"}, {"CiD": 13, "CmD": "ach"}, {"CiD": 14, "CmD": "ach"}, {"CiD": 15, "Cm
D": "ach"}]}'


curl http://10.33.0.66/api/set_cell -d '{"cells": [{"CiD": 0, "CmD": "adc"}, {"CiD": 1, "CmD": "adc"}, {"CiD": 2, "CmD": "adc"}, {"CiD": 3, "CmD": "adc"}, {"CiD": 4, "CmD": "adc"}, {"CiD": 5, "CmD": "adc"}, {"CiD": 6, "CmD": "adc"}, {"CiD": 7, "CmD": "adc"}, {"CiD": 8, "CmD": "adc"}, {"CiD": 9, "CmD": "adc"}, {"CiD": 10, "CmD": "adc"}, {"CiD": 11, "CmD": "adc"}, {"CiD": 12, "CmD": "adc"}, {"CiD": 13, "CmD": "adc"}, {"CiD": 14, "CmD": "adc"}, {"CiD": 15, "CmD": "adc"}]}'

watch -n1 'curl http://10.33.0.66/api/get_cells_info 2>/dev/null | egrep "amps|capacity|voltage"'

p.s. stay tuned, there are even more interesting parts of MCC I want to share ;)
p.s.2 btw, that was me who discovered a bug on MCC that it always added an extra ~100mAh capacity to each slot on mCap command. Devs were really good to fix it very fast.
 
Last edited:

Oleksii

Member
Joined
Mar 18, 2020
Messages
48
Let me say a few words about voltage reading, as it's related to possible improvements in a similar way.

MCC looks like (I guess) uses the same ADC pin on main chip ESP8266, using HP4067 chips (CD74HC4067 - Analog Multiplexer/Demultiplexer) to connect cells for reading.
So, voltage on all slots are 100% the same, which is nice.

But on my MCC difference between MCC and DMM I trust is 0.018v. MCC shows higher value than DMM.
I'd be happy if there would be a way to have a new settings - Voltage correction factor, in %. It could be a global option, as no needs to heave it per slot.
It should accept float values, to be able to set 0.1% as a value. Such precision should be enough.

Will try to ask devs to implement such setting.
 
Last edited:

ipirk

New member
Joined
Dec 10, 2018
Messages
4
Hello, her are my Cal Corection Tests of my 10 Chargers.
 

Attachments

  • MegaCellCharger_Calibration.xls
    69 KB · Views: 112

italianuser

Member
Joined
Feb 25, 2020
Messages
395
Well done. In the Excel spreadsheet I would add the possible offset due to multimeter's precision, because in any case readings could float up or down, for e.g. ±1%. The first mAh value reading 1004 could be 993,96 up to 1014,04.
 

Wolf

Active member
Joined
Sep 25, 2018
Messages
1,649
But on my MCC difference between MCC and DMM I trust is 0.018v. MCC shows higher value than DMM.
I concur to the ≈ 0.018v difference between my verified RC3563 and the MCC which shows mostly higher.
On my last batch of 1375 cells all tested with the MCC and ending voltages copied from the MCM into Excel then verified with the RC3563
I come up with an average difference of 0.016v
1613756747355.png
When graphed there is definitely a slot to slot comparison. As in each slot has its own variation of a voltage difference.
The graphs makes it quite evident. Although the differences are very minute they still could be a go/no-go when measuring for SD cells especially if you never measure the true exit voltage which also tends to be not really ≈4.2v or whatever you set storage voltage too.
1613756394400.png1613757765936.png
MCC exit voltages differences between slots is also an issue MCC 1 Slot 2 is very apparent.
These are the voltages copied and pasted from the MCM interface not my voltage observations.
1613758829106.png
Wolf
 

Oleksii

Member
Joined
Mar 18, 2020
Messages
48
#BUGREPORT

Yeah, I'll use this #BUGREPORT tag to indicate that and to simplify searching here, I as I'm going to report a few of them really soon.
As I you know I like when everything works correctly and if it's not I start to find a root cause. MCC is not an exclusion, so let's go to the topic :)

Summary: changed ESR reading on firmware V4.3.0.11 is really bad and may lead to wrong results!

Input conditions: recent MCC revision in plastic case (with single INA219 ADC), discharge current is 1A is MCC settings.

Details: In previous firmware V4.1.8 MCC was ESR measuring this way:
measure voltage without load, apply discharge, wait for 6 seconds (making 12 readings with 500 ms intervals - just an internal logic of polling all 16 slots), measure voltage again, then make calculation: (Vstart-Vend)/Idisch = R (ESR) in ohms.

That gave pretty consistent readings on any slot and every time. But disadvantage is that cells will low capacity could show quite high ESR.
Example:
Cell capacity, mAhReal ESR (measured on YR1035+), mRESR measured by MCC V4.1.8 (with improved neg spring) , mR
25037190
130023115
25001668


After firmware upgrade to V4.3.0.11 I observed other values (comparably lower) reading and, what is very bad, they were very inconsistent !!!
What happened?

Ok, I checked debug (listening MCC's TCP port 8888) and spot messages which were not there on previous firmware. Let me post them here, shortened:
Code:
000 03:20:22.808 - (Debug) - CiD: 15 SetEsrRunning: 1
000 03:20:22.809 - (Debug) - Current DiR: 1000
000 03:20:22.811 - (Notice) - Setting DiR: 200
000 03:20:22.812 - (Notice) - Class parameter DiR: 200
000 03:20:22.813 - (Debug) - Previous DiR: 1000 Current DiR: 200
000 03:20:22.816 - (Warning) - ClearCellDischargeData - reseting dischargeCapacity
000 03:20:22.819 - (Notice) - Setting fan speed to FULL!
000 03:20:22.822 - (Notice) - Wait cycle count configured to: 26
000 03:20:23.330 - (Debug) - CiD: 15 - ProcessWorkflow: eWorkflow::Start_ESR_mcap - countdown wait cycles (26 / 26)
... 19 repeats ....
000 03:20:33.554 - (Debug) - CiD: 15 - ProcessWorkflow: eWorkflow::Start_ESR_mcap - countdown wait cycles (6 / 26)
000 03:20:33.572 - (Debug) - CiD: 15 - V1: 3.76 - i1: -23.64Stage 1 of ESR completed.
000 03:20:33.574 - (Debug) - CiD: 15 SetEsrRunning: 1
000 03:20:33.575 - (Notice) - Setting DiR: 1000
000 03:20:33.576 - (Notice) - Class parameter DiR: 1000
000 03:20:33.577 - (Debug) - Previous DiR: 200 Current DiR: 1000
000 03:20:34.052 - (Debug) - CiD: 15 - ProcessWorkflow: eWorkflow::Start_ESR_mcap - countdown wait cycles (5 / 26)
... 3 repeats ....
000 03:20:36.092 - (Debug) - CiD: 15 - ProcessWorkflow: eWorkflow::Start_ESR_mcap - countdown wait cycles (1 / 26)
000 03:20:36.589 - (Debug) - CiD: 15 - ProcessWorkflow: eWorkflow::Start_ESR_mcap - calculate
000 03:20:36.600 - (Debug) - CiD: 15 SetEsrRunning: 0
000 03:20:36.602 - (Debug) - previous DiR: 1000 Current DiR: 1000
000 03:20:36.603 - (Notice) - Setting DiR: 1000
000 03:20:36.604 - (Notice) - Class parameter DiR: 1000
000 03:20:36.605 - (Debug) - Reset previous DiR: -1 Current DiR: 1000
000 03:20:36.618 - (Debug) - CiD: 15 - V2: 3.74 - i2: -999.01Stage 2 of ESR completed.
000 03:20:36.620 - (Debug) - CiD: 15 - Volt drop: 0.02 - amps: -975.37
note - ESR in JSON reported by MCC in this particular cell measurement was "esr"=0.020505
What we see here? Reworked approach!
Btw, let me ask devs right here, where is Changelog where this change is reflected ???

Ok, according to the log, recent firmware tries to:
- set kind of 200 mA discharge current, keep it during 10 seconds, measure voltage at the end,
- then change discharge rate to 1000mA and then keep it during 2 seconds, measure voltage at the end again,
- then make calculation (Vstart-Vend)/(Iend-Istart) = R
It looks interesting, like 2 levels Vdrop, to consider more "ohmic" resistance (separate topic).

But!!! Problem is that MCC does NOT have pure and trusty possibility on HARDWARE level to set CONSTANT discharge rate to 200mA!
It has an option to set kind of "discharge rate", but using hardware constant PWM method only. Frequency is fixed to 100Hz. Once you set it in settings, GPIO15 pin of main IC ESP12F produces it constantly which basically interrupts all discharge MOSFETSs, including the time when they are discharging.

This method, btw, affects all the slots simultaneously. So, as a side effect for example, when one slot measuring ERS, discharge rare on ALL other slots is also affected, temporary. I hope that does not screw us discharge capacity calculation on other slots.

What we see wrong on the example: current of Stage1 is read as unexpected value - 23.64 mA, which is too far from 200mA. It happened probably because measuring was performed during PWM pulse rise/fall transition.
Voltages reading were 3.76-3.74 - both happened during actual 1000mA discharge current (PWM pulses were at high level), because the cell was inserted with ~250mR shunt resistor in series to measure current externally too.

Here is another measurement with the same cell (16 mR-AC/2500mAh), without the shunt:
Code:
000 04:28:42.748 - (Debug) - CiD: 15 - V1: 4.13 - i1: -221.64Stage 1 of ESR completed.
000 04:28:45.756 - (Debug) - CiD: 15 - V2: 4.09 - i2: -1088.60Stage 2 of ESR completed.
000 04:28:45.758 - (Debug) - CiD: 15 - Volt drop: 0.04 - amps: -866.96
This time measuring time points were lucky and data from JSON: "esr": 0.046138
A few additional ESR test (started and interrupted mCap) on the SAME cell WITHOUT removing it from slot gave very inconsistent ESR values:
Code:
0.036888,
0.092228



Another test. 37 mR-AC/250mAh cell, with the shunt in series:
Code:
000 02:39:59.142 - (Debug) - CiD: 15 - V1: 4.10 - i1: -202.32Stage 1 of ESR completed.
000 02:40:02.196 - (Debug) - CiD: 15 - V2: 3.69 - i2: -987.43Stage 2 of ESR completed.
000 02:40:02.198 - (Debug) - CiD: 15 - Volt drop: 0.41 - amps: -785.11
this time "esr": 0.52477

Do you see how falsely this result is if compare with very first test described above?
I.e. On Stage1 voltage reading was at low PWM pulse level, while Stage2 was at high PWM pulse level. This gave huge voltage drop, which again proves inconsistency.

I'm sure this must be reverted in firmware as it was in previous version!

I have some idea for better ESR reading algorithm on MCC and ready share it to MCC devs, if they are ready to listen and fix it.

For now I've reverted firmware to V4.1.8 (I collected firmwares every time after upgrade). Btw, why older firmwares are not available for download?
I know how to do it from Linux shell by single curl command, OTA method ("over the air"), the same way how MCM does it when it wants.

Btw, I hate that MCM does firmware upgrade silently without asking me if I'm agree to do that.
I understand that there are configuration changes (new options MsR, MuL), but still I WANT that MCM software asks me for firmware upgrade!
Doing it silently - bad idea!

As for AC vs DC reading method, here is nice thread on this forum:

p.s. more very interesting technical details and hacks :cool: are coming soon, stay tuned.
Bonus picture, just for fun.
Selection_1086.png
 
Last edited:

RattleZ

New member
Joined
Oct 21, 2021
Messages
3
Thanks for your efforts raising awareness of the above mentioned inconsistencies and also raising it with the Dev's.
It looks like there is a new MCM Beta available (Version: 4.4.2.10) which addresses the request for manual CcO and DcO calibration on a cell level.
This should be a good step in the right direction for more accurate readings.

However, while there is now the Option to adjust CcO and DcO per cell level, I was wondering what one must do in order to adjust each slot with the correct adjustment values. As I understand each MCC has slight variations in component tolerances which leads to diff test results for diff. slots. How can I adjust my MCC in such way, that I can account for these tolerances. I believe I have to find out what my individual derivations for each slot are and then adjust the CcO and DcO accordingly. So what methods are available to identify these derivations without the use of expensive lab equipment.

RattleZ
 

Oleksii

Member
Joined
Mar 18, 2020
Messages
48
Yes, it's really good that the feature is already in MCC firmware. That's a key point.
But MCM with the feature is still in beta and not well tested. After that will be in stable, I think there will be instructions, hopefully official ones.

If not official - I'll prepare some instructions. I'll probably will prepare them anyway, to show how to do that easier/faster, using command line, not MCM.

You do not need to have expensive lab equipment, but what you should have is a good DMM with current measurement which you can trust.
If you do not have any good one, like some Fluke or so, I could recommend to by some on Aliexpress with ~20-30$ price.

I recommend to pay attention for "number of counts" property of a DMM, because it usually indicates how high resolution ADC is there.
Select ones which have 9999/10000 counts, preferably. Having 2000-6100 counts would work as well, but such DMMs cost just a little cheaper, while I'm not sure how precise they are. So these DMMs have to measure current with 1mA precision in range up to 2A.

Here is very good site to overview of DMMs https://lygte-info.dk/info/DMMReviews.html
Good candidates are (pay attention for Display column - that's number of "counts"):
Aneng AN8008
Aneng AN8009
BSide ZT302
Aneng Q1

There are quite a lot of DMMs which looks identical/similar to ones in the list, selling under different names, like Richmeters 109 (on my photo above, cost 17$, free shipping) or others. But they are very similar/the same, so all are good.
All such DMMs are digitally calibrated after manufacturing, quite precise as for our needs.
I'm 100% sure that such DMMs measure current much better that any random slot on MCC, so we can use DMM as an example and trust it.
 

RattleZ

New member
Joined
Oct 21, 2021
Messages
3
Thanks for that, this is actually a pretty cool Website for DMM comparison! Getting the Aneng Q1 now, since my Mestek CM82C Clamp meter could only do up to 6000 counts.

Yeah lets hope that the new MCC firmware will go out of Beta and merged into the main branch soon, so that this feature will be available for the mainstream, along with some form of documentation.

Cheers!
 

Oleksii

Member
Joined
Mar 18, 2020
Messages
48
since my Mestek CM82C Clamp meter could only do up to 6000 counts.
Having only clap current metering, it actually does not have option to measure current using probes.
So, having classic DMM too is a proper step in your case.
 
Top