Project

General

Profile

Actions

Bug #7455

closed

Baofeng UV-5R radio not responding

Added by John Kilco over 4 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
12/12/2019
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
Baofeng UV-5R
Platform:
All
Debug Log:
I read the instructions above:

Description

Chirp daily latest version used
original FTDI radioddity usb cable used
It appears from the error.log that the Radio id (Baofeng UV-5R)is rejected thus causing an error
Firmware (3 + Power on) BFB298
Radio UV-5R 136-174mhz 400-520mhz S/N 13u38131131

error file

[2019-12-12 10:46:06,249] chirp.ui.reporting - DEBUG: Checking for updates
[2019-12-12 10:46:06,911] chirp.ui.reporting - DEBUG: Server reports version daily-20191206 is latest
[2019-12-12 10:49:34,784] chirp.ui.mainapp - DEBUG: User selected Baofeng BF-F8HP on port /dev/ttyUSB0
[2019-12-12 10:49:35,070] chirp.ui.clone - DEBUG: Clone thread started
[2019-12-12 10:49:35,073] chirp.drivers.uv5r - INFO: Sending Magic: 000: 50 bb ff 20 12 07 25 00 P.....%.

[2019-12-12 10:49:35,213] chirp.drivers.uv5r - DEBUG: '\x00'
[2019-12-12 10:49:35,214] chirp.drivers.uv5r - ERROR: uv5r._ident_radio: Radio did not respond
[2019-12-12 10:49:37,217] chirp.drivers.uv5r - INFO: Sending Magic: 000: 50 bb ff 20 14 04 13 00 P.......

[2019-12-12 10:49:37,292] chirp.drivers.uv5r - DEBUG: '\xfc'
[2019-12-12 10:49:37,293] chirp.drivers.uv5r - ERROR: uv5r._ident_radio: Radio did not respond
[2019-12-12 10:49:39,298] chirp.drivers.uv5r - INFO: Sending Magic: 000: 50 0d 0c 20 16 03 28 00 P.....(.

[2019-12-12 10:49:39,375] chirp.drivers.uv5r - DEBUG: '\x87'
[2019-12-12 10:49:39,382] chirp.ui.reporting - DEBUG: Reporting exception
[2019-12-12 10:49:39,383] chirp.ui.common - ERROR: -- Exception: --
[2019-12-12 10:49:39,388] chirp.ui.common - ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 256, in run
self.__radio.sync_in()
File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 809, in sync_in
self._mmap = _do_download(self)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 543, in _do_download
data = _ident_radio(radio)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 538, in _ident_radio
raise error
RadioError: Radio did not respond

[2019-12-12 10:49:39,389] chirp.ui.common - ERROR: ----------------
[2019-12-12 10:49:39,390] chirp.ui.clone - ERROR: Clone failed: Radio did not respond
[2019-12-12 10:49:39,400] chirp.ui.clone - DEBUG: Clone thread ended
[2019-12-12 10:49:39,412] chirp.ui.reporting - DEBUG: Reporting model usage: Baofeng_BF-F8HP,download,True
[2019-12-12 10:49:39,418] chirp.ui.reporting - DEBUG: Reporting exception
[2019-12-12 10:49:39,418] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Radio did not respond ---
[2019-12-12 10:49:39,430] chirp.ui.inputdialog - ERROR: None

[2019-12-12 10:49:39,431] chirp.ui.inputdialog - ERROR: ----------------------------


Files

debug.log (28.3 KB) debug.log bit basher, 01/21/2020 05:54 PM
MVIMG_20200121_205255.jpg (44.4 KB) MVIMG_20200121_205255.jpg bit basher, 01/21/2020 07:35 PM
debug.log (26.1 KB) debug.log debug GREG ST MARTIN, 02/20/2020 02:56 PM
uv5-r_no_hello.logicdata (3.45 KB) uv5-r_no_hello.logicdata Kiril Zyapkov, 05/31/2020 08:02 AM
debug.log (23.8 KB) debug.log John Kilco, 06/08/2020 03:25 PM
Actions #1

Updated by bit basher over 4 years ago

Where is error.log generated? You need to enable it from the Help->Enable Developer Functions first, yes?

I did search chirp website and did not find this answer. TIA.

Actions #2

Updated by Jim Unroe about 4 years ago

  • Status changed from New to Feedback

The radio is either not communicating with CHIRP (which could be a programming cable, device driver or connection issue between the 2-pin plug and the speaker/mic socket) or the user is selecting the wrong radio model.

Why are you choosing BF-F8HP when you have a UV-5R?

Jim KC9HI

Actions #3

Updated by Jim Unroe about 4 years ago

bit basher wrote:

Where is error.log generated? You need to enable it from the Help->Enable Developer Functions first, yes?

I did search chirp website and did not find this answer. TIA.

You do not have to enable anything. CHIRP always generates a debug.log file when it runs. The "How To Report Issues":https://chirp.danplanet.com/projects/chirp/wiki/How_to_report_issues page shows how to locate the debug.log file in all 3 supported operating systems.

Jim KC9HI

Actions #4

Updated by John Kilco about 4 years ago

I have been unable to respond before but her is current error log, the issue with false radio being chosen is not the issue. Cable is producing electrical output as checked with multimeter...

current error log below:

2020-01-07 19:45:55,563] chirp.ui.reporting - DEBUG: Checking for updates
[2020-01-07 19:45:56,099] chirp.ui.reporting - DEBUG: Server reports version daily-20200107 is latest
[2020-01-07 19:47:53,683] chirp.ui.mainapp - DEBUG: User selected Baofeng UV-5R on port /dev/ttyUSB0
[2020-01-07 19:47:53,687] chirp.ui.clone - DEBUG: Clone thread started
[2020-01-07 19:47:53,688] chirp.drivers.uv5r - INFO: Sending Magic: 000: 50 bb ff 20 12 07 25 00 P.....%.

