Why is it so hard to get a proper "all chemistry" charger for cylindrical cells?

[0xdeadbeef]

There is, look for this setting: CYCLE MODE:   C>D, D>C>D, D>C, C>D>C

I should have switched to "advanced" immediately But hey, I'm an engineer, I don't read manuals.
In the "simple" mode, there is a just a cycle mode (D>C>D) but without configuration.
Now in the advanced mode there is everything I ever wanted to configure. Sweet.
Seems my only concern now is the cryptic program selection.

Well, and I guess it would have been possible to jump to to the 1st sensible program when a battery is put in the slot.
Currently, the default type for program #1 is LiIon, so if you put a NiMH battery in a slot even in simple mode, a LiIon mode will be selected
which results in a voltage warning after a few seconds.

[HKJ]

Well, and I guess it would have been possible to jump to to the 1st sensible program when a battery is put in the slot.

With all the support chemistries and battery sizes it would not really help much, but would often select the wrong entry.
And the entry on startup is not the first entry, but the last selected entry.

[0xdeadbeef]

With all the support chemistries and battery sizes it would not really help much, but would often select the wrong entry.
And the entry on startup is not the first entry, but the last selected entry.

True, even though a NiMH / LiIon selection would still help in a large percentage of cases.
Admittedly though, it wouldn't help for e.g. the LiFePO4 cells I use as they would be detected as LiIon.

Anyway, it's probably about time for something like a barcode system to quickly identify battery parameters.

[HKJ]

True, even though a NiMH / LiIon selection would still help in a large percentage of cases.
Admittedly though, it wouldn't help for e.g. the LiFePO4 cells I use as they would be detected as LiIon.

There is not only the chemistry, also the battery size. I have cells with charge current from 50mA to above 3000mA, using a high current on a small cell is not a good idea!

[0xdeadbeef]

There is not only the chemistry, also the battery size. I have cells with charge current from 50mA to above 3000mA, using a high current on a small cell is not a good idea!

Yeah, but selecting the mode with the lowest current would always be a safe choice. I'd assume there are also more clever ways to adjust the charge current to the estimated capacity.

I still think it would be possible to use the auto detection of the dummy mode without sacrificing anything in advanced mode.
Like:
- Detect battery voltage
- If it fits the last used program, use the last program
- If it doesn't fit, choose NiMH or LiIon depending on voltage with according default current (or search for fitting program with lowest current)

Still this would select the wrong voltage for some not so common types like LiFePO4 but still better than nothing.

Anyway, more urgently, some information regarding the current program should be shown like type and/or voltage/current instead of just "PROGRAM [#1]".
With the same 12 characters, it could display e.g. "#1:LiIo 1.5A". It could even scroll the text to show more details like "LiIon charge 4.2V 1A" or so.

[HKJ]

Anyway, more urgently, some information regarding the current program should be shown like type and/or voltage/current instead of just "PROGRAM [#1]".
With the same 12 characters, it could display e.g. "#1:LiIo 1.5A". It could even scroll the text to show more details like "LiIon charge 4.2V 1A" or so.

This I can agree with you on, I do also complain about it in my review (Will be published in a few days).

[0xdeadbeef]

Yeah, this would be my biggest concern right now.
There is just one other thing that I think is the opposite of intuitive:
If you press a slot button, you can select the program. Now if you press enter shortly, you can change the program while pressing it long selects the program.
At least for me, it would me much more sensible the other way round: select with a short and change with a long button press.

[dinoboy]

Regarding firmware update: is there already one? And is Win7 save?

I am on the run, so i'll just comment on the FW question:

Yes, there is an update available, but the update procedure doesn't seem to work reliably on all Windows OS. Reports of bricked chargers with Win10, Win7 compatibility modue, and even Win7 exist, so i am asking the company to pull all files from the web, both the PC Link Software (which works great on my WinXP system) and the firmware binary from the download server.

Do NOT update or try to update your firmware. It is unsafe at this point in time. It's weekend, so the online files can't be pulled right now, too bad.

[0xdeadbeef]

Sounds grim. I hope they can sort this out.
I figure the microcontroller is an STM32, so reprogramming should be possible through JTAG - if there is a connector somewhere. But doesn't look like it...

