Bug #11668
openError communicating with radio
0%
Description
I've been trying to read from the radio using multiple computers with multiple operating systems. I've used the prolific cable with drivers ranging from 3.2.0.0 to current. I also ordered a set of cables with the FTDI chip with most recent drivers. I've attemped reading from radio on a Macbook Pro running Linux Mint and iOS High Sierra; an ASUS laptop running Windows 10; and a custom built gaming computer using Windows 11 (prolific cable not compatible) and Linux Mint. All of these attempts were done using both types of cables
I also tried using the legacy version of Chirp on all of these systems with no luck. I've made sure the PL tones are turned off on the radio, I've tried programming it while the radio is in channel mode and tried it in VFO. I have taken my radio apart to inspect the 3.5mm jack and board, but everything looked fine. I took apart my prolific cable to make sure all the soldering points still looked strong, and they were.
I tried using the manufacturers programing software with a custom driver set for the prolific cable on Windows 10 and also attempted running their program in Windows XP, Vista, 7 and 8.
All of these attemps resulted in a "failed to communicate with radio" error.
I expected the radio to load its information into Chirp, the same way every other radio has performed.
Files
| config.txt (1.44 KB) config.txt | |||
| debug_log.txt (5.64 KB) debug_log.txt | |||
| QYT7900 SN.jpg (110 KB) QYT7900 SN.jpg | |||
| chirp_debug-duart8wi-badack.txt (7.98 KB) chirp_debug-duart8wi-badack.txt |
Updated by Ben Stearns 14 days ago
- File config.txt config.txt added
- File debug_log.txt debug_log.txt added
[Uploaded from CHIRP next-20241101]
Updated by Jim Unroe 13 days ago
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.
Updated by Ben Stearns 12 days ago
- File QYT7900 SN.jpg QYT7900 SN.jpg added
Yes, it was definitely plugged into the data port. As a matter of fact, while doing some research I came across someone claiming that they could only program their 7900 using the headphone jack. Since I was out of options, I tried that for the heck of it and got a "Bad Ack from radio" message, which I expected. I've tried two of the prolific cables and then that brand new cable with the FTDI chip.
It seems to me that everything is working fine from the computer to the radio. I'm basing that on the fact that I received a different error message when plugging into the phone jack than the data jack. I feel like it would have been the same error message on either jack if it was an issue with the cable.
I was able to program a second radio which is identical to this one about 4 months ago using chirp, but I can't remember if it was Legacy or NEXT. That was on my ASUS laptop running Windows 10. Now neither of the two radios can communicate to a computer.
Is it possible to force a firmware update to the radio, or possibly rollback the firmware to a previous version? Maybe QYT had a batch of these 7900's with similar problems? S/N is attached if that helps.
Thanks,
Updated by Dan Smith 12 days ago
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.
Updated by Ben Stearns 12 days ago
I just tried it again through the audio jack. debug log is attached as "chirp_debug-duart8wi-badack"
Thanks,
Updated by Ben Stearns 11 days ago
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.
Updated by Dan Smith 11 days ago
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.
Updated by Jim Unroe 11 days ago
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.
Updated by Ben Stearns 11 days ago
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?
Updated by Dan Smith 11 days ago
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.
Updated by Ben Stearns 11 days ago
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?
Updated by Dan Smith 11 days ago
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.