[2020-01-07 19:47:53,760] chirp.drivers.uv5r - DEBUG: '\x00'
[2020-01-07 19:47:53,760] chirp.drivers.uv5r - ERROR: uv5r._ident_radio: Radio did not respond
[2020-01-07 19:47:55,763] chirp.drivers.uv5r - INFO: Sending Magic: 000: 50 bb ff 01 25 98 4d 00 P...%.M.

[2020-01-07 19:47:55,836] chirp.drivers.uv5r - DEBUG: '\xf0'
[2020-01-07 19:47:55,837] chirp.drivers.uv5r - ERROR: uv5r._ident_radio: Radio did not respond
[2020-01-07 19:47:57,838] chirp.drivers.uv5r - INFO: Sending Magic: 000: 50 0d 0c 20 16 03 28 00 P.....(.

[2020-01-07 19:47:57,911] chirp.drivers.uv5r - DEBUG: '\x87'
[2020-01-07 19:47:57,913] chirp.ui.reporting - DEBUG: Reporting exception
[2020-01-07 19:47:57,913] chirp.ui.common - ERROR: -- Exception: --
[2020-01-07 19:47:57,914] chirp.ui.common - ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/clone.py", line 256, in run
self.__radio.sync_in()
File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 809, in sync_in
self._mmap = _do_download(self)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 543, in _do_download
data = _ident_radio(radio)
File "/usr/lib/python2.7/dist-packages/chirp/drivers/uv5r.py", line 538, in _ident_radio
raise error
RadioError: Radio did not respond

[2020-01-07 19:47:57,915] chirp.ui.common - ERROR: ----------------
[2020-01-07 19:47:57,915] chirp.ui.clone - ERROR: Clone failed: Radio did not respond
[2020-01-07 19:47:57,917] chirp.ui.clone - DEBUG: Clone thread ended
[2020-01-07 19:47:57,920] chirp.ui.reporting - DEBUG: Reporting model usage: Baofeng_UV-5R,download,True
[2020-01-07 19:47:57,931] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Radio did not respond ---
[2020-01-07 19:47:57,932] chirp.ui.inputdialog - ERROR: None

[2020-01-07 19:47:57,932] chirp.ui.inputdialog - ERROR: ----------------------------
[2020-01-07 19:47:57,934] chirp.ui.reporting - DEBUG: Reporting exception

it appears cable is ok....
radio wake up not working

I am a dumbo but trying#

Actions #5

Updated by John Kilco about 4 years ago

Have decided that output from software is ok, Drivers & cables are ok.. so its a radio connection problem.... I am going to take it apart to see what it is......

Will update solution (I hope here)

Actions #6

Updated by bit basher about 4 years ago

Found the debug.log. Looks to match John's reported debug log as well.

John - you think it's the radio? I did read on a few boards that (1) you have to really press the spk/mic connectors into the radio jacks and (2) sometimes licking the contacts helps. (shrug)

FWIW - I have to UR-5Vs that exhibit the same behaviour. Very interested in hearing your results!

Let me know what experiments I can perform to help!

Actions #7

Updated by bit basher about 4 years ago

Okay - I think I have a process that works for me. I'm a new ham myself, so this might be well known.

Make sure that the radio is in frequency mode and the channel is clear. Follow the instructions exactly as the pop-up screen tells you to.

Once the cable is in, I press the radio down onto the table.

Actions #8

Updated by Jim Unroe about 4 years ago

bit basher wrote:

Okay - I think I have a process that works for me. I'm a new ham myself, so this might be well known.

Make sure that the radio is in frequency mode and the channel is clear. Follow the instructions exactly as the pop-up screen tells you to.

Once the cable is in, I press the radio down onto the table.

There is no need for a UV-5R type radio to be in VFO (frequency) mode when programming with CHIRP. This is only a requirement for manual programming.

Jim KC9HI

Actions #9

Updated by GREG ST MARTIN about 4 years ago

Also getting a connection error when trying to connect to the BAOFENG UV-5R. My friend tried to program it and could not get it to connect to the radio when attempting to download. I just tried and am getting a similar issue with the BFB298 firmware. I checked by holding down the "3" button and powering on the radio. This flashes BFB298. I select the correct radio model in the latest version of CHIRP downloaded today. It says cloning the radio then comes back a few seconds later with a box that says "An error has occurred" "The radio did not respond". I have a BTECH UV-5X3 and it communicates fine so I know it is not a cable issue.

Attaching the debug file.

Any ideas?

Actions #10

Updated by Bernhard Hailer about 4 years ago

  • Model affected changed from (All models) to Baofeng UV-5R
  • Platform changed from Linux to All

The debug logs indicate that the radios don't respond at all. A previous post mentions that the connector has to be pressed hard into the radio - that's a common problem with these cheap Chinese radios. If the connector isn't seated right, then the radio can't send data and Chirp can't read it.

There are various solutions, such as pressing the connector in hard while cloning, shaving off some material from the connectors housing, or replacing the connector with one which fits better.

Please let us know if you succeed.

Actions #11

Updated by John Kilco about 4 years ago

Have tried numerous ideas including taking radio apart, the plug connections are mounted too far back on the board relative to the housing of the radio, that's why people say push plug very hard in etc.........I thinks its a pure electrical connection issue (This is not the first radio I have programmed I also have the same problem with a Radiocity radio copy (I forget model). it's not the cable as it works elsewhere, it's not a driver problem......)

I have limited resources here so things take time I am in the process of building 2 new 2.5mm and 3.5mm plugs that are longer to check connectivity. I have already built 2 new cables having ordered usb chips and plugs and they don't work either... so go think

I will report back when completed.

Actions #12

Updated by Bernhard Hailer almost 4 years ago

I believe we can close this? It seems to be the common problem with this type of radio not allowing to seat the cable plug deep enough. If there's no further feedback, we'll close the ticket soon.

Actions #13

Updated by Kiril Zyapkov almost 4 years ago

Archlinux, AUR package chirp-hg updated just now.

I am experiencing the same issue with 3 UV-5R radios and a cable which was known to work. I used it a couple of days ago to program one of my radios and it worked! I later upgraded chirp and now:

File "/usr/lib/python2.7/site-packages/chirp/drivers/uv5r.py", line 538, in _ident_radio
raise error
RadioError: Radio did not respond

I removed ~/.chirp and tried fresh a couple of times. Once, I was able to get chirp to talk to the radio by mistakenly selecting the wrong model. It errored out, and I am not able to reproduce it.

With the correct model (UV-5R) I only see the magic bytes being sent by the PC, the radio doesn't respond indeed, confirmed with a logic analyzer. But it used to work.

Actions #14

Updated by Kiril Zyapkov almost 4 years ago

I should probably also mention that I built 2 new cables, using another original FTDI cable and a CP2101 breakout board, verified each, none works with Chirp. The jacks are all the way in.

Actions #15

Updated by Kiril Zyapkov almost 4 years ago

release_0_3_1 is incompatible with the system's pyserial package:

File "/usr/lib/python2.7/site-packages/chirp/uv5r.py", line 460, in sync_in
raise errors.RadioError("Failed to communicate with radio: %s" % e)
RadioError: Failed to communicate with radio: 'Serial' object has no attribute 'setTimeout'

so I cannot easily confirm that the older version works.

Actions #16

Updated by Bernhard Hailer almost 4 years ago

Two possibilities:
1) the radio doesn't hear your computer. That would still be a connector problem; i.e. the data signal from the computer is not actually making contact with the radio, and the radio doesn't respond. Your cable might be fine, your connector might be fine, but the radio socket often isn't.
2) you got radios with a firmware which has cloning disabled (N5R firmware family, if I remember right). In that case you're out of luck. :-(

