Project

General

Profile

Actions

Bug #11532

closed

Bug reading from Retevis RT622 - looks similar to issue 10080

Added by Ari S about 2 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
09/11/2024
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next
Model affected:
Retevis RT622
Platform:
MacOS
Debug Log:
I read the instructions above:
Yes

Description

I am trying to download an image from a Retevis RT622 that was previously programmed with an older version of CHIRP.

I get the error message "Radio identification failed."

I have a few Retevis RT622s and only have this issue with this one. Using the same cable and exact setup works fine with other Retevis RT622 radios.

I updated to the latest CHIRP, I tried different USB ports and adapters from USB C to A and they all seem to be the same, not working with this one radio only (and working fine with the others).

I see a past issue about 2 years ago - issue number 10080. (chirpmyradio.com/issues/10080)
Which looks to be the same symptoms.

I tried to read my problematic radio using the modified driver as in that issue but I get an error message that the driver is incompatible. I expect CHIRP has changed that much since then and also see that issue was in Legacy and I am using NEXT.
I think this radio was probably originally programmed with Legacy but fairly sure most of mine were also.

I see from issue number 10080 —
“It seems that the OEM CPS can "zero" the identification string. Apparently it can be edited to be anything that you want.
For now, this patch includes this new identification string to the list of strings known strings. If additional strings appear in the future, another solution will need to be found.”

I am on a Mac and never used the OEM software on any of my radios. So perhaps the string has been corrupted somehow?

I wonder if there is some way to get this back -
I am happy to try anything and also report any more details if I missed something.

CHIRP is amazing and very helpful (use it all the time) Thank you for all the work. I wish I could contribute more.


Files

config.txt (1.72 KB) config.txt Ari S, 09/11/2024 07:35 AM
debug_log.txt (4.57 KB) debug_log.txt Ari S, 09/11/2024 07:35 AM
retevis_rt22.py (22.2 KB) retevis_rt22.py Dan Smith, 09/11/2024 03:07 PM
config.txt (1.72 KB) config.txt Ari S, 09/12/2024 02:48 AM
Retevis_RT622_20240912.img (1.18 KB) Retevis_RT622_20240912.img Ari S, 09/12/2024 02:48 AM
debug_log.txt (20.7 KB) debug_log.txt Ari S, 09/12/2024 02:48 AM
config.txt (1.72 KB) config.txt Ari S, 09/13/2024 10:38 AM
Retevis_RT622_20240913.img (1.18 KB) Retevis_RT622_20240913.img Ari S, 09/13/2024 10:38 AM
debug_log.txt (24.4 KB) debug_log.txt Ari S, 09/13/2024 10:38 AM

Related issues 1 (0 open1 closed)

Related to Bug #10080: RT622: Unable to import or export after first exportClosedJim Unroe10/16/2022

Actions

Updated by Ari S about 2 months ago

[Uploaded from CHIRP next-20240905]

Actions #2

Updated by Dan Smith about 2 months ago

  • Related to Bug #10080: RT622: Unable to import or export after first export added
Actions #3

Updated by Dan Smith about 2 months ago

Thanks for digging up the other bug. I'll mention @Jim Unroe here in case he has had any more experience since that bug that might help. It's definitely a slippery slope if the ID can completely be changed to anything.

Please try the attached module with LoadingTestModules. Please update this bug (with the Help->Report or update tool) after you try so I can have a look at the image it grabs and the log.

Updated by Ari S about 2 months ago

[Uploaded from CHIRP next-20240911]

Thank you so much for looking into this.

Yes agreed this would definately be a slippery slope. I have a number of these radios so will go through them all to see if any others have the issue also.

With the attached module I was able to read from the radio and have attached that here as requested.

Actions #5

Updated by Dan Smith about 2 months ago

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.

Updated by Ari S about 2 months ago

[Uploaded from CHIRP next-20240911]

Further testing.

I have pulled a few radios out of the fleet and found, thus far, one other radio that seems to have the same issue.
Using the above test module I was able to read from that radio also, and upload it to this report to help troubleshoot the issue.

— As an asside —
You may see the weird step frequencies I have been “trying” to accomodate here (which we discussed in another bug/issue). I am going to recall and reprogram the whole radio fleet and update to a sensical frequency step to negate those issues going forward.

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.
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. Sorry if that is too simplistic for what is going on here - I may not have fully understood.

Thank you again for your time and input.

Actions #7

Updated by Dan Smith about 2 months ago

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.

Actions #8

Updated by Ari S about 2 months ago

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.

Actions #9

Updated by Dan Smith about 2 months ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
Actions #10

Updated by Ari S about 2 months ago

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 ..

Actions #11

Updated by Dan Smith about 2 months ago

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

Actions

Also available in: Atom PDF