CHIRP

Okay, it's hard to tell but I think maybe you opened your existing .img file, then loaded the module, then tried an upload, is that right? If so, you need to load the module first (in a freshly-started chirp), then open the .img file, then try to do an upload. I should update the instructions to clarify that...

Okay, that definitely looks like it's doing the right thing now (i.e. actually sending to the radio what we expect and getting the echo back from the cable). But, it's not getting any response from the radio. To be clear, you're putting the radio into clone mode and pushing whatever button is required to get it ready to receive the image (i.e. when it says WAIT), right? What does the radio do when this all happens? Does it stay in WAIT state or change to something else?

The radio stays in the WAIT mode. I am following all of the requisite preparatory steps. Powering on the radio with PTT and the VFO knob pressed, then pressing the MON switch to put the radio into the WAIT condition.

BTW -- Once an upload is attempted, the radio will NOT come out of the WAIT condition unless the battery is removed. IDK if that helps any...

Dan -- I had a breakthrough here. I got to thinking about the Prolific chipset driver and its sometimes strange behavior. I decided to see what happens if I roll it back to an earlier version of the chipset driver. As you may have seen from the original bug report, on my Windows 10 machine, the driver was version 3.8.42 dated 02/22/2023. I rolled it back to version 3.6.81.357 dated 09/04/2015 and the upload worked. It took a while for the upload to complete, but complete it did.

I am SORRY to have put you through all of this. I was considering sourcing a programming cable with the FTDI chipset to see if that worked any better, and I may still do that. If I do, I will let you know the results of that test. It was thinking about the FTDI alternative that made me think about changing the driver.

Thank you for your patience and working with me through this. It is the least that I could do to bear with you and all of the trial-and-error work. I must compliment you on your superb efforts. Thank you very much for the great job and for the superb application. I actually taught a class on using CHIRP at my local radio club not too long ago... and I will do so again, I am sure. I am considered to be the CHIRP guru at our local club (believe or not!)

This may be a good note to post somewhere, wherever this type of information would get posted, in case somebody else experiences it.

73

Okay, no worries, I was going to suggest re-checking drivers and connections but nobody ever wants to hear that ;)

But before you go, we need to make sure we capture which one worked. The latest one I attached is not what we want to give to everyone else because it's massively slowed down. So can you make sure that the "3b585b41" does work? Maybe attach a debug log for me showing that you loaded that one and did the upload so I can sanity check the module version and the log? If so, I'll queue this up for the main build to make sure we fix it for everyone.

Thanks!

Well, bad news. I could not duplicate the upload. I reset the radio back to factory and went to repeat the process with a clean debug log, but the same error repeatedly occurs. I guess that I will have to locate and try an FTDI cable. I really believe at this point that the Prolific chipset is at fault here. I will let you know what happens...

Okay, make sure you're loading the module each time. It does not stay in chirp after you close and must be loaded for every session.

I merged what we had before because it was obviously better than what was there, even if it might not fully fix the problem. It'll be in tomorrow's build which will make further testing easier.