Bug #10679
closedRuyage UV58Plus - Radtel Rt 980 - iradio UV-5118plus OEM Software read error after write with CHIRP-NEXT
100%
Description
Hi,
In the OEM UV5118 Plus Radio Program Windows Software, it will throw "Error" after "Completed!" read, will not display a correct read of at least the channels written before in chirp-next. Also the Radio will show chinese Symbols and artifacts which where not part of the Channel name when written by chirp-next. Artifacts are confirmed by other users of chirp-next (Telegram group: "RT-890"). Uploading the stock config with chirp-next solves these errors, but it is reproducable with the config attached.
INFO: The config includes 27.xxx frequencies, which are discarded when loading. The radio itself is capable of receiving these frequencies, Worldwide band: 18 MHz ~ 620 MHz, 840 MHz ~ 1200 MHz (BEKEN "BK4819" http://www.bekencorp.com/en/goods/detail/cid/50.html )
Can you please look into this? I am very curious what happens here.
Files
| error_Ruyage_UV58Plus_20230627.img (44.3 KB) error_Ruyage_UV58Plus_20230627.img | |||
| PXL_20230627_125754450.MP.jpg (92.2 KB) PXL_20230627_125754450.MP.jpg | Artifacts | ||
| iradio_uv_5118plus-space_padded_names.py (37.2 KB) iradio_uv_5118plus-space_padded_names.py | Test driver module with 0x20 padding | ||
| error_Ruyage_UV58Plus_20230627-fixed.img (44.3 KB) error_Ruyage_UV58Plus_20230627-fixed.img | Original .img with padding converted to 0x20 (spaces) |
Updated by Jascubek Tiriallala 10 months ago
INFO: The config includes 27.xxx frequencies, which are discarded when loading. The radio itself is capable of receiving these frequencies, Worldwide band: 18 MHz ~ 620 MHz, 840 MHz ~ 1200 MHz (BEKEN "BK4819" http://www.bekencorp.com/en/goods/detail/cid/50.html )
Same chip like the, UV-K5 (modified firmware) nolimits, from https://chirp.danplanet.com/issues/10478
Updated by Jascubek Tiriallala 10 months ago
Another side note please: "Tail Tone" in the settings is actually "Tail Tone Elimination", it is also mislabeled and misleading in the OEM Software.
Updated by Jim Unroe 10 months ago
- File iradio_uv_5118plus-space_padded_names.py iradio_uv_5118plus-space_padded_names.py added
- File error_Ruyage_UV58Plus_20230627-fixed.img error_Ruyage_UV58Plus_20230627-fixed.img added
The problem was that CHIRP is padding the channel names with 0xFF out to the full length (like it is done most other radios). What the OEM software and the radio expects is 0x20 (the space character) padding of the channel names.
The OEM software generates and error when an 0xFF is encountered in any channel name. The radio will sometimes display artifacts when an 0xFF is encountered in a channel name.
The attached test driver module updates the support for names to use spaces for padding. My testing shows that all is working properly now but before I submit the changes to be included in CHIRP, I would like testing and feedback from others.
How to use test driver module: LoadingTestModules
The easiest/quickest way to "fix" (convert the 0xFF padding to 0x20 padding) existing images is to...
- load image into CHIRP (while running the test driver module)
- click any memory row to highlight a single memory row
- type Ctrl+A (or click Edit -> Select All) to highlight all of the memory rows
- type Ctrl+C (or click Edit -> Copy) to copy the highlighted memory rows into the clipboard
- click the top memory row to highlight only the top memory row
- type Ctrl+V (or click Edit -> Paste) to paste the memories in the clipboard back into CHIRP
Jim KC9HI
Updated by Jascubek Tiriallala 10 months ago
others
That solution is on point. Radio bricked. No, I mean, Radio Software works now, followed your fix. NOTE: Reopening the desired image after importing the module (in chirp-next: help->load module from issue->10679) is important.
Thank you for tracking it down, solving, and explaining so fast :)
Now I can go ahead and export the *.updat file from the OEM Program, to hex-edit some channels, to be in the 14 mHz to 1310 mHz range (brilliant documentation from someone who did it with CB frequencies https://www.youtube.com/watch?v=lRClHpwNGuo ). Rumor is, even the unlisted 757 to 840 mHz work fine on the BEKEN chip. Very exciting radio.
If chirp-next could support such test frequencies (analog to the UV-K5 solution) that would be absolute amazing. Unfortunately I don't know any magic behind the UI. Would that be possible technically? Like a "dev" mode, including the same UV-K5 "brick risk" disclaimer.
Thank you for working the magic, Jim!
Updated by Jim Unroe 10 months ago
- Status changed from New to Resolved
- Assignee set to Jim Unroe
- Target version set to chirp-py3
- % Done changed from 0 to 100
Jascubek Tiriallala wrote in #note-6:
others
That solution is on point. Radio bricked. No, I mean, Radio Software works now, followed your fix. NOTE: Reopening the desired image after importing the module (in chirp-next: help->load module from issue->10679) is important.
Thank you for tracking it down, solving, and explaining so fast :)
Now I can go ahead and export the *.updat file from the OEM Program, to hex-edit some channels, to be in the 14 mHz to 1310 mHz range (brilliant documentation from someone who did it with CB frequencies https://www.youtube.com/watch?v=lRClHpwNGuo ). Rumor is, even the unlisted 757 to 840 mHz work fine on the BEKEN chip. Very exciting radio.
If chirp-next could support such test frequencies (analog to the UV-K5 solution) that would be absolute amazing. Unfortunately I don't know any magic behind the UI. Would that be possible technically? Like a "dev" mode, including the same UV-K5 "brick risk" disclaimer.
Thank you for working the magic, Jim!
Support for the correct name padding will be in the next CHIRP-next build.
Jim KC9HI