Current/Charging detection

[sergeibit]

I have an UV-K5(8) and I'm looking to understand how charging detection works in the firmware.

Currently, my device won't show anything on screen when charging by using the USB port.

It charges just fine, blue led will lit, but software won't react or detect anything.

I tried debug anything related with ENABLE_SHOW_CHARGE_LEVEL, ENABLE_FEAT_F4HWN_CHARGING_C, gChargingWithTypeC and anything else I could find that could be related with charging.

Also, ADC_GetValue(ADC_CH9) , always return 0, what makes me think the hardware is not properly wired. I don't know if the firmware just don't support USB power detection or if it's a hardware problem.

Do you know if it's a software bug, hardware limitation or if it's just a hardware fault on my side?

Does the charging detection by software works in your device?

Thank you!

[armel]

Hi there,

The infamous USB-C charging question... :) Let’s try to clear things up.

First important point: USB-C charging on the Quansheng K5 is entirely handled by hardware, not software. The firmware does not manage the charging process, nor does it control the blue LED.

You mentioned that ADC_GetValue(ADC_CH9) always returns zero — that confirms that, on your board revision, VBUS (the 5V from USB-C) is not connected to any ADC input. As a result, the firmware simply has no way to know whether a USB cable is plugged in. So this is not a bug, but a hardware limitation.

Another thing worth noting: if the battery is already well charged (say, above 70–75%), it’s possible that the charging circuit just doesn’t activate. This might be a kind of hardware protection or "eco" ♻️ behavior, but in any case, it’s not something the firmware can override.

As a side note, keep in mind that the official documentation describes USB-C charging as more of an emergency feature 🚨 — something to help you out when the battery is completely dead. It’s not intended for regular or "comfortable" charging.

Lastly, it’s important to understand that the K5's USB-C port does not implement the USB Power Delivery (PD) standard. It simply expects a source that provides a dumb 5V supply. If you plug the K5 into a "smart" USB-C charger that waits for a PD negotiation before supplying current, nothing will happen: the K5 won’t talk, it doesn’t support PD, and so no power will be delivered. Result: no charging, no LED, nothing.

To sum up:

• The firmware cannot detect charging if the ADC is not wired.
• The charging circuit is fully autonomous, the software doesn’t control it.
• If the USB power source expects a strict PD negotiation, it won’t work.

This behavior may vary across PCB revisions.

73'

Armel, F4HWN

[armel]

So that means there's some hardware revision that has the ADC wired properly? It's another radio (e.g., another radio, such as what they call UV-K6) or it's the same UV-K5 but just a different board?

I haven’t specifically looked into the ADC wiring, mainly because, as I’ve already mentioned, the USB-C port is intended solely for emergency charging. That said, I can confirm that there are several revisions of the K5 PCB. The revision number is printed directly on the board — for example, I have two K5 PCBs in front of me: one marked R51-V1.4, and the other R51-V1.6.

Not sure it's the same info I got in my radio manual. I'll have to check. But anyway, if it's not intended to charge, what would be the proper way to charge, considering most units won't come with a dock? Mine, for example, came just with a USB-C cable.

I confirm what @lohtse stated and have nothing further to add on this matter.

Considering the above, wouldn't be better to strip all the gChargingWithTypeC and related code (e.g. BITMAP_USB_C, global variables, code that checks for USB status, etc) and saving some very precious flash storage?

You’ve probably noticed that the compilation directive ENABLE_FEAT_F4HWN_CHARGING_C is set to 0 by default. As a result, BITMAP_USB_C is not used anywhere in the firmware code. The compiler is smart enough to handle that kind of optimization on its own. So the compiler will simply ignore it, whether it’s declared or not.

73'

Armel, F4HWN

[sergeibit]

So that means there's some hardware revision that has the ADC wired properly? It's another radio (e.g., another radio, such as what they call UV-K6) or it's the same UV-K5 but just a different board?

I haven’t specifically looked into the ADC wiring, mainly because, as I’ve already mentioned, the USB-C port is intended solely for emergency charging. That said, I can confirm that there are several revisions of the K5 PCB. The revision number is printed directly on the board — for example, I have two K5 PCBs in front of me: one marked R51-V1.4, and the other R51-V1.6.

Does the ADC detects when it's charging in any of these revisions?

Look, I'm not asking YOU to work on anything. I'm just searching for help by looking for a hardware revision that will detect when it's working and I'll adapt the code by myself to solve a specific problem I know I'm the only one in the world that have it.

Thanks

[armel]

Does the ADC detects when it's charging in any of these revisions?

As I already mentioned, I haven’t specifically checked the ADC wiring. I can only confirm that there are several PCB revisions.
Why not ask Quansheng directly about the ADC wiring? That would probably be the most reliable way to get an accurate answer.
As it stands, the recommended way to properly charge the K5 is by using the charging cradle — which you apparently don’t have. An alternative would be to get a battery with a built-in USB-C charging port (as found on the newer TK11 models). I sometimes use this type of battery and it works like a charm.

Armel, F4HWN

[sergeibit]

As I already mentioned, I haven’t specifically checked the ADC wiring. I can only confirm that there are several PCB revisions. Why not ask Quansheng directly about the ADC wiring? That would probably be the most reliable way to get an accurate answer.
As it stands, the recommended way to properly charge the K5 is by using the charging cradle — which you apparently don’t have. An alternative would be to get a battery with a built-in USB-C charging port (as found on the newer TK11 models). I sometimes use this type of battery and it works like a charm.

That's not the point. I was asking if in any of your radios the ADC work by reacting to the USB connection on the firmware side.
For a fw dev, I don't think it was supposed to be a very difficult task. In the end, the energy wasted in this talk is greater than plugging a USB cable and saying "no, it won't detect in any of the radios".

But ok, I got the message. I was just looking for some help but I understand is better to reach Quansheng or look somewhere else.

Thanks again! 👋

[armel]

That's not the point. I was asking if in any of your radios the ADC work by reacting to the USB connection on the firmware side.
For a fw dev, I don't think it was supposed to be a very difficult task. In the end, the energy wasted in this talk is greater than plugging a USB cable and saying "no, it won't detect in any of the radios".

Seriously ? I have provided you with all the information I have. And sorry if that USB-C charging doesn't work the way you wanted it to.

The USB-C port on the K5 is intended exclusively for emergency charging, regardless of the model.

Furthermore, this port does not implement the USB Power Delivery (PD) standard.
This means the behavior can vary depending on the USB source used, and not only based on the K5 version.

I can't be more specific.

By the way, there are many variants of the K5 (UV-K5, UV-5R, UV-K5(8), UV-K5(99), en the last UV-K5(9)), with several revisions of the PCB. I can't cover everything, and I'm sorry if my answers don't meet your expectations.

But I'm not obligated to anyone, I don't sell anything, I just share my work and I believe I've helped as much as I can.

In summary, do like everyone else, having read the documentation : don't expect anything from this connector. It's there for emergency use, period.

I'm closing this discussion.

73'

Armel, F4HWN