CHIRP

The recent radios that display BFB298 firmware and similar radios have a dropped byte issue that made them incompatible with CHIRP and early versions of CHIRP-next. The radios would dump the values in some or all of their Aux memory area (welcome message, squelch thresholds, band limits, etc). Once the radio hoses itself, you have to restore the Aux memory area using an image that the radio hasn't corrupted yet. For example, the original backup image that was made following the first successful download from the radio. For those that didn't make a backup, you have can locate and use the backup that CHIRP now makes or use one from another radio that hasn't dumped it Aux memory yet. You then upload this 'backup' image using the process described in issue #10505 to restore the Aux memory area. CHIRP-next has been updated to recognize these radios and adjusts accordingly to prevent them from dumping their memory.

It loads up into Chirp fine, that's not the problem =) The problem is as I described above, go change the POM string or other settings w/ that .img loaded, that's when you get the attribute errors. Tnx.

Rob Short wrote in #note-4:

It loads up into Chirp fine, that's not the problem =) The problem is as I described above, go change the POM string or other settings w/ that .img loaded, that's when you get the attribute errors. Tnx.

I just edited everything in the image that you attached and there were no errors.

Your image with errors (that you didn't provide) is most likely due to your radio erasing all or part of it's Aux memory area. This puts invalid values in the settings that CHIRP doesn't expect (out of range band limits, out of range squelch thresholds, invalid characters in text fields, etc).

This is most likely do to programming the with an older version of CHIRP that was not able to handle the changes that Baofeng recently made to these radios. Their changes made these radios incompatible with CHIRP.

Upload your "backup" image to your radio using the latest CHIRP-next following the instructions issue #10505 (I believe it is note 40) to restore its Aux memory area. Then make a fresh download from this radio to verify that you can now make changes without errors. If good, then copy-and-past any channels from your 'bad' image to this 'good' image, make any other global changes (like POM) and then upload back to your radio.

Avoid using any older versions of CHIRP that don't know how to work with these radios or they will dump some or all of their Aux memory area.

Hmm ok, that's weird, the default image I provided, does throw the setting exceptions for me in the Chirp next rev 20231217. For now though, I just made the edits I needed w/ the 20231021 rev even though I get the FW warning, it saves the image correctly, then I loaded the image w/ the latest Chirp 20231217 rev and was able to get the settings to flash to the UV-5R correctly and they work fine. I just needed to program a bunch of new radios quickly for a club and somehow they had that crappy BFB298 FW that I guess others have struggled with as well, if they were actually mine, I'd probably send them back for the other BFB297 rev radios...

I've not seen this problem before programming my Baofeng BFB297 FW radios or even my TIDRadios that I have. Using these cheap radios really makes me appreciate my Icom and Yaesu radios, even though they cost more, it's worth it...

Thanks so much for your help though and your instructions above, I'll look into when/if I have to program these again at some point, but for now my workaround works.

Right. And actually BFB298 firmware is actually from about 10 years ago when the even numbered firmware versions were for the VHF/220 models. I have no idea why that are having the radio display it at the masqueraded firmware version (the actual firmware version is HN5RV011).

For at least the UV-5R models (and really for all Baofeng models) you should not upload a image into any image except the one that it came from. You need to always download from the radio that you intend to program and then either copy-and-paste the channels from a tab containing your 'master' list of channels or Import you master image into the tab for the radio being programmed. Then adjust any global settings an upload back to the radio it came from. A lot more work than it used to be, but you can thank Baofeng for that.

Thanks Jim. That's what I've always done with any new radio, is download the data first then just copy/paste freq's from other images to build a new one and have had no problems, but this time it was different with the next-20231217 build. Last night I had some time to try and change some text settings (e.g. POM Message) in my known working TIDRadio H8 images and other working images and actually get the same 'NonType' object has no attribute 'SetValue' error, so there something else going on w/ this build. I know you can't reproduce it, but I'm reverting back to what worked w/ my next-20231021 rev for now and let things work there way out since I'm sure others will be reporting the same error if it's a problem. I've been using this software for years and haven't see this problem before, just saying.

Anyway, thanks again for your work on this software. I'm a software engineer for a radar company I know the work and frustrations that go into these integrations to make it play with all these radios. If I get some time I might just pull a branch from the Chirp repo and see if I can't track down the problem and fix my build if it continues to fail.

Merry Christmas!

This is apparently due to a change that was made to CHIRP itself that is causing side affects with this driver. I am investigating. In the mean time revert back the CHIRP-next build prior to this change.

https://trac.chirp.danplanet.com/chirp_next/next-20231213/