Actions #17

Updated by Kiril Zyapkov almost 4 years ago

I was planning to open up one of those anyway, for a mic preamp mod.

https://dl3.pushbulletusercontent.com/GxO6j40967g9d2pinQuQPkenJzOU0rda/20200531_124457.jpg

Also, measured < 2ohm between FTDI cable connector and PCB solder points of the jacks when using my DIY cables. Results remain the same. The radio still works fine with a headset.

Actions #18

Updated by Kiril Zyapkov almost 4 years ago

Attached is a Saleale-logic capture. Magic bytes are sent at 9600 baud with a large pause in-between. TX/RX channels are 0/1. Is this how things are supposed to look?

Maybe this is related to the version of pyserial (3.4) or the USB-serial driver, or kernel?

Actions #19

Updated by Jim Unroe almost 4 years ago

Kiril Zyapkov wrote:

release_0_3_1 is incompatible with the system's pyserial package:

File "/usr/lib/python2.7/site-packages/chirp/uv5r.py", line 460, in sync_in
raise errors.RadioError("Failed to communicate with radio: %s" % e)
RadioError: Failed to communicate with radio: 'Serial' object has no attribute 'setTimeout'

so I cannot easily confirm that the older version works.

Hi Kiril,

Part of the issue is that you have a very old version of CHIRP installed (v0.3.1 from 2014). Please update to the most recent CHIRP daily build to see if that solves the issue.