[Emo]

OK, I can confirm a working firmware update on win 7. I do have some problem however connecting to the iPhone app with BT.
Charging info and graphs are very nice. Still a lot to figure out on this very versatile charger

[0xdeadbeef]

In the meantime, I tested the MC3000 quite a bit more. All in all, it's an amazing charger and I don't regret buying it at all.
I love the amount of the configuration options and information it displays during charging, especially the internal resistance.
There are some issues though which might or might not be possible to fix in future firmware versions

• There is no power switch and apparently no auto power off either. I wonder if it's possible to implement an auto power off after a selectable time.
  Also the display light control could be more intelligent (like switching on when a battery is inserted).
  
• When you do a discharge-charge cycle, you can only see the discharged capacity before the charging starts.
  
• When discharging 2 Li-Ion cells with ~800mA each, the device quickly reaches >50° and the fan kicks in. Which is much too small and quite a bit annoying.
  Good thing is that when discharging NiMH cells, the fan stays off (tried with 3 Eneloops discharged with 600mA).
  
• As discussed before, the display of the currently selected program leaves to be desired. Maybe it would be possible to name your programs through the PC program or app.
  
• Some of the interface choices seem a bit weird. E.g. as discussed before, to select a program you need a long button press but to change it a short one.
  Also pressing the stop button is used to leave/quit some menus but also stops the current program in others without warning.
  Something as important as canceling a running program should need a long button press or even a confirmation.
  
• The Android app only works on relatively new Android versions (like >4.3) while e.g. the app for the NC2500 also works with older versions.
  

[dinoboy]

"There is no power switch and apparently no auto power off either. I wonder if it's possible to implement an auto power off after a selectable time." — Sorry, i can't comment. And even if it were possible (feasible), it doesn't mean that the team would decide in favor of it. To cut my non-comment short, i don't think that this will ever happen.

"Also the display light control could be more intelligent (like switching on when a battery is inserted)." — it is already on the to-do list, thanks

"When you do a discharge-charge cycle, you can only see the discharged capacity before the charging starts." — in CYCLE mode, e.g. "D>C, N=3", the SOV (did you read the manual and learn the abbreviations and glossary?) will show the discharged capacities of all 3 cycles. The very final routine is Charge, DCDCD[C], so TOV will finish by displaying the charged capacity. If you need to see the other 2 charged capacities, they're only available on the PC monitor.

"When discharging 2 Li-Ion cells with ~800mA each, the device quickly reaches >50° and the fan kicks in. Which is much too small and quite a bit annoying." — I need to check that, but it sounds about right. *FYI* SysTemp maxes out on my unit at around 83°C (displayed value) at full discharge load.

"As discussed before, the display of the currently selected program leaves to be desired. Maybe it would be possible to name your programs through the PC program or app." — you prefer cryptic naming, i prefer thing as they are. I don't believe that things will change in this regard, sorry.

"Some of the interface choices seem a bit weird. E.g. as discussed before, to select a program you need a long button press but to change it a short one.
Also pressing the stop button is used to leave/quit some menus but also stops the current program in others without warning.
Something as important as canceling a running program should need a long button press or even a confirmation." — thanks for your opinion. The operation of the UI with the long and short pressing of the buttons (like ENTER or STOP) are, in the end, a matter of opinion and taste, custom and practice. there will never be agreement. i will always like and prefer the way it is.

"The Android app only works on relatively new Android versions (like >4.3) while e.g. the app for the NC2500 also works with older versions." — afaik the coding of the Android version 1.0 didn't start until recently, it is super unstable and crashes right away. they are working on improved versions. tbh shoppers should not count on great apps for the charger. hauptaugenmerk was invested in the development of great electronics, mechanics, and firmware. and again tbh, i never use the app. I do appreciate the existence of DEX which is an attractive alternative logging software for the device.

[0xdeadbeef]

And even if it were possible (feasible), it doesn't mean that the team would decide in favor of it. To cut my non-comment short, i don't think that this will ever happen.

For the protocol: in idle with display light off, the MC3000 still needs slightly less than 1.4W. With light on, it's about 2W, the power supply alone needs around 0.3W.
It's not catastrophic, but also considering aging etc., this means for me that I'll have to plug/unplug it every time I use it.

