CHIRP

CHIRP is not receiving any data from the radio. I suspect that there is an issue with the connection between the programming cable and the radio. Do you have the programming cable plugged into the data port? It is easy to accidentally plug the programming cable into the headset port by mistake since they are side-by-side on the back of the radio. I've done it myself.

Ben, without seeing a debug log, the "bad ack from radio" isn't helpful to us. So please reproduce and upload a report here with the in-chirp functions described in How_To_Report_Issues. I wouldn't put much faith in the error message being different meaning much unless it's 100% consistent across multiple tries. Just plugging and unplugging can generate noise on the line which sits in a buffer.

Yep, same error on this try with that jack as the original.

This section of the log dated 11/7/24 pertains to connections via data jack.

[2024-11-07 20:52:15,299] chirp.wxui.clone - ERROR: Failed to clone: Error reading data from radio
Traceback (most recent call last):
File "chirp\drivers\btech.py", line 374, in _rawrecv
chirp.errors.RadioError: No data received from radio

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "chirp\wxui\clone.py", line 93, in run
File "chirp\drivers\btech.py", line 762, in sync_in
File "chirp\drivers\btech.py", line 538, in _download
File "chirp\drivers\btech.py", line 452, in _do_ident
File "chirp\drivers\btech.py", line 382, in _rawrecv
chirp.errors.RadioError: Error reading data from radio

This section of the log dated 11/9/24 pertains to connections via the audio jack.

[2024-11-09 19:28:47,579] chirp.wxui.clone - ERROR: Failed to clone: Bad ack from radio
Traceback (most recent call last):
File "chirp\wxui\clone.py", line 93, in run
File "chirp\drivers\btech.py", line 762, in sync_in
File "chirp\drivers\btech.py", line 538, in _download
File "chirp\drivers\btech.py", line 456, in _do_ident
chirp.errors.RadioError: Bad ack from radio

Again, I'm not sure what this means (if anything) but I'm definitely able to recreate different error messages in the log depending on which jack I plug into on the radio.

Okay, I was hoping you were going to just capture a clean log where you had connected only to the speaker jack to avoid any confusion while changing the cable. Especially on cheap cables, just the act of touching the connector and definitely the act of switching a jack can generate noise that the radio sees as "data" but it's just noise. 8 bytes is a lot, but this is the first read being done of the radio, so it's certainly possible.

Also, is your computer's clock really days off or have you not restarted chirp and made multiple attempts since the original report? The debug log is cleared on each startup...

Anyway, Jim knows these radios well and so I'm quite sure the speaker jack thing is a dead end, I was just trying to confirm.

Yeah, the 'speaker' jack is actually a 'headset' jack. It is a TRRS jack which contains speaker, microphone and PTT. There is no data there. The data jack is a TRS jack to match the TRS plug of the programming cable.

I tried to help someone the other night with a KT-8900D that has the same symptoms. Perhaps QYT has made a change recently that affects the cloning process. He decided to send the radio back so I didn't pursue it any further.

At this point I would suggest giving the OEM software a try. If that works, then there is a possibility that a solutions can be found to overcome this issue. If that also fails, then it is most likely a programming cable issue.

Computer date and time are correct. I didn't realize Chirp needed to be restarted to create a fresh debug log.

I've tried the manufacturer programming software (UV4BAND_E_CPS") with two of the manufacturer's programming cables (prolific chip) and even used the manufacturer's "checkChipVersion_v1006.exe" tool to confirm the version of the prolific cables. I also used the "PL2303_Prolific_DriverInstaller_v1120.exe" drivers that are specific for those cables. Like I said earlier, I've tried every combination cables, operating systems, computers, etc. I've even attempted running programming software in earlier versions of Windows, adjusting baud rates, making sure USB ports have constant power/can't sleep. I've factory reset the radio several times, taken apart the radio and one of the prolific cables for physical and visual inspection.

I just don't know what I'm missing.

Is there a timeout setting in a configuration file that can be adjusted? I'm wondering if the radio needs a split second longer to make the connection.

The two prolific cables and the brand new FTDI cables are solid. I feel like it's a problem with the radios, but that doesn't explain why one of them was able to be programmed with Chirp/Prolific cable on 7/21/24.

What am I missing here?

I've tried the manufacturer programming software (UV4BAND_E_CPS") with two of the manufacturer's programming cables (prolific chip) and even used the manufacturer's "checkChipVersion_v1006.exe" tool to confirm the version of the prolific cables. I also used the "PL2303_Prolific_DriverInstaller_v1120.exe" drivers that are specific for those cables.

You say you've tried, but...did it work? If it's not working with the OEM software then it's definitely not a chirp issue.

I've even attempted running programming software in earlier versions of Windows, adjusting baud rates

Just FYI, you cannot "adjust the baud rates": FAQ_Adjusting_The_Serial_Port_Settings_In_Windows

Is there a timeout setting in a configuration file that can be adjusted? I'm wondering if the radio needs a split second longer to make the connection.

Nope, and the timeout for this radio is already set quite long.

OEM Software did not work. The first time I programmed the radio was with Chirp on 7/21/24 with the OEM cable. It read from and wrote to the radio just fine. I only downloaded the OEM software when I started having trouble with Chirp.

My mistake on the "baud rate." I was adjusting the BPS on my com port to see if it would help... Which it certainly didn't according to the info in the link you provided! Thanks, by the way.

So it looks like my best option might be to try to download whatever version of Chirp Next I had on 7/21/24? The radio hasn't been damaged or anything, so it seems like that might be my only hope. Or, just wait for the stars to align?

So it looks like my best option might be to try to download whatever version of Chirp Next I had on 7/21/24? The radio hasn't been damaged or anything, so it seems like that might be my only hope. Or, just wait for the stars to align?

I doubt that's going to make a difference based on the (lack of) changes to that driver since then. But, if the old build still works, then that will for sure be a useful data point.