Bug #10406
closedUV-5R FM freq
Added by Kirk Beasley over 1 year ago. Updated over 1 year ago.
100%
Description
On my new UV-5R, the CHIRP-entered frequency for the FM radio gets uploaded to the radio, but upon using the radio afterwards doesn't work (appears as if write failed). I've diagnosed this to a big/little endian issue (byte reversal) between CHIRP and the UV-5R. CHIRP is big endian, UV-5R is little endian (for FM radio frequency anyway).
I did hex dumps of CHIRP img files to compare the memory contents for values stored by CHIRP (for upload) versus contents for values stored by the UV-5R (via download). Attached is a cut-n-paste of hex dump data of img files for two test cases I did.
This issue appears in other bug reports, including 2299, 2765, and 10005.
Files
Updated by Jim Unroe over 1 year ago
Kirk Beasley wrote:
On my new UV-5R, the CHIRP-entered frequency for the FM radio gets uploaded to the radio, but upon using the radio afterwards doesn't work (appears as if write failed). I've diagnosed this to a big/little endian issue (byte reversal) between CHIRP and the UV-5R. CHIRP is big endian, UV-5R is little endian (for FM radio frequency anyway).
I did hex dumps of CHIRP img files to compare the memory contents for values stored by CHIRP (for upload) versus contents for values stored by the UV-5R (via download). Attached is a cut-n-paste of hex dump data of img files for two test cases I did.
This issue appears in other bug reports, including 2299, 2765, and 10005.
It appears that chip shortages have caused Baofeng to change chips for the broadcast FM chip (and in some cases leave it out, altogether). The new chip requires that CHIRP must understand and recognize a 3rd method of how the frequency could be stored in these radios. This has already been updated on some drivers but has not been done to this one yet.
Please test the attached experimental driver to see if it addresses the storage format as it has for the other that it as already been implemented in.
- Save experimental driver
- In Help menu enable Developer Functions
- Re-start CHIRP
- In File menu select Load Module
- Locate an load the driver saved in step 1
Now you can test the with your radio.
Note: Loading an external driver module does not permanently change your CHIRP installation. Once you close CHIRP, the next time CHIRP is opened you will have to load the driver again to have access to its added features or bug fixes again.
Let me know how it works.
Jim KC9HI
Updated by Kirk Beasley over 1 year ago
I get the following error when attempting to load the driver:
From the debug log:
[2023-03-01 07:58:07,669] chirp.wxui.main - INFO: Loading module C:\Users\Kirk\Downloads\uv5r_fm_preset_add_3rd_method.py
[2023-03-01 07:58:07,684] chirp.wxui.common - ERROR:
Traceback (most recent call last):
File "chirp\wxui\common.py", line 452, in run_safe
File "chirp\wxui\main.py", line 1250, in load_module
File "C:\Users\Kirk\Downloads\uv5r_fm_preset_add_3rd_method.py", line 714, in
UV5R_DTCS = tuple(sorted(chirp_common.DTCS_CODES + (645,)))
TypeError: can only concatenate list (not "tuple") to list
Updated by Jim Unroe over 1 year ago
Kirk Beasley wrote in #note-2:
I get the following error when attempting to load the driver:
can only concatenate list (not "tuple") to list From the debug log:
[2023-03-01 07:58:07,669] chirp.wxui.main - INFO: Loading module C:\Users\Kirk\Downloads\uv5r_fm_preset_add_3rd_method.py
[2023-03-01 07:58:07,684] chirp.wxui.common - ERROR:raised unexpected exception
Traceback (most recent call last):
File "chirp\wxui\common.py", line 452, in run_safe
File "chirp\wxui\main.py", line 1250, in load_module
File "C:\Users\Kirk\Downloads\uv5r_fm_preset_add_3rd_method.py", line 714, in
UV5R_DTCS = tuple(sorted(chirp_common.DTCS_CODES + (645,)))
TypeError: can only concatenate list (not "tuple") to list
Attach the full debug.log file and and a few CHIRP image files with the only difference being the FM frequencies selected. I will try to look at this later today.
Jim
Updated by Kirk Beasley over 1 year ago
- File chirp_debug FM_presets TC1.txt chirp_debug FM_presets TC1.txt added
- File chirp_debug FM_presets TC2.txt chirp_debug FM_presets TC2.txt added
- File chirp_debug FM_presets TC3.txt chirp_debug FM_presets TC3.txt added
- File FM_presets TC1.img FM_presets TC1.img added
- File FM_presets TC2.img FM_presets TC2.img added
Disregard my prior reporting of a Python error. I closed duplicate apps, downloaded latest CHIRP, and your experimental driver loads fine. Cockpit error on my part.
Your driver solves half the problem - recognizing and converting FM_preset from little-endian to big-endian so CHIRP properly displays the FM freq set by the keypad on current generation UV-5R radios. Your experimental driver does this both for UV-5R downloads, and for CHIRP opening a stored img files.
The second half of the problem is converting FM_preset from big-endian back to little-endian before uploading back to the radio. Currently, the experimental driver doesn't do this so any changes to FM_preset made in CHIRP won't get properly uploaded and displayed on the radio. Perhaps if a flag gets set upon detecting the little-endian format during download/open that flag could be tested before uploading so a byte swap could be done then?
Here are my test cases:
Test Case 1: Verify Interpretation of FM_preset from CHIRP UV-5R download
1 Open CHIRP in developer mode, set fm_presets to 101.1 in radio, download - Note, CHIRP displays 76.0
2 Load revised driver, re-download, - Note, CHIRP now correctly displays 101.1
3 Save image "FM_presets TC1.img"
4 Save debug log "chirp_debug FM_presets TC1.txt"
5 Exit CHIRP
Test Case 2: Verification CHIRP can properly write FM_preset during upload to UV-5R
1 Open CHIRP in developer mode, set fm_presets to 88.1 in CHIRP, upload - Note, radio incorrectly displays 65.0
2 Load revised driver, upload, - Note, radio still incorrectly displays 65.0
3 Save image "FM_presets TC2.img"
4 Save debug log "chirp_debug FM_presets TC2.txt"
5 Exit CHIRP
Test Case 3: Verify CHIRP can properly reload FM_presets from an image
1 Open CHIRP in developer mode
2 Load image "FM_presets TC1.img" - Note, CHIRP displays 76.0 for FM_presets
3 Load image "FM_presets TC2.img" - Note, CHIRP displays 88.1 for FM_presets
4 Load revised driver
5 Load image "FM_presets TC1.img" - Note, CHIRP displays 101.1 for FM_presets <- experimental driver fixed
6 Load image "FM_presets TC2.img" - Note, CHIRP displays 88.1 for FM_presets
7 Save debug log "chirp_debug FM_presets TC3.txt"
8 Exit CHIRP
Updated by Jim Unroe over 1 year ago
Kirk, I don't need any test cases. Without any extra drivers running I simply want you to...
- set FM in the radio to 101.1
- download to CHIRP
- save to file Baofeng_UV-5R_20230301_FM1011.img
- set FM in the radio to 88.1
- download to CHIRP
- save to file Baofeng_UV-5R_20230301_FM881.img
- attach both files to this issue
Updated by Kirk Beasley over 1 year ago
- File Baofeng_UV-5R_20230301_FM881.img Baofeng_UV-5R_20230301_FM881.img added
- File Baofeng_UV-5R_20230301_FM1011.img Baofeng_UV-5R_20230301_FM1011.img added
Attached
Updated by Jim Unroe over 1 year ago
Updated by Jim Unroe over 1 year ago
Kirk Beasley wrote in #note-4:
The second half of the problem is converting FM_preset from big-endian back to little-endian before uploading back to the radio.
Haha. Yes. I should have read this more closely earlier. I left out half of the fix. Standby.
Updated by Jim Unroe over 1 year ago
Here is the full fix. Thanks to the "image" files that you provided, I was able to test it here. I will add the module to this issue so you can test it today, but as soon as I post this I will try work up a formal patch and put push this up to be in tomorrow's build. Thanks your you help with this.
Jim KC9HI
Updated by Jim Unroe over 1 year ago
- Status changed from New to In Progress
- Assignee set to Jim Unroe
- Target version set to chirp-py3
Updated by Jim Unroe over 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
The patch has been submitted. Support will be in the next CHIRP-next build following acceptance (hopefully tomorrow).
Jim KC9HI
Updated by Kirk Beasley over 1 year ago
Your fix is working just fine - Thanks!
Kirk (retired SW engineer)