There is no point to refresh LiIon cells. You can run C>D cycle as per manufacturer recommendations (charge current, end of charge current, discharge current, end of discharge voltage), only to measure discharged capacity. This may be useful if you want to follow the state of wear of your cells. If you have a reference on the new cell, you may want to do it once every 30-40 cycles.
As mentioned here, here are some links to MC3000-specific info I posted on another thread. I’m reposting here to try and make it easier to find as this seems to be the BLF’s “main thread” for the MC3000:
-
Material changes in the MC3000 hardware in the last few years: Checking mAh - #49 by dmenezes;
-
Other forums with MC3000 information: Checking mAh - #51 by dmenezes (English), Checking mAh - #53 by dmenezes (Russian, but useable in English via Google Translate);
-
Version 1.20 of the MC3000 manual (not the firmware): Checking mAh - #56 by dmenezes;
-
Initial discussion about firmware versions for the MC3000, specially v1.15 vs v1.18 (will be continued here): Checking mAh - #58 by dmenezes (and the next 4 posts following it).
Following up on this, early this morning I managed to get ahold of a helpful representative at the SkyRC website chat, and asked about v1.17 (which came on my SkyRC MC3000, purchased late last April), the previous version v1.15, and the current one v1.18;
TL;DR: v1.17 has a bug (related to the operation of D.REDUCE setting and possibly to its “inverse similar during CV-Phase of Li-Ion battery charging”[1] which is why SkyRC does not make that version available for download, and instead recommend updating to v1.18. I asked about falling back to 1.15 in case 1.18 doesn’t work for me, but they apparently evaded that question.
[1] see the SkyRC manual p.22, under “D.REDUCE”.
And here’s the complete transcript (edited for clarity/brevity):
13 Sep, 2023
[15:08] DMenezes: I have an SkyRC MC3000 with firmware 1.17. I see there’s an update available for firmware 1.18, but I’m worried that the new firmware could not work as well and I would need to go back to the old one.
[15:09] DMenezes: I searched the SkyRC website for version 1.17 so I could go back to it if needed, but could but could not find it. I could find version 1.15, tho.
[15:11] DMenezes: My question is, is there a reason the older version (1.15) is available for download, but the newer one (1.17) isn’t?
[17:34] SkyRC: There is a bug in V1.17
[17:34] SkyRC: So we did not put it on the site
[17:35] SkyRC: The bug is about the charge or discharge reduce[17:50] DMenezes: Ok, so I better upgrade ASAP, I guess
[18:34] DMenezes: if I upgrade to 1.18 and it doesn’t work for me, should I then move to 1.15?[18:45] SkyRC: I believe 1.18 will work for you
I hope this is helpful to other MC3000 owners.
1 Thank
Yes, the person did not answer the firmware rollback question… I swear I read that it was possible. Probably in that CPF thread where people were dealing with Betas.
Too bad he didn’t point you to a changelog. But at least we know why 1.17 is not available.
Thanks for posting this!
2 Thanks
I will try and ‘update’ (actually, fall back) to 1.15 first (and run with it minimally, in order to answer that question), and then to 1.18 (and use it extensively, to see how well that version works). Will post my results here.
Might take a while (from many hours to a couple of days) as I’m currently recovering from a data-loss event on my computer, and have to finish it before rebooting into Windows to do these upgrades.
1 Thank
Glad to join you all here!
I confirm that I have read the firmware rollback stuff too, but I also can’t find/remember where. I also don’t recall the level of reliability of this information: not implying it is unreliable just that I don’t recall.
Also posting here the stuff on the PHYSICAL hardware (which is NOT the same thing as the MC3000 firmware reports about “HW version” in its Setup program)
1 Thank
I tore down my HW >V2.2 MC3000 and was surprised to find an STM32 clone as the MCU. Mine has a Geehy APM32F103RBT6, which seems to be a clone of the STM32F103RBT6.
1 Thank
Thanks for sharing that. I’ve been wondering about my MC3000 MCU and was about to open it up to have a look, and you just saved me the effort.
How so, “surprised”? (not arguing, just curious.)
I wonder how easy (or hard) it would be to use JTAG or similar to dump its internal flash. Then we could try and reverse-engineer it to see whether there’s a way to implement some functionality I for one been lusting after, eg reading programmed charging parameters via Bluetooth.
Managed to do it all last night.
Was unable to update using the PC Monitor 1.05 software: it always complained of “can’t get firmware list from the internet”.
So I downloaded manually from the SkyRC website, first version 1.15 and then ran it: update took a couple of minutes and in the end the charger rebooted and came back up with all my settings erased. Tested it first with the app and then the PC Monitor software and both seemed to work ok, at least for charging.
As I was originally running the version 1.17 that came in my charger, that confirms to me that downgrading (ie, flashing an older firmware version) indeed works.
Then I did the same with firmware version 1.18, same erase-settings behavior, and also seems to work ok with the app and the PC Monitor software.
Then I rebooted back into Linux and confirmed that 1.18 also works with my custom mc3000ble.py firmware.
I will test 1.18 more extensively in the coming days and weeks and report here if I find anything interesting.
1 Thank
A few notes about that: the PC software really sucks, besides its non-working firmware upgrading feature as mentioned, it’s full of typos and lacks basic functionality; case in point, I couldn’t find a way to see the battery IR anywhere (not on the screen and not in the generated CSV file, which BTW is generated “invisibly” when one clicks on the Save button in the main screen – and I say invisibly because it only offers to save a BMP file of the screen, the CSV is saved along but you have to figure it out by checking in the same directory afterwards.
And I thought the smartphone app was bad… which it actually is, but the PC software manages to be much worse.
Well, at least I won’t be missing it as I can’t get it to run under Linux anyway (won’t work in a Windows VM due to the USB VID/PID issue I already mentioned, and also fails to work under WINE because it can’t connect to the charger).
To sum it up, this is an area where the MC3000 could really use some improvement – or SkyRC could publish the complete protocol spec so opensource developers could support it fully, instead of piecemeal due to gaps during reverse engineering.
Thanks. I had seen references to it already, but was under the impression that it was only for data capture/visualization. Can it be used to operate the charger (load/save/start programs, change charger settings, etc)?
OK, just installed the latest DataExplorer (v.3.8.0) and had a look. On the positive side, it’s opensource and runs perfectly on Linux (and should run as good everywhere there’s a JRE, as it’s written in Java).
On the negative side, it’s large and complicated and worse, incomplete: can’t use it for eg seeing the device firmware/hardware versions nor change any of its “global” settings.
AFAICS its largest advantage vs the bluetooth app is being able to back-up/restore programs from/to the device, but it’s quite labor-intensive as one has to operate the device and set a specific program to each slot, and then use the DataExplorer device dialog to read that program and save it in a DataExplorer slot; AFAICS there’s no way to read all programs and save them correspondingly, it has to be done one by one, and carefully so as not to mix slots as the program doesn’t guarantee any correspondence of its own slots vs the device slots. And restoring the device programming has to be done the same way, one by one and operating the charger and the program in concert, carefully and laboriously.
Worse, the program data you went to all that trouble to transfer to your PC is then saved in ASCII-encoded-binary form (ie, illegigle/uneditable), despite it being saved in a XML file that’s otherwise totally legible and editable. WT actual F?!
Well, I guess I won’t be using DataExplorer much either – my modded mc3000ble.py serves me well so far, has the added advantage of working totally over Bluetooth (so it’s one less cable, and the charger can be anywhere in Bluetooth range). I will eventually mod it further to support eg saving slot programs in the PC and have them transferred to the device.
2 Thanks
Are you aware of a compelling, or even good, specific reason to update a v1.15 unit to a higher firmware revision?
I know you’ve done some related research on such matters, and would likely know the answer.
Thanx!
EDIT: Excuse me. I meant to include anyone else who might happen to know as well. Thanx to any / all!
1 Thank
Hard to say as there aren’t any changelogs, and what little information there is, is very fragmented and caricatural.
The reason I’ve upgraded to 1.18 is basically the manufacturer information that 1.17 (which is the one my charger came with) is broken, and a desire to stay with the latest if possible. But I’ve briefly tested 1.15 too, so I have a fallback in case 1.18 doesn’t work for me.
I know you’ve done some related research on such matters, and would likely know the answer.
Sorry to disappoint you 
In fact I’m still doing my research (going through that monster thread over there in CPF, and also the much smaller but still large thread in a Russian forum), I will try and post a summary here when I’m done, and will tag you if I find anything concrete re: 1.15 vs 1.18
1 Thank
I found this on 1.17…CPF
"skyrc replied:
Just improve the internal resistance measurement in the new 1.17 firmware."
Cryptic… right?
Then:
The newest firmware version (1.17) gives an unrealistically low value for the IR, this is the only change. I do not recommend to upgrade.
And apparently 1.17 was also broken in the way @dmenezes mentioned.
So 1.18 fixed what they broke in 1.17 ?? Did it keep the IR reading variance?
It would be so much easier if they published comprehensive change logs…
1.15 doesn’t have any glaring errors. If you have logged IR for cells using 1.15. they may not be comparable to 1.18 (??).
I have been wrestling with the decision myself. So far, I have stayed put on 1.15.
1 Thank
This lack of a detailed Changelog makes it difficult to know if there is ANY reason to upgrade ever! And why they even bother to issue new Firmware versions.
As mentioned before, I have not upgraded my 1.13 Firmware because there appears to be no compelling reason to do so and I don’t want to delete my programs. I think the venerable HKJ made a similar comment somewhere.
1 Thank
@Mandrake50, many thanks for the detailed and thoughtful response! I will comment further below:
Thanks for looking! I’m still on page 12 of that CPF thread, and these mentions you found are on page 280, so it would have taken me a long time to get there yet 
Just adding the URLs to the posts you quoted:
"skyrc replied:
Just improve the internal resistance measurement in the new 1.17 firmware."
This is on post #5,586.
Cryptic… right?
Agreed, they should have stated exactly how they “improved” it.
Then:
The newest firmware version (1.17) gives an unrealistically low value for the IR, this is the only change. I do not recommend to upgrade.
And this is on post #5,589
As per this last one, I would like to point it doesn’t seem to be ‘official’ info from SkyRC, but just the isolated opinion of a CPF user (NiOOH), who I haven’t seen so far in my reading-through of that thread, (so I can’t say how knowledgeable/reliable that user/information is) and which doesn’t seem to be corroborated by further posts in that same thread (other users seem to have basically taken that info as granted).
And apparently 1.17 was also broken in the way @dmenezes mentioned.
Yes, according to the information I got straight from SkyRC.
So 1.18 fixed what they broke in 1.17 ?? Did it keep the IR reading variance?
From a straight-up interpretation of what they told me, I would say that from 1.17 to 1.18, they only fixed the bug related to the D-REDUCE and its conterpart in the charging process.
But I can somewhat easily check for that, as I have logged the IR for many of my batteries with 1.17; now that I have upgraded to 1.18, I can just run the same ops (some were refresh and some recharge) with the same batteries and compare the reported IRs.
It would be so much easier if they published comprehensive change logs…
Agreed 100%. IMHO SkyRC is handling this firmware versioning matter in a totally unprofessional way, any hobbyist with a Github account (and even most without one) handles this in a much better, more transparent manner,.
And that’s one of the reasons I hate closed-source firmware/hardware… 
And the worst part is, SkyRC once used to publish exactly that automatically, on a panel of the PC Monitor application, when one checked for available firmware. But now, as I reported, it seems the PC Monitor application only returns errors for any firmware-related operation… 
1.15 doesn’t have any glaring errors. If you have logged IR for cells using 1.15. they may not be comparable to 1.18 (??).
Again, I can check for that somewhat easily: now that I’ve determined that I can flash up/down versions on the MC3000, let me just collect a little more data with version 1.18 and then I will go back to 1.15 and repeat the same process with the same batteries. Then I will be able to report the IR measurements for each one with both 1.15, 1.17 and 1.18; this should give us a fair appraisal of that IR thing.
I have been wrestling with the decision myself. So far, I have stayed put on 1.15.
Yeah. It’s the old motto, “if it ain’t broken, don’t fix it”. OTOH, it will make it more difficult to make sense of any previous/current data when SkyRC releases an even newer version (1.19? 1.20?) with some worthwhile improvement; in that sense, it would make more sense to keep the charger always upgraded with the latest version.
My recommendation for now is to stand by and let me make those IR measurements in 1.18 and 1.15 and put them both in a table, along with the ones I already have from 1.17; if indeed 1.17 (and presumably 1.18 too) are b0rked in that regard, that table should make it easy to see.
1 Thank
I agree 100%. SkyRC should do much better in that regard.
Agreed, if I had any programs on my MC3000 (which I don’t, I keep all of them on the bluetooth app)I would also be unwilling to upgrade; the fact that flashing new firmware erases all settings (including programs) and that they can’t be backed up and much less restored unless AFAICS one goes through a long, labor-intensive and error-prone procedure using DataExplorer (see my post above) is one more nail in the coffin of MC3000 firmware upgrades…
What would be really great is if someone managed to reverse-engineer the MC3000 firmware and its upgrade process and could develop an entirely open-source alternative to it, in the same way that has been done for countless similar ‘embedded’ products like famously the WRT54G line of routers, long ago… then we could buy the great hardware that MC3000 is, and skew the SkyRC bad/opaque software and firmware for something transparent and understandable…,.
Which brings up something I have thought about recently. I have the app on and old phone. Like a Galaxy 5 or 6 . At some point I will need to switch to another phone (the battery on the current one is getting a bit flaky). Has anyone tried backing up the app and saved programs so it can be transferred to a new device? Or, heck, just to have a backup?
1 Thank