CH340G - based chips/adaptors: Not reading data correctly
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.
Updated by Brian Dickman over 6 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
Updated by Stephen Ireland over 6 years ago
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?
Updated by Dan Smith over 6 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.