Bug #229
closed
Baofeng UV-5r An Error has Occured the radio did not respond
Added by Jordan McGilvray almost 12 years ago.
Updated about 4 years ago.
Model affected:
Baofeng UV-5R
I read the instructions above:
Description
I do the following:
In the GUI I select Radio > Download from Radio
I select /dev/ttyUSB0 (The only USB device) Baofeng UV-5r
The program looks for input from the radio for a second or two and then spits a dialog box which says: An Error has Occured the radio did not respond
The terminal displays the following:
Clone thread started
''
-- Exception: --
Traceback (most recent call last):
File "~/Downloads/chirp-daily-20120630/chirpui/clone.py", line 223, in run
self.__radio.sync_in()
File "~/Downloads/chirp-daily-20120630/chirp/uv5r.py", line 262, in sync_in
self._mmap = _do_download(self)
File "~/Downloads/chirp-daily-20120630/chirp/uv5r.py", line 180, in _do_download
data = _do_ident(radio)
File "~/Downloads/chirp-daily-20120630/chirp/uv5r.py", line 136, in _do_ident
raise errors.RadioError("Radio did not respond")
RadioError: Radio did not respond¶
Clone failed: Radio did not respond
Clone thread ended
--- Exception Dialog: Radio did not respond ---
None¶
- Status changed from New to Feedback
This means that chirp was able to open the serial port and the radio didn't respond. There are a number of possible reasons for this, and I would recommend you look through the archives of the UV-5R for details. Here are a few common ones:
- Cable not fully inserted (this affects a ton of folks)
- Bad cable (most of them available now are knock-off USB chips with major problems)
- The radio is not on, or is locked into transmit mode
I used the vendor software once and then tried Chirp. I get the same error using chirp.
I went back to the vendor software and it doesn't find the radio either.
How can we confirm that the USB cable is still working?
Also, radio seems to reset after the read is tried. So it would appear that data is getting to the radio
but not back to the program.
Tnx, WB9VXY
One more observation. If I use GTKterm to talk to the radio when I send a break I get the LED on the radio to flash RED and I get a bunch
of binary characters back. Doesn't appear that they are the same each time.
If I send the 50 bb ff 01 25 98 4d init string I see a brief blink of the RED led but no characters appear in the GTKterm window.
Tnx,
T3
Sorry for so many posts. I keep giving up and then thinking of "one more thing" to try.
So, I shorted from the Ring of the 2.5mm to the Sleeve of the 3.5 mm connector
which according to the web is TX to RX.
When I open the port with GTKterm I see what I type echoed back on the screen. Echo goes away
when I loose the short.
At one point with GTKterm I started getting the 0x06 answer back from the radio then it went
away and I have not been able to get it back.
Maybe a bad connection to the sleeve on the connector or ??
Gave up, unplugged everything, turned off radio. Tried again in the morning and it worked first time,
reading and writing.
Unplugged and tried again and couldn't read. Re-plugged and all was good.
WB9VXY
Better late than never:
On Windows 7 , using a cheap knock-off cable, I found that the cable used a (probably fake) Prolific PL2303 USB-to-Serial adapter. Windows installed the latest driver, but I had to manually install an older version of the driver (v. 3.4.25.218) in order to get the software to communicate with the radio. Once I manually installed the software, everything worked fine.
- Status changed from Feedback to Closed
- Chirp Version changed from 0.2.2 to daily
- Model affected changed from (All models) to Baofeng UV-5R
Issues seem to have been resolved. No more traffic on this ticket.
Also available in: Atom
PDF