In CYCLE mode, e.g. "D>C, N=3", the SOV (did you read the manual and learn the abbreviations and glossary?) will show the discharged capacities of all 3 cycles. The very final routine is Charge, DCDCD[C], so TOV will finish by displaying the charged capacity. If you need to see the other 2 charged capacities, they're only available on the PC monitor.

I read the manual, but for sure won't use these acronyms as they are unreadable for anyone who didn't just read the manual. Actually I found this use of acronyms quite annoying. Bad style IMHO.
Anyway, I'm quite sure that there was only the charged capacity shown in the "slot operation view" during charging in a D>C cycle. Then again, maybe I'm mistaken. I'll try this again.

I need to check that, but it sounds about right. *FYI* SysTemp maxes out on my unit at around 83°C (displayed value) at full discharge load.

Admittedly, about 6W need to be cooled this way or the other yet I wonder if another cooling strategy (e.g. air tunnel side to side) with a slightly larger cooler would have decreased temperature and noise level.

you prefer cryptic naming, i prefer thing as they are. I don't believe that things will change in this regard, sorry.

Quite the opposite. I think I made clear that I don't like the cryptic naming like "PROGRAM [#1]" and I'd rather had something meaningful.
To quote myself: With the same 12 characters, it could display e.g. "#1:LiIo 1.5A". It could even scroll the text to show more details like "LiIon charge 4.2V 1A" or so.
Then again, if I could name my programs to something like "EneloopAA_DC" this would be also fine for me.

The operation of the UI with the long and short pressing of the buttons (like ENTER or STOP) are, in the end, a matter of opinion and taste, custom and practice. there will never be agreement. i will always like and prefer the way it is.

Still, it's not intuitive and you should consider that you're probably already too used to the current weirdness to judge it fairly.
For sure nobody would expect that a common use (select) needs the more specific button press (long) compared to the uncommon use case (edit).
I would maybe agree if selecting the program would immediately start it, but you need to confirm it with another press of the enter button.

tbh shoppers should not count on great apps for the charger.

Honestly, this seems to be a strange attitude. If a bluetooth module is added to a device and "app control" is part of the advertised features, you would expect that at least some attention is paid to deliver a stable app.

[dinoboy]

"It's not catastrophic, but also considering aging etc., this means for me that I'll have to plug/unplug it every time I use it." — So you're measuring a total of 1.7W standby power, i see. I don't know how much other notable 4-bay chargers consume. But personally i put them all away from my desktop when i don't use them. The next manual revision will include the note 'When not in use, remove all batteries, unplug from main, disconnect the adapter, put everything neatly away in storage.', it will ensure that no dust or humidity reaches the device also during non-usage time.

"I'm quite sure that there was only the charged capacity shown in the "slot operation view" during charging in a D>C cycle. Then again, maybe I'm mistaken. I'll try this again." — I'll try too. So far i've been trying my favorite CYCLE mode only, which is "C>D".

"Admittedly, about 6W need to be cooled this way or the other yet I wonder if another cooling strategy (e.g. air tunnel side to side) with a slightly larger cooler would have decreased temperature and noise level." — Of course. It needs to be seen if the majority of buyers receives the product well, finds it likable and is really wishing for a Mk II release (2018) with particular hardware improvements such as bigger fan, redesigned heat sink, and such. Total dimensions will increase then too, naturally. Mk I (2015) is to the maker's liking im stillen kammerlein, Mk II (if every materialized) will be adapted to the WWW feedback on the Mk I.

"With the same 12 characters, it could display e.g. "#1:LiIo 1.5A". It could even scroll the text to show more details like "LiIon charge 4.2V 1A" or so. Then again, if I could name my programs to something like "EneloopAA_DC" this would be also fine for me." — I totally get the idea, even if i am not fond of such naming at all. Confuses me, doesn't look neat. Maybe a new option could be created in GSV, "Naming: {Default|Parameter}", such that both naming methods are available. I've added it as idea to the list 

