[SOLVED] SkyRC MC3000: *dis*charging an Eneloop AAA never ends?!

[dmenezes]

EDIT: here’s a brief TL;DR to help people just reaching this topic avoid having to wade through it all:

On Eneloop/NiMH batteries, the MC3000 unexplainably takes in practice a very long time (twice as long or more) during the discharge phase of the refresh operation than it theoretically should (it should stop at CUT VOLT), but whatever it’s doing, is not harming the batteries: we can see their capacity keeps improving after repeated Refresh operations. So the best approach as a user seems to be the BOHICA one: just be patient and endure the extra time and wait for the MC3000 to do its thing, because it apparently knows it better than us.

Original post follows:

As per the subject: during a refresh operation, the charger spent almost 9 hours(!) in the discharge step of the C>D>C cycle, until I aborted the operation, and almost 6 of these hours were spent with the battery voltage hovering just above 1.0V and the current switching between 0.00 and 0.01A, here’s a video clip of what the display was showing: https://www.youtube.com/shorts/SNaWP0JV-v4

Here’s the app screenshots of the program I used for this operation:

Here’s the relevant parts of @SYZYGY’s “Ultimate Program Guide” for the MC3000:

As you can see, I set everything in the app’s program exactly the same as recommended in the spreadsheet (except the battery chemistry, which I changed from “NiMH” to the more specific “Eneloop”).

I’m aware that the MC3000 (depending on the “Delta Peak” parameter) can have issues with NiMH charging, specially with old batteries and depending on the DELTA PEAK parameter, not discharging – so I’m really stumped on this one.

I have 2 main questions:

1. Can any of you see any mistakes or omissions in my program?

2. Has anyone ever seen anything similar?

TIA!

EDIT: more details: the charger is the new model with “knobbly” contacts on the battery terminais and 2 fans, and its GSV shows “HW Version: ≥ 2.2” and “FW Version: 1.18”. I control all operations exclusively using its Android app, which is version 3.95 (latest AFAIK).

[Mandrake50]

@dmenezes

the battery voltage hovering just above 1.0V

I don’t use the Mc3000 for NiMh. I use my Maha C9000s for this. So obviously I have never seen this behavior. But it is almost like the discharge rate that you are using is not enough to lower the cell voltage to the target that will stop the discharge. Which doesn’t make sense, as you mention that the current drops to zero at times… Did you put a meter on the cells when you terminated the test to see what the voltage was? Have you calibrated the voltages on the MC3000?

As a test I would try increasing the discharge amps to maybe 0.20, or increasing the discharge cut off to maybe 1.01. Just to see if it allows it to stop the discharge in a reasonable amount of time.

Alternatively, if you have the patience, just let it run until it finishes.

[dmenezes]

Thanks for the suggestions.

@Mandrake50

But it is almost like the discharge rate that you are using is not enough to lower the cell voltage to the target that will stop the discharge. Which doesn’t make sense, as you mention that the current drops to zero at times…

To me it looks more like voltage and current are “chasing” each other around, like that: (1) the voltage drops to (or more probably, very near) the discharge cut-off voltage of 1.00; (2) the charger notices it and cuts the current down to zero. Then obviously (3) the voltage goes up again, to 1.01 or so, which causes the charger to again up the current (to 0.01V), which goes back to step 1, rinse and repeat. I see this behaviour both in the display and in the log my program is generating.

This should absolutely not happen, as I have set D.REDUCE to zero (and then the charger is supposed to stop the discharging immediately when the battery reaches the discharge cut-off voltage), but who knows, maybe it never reaches exactly 1.000 (the charger internally measures and keeps all voltage data with 3 decimal places).

@Mandrake50

Did you put a meter on the cells when you terminated the test to see what the voltage was?

It was just one cell, but yes I did, and it was showing 1.229V

@Mandrake50

Have you calibrated the voltages on the MC3000?

I checked it against my Unicel UT210E and they’ve agreed on all 3 decimal places (the 3rd decimal place can only be seen when capturing data directly from the charger like my logging program does). But there’s been quite a few months since I did that (when I got the charger), so I will repeat it as soon as the currently running test (see below) finishes.

@Mandrake50

As a test I would try increasing the discharge amps to maybe 0.20, or increasing the discharge cut off to maybe 1.01. Just to see if it allows it to stop the discharge in a reasonable amount of time.

That’s a good idea, but I just checked the datasheet for my battery’s exact part number (HR-4UTG) and it states:

Single cell capacity under the following condition.
 [...] Discharge : 160mA(E.V.=1.0V) at 20°C

