CHIRP

This is an issue with the radio. Not CHIRP. I worked with another UV-5R within the past week or so that does not accept or store any settings in what is called the Aux memory area. This would include the band limits, squelch thresholds and other setting that typically show up in the "Other Settings" tab. You radio most likely does not include the broadcast FM radio feature, either.

Jim KC9HI

Thank you for such a quick answer, the problem appeared for me as well as for other users after, when the first download of the image from the radio, when the settings tab was working, I made a change to the frequency band, and an error appeared during the upload to the radio (those with firmware mismatch). Afterwards I could no longer access settings. When uploading, I can only upload channels with changes.

Attach a freshly download CHIRP Radio Images (*.img) file and a debug.log file. How_To_Report_Issues

I'm having the same issue, so I'll add my experience here, in case it's of any help.

First, I have two UV-5Rs. The first one I've got shows BFB297 when turned on with the 3 key pressed. This one is working perfectly with Chirp, I can access the Settings and I used the Other settings section to disable TX completely.

I recently got a new one. This one shows BFB298 when turned on with the 3 key pressed. I downloaded and saved an image from the radio, I was able to access Settings and Other settings, all fine. I disabled TX and uploaded to the radio. It immediately failed with the "firmware version does not match ..." message, like in Liviu's screenshot above. After that, downloading the image from the radio gives the 'NoneType' object is not iterable message when accessing the Settings. So not only the settings were not saved to the radio, but the existing section is not available for download anymore.

Next, I tried the following steps:

1. I made a copy of the original image and hex-edited it and changed 6 bytes at address 0x1840 from FF to 00.
2. Uploaded this image to the radio.

Uploaded completed with no errors, and then I was able to download from radio again and be able to access Settings section again.

I then tried to:

1. Disable TX in Settings > Other settings
2. Save the modified image
3. Hex-edit and fix the image by replacing FF with 00 (6 bytes) at address 0x1840
4. Upload image to the radio

Again, upload works with no errors, I can get the image back from the radio and access Settings correctly, and it shows the disabled TX options. However, the radio still transmits, like those settings are not used at all!

Other interesting facts:

1. Once you fix an image and upload it, when downloaded again the new image seems to retain the settings section, however, those 6 bytes are FF again.
2. Once you "break" the radio by trying to upload an "unfixed" image and get the "firmware version does not match ...", when you download from radio again the entire "settings" section in the resulting file is FF.
3. This new radio has wider range, like you can set frequency to 130.000 (on the other one I can only set >= 136.000). Strange part is that the original image does show VHF Lower Limit (MHz) = 136! So it simply looks like the radio completely ignores the settings.

To be honest, I think the radio is at fault here, but if anyone has a different idea, I would like to hear it.

@Liviu: Can you check what range your radio has? Can you power on your radio while pressing the 3 key and see what version you have?

Bogdan N. wrote in #note-5:

I'm having the same issue, so I'll add my experience here, in case it's of any help.

First, I have two UV-5Rs. The first one I've got shows BFB297 when turned on with the 3 key pressed. This one is working perfectly with Chirp, I can access the Settings and I used the Other settings section to disable TX completely.

I recently got a new one. This one shows BFB298 when turned on with the 3 key pressed. I downloaded and saved an image from the radio, I was able to access Settings and Other settings, all fine. I disabled TX and uploaded to the radio. It immediately failed with the "firmware version does not match ..." message, like in Liviu's screenshot above. After that, downloading the image from the radio gives the 'NoneType' object is not iterable message when accessing the Settings. So not only the settings were not saved to the radio, but the existing section is not available for download anymore.

Next, I tried the following steps:

1. I made a copy of the original image and hex-edited it and changed 6 bytes at address 0x1840 from FF to 00.
2. Uploaded this image to the radio.

Uploaded completed with no errors, and then I was able to download from radio again and be able to access Settings section again.

I then tried to:

1. Disable TX in Settings > Other settings
2. Save the modified image
3. Hex-edit and fix the image by replacing FF with 00 (6 bytes) at address 0x1840
4. Upload image to the radio

Again, upload works with no errors, I can get the image back from the radio and access Settings correctly, and it shows the disabled TX options. However, the radio still transmits, like those settings are not used at all!

Other interesting facts:

1. Once you fix an image and upload it, when downloaded again the new image seems to retain the settings section, however, those 6 bytes are FF again.
2. Once you "break" the radio by trying to upload an "unfixed" image and get the "firmware version does not match ...", when you download from radio again the entire "settings" section in the resulting file is FF.
3. This new radio has wider range, like you can set frequency to 130.000 (on the other one I can only set >= 136.000). Strange part is that the original image does show VHF Lower Limit (MHz) = 136! So it simply looks like the radio completely ignores the settings.

To be honest, I think the radio is at fault here, but if anyone has a different idea, I would like to hear it.

@Liviu: Can you check what range your radio has? Can you power on your radio while pressing the 3 key and see what version you have?

These radios do not accept changes to the Aux memory area. So all values that CHIRP expects to see for settings in this area (welcome message, band limits, etc) are invalid (which causes the Settings tabs to not display). Nothing can be done to fix these values because the radio rejects any changes to them. This is a problem with the radio.

The best that CHIRP can possibly do would be to completely disable the Other Settings menu and ignore all settings that are typically stored in the Aux memory area if the Aux memory area is detected as being populated with all 0xFF values.

Jim KC9HI

Thanks for getting back! That's what I thought as well.

It's strange though that the initial download from the radio does have the section correctly filled in, and Chirp was initially able to read the Aux memory area and decode it.
Even stranger, if I upload an edited image that has the 6 bytes set to 0, the aux memory area seems "fixed", retains some data and can be correctly read again.

I've done some more tests and it looks like:

1. 6+Power-On Message 1 and 6+Power-On Message 2 are not written to the radio, nor used (the radio shows "210223M", although the area where that should go is all FF)
2. Power-On Message 1 and Power-On Message 2 are both written to the radio and used correctly!
3. VHF Lower Limit (MHz), VHF Upper Limit (MHz), UHF Lower Limit (MHz) and UHF Upper Limit (MHz) are all written to the radio but NOT used
4. VHF TX Enabled and UHF TX Enabled are both written to the radio but NOT used

In addition, the original image has data starting at 0x1488 up to 0x18A7, but when uploaded back and read again the same area shows FF only.

