CHIRP

Okay, glad to hear it works. If you have other radios that uses the same driver but worked before the change, confirmation that they still work after would be helpful.

Just to be clear - you're saying you found one more radio that was not readable with mainline chirp, but is readable with the module supplied above right?

I assume I should hold fire doing anything further with the problematic radios till I hear from you in case you wish me to test or pull anything from them. I have only downloaded the img from them and done nothing else as yet.

No, I'd like you to do as much testing as you can with the module to make sure it seems workable, before we merge it for "everyone else." That would include making changes and uploading to the radio. If indeed the only thing in play here is a different identification string, this should be low-risk and straightforward, although since I can't reproduce this issue (and didn't write this driver in the first place) I can't really say for sure.

If I have understod correctly this is a corruption (in some way) of the identification string in the radio. I have no idea how wide spread or problematic this is but would a solution perhaps be a test module that can correct the radio back to what it should be.

Someday maybe, but I wouldn't try to modify the identification string of the radio without more data (like observing exactly what the OEM software is doing). If this works for you (and it sounds like there's mounting evidence that this is reasonable) then we can just merge this and hopefully it will help and apply to others as well. The change I made doesn't just bless your identification string explicitly, but strings that look like yours, which I hope will be more generally applicable.

Dan Smith wrote in #note-7:

Just to be clear - you're saying you found one more radio that was not readable with mainline chirp, but is readable with the module supplied above right?

Yes that is correct - so two examples with the issue.

No, I'd like you to do as much testing as you can with the module to make sure it seems workable, before we merge it for "everyone else." That would include making changes and uploading to the radio. If indeed the only thing in play here is a different identification string, this should be low-risk and straightforward, although since I can't reproduce this issue (and didn't write this driver in the first place) I can't really say for sure.

Understood - I will go ahead and play about with the test module and make as many changes as I can with both radios that have the issue and those that do not. I will report back. Thank you for clarification.
I was jumping to false conclusions about this process based on the past bug report.

Someday maybe, but I wouldn't try to modify the identification string of the radio without more data (like observing exactly what the OEM software is doing). If this works for you (and it sounds like there's mounting evidence that this is reasonable) then we can just merge this and hopefully it will help and apply to others as well. The change I made doesn't just bless your identification string explicitly, but strings that look like yours, which I hope will be more generally applicable.

Appreciated ..

Thank you
I will continue testing and update you as soon as I have any more details to report back.

Just to update --
I have continued testing with both of the problematic radios and the ones not showing any issues.
All seem to be working fine when using them with the above test module. I have tested Reading, editing and writing back to the radios.

Thank you again ..

Cool, thanks. This went out in yesterday's build.