And I’m discharging (“D-Current”) at 0.19A = 190mA, so I’d be already over the manufacturer’s recommended discharging current (for maximum capacity).

As this battery is from 2010 and 1st Genteration to boot, and has been pretty heavily used (albeit I estimate nowhere near its stated 1000 cycles but a couple of hundreds of times), and under colder temperatures than specced (many times at 0C or under, while the datasheet indicates its “discharging” temp range as 0-50C), I’m starting to suspect that battery itself could be the problem.

So, right now I’m repeating the test with it plus 3 other eneloop AAAs I bought over the years (a silver BK-4MCCA from 2015, a white also BK-4MCCA from 2018, and finally another also white and also BK-4MCCA from 2020) all of them with the exact same refresh program that failed to complete its discharge phase on the first battery, and let’s see what happens. If all other batteries work but the first fails again, I will then try recharging that failing battery on my other chargers (a MiBox C8 and a Fenix ARE-D1, both much dumber than my MC3000) and then take it from there.

I will keep this topic posted.

[Mandrake50]

It seems that it might be the cell causing problems… But that doesn’t really excuse the behavior of the charger.
It will be interesting to see how the other cells do. Keep us posted, for sure.

[dmenezes]

@Mandrake50

But that doesn’t really excuse the behavior of the charger.

Agreed, the charger’s algorithm should have detected something was wrong even (or perhaps specially) if the issue is being caused by a bad battery. I did not set a “Timer Cut-off” as @SYZYGY’s spreadsheet did not recommend one and NiMH is a pretty safe chemistry so putting too many milliamp/hours into the battery should not result in any disaster, but maybe it’s always a good idea to set this to a reasonable limit as a “safety backstop” in case the charger ends up in a situation it can’t recover from. But I wonder if that “Timer Cut-off” applies to the whole “Refresh” operation or just to its charging step (would have to be the first case for it to be useful in that situation).

OTOH, I was just quadruple-checking everything and noticed something interesting: when setting the battery type as “Eneloop” like I did instead of the more generic “NiMH” as @SYZYGY put on his spreadsheet, the “Capacity Cut-off” field disappears from the app program screen.

That should not change anything as this is checked during charging (to interrupt the operation if the battery takes more than the stated number), but perhaps some other stuff may have changed too? Checking the MC3000 manual, it states:

BATT TYPE
* NiMH - Nickel-Metal Hydride battery, 1.2V nominal voltage. The most common type of consumer
class AA size rechargeable batteries for cameras, equipment, flashes, flashlights, tools, toys,
bedroom, etc.
[...]
* Eneloop - Not really a battery type but a brand name. Market leading professional grade NiMH-
based low self-discharge industrial standard superior battery product originally made in Japan by
Sanyo or FDK, now by Panasonic and also in China. The charging algorithm is the same as for
NiMH but some options in SPV have been adapted for more convenient presets. Can be cycled
2100 times according to claims in ads; visit eneloop.com or also eneloop101 .com for further info.

“Some options have been adapted for more convenient presets”… hummrmrmr… Perhaps I will do another test following the current one with the battery type set to “NiMH” instead of “Eneloop” and see what happens.

[Mandrake50]

@dmenezes

adapted for more convenient presets”… hummrmrmr

See, they are just making your life easier…

[dmenezes]

@dmenezes

So, right now I’m repeating the test with it plus 3 other eneloop AAAs I bought over the years (a silver BK-4MCCA from 2015, a white also BK-4MCCA from 2018, and finally another also white and also BK-4MCCA from 2020) all of them with the exact same refresh program that failed to complete its discharge phase on the first battery, and let’s see what happens.

Quick preview before going to bed: at least 2 of the 3 other batteries seem to have the charger stuck in the same “hovering just above 1.00V” situation, and the other one (as well as one that got the charger in the previous situation) seem to be going to the same, just haven’t arrived there yet.

Will let it run until tomorrow morning (about 8h from now), if they all get stuck and remain so, then I have the next best thing to a solved problem, which is a repeatable one.

[ToyKeeper]

In really low-current devices, I’ve often found Eneloops seem to get stuck at “almost empty”, where they’ll power the device for a short time and then need to rest for a while. It seems like there’s some spontaneous recovery happening, or something like that.

It’s how I got, for example, what seemed like an immortal AAA keychain light which just never ran out of power until I got curious and pulled the cell out to take a closer look. It also happens regularly on a 2xAA wireless keyboard, where it’ll work fine for a few minutes after flipping the power switch, and then it stops responding, and then it works after flipping the switch again.