Hi, Bogdan, the situation with my radio stations is very similar to yours. The first purchased, which works perfectly with chirp, shows BFB297 when starting with key three pressed, the second, bought later, shows BFB298. Second, the problem seemed like yours when I changed the frequency from 136 to 135 MHZ (I wanted to see if it was possible to widen the band) and I tried to upload the image to the radio. Later I found that mine also has the lower limit of the VHF is set to 130 MHZ, without being able to change it. And your other observations related to saving the settings are like mine. Otherwise radio can be used, it works OK. If you are from Romania (your name suggests you are) I would like to contact you privately for other information related to HAM radio, or Baofeng uv-5r, i am a beginner to this. Thank you.

First of all, I completely fixed mine! I played with the Chirp source code and basically forced it to write everything from 0x1808 to 0x1948 in file to the radio. Now everything is working, range is limited by the settings in Other settings, TX can be disabled and so on, everything works perfectly.

What I noticed is this: in the upload function _do_upload (in uv5r.py file) the radio_version = _get_radio_firmware_version(radio) returns something like b'HN5RV011\x00\x00\x00\x00\x00\x00' for this radio.
The function basically does this:

...
block1 = _read_block(radio, 0x1EC0, 0x40, True)
block2 = _read_block(radio, 0x1F00, 0x40, False)
...

However, when the same section at 0x1EC0 is read during the download, the radio (correctly) returns FF instead of 00! I'm not sure why that's happening. The only difference from the code point of view is that in _get_radio_firmware_version the _read_block function is called with the first_command parameter set to True, while during the image download the parameter is False. I assume that's an issue in the firmware that makes it reply with a different block, strange nonetheless.

In any case, once that happens, the aux region is not written back to the radio, and for some reason the entire area from 0x1ec0 to 0x2000 is filled with FF, and the radio starts to basically disregard those settings completely and use some defaults. It's awesome it's not completely bricked, after all.

@Liviu I'm a beginner too, but feel free to contact me, I can at least help you fix your radio. Feel free to email me at brash.rasa0q @ icloud.com and we can go from there. Or if you can DM me here, that's fine too, but I don't know if that's possible.

Thanks for letting me know you have the same issues.
Is there a fix or are you just using the radio with its limitations/firmware errors?
FM works on mine.
I might rip mine down and use it in an Allstar node (I don’t like the up-down buttons for frequency change).
Cheers,
Alan

Bogdan N. wrote in #note-11:

First of all, I completely fixed mine! I played with the Chirp source code and basically forced it to write everything from 0x1808 to 0x1948 in file to the radio. Now everything is working, range is limited by the settings in Other settings, TX can be disabled and so on, everything works perfectly.

Hi Bogdan,
Could you please help me and advise step by step what I have to do with my img file?
Have exactly same issue, loaded your img (with 0) and finally it was loaded with no error, however it turned out some seetings even loaded have no impact on the functionality. Need your guidance how to write all the settings to receiver please...

Regards
Mario

The image alone is not enough after all. I made some changes to Chirp and I was able to fix my radio using the modified version. Feel free to contact me via email and I'll try to give you more directions: brash.rasa0q @ icloud.com

Bogdan N. wrote in #note-14:

Feel free to contact me via email and I'll try to give you more directions: brash.rasa0q @ icloud.com
Just sent you the email - any help much appreciated.

regards
Mario

I replied to Alan, Mario and Liviu, if you don't see my email please check your spam folder as well. Thanks!

Bogdan N. wrote in #note-16:

I replied to Alan, Mario and Liviu, if you don't see my email please check your spam folder as well. Thanks!

Thanks Bogdan. I did think you are polish so wrote the email in PL directly. I am sorry for confusing you, thank you so much for your instruction, will test tomorrow following all steps.
Kind regards
Mario

Thanks Bogdan - all received and working. Alan

Bogdan N. wrote in #note-11:

However, when the same section at 0x1EC0 is read during the download, the radio (correctly) returns FF instead of 00! I'm not sure why that's happening. The only difference from the code point of view is that in _get_radio_firmware_version the _read_block function is called with the first_command parameter set to True, while during the image download the parameter is False. I assume that's an issue in the firmware that makes it reply with a different block, strange nonetheless.

The section of the code reads 2 blocks of data. The first block read requires that CHIRP supplies and ACK (True), the second block must not have an ACK (False).

CHIRP reads the firmware version of the radio to compare it with the firmware version of the currently selected tab. This is because there are different Aux memory layouts in these radios. If you upload an image into a different radio than it was downloaded from, you run the risk of uploading an incompatible Aux memory layout that will cause undesired behavior (squelch won't open, radio won't scan, etc). So if the firmware versions don't exactly match, only small part of the Aux memory is uploaded.

Because of this, you should never directly upload an image from one radio into another radio even if the firmware versions are exactly the same. You should load a saved image from the source radio (or download from the source radio). Next you should download from the target radio to create a compatible tab. Copy-and-paste the channels from the source radio tab to the target radio tab. Finally upload the target radio tab back into the target radio. This completely prevents corruption of the Aux memory area (along with its undesired behavior) by overwriting it with incompatible data from another radio.

In any case, once that happens, the aux region is not written back to the radio, and for some reason the entire area from 0x1ec0 to 0x2000 is filled with FF, and the radio starts to basically disregard those settings completely and use some defaults. It's awesome it's not completely bricked, after all.

What you are saying is not entirely true. When the firmware versions don't exactly match, the part of Aux memory containing the [6] key + Power-On message and the Power-On message is uploaded because, so far, their location in Aux memory has remained the same across all models for 11 years. Everything else after that is skipped to prevent overwriting the Aux memory with incompatible data.

I just bought a pair of cheap radios (UV-5R and UV-5R5). Maybe I will get luck (or unlucky) and at least one of them would behave as yours does. But so far all of my test has worked exactly as expected.

Jim KC9HI

What you are saying is not entirely true. When the firmware versions don't exactly match, the part of Aux memory containing the [6] key + Power-On message and the Power-On message is uploaded because, so far, their location in Aux memory has remained the same across all models for 11 years. Everything else after that is skipped to prevent overwriting the Aux memory with incompatible data.

I understand what you're saying, and indeed when the versions don't match the range_aux is set to:

_ranges_aux_default = [
(0x1EC0, 0x1EF0),
]

And it then attempts to write the range between 0x1EC0 and 0x1EF0 only.

Problem is this firmware is faulty, or let's say different, and what happens is that as soon as you try to write to 0x1ED0, it fills everything between 0x1F00 up to 0x1FC0 with FF! I tested this with a small script that just writes something at that address (tested with writing both 0xFFs and 0x65s, no difference). Also, if you attempt to write at 0x1EE0 (even without writing at 0x1ED0 first), it also writes FFs at 0x1FC0!
As expected, if you set ranges_aux = _ranges_aux_default + _ranges_aux_extra, it actually works a lot better, because first the areas mentioned above are filled with FFs but then the relevant sections for frequency limits and TX enabled / disabled (other settings in general) are actually populated correctly.