"Honestly, this seems to be a strange attitude. If a bluetooth module is added to a device and "app control" is part of the advertised features, you would expect that at least some attention is paid to deliver a stable app." — Yesyes we would all agree. It's shaming that there is a dazzling gap between app quality/evolution status (immature) and firmware version (mature). Oh well.

Anyway, let's accept and appreciate what we've got so far! The product has been meeting my expectations, happy camper here. O0

[0xdeadbeef]

Did I say I'm unhappy? No way!
Anyway regarding charged/discharged capacity: I just tried it again with a nearly fully charged Eneloop. There is just one "Capacity" value displayed in the slot operation view. It's the same value as displayed in the total overview. And both represent the discharged capacity during discharging and the charged capacity during charging. So as I said: as soon as the charging starts, the discharged capacity is lost.
I still have the firmware version v1.02 btw.

[dinoboy]

Did I say I'm unhappy? No way!
Anyway regarding charged/discharged capacity: I just tried it again with a nearly fully charged Eneloop. There is just one "Capacity" value displayed in the slot operation view. It's the same value as displayed in the total overview. And both represent the discharged capacity during discharging and the charged capacity during charging. So as I said: as soon as the charging starts, the discharged capacity is lost.
I still have the firmware version v1.02 btw.

You're talking about the case "D>C, N=1"? Oki, now i am getting why the firmware does that. It is programmed in such a way that it displays the capacities of full charges (or full discharges) only, not the capacities of partial charges (or partial discharges) from the very beginning of a "Cycle", the initial charge transfer routine.

So, technically, from the coder's standpoint, the behavior is logical/correct 
I can see 2 solutions:
1) If you're interested in the discharge capacity, you could use Discharge mode, "D" or "D>". (the symbol ">" may represent a resting phase, D.RESTING). Or:
2) The fw author changes the code such that the initial partial charge (or partial discharge) in the two exceptional cases "D>C, N=1" and "C>D, N=1" …nah scratch the latter… only 1 exceptional case: "D>C, N=1", is displayed as "Cycle 1" in slot operation view.

Thinking about it .. you're right, this could be regarded as bug because the Cycle counter should be assigned to the discharge routines (no matter what) and not to the full routines. This finding has been noted before and also listed. Thanks!

 

[0xdeadbeef]

Ok, thanks.
Again, it's not a showstopper, but I usually charge my Eneloops with D>C when they are already reported to be low. My Charge Master 2016 calls this mode "Check".
The main idea of discharging before is of course to get a an idea of the battery's capacity after charging (instead of just the capacity that was charged).
Yet I find it also interesting to see how much capacity was actually left.

Another thing: I understand that there is no way of using an altered program without saving it before. Is this correct?
Like as I said I usually use "D>C" for my AA Eneloops which I now stored as program #1. I use #2 for AAA Eneloops, #3 for LiIon, #4 for LiFePO4 in the same way.
Now sometimes I just want to charge without the discharge cycle first (e.g. since I think the battery is still more or less fully charged). Is there any way to select program #1,
alter it (Cycle -> Charge) and use it without saving it first?

If not (as I assume): I think it's nice to be able to save default programs but it's not so nice to not be able to use altered programs without saving them.
This forces you to have a separate program for the same battery but different use cases and this can quickly become a bit of a mess.
Maybe it would have been better to separate the mode (cycle/charge etc.) from the battery type.
Most of the parameters of a program are actually parameters for a certain battery (charge/discharge current, cutoff voltage etc.) while a mode (charge, discharge, cycle) is independent of the battery.

[dinoboy]

You could reuse [30] as "temporary program" by over-writing this single memory spot over and over.

i like the following scenario:

Say you have small set of favorite programs [01]…[05] which you really don't want to see changed. ("write-protected programs")
All slots are empty.
You want to charge 1 battery and insert it in #4.
Because of 'last mode memory' TOV shows that [30] is assigned to #4.
You click on SNB1 to enter SPV for #1 (which is empty).
You change the program number to say [04], click Enter and then alter the settings of [04] without saving.
However in the last row, SAVE TO, you long-press on "SAVE TO [30]". So basically you are saving the edits.
[04] stays intact, unaltered.
Yes, technically you created "a new" program, [30], but think of it more like overwriting an existing memory spot, or computer file.
Now use it: Since #4 was pre-assigned with [30] and your battery is in #4, all you need to do is 1 click on Enter or 1 depress on SNB4.