I doubt it’s good for the cell, so when I notice an Eneloop doing this, I take it out and recharge it. Or maybe put it through a reconditioning cycle on my BC-700.

[dmenezes]

@ToyKeeper

In really low-current devices, I’ve often found Eneloops seem to get stuck at “almost empty”, where they’ll power the device for a short time and then need to rest for a while. It seems like there’s some spontaneous recovery happening, or something like that.

I think all battery chemistries do that: voltage comes back up after load is removed or lowered. I’ve noticed that effect with at least Li-ion, SLA (sealed lead-acid) and LiFePO4. Perhaps the difference with Eneloops (or with the devices using them) is that the voltage keeps above a certain limit for some time after load is reapplied/raised, while in the other cases it goes back down faster.

@ToyKeeper

I doubt it’s good for the cell, so when I notice an Eneloop doing this, I take it out and recharge it.

My point exactly: the MC3000 shouldn’t be doing that, instead it should interrupt the discharge immediately once the voltage reaches its cut-off limit. Failing to do so not only extends the discharge duration needlessly, but also probably isn’t good for the battery either.

[dmenezes]

@dmenezes

Will let it run until tomorrow morning (about 8h from now), if they all get stuck and remain so, then I have the next best thing to a solved problem, which is a repeatable one.

No such luck: ALL batteries (including the one from the previous test) were able to finish the refresh operation this time.

There’s more to it and I’ve captured all data, will analyze and post an update later today (kinda busy with IRL right now).

[Mandrake50]

Well, maybe just a matter of using more patience than is normally required… nut still a bit weird.
Usually when I do this, I just set it up and walk away Using the MAHA C9000). When it finishes, it finishes. So I am not even sure how long it takes.

[dmenezes]

@dmenezes

There’s more to it and I’ve captured all data, will analyze and post an update later today (kinda busy with IRL right now).

So it took longer than I thought until I was able to get back to this, but here it is:

Analysis:

• First test, with just one battery and which was forcibly interrupted by me, after judging it was taking too long:

  • Battery #1 (Eneloop White HR-4UTG 750mAh AAA from 2010): 8.70h in discharge ste(until interrupted); the last 3.12h was spent after the battery touched the “1.00V” mark (which is what “CUT VOLT” has been configured to, and so when it should have stopped). Additional mAh the charger was able to take from the battery during these 3.12h: 117 out of 711 mAh = 16.5% (so not insignificant).

• Second test with the same battery above plus 3 more (keeping the bold numbers in the same order as above):

  • Battery #1 (Eneloop White HR-4UTG 750mAh AAA from 2010, same one as above): 8.72h, and the battery never hit 1.00V: lowest was 1.03V at the 4.00h mark (so 4.72h from it until the end of the discharge step), and at the end of the discharge step it was 1.16V (which is weird as this is significantly higher than the 1.00V CUT VOLT that was configured, so the charger apparently used some other criteria to consider the discharge finished). During these final 4.72h, an additional 45 out of 696mAh total = 6.5% were taken from the battery.

  • Battery #2 (Eneloop Silver BK-4MCAA 750mAh AAA from 2018): 9.77h, battery hit 1.00V at 4.18h, so it spent an additional 5.59h after it should have finished. Voltage at the end of the discharge step was 1.00V (so not as weird as the one above) . During these final 4.72h, an additional 35 out of 808mAh total = 4.5% were taken from the battery.

  • Battery #3 (Eneloop White BK-4MCCA 750mAh AAA from 2017): 10.07h, and the battery hit 1.00V at 10.02h, so it spent just 0.05h (about 3 minutes) at that voltage, which was also the voltage it ended the discharge at. Total capacity measured was 818mAh, and it drained exactly zero during these last 0.05h.

  • Battery #4 (Eneloop White BK-4MCCA 750mAh AAA bought in 2020, but only put into use in 2021): 8.13h, and hit 1.00V at 4.59h, so it spent an additional 3.54h after reaching the cut-off voltage; during these final 3.54h, it drained an additional 13 out of 800mAh total = 1.7% out of the battery.

Additional data:

• The test did run to its completion (ie, with all batteries fully charged after the charge step that followed), except for Battery #3: the charger interrupted its charging with the message “Capacity limit reached”: this is very interesting as setting the “Eneloop” battery type does not allow me to change the CAPACITY field (called “Capacity cut-off” in the app, this field simply isn’t shown). So, it must be one of the “convenient presets” the manual mentions (as I quoted above).

  • EDIT: I have gone back to the logs and found the battery reached 960mAh when the “Capacity limit reached” interrupted the charging, so this must be the preset limit the charger is setting this value to when “Eneloop” battery type is chosen. Not a very round number at 1.28x the nominal 750mAh capacity, but it is what it is).

