drivers: Add Quansheng UV-K1 / UV-K5 V3 F4HWN Fusion driver

[macikm]

This pull request introduces a new driver (chirp/drivers/uvk5_f4hwn.py) to support the custom F4HWN Fusion firmware on the Quansheng UV-K1 and UV-K5 V3 radios.

The driver has been cleaned up and formatted according to PEP8 guidelines using autopep8 to ensure it passes CHIRP linting checks. Unused variables and syntax issues have been resolved. The driver class is registered as UVK5RadioF4HWN under the vendor Quansheng and model UV-K1 & UV-K5 V3 (F4HWN Fusion).

Improvements

• Dynamic Scanlist Names: Added dynamic resolution of scanlist names. Instead of displaying static strings like List [1] to List [24] in the memory grid, the driver now reads the user-defined names directly from the radio settings structure, displaying the actual custom names (e.g., PMR, AIR) when set.

Credits & Acknowledgement

This driver is based on the hard work and adaptations of the following authors in the community:

• Jacek Lipkowski (sq5bpf@lipkowski.org): Creator of the original Quansheng UV-K5 driver.
• EGZUMER and JOC2: Adapted it for the EGZUMER custom firmware.
• JOC2: Adapted it for the EGZUMER/F4HWN version.
• F4HWN (Armel): Re-adapted it specifically for the UV-K1 & UV-K5 V3 F4HWN Fusion custom firmware.

We are submitting this driver on behalf of the community to integrate standard support for the F4HWN Fusion firmware directly into CHIRP next.

[kk7ds]

Thanks, but I have NAK'd this multiple times. This needs to inherit from the base UV-K5 driver, participate in the detection scheme, and not just duplicate/reimplement everything from the base driver. Last I looked at this, it was forked from one of the earlier versions of the driver which means it committed all the same sins that had to be fixed before we could merge the base driver into the tree. Given the huge amount of silly manual data structures in this commit, the still-present duplication of things in the base driver and common code, I'm guessing that not much has changed.

[macikm]

Hi Dan,

I have refactored the driver to address your feedback. Here is a summary of the changes implemented in the latest commit:

1. Inheritance & DRY:

   • UVK5RadioF4HWN now correctly inherits from uvk5.UVK5RadioBase rather than duplicating the entire driver codebase from scratch.
   • Removed over 170 lines of duplicate low-level serial communication code (such as packet XORing, CRC-16 calculation, raw send/receive commands, and reset helpers) by importing them directly from the base uvk5 module.

2. Detection Scheme Integration:

   • Decorated the class with @directory.detected_by(uvk5.UVK5Radio) to hook it into the shared auto-detection loop.
   • Implemented k5_approve_firmware to approve and route connection requests for radios returning the F4HWN Fusion firmware signatures (e.g., strings starting with F4HWN or FUSION ).
   • Added self._check_firmware_at_load() inside process_mmap() to enforce validation and compatibility checks when loading saved .img files.

3. CI/Style & Warnings Fixes:

   • Cleaned up PEP 8 style issues (e.g., unused imports like struct and util, visual indents, and blank lines).
   • Updated the metadata of the test image Quansheng_UV-K1_&_UV-K5_V3_F4HWN_Fusion.img to include the uvk5_firmware signature, resolving the test warning that was causing test_detect to fail on CI.

All GHA checks and unit/driver tests are now passing successfully. Please let me know if any further adjustments are needed. Thank you!

[kk7ds]

You may not import webbrowser or wx, nor try to manipulate the GUI in any way from the driver.

[macikm]

is now everything OK?