Project

General

Profile

Actions

Bug #4125

closed

CH340G - based chips/adaptors: Not reading data correctly

Added by Stephen Ireland over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
10/11/2016
Due date:
% Done:

0%

Estimated time:
Chirp Version:
0.4.0
Model affected:
(All models)
Platform:
Windows
Debug Log:
I read the instructions above:

Description

Hi,

The CH350G is a commonly used chip these days to supersede the PL2303.

You get buffer-under-runs/over-runs with this chip when used with the latest wch.cn supplied driver.

i.e. Wouxun KG-UVD1P -

"Failed to communicate with radio: Failed to read full block (65!=64).

Also unspecified issues with Baofeng radios.

All works perfectly with FTDI (possibly fake) Chip.

Using Windows 10 1607.

Please investigate.

73

Steve I
VK3VM

Actions #1

Updated by Brian Dickman over 7 years ago

  • Status changed from New to Closed

Unfortunately, the functionality of the chip and driver is out of CHIRP's control. The program asks for data from the driver, and it is up to the cable chip and driver to return the correct amount of data. As you note, FTDI chips do work properly so we know CHIRP is behaving as expected. We recommend using FTDI-based cables going forward. You may also refer to the cable guide page here: http://chirp.danplanet.com/projects/chirp/wiki/CableGuide

Actions #2

Updated by Stephen Ireland over 7 years ago

Hi,

I actually find this to be a strange response.... as the entire CHiRP project is dedicated to advancing the free and open access to hardware that is somewhat shunned by the traditionals - i.e. Icom, Yaesu, Kenwood and major manufacturers such as FTDI.

The reason that I raise the CH340G is in relation to its exposure out there with the Arduino "Clones" etc.

Note that I have been able to apply the CH340G in almost every application and see it work better than chips that are prices 10 - 100 times its price. The only application that I cannot see it functioning correctly in is CHiRP.

I have seen this error a number of times before in very early CHiRP versions....

Therefore perhaps it is worthy of investigation/reinvestigation?

Steve I

Actions #3

Updated by Dan Smith over 7 years ago

No, really. As Brian says, CHIRP has no idea which driver or chip you're using. It can't. It's insulated from all of that by the serial line discipline abstraction layer of the operating system. We have no existing code in chirp that is specific to any driver or chip because we can't.

Actions

Also available in: Atom PDF