• Battery #3 also logged a significantly higher TEMPERATURE than the other cells: 36 degrees Celsius, vs 20, 21, and 21 degrees Celsius for batteries #1, #2 and #4 respectively. This was about 15C (71%!) higher, and while not high enough to trigger the CUT TEMP which was set at 45C, marks this battery as significantly different than the others. Coincidentally or not, this was the only battery where the charger behaved close to its “drain D.CURRENT from the battery until it reaches CUT VOLT and then stop” expected behavior, and also it was the battery clocking the most capacity during the discharge step.

My conclusions, based on the above data:

• @Mandrake50 is probably right: it seems I was not patient enough during the first test and interrupted it when it could have been about to finish (given that this same battery, with this same program, did finish the discharge during the 2nd test just 0.02h – about 1 minute! later).

• There’s certainly something else going on in the discharge step besides the expected “drain D.CURRENT from the battery until it reaches CUT VOLT and then stop”; all batteries (except Battery #3) spent a LOT of time (more than half of the total discharge time) after reaching CUT VOLT. Perhaps the discharge algorithm somehow uses battery temperature to signal when a battery is really drained? Perhaps it does something else, like IR measurement (but the IR displayed for each battery never changes after it’ s determined at the start of the refresh), or very minute differential voltage (dV?) measurements, on a second-by-second or even sub-second basis, which I can’t perceive (but the manual only mentions dV during charge, not discharge)? Perhaps something else? I’m at a loss to explain how and why this charger takes so long after reaching CUT VOLTAGE to actually finish the discharge step.

• Regardless of the reason for that extended discharge, I see no point in it given that the maximum extra mAh that the charger was able to extract from the batteries was 6.5% – for me it doesn’t make any sense to more than double the duration of the discharge step in order to drain so little additional mAh from the batteries. Maybe draining every last mAh is important for reconditioning the batteries? The charger has a separate operation called “Cycle” for that, but perhaps the discharge step algorithm is the same on both the “Refresh” and the “Cycle” operations?

• Anyway, I don’t think spending many hours draining the batteries of every last mAh is good for them, as @Toykeeper mentioned. This should be at least optional, and clearly mentioned in the manual (the manual totally fails to mention this).

I plan on doing one further test, repeating the above but with Battery type = NiMh instead of Eneloop. I will post the result here.

In the meantime, all comments, tips and criticisms are more than welcome. TIA!

[epictetus]

Thankyou for this detailed analysis. It is indeed strange that the MC3000 waits for so long after substantive discharging to actually complete the discharge cycle.

[sam_sam_sam]

Try this change the voltage termination to 0.900 volts and see if this makes a difference or not

I have the same charger and I use it for 18650 batteries and I know for a fact that this charger has bug in the firmware I go into this later

[dmenezes]

@dmenezes

I plan on doing one further test, repeating the above but with Battery type = NiMh instead of Eneloop. I will post the result here.

So I did, and again captured all data; just went through it and this time I made a table of the results:

Batteries are the same and in the same order as in the previous tests (Battery #1, Battery #2, etc). Batte

What did NOT change: the very large time (“Extra hours spent”) the charger kept draining all batteries (except #2) after they reached 1.00V, in all cases over twice the time it spent to reach 1.0V.

What DID change: all batteries have reported more mAh in the end, and all except Battery #1 (which was already quite high) have reported a larger mAh delta from the 1.00V mark to the end: while in the previous test the maximum gain among batteries #2-#4 was 4.5% (and minimum was exactly zero), this time these batteries had a minimum gain of 5.65%, and it was as high as 8.74% with battery #2 (that in the previous test had gained just 4.5%) and 8.49% with Battery #3 (ditto, zero).

Additional data not on the table:

• Batteries #1 and #4 finished their refresh operation correctly; Batteries #2 and #3 aborted during the charging cycle that follows the above discharge, both with the message “capacity limit reached” (which only happened with battery #3 in the previous test). This is probably because the battery capacities have all improved since the last test (see below).
• All batteries had very different IR measurements when compared to the previous test: Battery #1 was 54mΩ vs N/A, #2 was 35mΩ vs 36mΩ, #3 was 44mΩ vs 11mΩ, and #4 was 13mΩ vs 27mΩ.

Conclusions:

• The extended draining the batteries are being subjected to does not seem to be harming them, but apparently the contrary, as indicated by the added capacity gains seen on the latest test; this gives credence to my “draining every last mAh is important for reconditioning the batteries” hypothesis I had formulated at the end of the previous tests. Of course, there’s no way to know if each battery’s useful life (ie, total life cycles) is being reduced.
• Internal resistance for batteries except #2 were reduced when compared to the previous test (Battery #1 was showing as “N/A” previously, probably because it was too high). This IMO also corroborates the “reconditioning” hypothesis above.
• Specially with the improved capacities after cycling, it seems the default 900mAh maximum capacity (aka CAPACITY in the spreadshet or Capacity Cut-off in the app) calculated by @SYZYGY spreadsheet for Eneloop AAA (or the 960mAh limit automatically preset by setting Battery Type in the charger to Eneloop instead of NiMH) is too low and will lead to premature termination of the final charging step; from looking at the data, I think it’s best to set that limit to at least 750*1+1/3= 1000mAh.

I have now started a 4th test exactly like the previous test: same batteries on the same slots with exactly the same program but with Capacity Cut-off set to 1000mAh instead of 900mAh; this will serve to see whether measured battery capacity and internal resistance keep improving or at worst stay the same (and therefore corroborates the “not harming but improving” hypothesis above) or diminishes significantly (therefore falsifying that hypothesis).

I will post here again when I have the results.

[Mandrake50]

WOW… Great write up. Also interesting results.
Why not just set the capacity cutoff much higher. Shouldn’t the DT/DV cutoff in the algorithm take care of stopping the charging cycle?
I look at the capacity cutoff as being sort of a safety feature. Just in case the charger misses the proper cutoff point. Which should correspond to the max capacity…yes?

[dmenezes]

@Mandrake50

WOW… Great write up. Also interesting results.

Thanks!

@Mandrake50

Why not just set the capacity cutoff much higher. Shouldn’t the DT/DV cutoff in the algorithm take care of stopping the charging cycle?
I look at the capacity cutoff as being sort of a safety feature. Just in case the charger misses the proper cutoff point.

Yeah, DT/DV should take care of finishing the charge, capacity cutoff is just an additional safety measure. I try and follow the defaults @SYZYGY’s put in his spreadsheet, but in this case they are clearly too small (please see my next comment).

Which should correspond to the max capacity…yes?

Yes, approximately so. In fact, thanks to goode olde 2nd Law of Thermodynamics,
charging_cutoff = max_capacity * efficiency
(part of the energy provided to the cell during charging always turns into heat and is lost).

[dmenezes]

@dmenezes

I have now started a 4th test exactly like the previous test: same batteries on the same slots with exactly the same program but with Capacity Cut-off set to 1000mAh instead of 900mAh; this will serve to see whether measured battery capacity and internal resistance keep improving or at worst stay the same (and therefore corroborates the “not harming but improving” hypothesis above) or diminishes significantly (therefore falsifying that hypothesis).

I will post here again when I have the results.

And here they are:

Main difference is that both total hours (“at Finish”) and “Extra hours” (ie, after reaching 1.0V) reduced; the rest seems to follow the same pattern observed above: capacities keep improving (which for me shows the MC3000 knows what it’s doing and it’s helping the batteries instead of harming them). Proportional mAh gained (in %) is smaller than in the previous test, so it seems we are reaching some sort of “diminishing results” which is to be expected when repeating an hypothetical “reconditioning” effort.

Re: increasing the Capacity Cut-off to 1000mAh, this solved the problem for battery #2 (whose charging step ended with 782 mAh put into it), but not #3 which aborted at 1000mAh, so it seems 30% additional margin is still too little. Next time I have to recharge this battery, I will change its program to have Capacity Cut-off set to 1100mAh.

Anyway, I’m finishing this sequence of tests at this point, and to emphasize it, my main conclusion is:

The MC3000 behavior during the discharge step of the refresh operation does not make sense to me (it should have stopped at 1.0V as configured and documented) and the extra time it ends up expending in that step makes me kind of uncomfortable, but whatever it’s doing, is not harming the batteries: we can see their capacity keeps improving. So the best approach for me as a user is just to be patient and wait for it to do its thing

I will edit my original post above to reflect that conclusion, to try and help people avoid reading all this just to arrive at it.

Thanks again to everyone who contributed with data, opinions and suggestions!

[epictetus]

And thankyou for the detailed work. Pleasing to know that the MC3000 knows what it is doing even if it takes a long time to do it.

[Mandrake50]

@dmenezes

just to be patient and wait

Yup !!!