Bug #4361: Interface cable bug - CHIRP

Actions

Copy link

Bug #4361

closed

Interface cable bug

Added by Ole Hermann almost 8 years ago. Updated about 4 years ago.

Status:

Closed

Priority:

Low

Assignee:

Category:

Target version:

Start date:

01/04/2017

Due date:

% Done:

Estimated time:

Chirp Version:

daily

Model affected:

(All models)

Platform:

Windows

Debug Log:

I read the instructions above:

Description

No problems with CHIRP, only an info around COM-ports used by CHIRP :-)
I have discovered a minor problem when using different USB cables!
The problem is created by Windows(10) where I'm forced to use an older driver (3.3.3.12x).
Windows assign different COM-numbers to different cables even I'm only using one cable a time, so for the moment I have my Baofeng cable on COM3 and the new KT8900 cable on COM5 when I connect cable. A newer cable from Baofeng (suppose different chip) is assigned to COM4 whenever it likes to work ;-) :-(

Actions

Copy link

Updated by Jim Unroe almost 8 years ago

Status changed from New to Feedback

Hi Ole,

I use mostly Prolific chip based programming cables here. Because most of them have an unauthorized copy of the Prolific chip, I must also install and select the older Prolific v3.2.0.0 device driver in my Windows based physical computers and virtual machines. The reason I prefer programming cables with the Prolific type chip is because they are cheaper, easier to find for the various radios that I have and +because I can switch between them at will and the COM port number does not change+.

It is when the programming cable is plugged into a different USB port that Windows installs another copy of the device driver and then assigns a different COM port number. But once this is done, you can go into Device Manage and reassign the COM port number. I have done this on the 2 USB ports on the front of my computer. No matter which USB port I plug any of my Prolific based programming cables into, the result is always the same COM port number.

And if each of your programming cables has a different type of chip (Prolific, FTDI, SiLabs, etc), then they will be assigned different COM port number. The issue I have then is that CHIRP preselects the COM port that was used last no matter if it currently available or not. I don't know if this behavior could be changed or not.

FTDI based programming cables are usually assigned a different COM port number for each programming cable. I read that there is a registry edit that can be made so that the FTDI device driver behaves the same as the Prolific device driver in this regard, but I have never tried myself.

Jim KC9HI

Actions

Copy link