I know this seems like an unique issue with my radio, but three other guys reported the same problem and two of them confirmed that writing back the entire original image fixed their radios. I'm waiting for confirmation from the 3rd. My hunch is that this is probably a newer, cheaper iteration of the UV-5R, and more and more of these will start appearing on the market, and more people will experience this issue. As for myself, I'm happy that I got to the bottom of this, I have a version of Chirp that works with my "faulty" radio, and I've learned a lot.

Also, the latest version of Chirp doesn't work with any of my UV-5Rs, not the BFB297, nor the BFB298, it gets stuck at downloading the image. Changing HARDWARE_FLOW = True back to HARDWARE_FLOW = False in chirp_common.py seems to fix it.

Cheers!

Bogdan N. wrote in #note-21:

My hunch is that this is probably a newer, cheaper iteration of the UV-5R, and more and more of these will start appearing on the market,

I am one of the guys Bogdan mentioned above - I ordered this radio a month ago so this is really new one and I don't think it is original one (all of them manufactured in China, but there are various clones of chinese UV5R) if the total price was below 15€.

Agree with Bogdan this issue will start to appear on more devices as soon as more people have new one with BFB298

Regards
Mario

Thanks to Bogdan, the solution proposed by him solved the problem with my radio for now. I hope the Chirp developers solve the problem, also with the latest version that doesn't work on any of my 2 radios.

Regards,
Liviu B.

I’m having the same issue.
I’m in the same situation as Liviu's screenshot above.
My radio shows BFB298 when I turned on with pressing the 3 key.
How can I fix this issue?

aki waki wrote in #note-24:

I’m having the same issue.
I’m in the same situation as Liviu's screenshot above.
My radio shows BFB298 when I turned on with pressing the 3 key.
How can I fix this issue?

