Project

General

Profile

Actions

Bug #7385

open

Baofeng UV-5R - CHIRP fails to connect using Ubuntu 18 LTS & Prolific USB cable

Added by Olof Tångrot about 5 years ago. Updated over 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
11/30/2019
Due date:
% Done:

0%

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

Description

Latest daily build for Debian/Ubuntu is used, latest Windows build is used (2019-11-30)

The radio seem to have firmware BFB307 (BFB297 shown on btn 3 pwr on).
Operating procedure on Ubuntu:
After selecting the correct USB unit and starting down loading from the radio nothing happens.
No download dialogue, error message or any activity on the radio device.

On my Windows 10 machine using the same cable and radio device the following happens.
1) Radio is turned on, PTT becomes activated by the cable -> radio device in TX mode.
2) Download is commenced using CHIRP OK dialogue button. PTT becomes released -> TX mode ends.
3) Download dialogue is shown -> No activity on the radio device
4) Download times out with error dialog about non responsive device or is cancelled using dialogue button. -> Radio device remains in passive RX mode.
5) New download attempt using CHIRP, down load dialogue is shown -> Radio device indicator flashes red.
6) Download dialogue progress bar increments.
7) Download completes. -> Radio device remains in passive RX mode.
8) After a few seconds the radio reboots and after some more time TX mode.

If I change operating procedure and starts the radio device just before the download is started on the Windows machine; the down load starts directly after 'OK'
but that does not work using ubuntu. Using Gtkterm a "BREAK" seems to activate PTT on the radio. So somehow it seems like the Linux/Ununtu version
fails to make the radio enter programming mode but also seem to assert from the download at that point. Possibly this is related to failing to send "BREAK" on the serial device.


Files

debug.log (23.8 KB) debug.log Olof Tångrot, 04/21/2020 11:48 AM
debug.log (33.9 KB) debug.log Olof Tångrot, 04/21/2020 12:09 PM
Actions #1

Updated by Bernhard Hailer over 4 years ago

  • Status changed from New to Feedback
  • Platform changed from Windows to All

Could you please provide debug logs for both OSes as described in the Wiki: "How To Report Issues"? Thanks!

Actions #2

Updated by Olof Tångrot over 4 years ago

I don't really know where that cable is right now.

Actions #3

Updated by Bernhard Hailer over 4 years ago

Ok, we'll keep the ticket open for a few more days.

Actions #4

Updated by Olof Tångrot over 4 years ago

Looks like some Python exception under from the Ubuntu log.

Actions #5

Updated by Olof Tångrot over 4 years ago

Log from windows 10.

Actions #6

Updated by Bernhard Hailer over 4 years ago

Olof, it looks like you are having trouble accessing /dev/ttyUSB0. That could be a permission issue.
Please check the Wiki document "Connection Issues using Ubuntu" and report back here. Good luck!

Actions #7

Updated by Olof Tångrot over 4 years ago

olof@olof-HP-ProBook-6450b:~$ id
uid=1000(olof) gid=1000(olof) groups=1000(olof),4(adm),5(tty),10(uucp),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),109(lpadmin),124(sambashare),130(kismet),1001(wireshark)

I can also open /dev/ttyUSB0 or using gtkterm.

Wrong privileges is not the problem.

Actions #8

Updated by Olof Tångrot over 4 years ago

I checked with a FTDI cable (no radio attached) and it seems to fail the same way so it is most likely not related to the USB-drivers for the attached devices.

Actions

Also available in: Atom PDF