CHIRP

Andrew Clapp wrote:

I just got two new Retevis RT22 radios and I am programming them to remove the tones and align the channel numbers correctly to communicate with other radios.

The first RT22 worked just fine but the other one keeps getting "identification failure" errors. Sometimes before attempting to clone and sometimes it starts then gets it at a "block."

I tried downloading the newest version of CHIRP just today but no change.

Did you close CHIRP before detaching the first and attaching the second device?

Andrew Clapp wrote:

I just got two new Retevis RT22 radios and I am programming them to remove the tones and align the channel numbers correctly to communicate with other radios.

The first RT22 worked just fine but the other one keeps getting "identification failure" errors. Sometimes before attempting to clone and sometimes it starts then gets it at a "block."

I tried downloading the newest version of CHIRP just today but no change.

Please attach the debug.log file.

Jim KC9HI

Jim Unroe wrote in #note-2:

Andrew Clapp wrote:

I just got two new Retevis RT22 radios and I am programming them to remove the tones and align the channel numbers correctly to communicate with other radios.

The first RT22 worked just fine but the other one keeps getting "identification failure" errors. Sometimes before attempting to clone and sometimes it starts then gets it at a "block."

I tried downloading the newest version of CHIRP just today but no change.

Please attach the debug.log file.

Jim KC9HI

I did attach it.

I and yes i closed chirp and also didnt multiple times.

Andrew Clapp wrote in #note-3:

Jim Unroe wrote in #note-2:

Andrew Clapp wrote:

I just got two new Retevis RT22 radios and I am programming them to remove the tones and align the channel numbers correctly to communicate with other radios.

The first RT22 worked just fine but the other one keeps getting "identification failure" errors. Sometimes before attempting to clone and sometimes it starts then gets it at a "block."

I tried downloading the newest version of CHIRP just today but no change.

Please attach the debug.log file.

Jim KC9HI

I did attach it.

I and yes i closed chirp and also didnt multiple times.

OK. I see it now. I've never seen it seen it added to an issue like it is to this one. I'm still getting used to this updated bug tracker.

Jim

Andrew Clapp wrote in #note-6:

Jim Unroe wrote in #note-5:

I have added the new Model ID that your radio is supplying to this test module. Click Help in the menu bar and choose Load module from issue to load this test module. Report back if it works or not.

Note: Externally loaded modules do not permanently change your CHIRP installation. Once you've closed CHIRP, the next time you open CHIRP you must load the module again before you have access to its added feature(s) and/or bug fix(es).

Jim KC9HI

I tried it and it did not work. Same problem. Ive attached the debug.

The data being returned from your radio is being randomly begin garbled (hence what I though was a new model ID. I would suggest that you unplug the programming cable from your computer and plug it back in, plus power cycle the radio. Is there a change that you could borrow an FTDI chip based programming cable to replace the Prolific chip based programming cable that you are using?

Jim

Jim Unroe wrote in #note-7:

Andrew Clapp wrote in #note-6:

Jim Unroe wrote in #note-5:

I have added the new Model ID that your radio is supplying to this test module. Click Help in the menu bar and choose Load module from issue to load this test module. Report back if it works or not.

Note: Externally loaded modules do not permanently change your CHIRP installation. Once you've closed CHIRP, the next time you open CHIRP you must load the module again before you have access to its added feature(s) and/or bug fix(es).

Jim KC9HI

I tried it and it did not work. Same problem. Ive attached the debug.

The data being returned from your radio is being randomly begin garbled (hence what I though was a new model ID. I would suggest that you unplug the programming cable from your computer and plug it back in, plus power cycle the radio. Is there a change that you could borrow an FTDI chip based programming cable to replace the Prolific chip based programming cable that you are using?

Jim

that seems odd.

I dont have access to one but I could order one if you think that could help. Im new to this so I just looked it up but dont really understand the difference between the types of cables. I just got the cable a couple days ago and used it for my two UV5Rs which worked fine.

I think that if one of the radios (consistently) works and the other does not, with the same cable, it's unlikely that the cable itself is the problem. That is, aside from resetting it by unplugging and re-plugging it. If you can do the following procedure:

1. Reboot (just for good measure, I know, I know)
2. Attach the cable to the radio
3. Attach the cable to the PC
4. Open chirp
5. Download

From scratch for each radio, and one consistently behaves as described, then it's likely the radio. You're on macos so I'm less concerned about reboot being necessary, but while some usb-serial drivers on windows are problematic, usb-serial as a class of devices on macos can be more flaky, because they're used so much less often on macs than windows machines and seem to get a lot less attention overall.

It's definitely true that FTDI cables are by FAR more reliable and well-behaved, as Jim notes, but I think I'd try to prove that it's not a problem with the radio before I bought another cable. You might also try OEM software just for comparison. It's certainly also possible that you got one old and one new radio, and that the new one is doing some sort of obfuscation of the protocol that the old one is not. Some radio OEMs have been doing such nefarious things lately, for questionable reasons.

I tried that and still didnt work. Cable works every time with the other radios.

I tried downloading the retevis software but apparently its only for windows.