Jim KC9HI

Actions #20

Updated by Kiril Zyapkov almost 4 years ago

... you have a very old version of CHIRP installed (v0.3.1 from 2014) ...

I tried to downgrade to see if the old version works. I was running a build of https://aur.archlinux.org/packages/chirp-hg package, but I've since checked out the source and managed to get the py3 branch working. It needs 2to3 on chirp/{drivers,ui}, but this didn't solve my problem either. I'll try to find other cables and radios to test with.

Actions #21

Updated by Jim Unroe almost 4 years ago

Kiril Zyapkov wrote:

... you have a very old version of CHIRP installed (v0.3.1 from 2014) ...

I tried to downgrade to see if the old version works. I was running a build of https://aur.archlinux.org/packages/chirp-hg package, but I've since checked out the source and managed to get the py3 branch working. It needs 2to3 on chirp/{drivers,ui}, but this didn't solve my problem either. I'll try to find other cables and radios to test with.

This is still a very old version of CHIRP. Download the latest CHIRP daily build tarball and use it.

Jim KC9HI

Actions #22

Updated by Kiril Zyapkov almost 4 years ago

No. I've tried the latest tip, and the py3 tip from mercurial. I am not running v0.3.1. Sorry for the multiple comments.

Let me summarize: I am not getting any response from all 3 of my UV-5R radios which previously worked without issues. The error is identical to the one originally reported here and is reproducible with the latest hg tip. I've done my best to verify that my USB-Serial chips and cable are OK. Currently working on the py3 branch on Archlinux with pyserial 3.4, linux kernel 5.6.15, python 3.8.3

Actions #23

Updated by Kiril Zyapkov almost 4 years ago

Sorry, my bad. For some reason a gpsd service was configured to poke serial ports (via hotplug/udev??). Normality is restored.

Actions #24

Updated by Bernhard Hailer almost 4 years ago

  • Status changed from Feedback to Resolved

Glad to hear.
Is this anything we should put into our FAQ? What did you do to resolve it?

Actions #25

Updated by John Kilco almost 4 years ago

Resolved, is not quite correct, it works on one of my slightly older radios BUT not the newest one, so there is still a problem.

Actions #26

Updated by Bernhard Hailer almost 4 years ago

  • Status changed from Resolved to Feedback

Reopening, not resolved.

Actions #27

Updated by Jim Unroe almost 4 years ago

John Kilco wrote:

Resolved, is not quite correct, it works on one of my slightly older radios BUT not the newest one, so there is still a problem.

You don't say which radios don't work. The debug.log file shows that you don't have the "python-future package" installed. It is required for some radios models.

In the Ubuntu terming enter the following command:

pip install future

Jim KC9HI

Actions #28

Updated by Bernhard Hailer over 3 years ago

  • Status changed from Feedback to Closed

No more traffic on this ticket.

Actions #29

Updated by Robert iovino over 1 year ago

bit basher wrote:

Okay - I think I have a process that works for me. I'm a new ham myself, so this might be well known.

Make sure that the radio is in frequency mode and the channel is clear. Follow the instructions exactly as the pop-up screen tells you to.

Once the cable is in, I press the radio down onto the table.

BRILLIANT. This resolved my problem instantly, especially your LAST line!
Cheers. Robert

Actions

Also available in: Atom PDF