The need for saving, even if it's under the same name, compares well to PC behavior:
EXAMPLE 1 you have on original write-protected HTML-file and you're editing it under the new name test.htm in a text editor while it is also being viewed in Internet Explorer 8. The edited HTML-contents cannot be viewed in IE8 by hitting F5, unless you have hit the SAVE-button in the text editor (test.htm, test.htm.bak). Saving is a must, before IE8 can process the edited file. But instead of creating different files test1.htm, test2.htm, etc., we work with 1 file only. And it is a temporary file. After we're done with the html-code test, we are free to delete the test.htm file.

EXAMPLE 2 you temporarily save a daily funny JPEG from an original web source under deleteme.jpg on your HDD (purpose: sharing new imgur URL or as email attachment with friends on the same day), knowing that you can delete the file any time in future when you accidentally encounter it on the HDD to clear space. instead of downloading 100 funny JPEG's under their original names (1 JPEG per 1 day, that's 100 jpeg's in 100 days, geesh!), you always save the new image under the same old name deleteme.jpg before "using" the file for its intended purpose, here: resharing with friends. This is also a great example of the temporary character of a file we "created" (for temporary use) and which we would overwrite at the next opportunity.

 

[0xdeadbeef]

Of course there are workarounds. It's always better if no workaround are needed.

[Edit]
Regarding the discharged current: actually I just noticed that when the program is finished (discharge and charge), the "Capacity" display toggles between "Capacity" and "Cycle 1" where the latter is the discharged capacity.
So it works, but only after the program is finished.
I'd think though that two separate lines for charged and discharged capacity would be a bit more readable. And of course the value(s) from the last step(s) could be already displayed before the full program is finished.

[dinoboy]

I'd think though that two separate lines for charged and discharged capacity would be a bit more readable. And of course the value(s) from the last step(s) could be already displayed before the full program is finished.

I am just explaining how it is:

For an ongoing multi-cycle program, i.e. CYCLE program with N>1, the discharge history of the completed cycles (completed 1st cycle, completed 2nd cycle, ..) is available in SOV. For the ongoing cycle one needs to wait until it has completed (C>D, or D>C), then its discharged capacity will be available too, once the program has entered the next cycle. One doesn't need to wait until the entire program has finished to see the history of discharged capacities.
Why this is so can be traced back to the software architecture (FOR loops and WHILE whatnot) and i won't bug the maker about making structural code changes in his regard. Partial history viewing is implemented, and it is good enough. In fact i had made the same observation months ago and i asked 'where is the value, why is that so?' and he explained. I thanked for the explanation and accepted it and moved on.

Anyway, thanks for your interest in MC3000 matters,
time for me to move back to where i'm coming from,
you can find other mc3k users and me there for furthers

 

[HKJ]

I have published a review of the MC3000 charger: http://lygte-info.dk/review/Review%20Charger%20SkyRC%20MC3000%20UK.html

[0xdeadbeef]

Gosh, I guess I don't want to know how much time you've spent on this.
Anyway, the teardown confirms that the thermal design leaves a bit to be desired. Then again, it doesn't really concern me so much as the fan is off during my normal charging needs and even when discharging Eneloops.
Still I'd wish a bit more passion would be put into the PC software, the app and the GUI. However dinoboy's comments make me think this is a somewhat futile hope ("should not count on great apps for the charger", "good enough").

[dinoboy]

I have published a review

Thanks so much for the review HKJ, i am going to study it over the next few days!  O0

For the protocol: in idle with display light off, the MC3000 still needs slightly less than 1.4W. With light on, it's about 2W, the power supply alone needs around 0.3W.
It's not catastrophic, but also considering aging etc., this means for me that I'll have to plug/unplug it every time I use it.

Here is a very acceptable solution for the standby power consumption, if you prefer to leave the unused 'machine' on the desktop:

Still I'd wish a bit more passion would be put into the PC software

DEX is compatible with MC3000. A very passionate project!
http://www.nongnu.org/dataexplorer/

I am testing the latest beta version. Works really well so far. So stay tuned for the official beta release!