I published a tool that might help you here: https://github.com/bogde/uv5rtool
Or you can contact me via email for more details, the email address you can use is in one of my messages above (https://chirp.danplanet.com/issues/10505#note-11)

Bogdan helped me with his modified chirp first and that worked.
Now i can confirm that his uv5rtool works too.
I tried linux version.

Bogdan N. wrote in #note-25:

aki waki wrote in #note-24:

I’m having the same issue.
I’m in the same situation as Liviu's screenshot above.
My radio shows BFB298 when I turned on with pressing the 3 key.
How can I fix this issue?

I published a tool that might help you here: https://github.com/bogde/uv5rtool
Or you can contact me via email for more details, the email address you can use is in one of my messages above (https://chirp.danplanet.com/issues/10505#note-11)

Bogdan thanks for the great tool!
You have solved my radio issue.
I tried windows version.

thanks for the feedback guys! all the best!

Hi there. I have read this thread thoroughly but with some trepidation, because I also posess two UV-5R radios bought here in Poland from the official dealer in Gdynia. Firmware version reads as follows: [3SAVE]+Power ON: "Ver.BFB298";
[6ABR]+Power ON: "210223M"; CHIRP: HN5RV01 (not HN5RV011, no double "1"s). I have reprogrammed them many times there and back, including changes of band limits etc, and both of them present no issues whatsoever, particularly none similar to descripted here in the thread. However I used CHIRP-legacy, because... sad but true... CHIRP-next seems to have some features present in the GUI not really working. For example Busy Channel Lock per channel in channel properties, if checked, not only does not make any change to the radio, but is not even remembered by the software after confirming and closing channel properties window. Reopening the properties window presents BCL again unchecked. This is why I have reverted to CHIRP-legacy. Consider my opinion: it may be that not Your radios are "guilty".

Indeed, some BFB298 work as expected. I recently got a new one (third UV-5R, 2nd BFB298), which works perfectly with Chirp, the most recent version. The one that doesn't work correctly has a S/N that starts with 23U4013, while the one that works has a S/N starting with UV5R665. So it was probably a bad batch or the firmware was fixed in the mean time.

Cheers!

Hi Bogdan,
I don't like to deviate from the main subject of this thread, but: does Your 23U4013 unit have an annotation "UE" on the back sticker up from the s/n? Further: do Your units have black plastic backs under the battery, or silver metallic ones? And back to CHIRP-related issues: I'd also love if You'd check/inform if the aforementioned Busy Channel Lock setting works correctly in Your units using current CHIRP-next?

I have experienced the issue described here:

I initially used Chirp (next 20230514) downloaded config from radio and I could see the settings tab. I modified the WELCOME message and upload config. The upload throw the version mismatch error. After that, when downloading the config to Chirp the settings were not available, apparently because some settings (VHF, UHF lower/upper limits) are out of range, although the welcome message was updated successfully.

S/N 2023A18915

BFB298

210223M

I can confirm that using https://github.com/bogde/uv5rtool solved the problem.

Thanks.

I just read your Bug #10578 description and tried to replicate your issue, but I couldn't. BCL stays checked or unchecked, as expected. Again, this was done on the BFB297.

Wito Krasnal wrote in #note-36:

Bogdan N. wrote in #note-33:

@Wito I'm uploading a picture of the back of the radio. I'm not seeing any UE marking, but check for yourself. That CH marking above the Li-Ion symbol is something that I scribbled to make sure I know which radio was sourced from Aliexpress and which one was bought locally.

thanks Bogdan
again to clarify: this one on Your photo is the one which works with CHIRP - or not? BFB297 or 298?
by the "UE mark" I mean as on my photo:

It is the recent model that identifies itself in the Power-on + [3] key message as BFB298 (the original BFB298 radios of a decade ago were VHF/220 radios and do not have this problem). The test driver module that I added to this issue last night should prevent the problem from occurring.

Jim KC9HI

Larry Kahhan wrote in #note-38:

The bug workaround python script didn't fix it for me. I did a reset on the radio before starting, and then loaded the python script per directions. I then loaded up my known good UV-5R file for my other (working) radio, uploaded it to the radio, and everything looked fine until it reached the end. Then I got an error window popup with the following:

Error communicating with radio

This is NOT an error.
Upoad finished. The 'Aux block' (which contains the 'Other Settings' and Service Settings'
was skipped because testing has determined that uploading it to this radio is not safe.

Debug log file attached.

It sounds like it did everything that was expected. It is just an informational message. It is to let you know that since your radio has the bug, uploading the Aux block setting has to be skipped.

The only unknown thing that needed to be tested would be to downloaded from your radio after the upload to make sure that the settings tabs still display.

Jim KC9HI

For those that have a radio with the BFB298 upload bug, if you saved your first successful download as a backup before making any changes and uploading them to your radio, you can restore your radio by the following method.

1. Start CHIRP
2. Load your previously saved "backup"/"good" image file into CHIRP
3. Click Settings -> Advanced Settings
4. Click in the field for the bottom Range Override Parameter setting
5. Type CTRL + A to highlight the whole field
6. Type the Delete key to empty the field
7. Manually type in UseAtOwnRisk (do not copy-and-paste from your browser)
8. Upload to your radio

You can use this same procedure to upload the Other Settings and Service Settings tabs to your radio.

DO NOT use this setting to upload images from another radio into your radio. This can result in unwanted side affects. The only save way it to open separate tabs from you source and target radios and then copy-and-paste between them.

I followed your UseAtOwnRisk directions, and uploaded my known good file to the BFB298 radio. The was an "Error Communicating with Radio" message, and something telling me it wasn't an error. I then restarted Chirp and downloaded the contents of my radio, and was finally able to see a proper Settings tab (not blank).

If I then try to upload my known good file to the radio again, and downlaod from the radio to verify, the Settings tab is blank. But if I again do the UseAtOwnRisk suggestion and upload my file to the radio. I can again download from the radio and see the contents of the Settings tab.

So, it looks like, for now, I can get it somewhat working, other than the "Error communicating with Radio" message, by always entering UseAtOwnRisk every time I want to upload a new file to the radio.

Larry Kahhan wrote in #note-41:

If I then try to upload my known good file to the radio again, and downlaod from the radio to verify, the Settings tab is blank.

Right. Because your radio has a bug. You must not upload to your radio unless my test drive module loaded. So once you "fix" your radio, restart CHIRP and load the test driver module. Only then can you upload safely to your radio.

Jim KC9HI

I did load the module first... though it sometimes takes several attempts to get the module to load.

I'm not sure I'd characterize the problem as a bug in the radio, because it does work with the Baofeng UV_5R_P3 Series Program Software, and once programmed, the radio does appear to function properly. It's only Chirp that has the issue.

Larry Kahhan wrote in #note-43:

I'm not sure I'd characterize the problem as a bug in the radio, because it does work with the Baofeng UV_5R_P3 Series Program Software, and once programmed, the radio does appear to function properly. It's only Chirp that has the issue.

Right. It is because the Boafeng software doesn't access the Aux block of memory (which includes band limits and service settings). If CHIRP skips those settings, which is what my test module does, there is no issue.

And is is a radio bug because if CHIRP directly reads block 0x1EC0 or it reads 0x1EC0 after reading another block first, the data returned from the radio to CHIRP is not the same. They should be identical.

Jim KC9HI

The v2 driver module worked perfectly for me.

Using Jim's last fix

1. Able to download via CHIRP, change settings and memories, and then upload the firmware to radio without getting the mismatch error that I was getting earlier.
2. I had [previously only had experienced the missing settings issue once (had to edit the img file to fix) but this has not occurred since
3. Unfortunately, no matter what I do my PTT keeps working. I have unchecked the VHF Tx Enabled and UHF Tx Enabled flags in CHIRP. Uploaded the image to radio. Downloaded from radio and confirmed the flags are unchecked but PTT still works

The PTT is so far the only thing that seems to not work in this fix.

I have a BFB298

Thanks again Jim.

James Flanighan wrote in #note-47:

Using Jim's last fix

1. Able to download via CHIRP, change settings and memories, and then upload the firmware to radio without getting the mismatch error that I was getting earlier.
2. I had [previously only had experienced the missing settings issue once (had to edit the img file to fix) but this has not occurred since
3. Unfortunately, no matter what I do my PTT keeps working. I have unchecked the VHF Tx Enabled and UHF Tx Enabled flags in CHIRP. Uploaded the image to radio. Downloaded from radio and confirmed the flags are unchecked but PTT still works

The PTT is so far the only thing that seems to not work in this fix.

I have a BFB298

Thanks again Jim.

This "fix" just prevents your radio from garbling up the Aux memory area when uploading. If your radio has a garbled up Aux memory area, you still have to restore your radio using a known good, previously saved image following the instructions in #10505#note-40.

Jim KC9HI

Today's (20230703) CHIRP daily build has a temporary fix to prevent the Aux memory area from being garbled by the radio during the upload. It basically bypasses the uploading of the Aux memory area to any radio that reports to CHIRP that is has HN5RV011 firmware so the radio will leave it alone.

This, unfortunately, also restricts CHIRP from uploading to radios with HN5RV011 firmware that do not have this undesirable behavior. I would like to continue to investigate ways to limit this restriction to only radios that actually have this behavior. To to this, I need to have access to image files from these problematic radios so I can examine them. If you have a radio with this exhibits this problem, I would appreciated it if you would attach a copy of your CHIRP Radio Images (*.img) file to this issue.

Jim KC9HI

Dear Sirs,
please clarify: is it finally HN5RV011 or HN5RV01 ?
double "11" or single "1" ?
are those two the same, or different?
my radios display HN5RV01 (single "1") and do not exhibit the problem

Wito Krasnal wrote in #note-53:

HN5RV01 is just the 7 characters in the first line of the firmware message. HN5RV011 includes the additional "1" in the second line of the firmware message. They can be considered the same.

Jim KC9HI

ok I see now.
Then maybe this will help: my radios display firmware message "HN5RV01" (or "HN5RV011" if You please) but as I mentioned many times before, are NOT troublesome in the way described in this thread, that is: they download and upload Aux settings without issues. I have noticed that my radios display (6+power on) "210223M" on the LCD, but (please bear with me) CHIRP reads from them 6+power on message line 1 as: "151123H". The same reading is accessible through Radio Browser, sixpoweron_msg line 1, and (important) this is the only thing my radios ignore: writing anything custom into 6+power on lines 1 & 2. This content is the only one unchangeable from CHIRP in my radios. But no errors if trying to write anything there. The radios just ignore, upload and redownload changes nothing.
I have also noticed that in Liviu's image sixpoweron_msg lines 1 & 2 are empty or rather entirely padded by unknown "y" chars. Yes, it might be caused by the read error, which is just the issue discussed here, if only other Aux settings from Liviu's image were also unreadable through Radio Browser. But they are readable: limits_new VHF & UHF etc. ARE displayed through Radio Browser in Liviu's image. So an error happens somewhere between Radio Browser and Settings tab.
My idea is: might this "151123H" (or lack thereof) be Your desired "sentinel" necessary to discern "good" HN5RV01 radios from "bad" ones?

I totally agree with you. Not all radios that identify themselves as HN5RV01 have this issue. But all radio that have this issue have HN5RV01. I had to purchase a few radio at my own expense to finally have a "bad" one. So the safest thing to do is until a better way narrow down the radios that have this issue is found. That is why I stated that this is only temporary.

Thank our for your idea, unfortunately data that you want to use is not fixed in the radio. It can be edited by the user and therefore would not make a good "sentinel".

I have an idea of a way to narrow down the issue but I need to have those with this issue attach a sample of their "image" so I can verify that what I am thinking is correct.

Jim KC9HI

Jordan, if you did a download from that radio with a build in the last few days, CHIRP may have stashed a backup right after download. Check the profile directory (%APPDATA%\CHIRP\backups on windows, ~/.chirp/backups on other platforms). I just added this feature for this sort of issue recently, so if you were using an older build (or never downloaded the affected radio) then it won't help.

Jordan Mills wrote in #note-56:

I just found a UV-82 that might have this issue. Firmware is identified as HN5RV01. I'm using today's version of CHIRP-Next, so I am not sure if it is affected or if it just hit the aux block. Unfortunately I did not preserve the original download and had made some minor changes to it and uploaded. Maybe this will still be useful though.

From looking at this image, I don't think that this radio is affected by the undesirable behavior that some of these most recent "HN5RV01" radios have. If you don't mind taking a risk, install a CHIRP next from June and use it to download from your radio, upload back to your radio and then finally download from your radio again. After doing all of this, see if you opening the Other Settings tab causes any error messages to appear and report back.

https://trac.chirp.danplanet.com/chirp_next/

Jim KC9HI

Dan Smith wrote in #note-57:

Jordan, if you did a download from that radio with a build in the last few days, CHIRP may have stashed a backup right after download. Check the profile directory (%APPDATA%\CHIRP\backups on windows, ~/.chirp/backups on other platforms). I just added this feature for this sort of issue recently, so if you were using an older build (or never downloaded the affected radio) then it won't help.

Well that is good timing. I downloaded the build from today, so the backups were there. I've made copies of them for safekeeping. Quick return on investment for a new feature. Thank you!

Jim Unroe wrote in #note-58:

Jordan Mills wrote in #note-56:

I just found a UV-82 that might have this issue. Firmware is identified as HN5RV01. I'm using today's version of CHIRP-Next, so I am not sure if it is affected or if it just hit the aux block. Unfortunately I did not preserve the original download and had made some minor changes to it and uploaded. Maybe this will still be useful though.

From looking at this image, I don't think that this radio is affected by the undesirable behavior that some of these most recent "HN5RV01" radios have. If you don't mind taking a risk, install a CHIRP next from June and use it to download from your radio, upload back to your radio and then finally download from your radio again. After doing all of this, see if you opening the Other Settings tab causes any error messages to appear and report back.

https://trac.chirp.danplanet.com/chirp_next/

Jim KC9HI

I tried CHIRP-next from 15 June 2023. The options section was available on the first download with no errors and all options under "Other Settings" that were available with the working UV-82. I saved the image, uploaded it, and downloaded it again. All of the "Other Settings" options were available with no errors. I downloaded again with CHIRP-next from 5 July 2023 and had no errors but only "Firmware Message 1" and "Firmware Message 2" were shown under "Other Settings". I believe that is expected behavior, but I wanted to try it and note the results.

Next I changed some settings (power on messages) and uploaded, then downloaded again. The updated settings were retained, are reflected in radio operation, and showed in the new settings download. So that seems to have worked around the issue for me. Thank you!

It is probably not relevant, but this model is sold as a "UV-82 PLUS" which I have not seen documented. I selected UV-82HP for all of these operations.

Jordan Mills wrote in #note-60:

I tried CHIRP-next from 15 June 2023. The options section was available on the first download with no errors and all options under "Other Settings" that were available with the working UV-82. I saved the image, uploaded it, and downloaded it again. All of the "Other Settings" options were available with no errors. I downloaded again with CHIRP-next from 5 July 2023 and had no errors but only "Firmware Message 1" and "Firmware Message 2" were shown under "Other Settings". I believe that is expected behavior, but I wanted to try it and note the results.

Next I changed some settings (power on messages) and uploaded, then downloaded again. The updated settings were retained, are reflected in radio operation, and showed in the new settings download. So that seems to have worked around the issue for me. Thank you!

It is probably not relevant, but this model is sold as a "UV-82 PLUS" which I have not seen documented. I selected UV-82HP for all of these operations.

Thanks for the testing. Your results support what I expected from looking at your image. Your radio is not in the group of radios that break when the Aux block of memory is written to it. I am hoping I can get more "image" files submitted from others that their radio did have an issue after uploading.

Jim KC9HI

aki waki wrote in #note-62:

I am submitting an "image" file of a radio that had a issue after uploading that I have.

Thanks. From this "image" I can confirm that due to Baofeng's recent changes, your radio is one of the new ones that won't have support for the "Other Settings" and "Service Settings". So the current CHIRP is as good as it will get for you.

Jim KC9HI

Jim Unroe wrote in #note-64:

This is my latest workaround. From the limited images that have been provided for examination, I have noticed another difference that seems to identify the radios having the broken Aux memory issue without using the HN5RV011 firmware version as the detection method.

So now all of the radios and/or images that are detected as having the issue will have HN5RV011 firmware and continue to have the Aux block blocked from uploading and continue to have the 'bug' related tabs/settings suppressed.

The radios and/or images with HN5RV011 firmware that are detected as not having the issue will no longer have the Aux block blocked from uploading and will no longer have any of their tabs/settings suppressed.

It took a lot of work to come up with workaround. Don't forget to keep a backup image handy, just in case. Please provide feedback and report any bugs. Once I get a sufficient number of favorable feedback, I can submit this to be included in CHIRP-next.

Here is a reminder for how to use this test driver module: LoadingTestModules

Jim KC9HI

I downloaded it via CHIRP on my radio. I changed the settings and uploaded it to my radio and did not get the same error as before.

We're looking for more reports from users on this proposed change from Jim. We've already gotten one response, but we really need more to increase confidence that this will work for everyone. If you're able to test please do so and report here!

today's build 20230714. as mentioned above, my twin HN5RV011s are special ones without the 10505 issue, commercial FM is present, Other Settings have been always working, only 6+ Message is: read, then if changed rewritten, and reread with new values, but ignored by the radio and not displayed on LCD (I still don't remember where the 6+ Message line #1 "151123H" came from, the radio displays "210223M" on LCD). today's build reads and rewrites properly, at least bandwidth limits and power-on message are again changeable and properly written. Radios not bricked. If that was the intention then thank You very much.

Wito Krasnal wrote in #note-68:

today's build 20230714. as mentioned above, my twin HN5RV011s are special ones without the 10505 issue, commercial FM is present, Other Settings have been always working, only 6+ Message is: read, then if changed rewritten, and reread with new values, but ignored by the radio and not displayed on LCD (I still don't remember where the 6+ Message line #1 "151123H" came from, the radio displays "210223M" on LCD). today's build reads and rewrites properly, at least bandwidth limits and power-on message are again changeable and properly written. Radios not bricked. If that was the intention then thank You very much.

Today's build should hopefully reduce the number of affected radios down to something that is much closer to the actual number of radios that have the issue of blanking their Aux memory area when it is being updated.

I see what you are referring to. I would appear on some of these latest radios, the 6 + power-on message is not read from the radio's Aux memory area like radios in the past. It is apparently read from somewhere else in the radio (perhaps the firmware or one of the chips. My $2.99 UV-5R purchased from TEMU (the only radio that I have that has this issue) also displays 210223M (23 February 2023) during the 6 + power-on message but in CHIRP both message lines are displayed as being blank.

Jim KC9HI

Do all these changes in the UV-5R also affect the derivitives of that radio, like the BF-F8+ and the GT-5R, and if so, are the fixes also going to help there?
Thank you.

Doug Nelson wrote in #note-70:

Do all these changes in the UV-5R also affect the derivitives of that radio, like the BF-F8+ and the GT-5R, and if so, are the fixes also going to help there?
Thank you.

Yes. The model UV-5R is used generically for this discussion. The recent changes will apply to any model that is supported by the uv5r.py driver and has the signs of being one of the models that will break its Aux memory when edited. In addition to the models that you mentioned it would include all UV-5R variants including the UV-5RX3, UV-5X, UV-5G, UV-6, all UV-82 variants including the UV-82X3, etc., including equivalent models from other vendors.

Jim KC9HI

Jim Unroe wrote in #note-69:

Today's build should hopefully reduce the number of affected radios down to something that is much closer to the actual number of radios that have the issue of blanking their Aux memory area when it is being updated.

Indeed Sir, my report was to underline that Your recent fixes to CHIRP, targeted at radios affected by #10505, have no negative consequences for radios not affected by #10505 :D Of course 6+ message issue mention is marginal and just for the sake of report, to narrow which version of radio do I have, among the variety of them. I mean the fix seems to be clear of unexpected "vice versa" side effects: does not affect "good" radios.

the new thread was unfortunately started by someone under #10739 so I'm now trying to move it here. There is a problem for a user: 20230719 does not write/change the welcome message, which falls under the #10505 here. So to unload some work from the developers' backs I have reverted to 20230719 and changed the boot message like he did.
For me it worked properly. 20230719 did change my welcome message in my baofeng UV-5R as ordered. There is a surplus surprise: since CHIRP (at least 20230719) does not automatically change welcome message to UPPERCASE, it happened that Baofeng UV-5R does accept lowercase letters at least in the welcome message. I have directed the user from #10739 to follow the discussion here at #10505.

reversion to 20230722, no issues from #10739 whatsoever. Both Power-on Welcome Message lines can be changed as ordered, and the radio accepts both lower- and UPPERCASE letters in the welcome message.

James McDowell wrote in #note-73:

having issues with the UV5R on version 20230719 and 20230722.
Last working version for me was 20230629

Most likely your radio has been detected as one of the radios that has an issue when the Aux memory is written to. If this is the case, then CHIRP is behaving as programmed and expected. Make a fresh download from your radio and attach it to this issue so I can determine if your radio is in fact one of those radios.

Jim KC9HI

Wito Krasnal wrote in #note-75:

reversion to 20230722, no issues from #10739 whatsoever. Both Power-on Welcome Message lines can be changed as ordered, and the radio accepts both lower- and UPPERCASE letters in the welcome message.

Radios that don't have the Aux memory bug, which your radio(s) would appear to be, should program as they have all along. It is only the radios that have issues are blocked from uploading to the Aux memory area, and the user will get a notification when an affected setting is edited.

Jim

Jim Unroe wrote in #note-76:

James McDowell wrote in #note-73:

having issues with the UV5R on version 20230719 and 20230722.
Last working version for me was 20230629

Most likely your radio has been detected as one of the radios that has an issue when the Aux memory is written to. If this is the case, then CHIRP is behaving as programmed and expected. Make a fresh download from your radio and attach it to this issue so I can determine if your radio is in fact one of those radios.

Jim KC9HI

Jim, Sir
most important is that he says the 20230629 worked for him before. If he had an "abnormal" radio, the 20230629 should not work to him, because it was before the fixes. Or should it?

Wito Krasnal wrote in #note-78:

Jim Unroe wrote in #note-76:

James McDowell wrote in #note-73:

having issues with the UV5R on version 20230719 and 20230722.
Last working version for me was 20230629

Most likely your radio has been detected as one of the radios that has an issue when the Aux memory is written to. If this is the case, then CHIRP is behaving as programmed and expected. Make a fresh download from your radio and attach it to this issue so I can determine if your radio is in fact one of those radios.

Jim KC9HI

Jim, Sir
most important is that he says the 20230629 worked for him before. If he had an "abnormal" radio, the 20230629 should not work to him, because it was before the fixes. Or should it?

And for the sake of argument, let's say this is true. The current method that CHIRP uses to determine if the radio has this behavior of not indicates that his radio does. Unless you have come up with a better method, then this is all there is to go on. Some radio that don't have the issue are going to be affected but this is much better err in this direction that to not catch a radio that has the problem and upload to it.

Now with the latest CHIRP, the user can still edit the settings. The changes will still be saved in the image. He or she is just told that the change will not be automatically uploaded to the radio. But anybody that wants to take the risk of uploading the change(s) can use the Range Override Parameter setting to make the change. Since all of the changes affected by this are of the type that you usually set once and forget, using the Range Override Parameter occasionally to get them updated should not be a problem.

Jim

Anyone unhappy about this should voice their feedback to their radio manufacturer. Releasing ten years of radio variations claiming to be the same version with different FM chips, quirks, and choking on certain bits of data that should be fine are poor design behaviors. Let Baofeng know this is not what you want from your purchased radios.

CHIRP has to work for everyone, and if we can't tell buggy radios from non-buggy radios, we have to choose the safest-for-everyone option. We've been flooded by requests from people with these new buggy radios who (soft) damage their device and need hand-editing of images to restore functionality. The fact that Baofeng makes no distinction between these and previous radios is the real problem here.

Jim Unroe wrote in #note-79:

Wito Krasnal wrote in #note-78:

Jim Unroe wrote in #note-76:

James McDowell wrote in #note-73:

having issues with the UV5R on version 20230719 and 20230722.
Last working version for me was 20230629

Most likely your radio has been detected as one of the radios that has an issue when the Aux memory is written to. If this is the case, then CHIRP is behaving as programmed and expected. Make a fresh download from your radio and attach it to this issue so I can determine if your radio is in fact one of those radios.

Jim KC9HI

Jim, Sir
most important is that he says the 20230629 worked for him before. If he had an "abnormal" radio, the 20230629 should not work to him, because it was before the fixes. Or should it?

And for the sake of argument, let's say this is true. The current method that CHIRP uses to determine if the radio has this behavior of not indicates that his radio does. Unless you have come up with a better method, then this is all there is to go on. Some radio that don't have the issue are going to be affected but this is much better err in this direction that to not catch a radio that has the problem and upload to it.

Now with the latest CHIRP, the user can still edit the settings. The changes will still be saved in the image. He or she is just told that the change will not be automatically uploaded to the radio. But anybody that wants to take the risk of uploading the change(s) can use the Range Override Parameter setting to make the change. Since all of the changes affected by this are of the type that you usually set once and forget, using the Range Override Parameter occasionally to get them updated should not be a problem.

Jim

understood Sir, thank You very much and apologies if offended

Wayne Del Rossi wrote in #note-81:

Dan,
I've read through this thread a couple of times trying to learn more about this issue with some of the UV-5R's. I just recently bought two of them on Amazon. +3 Power-on reads BFB298, +6 Power-on reads 210223M. Using today's version of CHIRP, I do get the warning message saying that "this setting will not be uploaded..." when I try to change some items on the Settings tab. Based on what I am reading here, I'm assuming that my radios are two of the ones that would be "soft damaged" by changing some of the Settings and using the Range Override Parameter to force a write to those settings. Are you able to confirm that based on the info provided? If my radios are in the problem group, is there any other way to change these settings? I'm primarily interested in changing the squelch settings under the Service Settings tab, but would also like to be able to change some of the other ones too. Just wondering if using Range Override Parameter is an option for me.
Thanks for your help.

Wayne

Fortunately the settings that are affected are settings that don't often change. So make all of the desired changes (they will update in the CHIRP image and be saved, they just won't be directly uploaded). Once you are satisfied with the changed, you can use the Range Override Parameter setting to upload them to your radio.

Just remember...

• You must have a working image saved as a backup just in case your attempt to upload these setting doesn't work properly.
• You must only upload the image back to the same radio that it came from. Sending it to a different radio may cause undesired behavior.
• You do this upload at your own risk.

Jim KC9HI
Then once that you have

Jim,
Thank you for the quick reply. I made a back-up copy of the image, opened a new copy of that file, saved it with a different filename and then set the Range Override Parameter, changed the settings that I wanted to change and uploaded the file to the radio. Looks like all is working correctly including power-on message, squelch settings, FM radio, etc. Thank you!
Wayne

Hi all.
I too have successfully changed lower and upper limits VHF and UHF, it took a few ties, didn't work first time. also I reverted to CHIRP 20230722
Range Override: I changed to: UseAtOwnRisk, 100.000-200.000 VHF, 300.000-500.000 UHF
Now, I have two UV5R 1-5W and UV-82HP 8W. I haven't really tested these to transmit to each other I've noticed when going to 125.977 and bellow or 178.177 and above, {100.000-200.000 VHF} when pressed PTT it get's stuck red LED is on, screen is lit, the only way to get out is OFF/ON radio. It is not mechanical PTT button fault, I've read on Bug #5593 same issue, just wandering if anyone else have had this problem since this Bug.
Thank you
Erik

Erik Priester wrote in #note-85:

Hi all.
I too have successfully changed lower and upper limits VHF and UHF, it took a few ties, didn't work first time. also I reverted to CHIRP 20230722
Range Override: I changed to: UseAtOwnRisk, 100.000-200.000 VHF, 300.000-500.000 UHF
Now, I have two UV5R 1-5W and UV-82HP 8W. I haven't really tested these to transmit to each other I've noticed when going to 125.977 and bellow or 178.177 and above, {100.000-200.000 VHF} when pressed PTT it get's stuck red LED is on, screen is lit, the only way to get out is OFF/ON radio. It is not mechanical PTT button fault, I've read on Bug #5593 same issue, just wandering if anyone else have had this problem since this Bug.
Thank you
Erik

The issue that you are experiencing is due to your attempt to program and use frequencies well outside the factory provided band limits (which are generally 130-180 and 400-520 or less) and not supported by the hardware.

Thanks Jim
Is that normal on all UV5R's? is there a work around it?
Erik

Having an issue with a Baofeng GT-5R.
Tried loading a new configuration for repeaters on Cape Cod. The whole radio did not seem to want to work after.
Then went to get my original configuration I downloaded from the radio, and load that back in, and that did not work either. Ran out of time then, but will try again. Could this bug be related?

Doug Nelson wrote in #note-88:

Having an issue with a Baofeng GT-5R.
Tried loading a new configuration for repeaters on Cape Cod. The whole radio did not seem to want to work after.
Then went to get my original configuration I downloaded from the radio, and load that back in, and that did not work either. Ran out of time then, but will try again. Could this bug be related?

Probably not, but there is no way to know. You didn't include any useful information.

Please attach a freshly downloaded CHIRP Radio Images (*.img) from your radio plus your "original configuration" file. Describe what you mean by "radio did not seem to want to work".

Aaron Hope wrote in #note-90:

Despite not having a prior issue with this, the Chirp software is now not pushing the modifications to my UV-5RTP due to the potential of an issue. I'm now locked out of that section of the radio with the same issue as everyone else. I have attached the screenshot.

You are not locked out. You can still edit all of the settings on this tab and the Service Settings tab. Then if you want to risk making these changes to the radio that they came from, you can use the procedure shown in note-40 above.

Is there a way to bypass this error message or do we have any resolution on this topic on the way?

No. What you have is the current resolution. The only other option at this time (and it was strongly being considered) would be to completely remove access to all settings stored in this Aux region of memory. To be clear, CHIRP didn't do anything to make this change necessary, Baofeng did.

Nacho Tronics wrote in #note-92:

Hi all, I recently bought a tri-power UV82, supposedly 8W (see photo).

I was able to successfully change poweron_msg using CPS for UV82_HP (https://www.miklor.com/UV82/UV82-Software.php), so I decided to risk writing from CHIRP with UseAtOwnRisk.

Through CHIRP, I was able to modify "Other Settings" and "Service Settings" without errors, read them back and it all seems OK.

Regarding firmware version, I can't be sure as there is something strange happening. On powering the radio, holding #3 displays "Ver NUV82" while #6 displays "190923M". On CHIRP, firmware_msg reads "?????? ÿÿÿÿÿÿÿ" and sixpoweron_msg reads "151123H ÿÿÿÿÿÿÿ".

Factory .img file attached for reference.

That doesn't look factory to me. Looks like a file from a radio after it was RESET. There is a chance that your radio is one that doesn't have the bug. Just keep a known working image as a backup in case you find out otherwise.

Jim Unroe wrote in #note-93:

Nacho Tronics wrote in #note-92:

Hi all, I recently bought a tri-power UV82, supposedly 8W (see photo).

I was able to successfully change poweron_msg using CPS for UV82_HP (https://www.miklor.com/UV82/UV82-Software.php), so I decided to risk writing from CHIRP with UseAtOwnRisk.

Through CHIRP, I was able to modify "Other Settings" and "Service Settings" without errors, read them back and it all seems OK.

Regarding firmware version, I can't be sure as there is something strange happening. On powering the radio, holding #3 displays "Ver NUV82" while #6 displays "190923M". On CHIRP, firmware_msg reads "?????? ÿÿÿÿÿÿÿ" and sixpoweron_msg reads "151123H ÿÿÿÿÿÿÿ".

Factory .img file attached for reference.

That doesn't look factory to me. Looks like a file from a radio after it was RESET. There is a chance that your radio is one that doesn't have the bug. Just keep a known working image as a backup in case you find out otherwise.

Sorry, now that you mention, that's exactly what it is. It's an image before programming, I will keep it as a backup. Thanks!

Jim Unroe wrote in #note-97:

--SNIP-- and provide feedback.

I have a relatively recently (within the last ~6 months) purchased Baofeng UV-82 (dual band, dual power, arrived with the "locked-to-ham-bands" firmware), I believe 190923M

The only config I changed was the startup message itself. While I still got the "this setting won't apply" notice, the setting did in fact upload correctly; the radio seems to be working properly as well, however I haven't dug deeply to look for unexpected settings changes.

edit - the message was not the "this won't upload" message, but in fact the new message about aux memory. Sorry, bad tester behavior here!

Geo Maciolek wrote in #note-98:

Jim Unroe wrote in #note-97:

--SNIP-- and provide feedback.

I have a relatively recently (within the last ~6 months) purchased Baofeng UV-82 (dual band, dual power, arrived with the "locked-to-ham-bands" firmware), I believe 190923M

The only config I changed was the startup message itself. While I still got the "this setting won't apply" notice, the setting did in fact upload correctly; the radio seems to be working properly as well, however I haven't dug deeply to look for unexpected settings changes.

The uv5r.py driver being tested supports many models, including the UV-82 model series. Any model with the 'dropped byte bug' bug that is supported by this driver should benefit from the changes. Once this issue is satisfactorily resolved by the uv5r.py driver changes, I will have to provided a similar fix for the affected models supported by the baofeng_wp970i.py driver.

I tested the module today on my 2 radios.

On my UV-5R (recent device BFB298)

• Module included by default in Chirp :
  • not detected as potentially affected
  • programming works in aux zone
  • FM Radio Preset tab displayed
• New test module :
  • no dropped byte issue nor aux memory mis-match
  • programming works in aux zone
  • FM Radio Preset tab no longer displayed!

On my UV-5R8W tri-power (also recent BFB298)

• Module included by default in Chirp :
  • detected as potentially affected!
  • programming works in aux zone despite alert (using "Range Override Parameter")
  • FM Radio Preset tab not displayed!
• New test module :
  • no dropped byte issue nor aux memory mis-match
  • programming works in aux zone
  • FM Radio Preset tab not displayed!

So there's an improvement, because there's no longer false positive on my UV-5R8W, but I've lost the "FM Radio Preset" tab on my UV-5R, where everything works fine.

Jim Unroe wrote in #note-102:

After doing some additional testing I have made some additional changes/improvements. Please test and provide feedback.

Hello, I have two UV-5R stations (and they are the same - BFB298). But one of them had an error when recording in "Power-On Message 1 and 2", and there was no section with FM radio. After applying the latest 10505 module, I was able to edit the station name in "Power-On Message 1 and 2" and successfully write it to the radio's memory. I also connected another UV-5R BFB298, which initially had no problems. Previously, without the 10505 module, I could read the FM radio section, but with the latest module it is no longer possible. However, this section is not needed and has no effect. Thank you for this development, all the best to you!

Just installed next 20231021. Radio up loads with no error message with UV-82 3 power firmware message line 1 N82-33. Other setting still not uploading properly. Squelch setting, power on message 1 and 2, MR A and B did not change on upload. Just noticed no FM preset on menu either. Went back to next 20230629 and squelch power on message 1 and 2 loaded properly. MR A and B did not but no big deal. I have image files and screenshots if needed.

Ray Mason wrote in #note-107:

Just installed next 20231021. Radio up loads with no error message with UV-82 3 power firmware message line 1 N82-33. Other setting still not uploading properly. Squelch setting, power on message 1 and 2, MR A and B did not change on upload. Just noticed no FM preset on menu either. Went back to next 20230629 and squelch power on message 1 and 2 loaded properly. MR A and B did not but no big deal. I have image files and screenshots if needed.

No changes have been submitted yet. You should be using the latest test module that was submitted to this issue ( LoadingTestModules ).

The FM Preset menu is being removed because the latest radios (with the dropped byte issue) do not expose the broadcast FM frequency to CHIRP any longer. Those with those radios will (and already have) complain that CHIRP doesn't program the broadcast FM frequency of their radio. CHIRP can't because those radios don't support the ability to read/write this frequency any longer.

For radios that still support this capability, all you have to do is set the radio to your desired frequency and download into CHIRP. If you change your radio and then upload from CHIRP back to your radio, you will see that the saved frequency is restored. That is the best that can be done.

After fixing some style issues and spelling errors, I submitted a patch that is basically the latest driver module that has been available above. It should be available in the next build that gets released.

If all goes well (it should with the testing that was done), I will make a similar update to the baofeng_common.py driver that also support a few Baofeng models that have the 'dropped byte' issue.

"will make a similar update to the baofeng_common.py driver that also support a few Baofeng models that have the 'dropped byte' issue"

Might these models include the GT-5R and BF-F8+?

Doug Nelson wrote in #note-110:

"will make a similar update to the baofeng_common.py driver that also support a few Baofeng models that have the 'dropped byte' issue"

Might these models include the GT-5R and BF-F8+?

No. They would mostly be the so-called "waterproof" models such as the BF-A58, GT-3WP, UV-9R, etc. The GT-5R and BF-F8+ are both covered in the new driver that is available in today's (20231027) build.

next 11/29/23 fixed most of my issues with my tri power UV-82. Squelch setting work, power on message work. Firmware version in browser no longer gets changed. The MRA & B channels don't update but no big deal. Thanks to the guys that work on these issues.