SkyRC MC3000 help thread

Some small manufacturing flaw can bring about such annoyance. Likely a reflow soldering defect somewhere in the board, or something like this.



Thank you sir. I'm not qualified to chase something like that down and whether I could solder it or not would depend on where it is.

Get this though. I restarted it and the slot is reading the internal battery resistance now That's not a very encouraging sign, but maybe just a software glitch or something.


A quick update on this. It appears that sometimes I wasn't waiting long enough for the analysis to finish and or not getting a 21700 battery seated in the slot cleanly/quickly enough and the unit wasn't able to properly read the resistance.

Hi, I need help, I have a MC3000 for a few years and channels 1 and 2 have stopped working, not even detecting the battery when inserting it. Is it a known bug? Is there a solution?

I am sure the manufacturer has extensive support on this product.

I have 25 AAA Eneloops of varying age and most test under 100 milliohm, but three test above 200 using a 750mA (1C) discharge. Not a huge concern as I don’t use these in high-drain situations. Still, I’d like to play around with my MC3000’s cycling functions to see if I can improve these batteries.

Is there a recommended program for this? I don’t mind if it stresses or even risks further damage to the batteries as this is mostly to satisfy my own curiosity.

Thanks!

So I just bought one of these a week ago and am trying to learn to use it (I overbought for my needs and level of knowledge) Right now I’m just using it to charge Samsun R25 batteries for my vape mod but I plan to expand to using more rechargeable batteries around the house. I’m trying to create a refresh program for the samsung R25s. Can anyone tell me what the setting would be and how to figured it out so I can create my own programs without having to take up other people time every time I get a new kind of battery. Any help would be appreciated and thank you in advance.

You generally don’t refresh 25Rs or any other Li-Ion battery, there’s no point. Do you mean you want a charge program tailored for the 25R? If you’re thinking about NiMH (like enloop) batteries, the default “Eneloop Refresh Std AA” (or AAA) programs look fine to me. I did a little research since my last comment :slight_smile:

Understood on not needing to refresh. Is there any point to a tailor made recharge program then?

The Battle Pumpkin, if you want them to last the only care li-ion batteries need is to put away or store them not fully charged (short answer: don't go much above 3.9V). You can read about this and many other battery knowledge here: BU-808: How to Prolong Lithium-based Batteries @ Battery University.

Sure I can recommend a custom 25R program. First, you need the tech specs for your battery. 18650batterystore.com and others often have links. Yours is here:
https://cdn.shopify.com/s/files/1/0481/9678/0183/files/samsung_25r_data_sheet.pdf

So I put those numbers into a program exactly as those specs recommend:
BATT TYPE: LiIon
MODE: Charge
CAPACITY: 3200mAh
C.CURRENT: 1.25A
D.CURRENT: OFF
C.RESTING: 0min
D.RESTING: OFF
CYCLE COUNT: OFF
CYCLE MODE: OFF
TARGET VOLT: 4.20V
TERMINATION: 0.10A
RESTART VOLT: OFF
D.REDUCE: OFF
CUT VOLT: OFF
CUT TEMP: 45C
CUT TIME: 240min

Note “CAPACITY” is a safety number a bit above your actual capacity, in case you were wondering. CUT TIME is also a safety maximum above how long it should actually take.

You could change these (or add a second program) for faster, still safe, within specs, and get you like 90 to 95% charge in about half the time:
C.CURRENT: 2.5A
TERMINATION: 0.25A
CUT TIME: 180min

If you have other 18650s and you’re not sure what to use, these will be slow, but safe:
CAPACITY: 4000mAh
C.CURRENT: 0.75A
TERMINATION: 0.10A
CUT TIME: 360min

Sorry, I didn’t actually answer your question :slight_smile:

The point of a tailor made recharge program is to get full use of your battery so it runs the longest every day and performs well over hopefully several years, while charging safely and quickly. It’s a balance between these factors. Honestly any decent charger will be fine in 99% of cases but the MC3000 allows you to tweak things.

Hope the programs are useful anyway!

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:

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 :slight_smile:
[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.