CHIRP

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.

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

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#

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)

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

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.

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.

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.

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.

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.

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. :-(

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.

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

... 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.

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

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

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

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

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