Bug #2605

IC-T70A does not work with FTDI cable at all

Added by Nick Papadonis about 5 years ago. Updated 5 months ago.

Status:Closed Start date:05/21/2015
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:chirp-daily
Chirp Version:daily Platform:All
Model affected:Icom IC-T70

Description

I have an Icom IC-T70A and a Genuine FTDI USB cable that supports OPC-i478 from reputable seller. Unfortunately, I keep getting an error downloading from the radio. "Failed to communicate with the radio: Unexpected response from radio". As device manager says the COM port is ok, I'm suspecting something else is going on. The USB serial cable is properly detected by my Mac OSX v10.10.3 as a USB serial device. The device properly appears in the OS as /dev/cu.usbserial-A9030T4G. I tried a couple versions of Chirp and used this device path. In my tests I tried downloading from the radio both by specifying Icom / IC-T70 and then Icom / Autodetect. Both setting resulted in failure to communicate with the radio. The radio then begins to cycle memory channels after the download fails. I have attached the Chirp debug log from a recent daily build 2015-05-02. I tried an older build from a year ago from 2014-12-15 with the same results. I have also noticed a few bugs around this radio and wondering if perhaps an older Chirp build works correctly. I am able to successfully program a Baofeng BF-F8HP+ (UV-5R) with FTDI cable.

I have also tried the same test under Windows XP in VirtualBox using FTDI drivers from FTDI with the same results. The USB port was shared in VirtualBox and properly detected by device manager. I have also tried a genuine Prolific cable as well with the same results.

I'm suspecting there is an issue with the protocol implementation talking to this radio given that multiple operating systems, cables and Chirp revisions. Any insight appreciated in getting this working or identifying a Chirp version that was previously known to work with this radio.

debug.log (13.8 kB) Nick Papadonis, 05/21/2015 04:57 pm

debug.log (16.5 kB) Nick Papadonis, 05/25/2015 08:57 pm

debug.log - Windows 7 SP1 debug log (21.7 kB) Nick Papadonis, 05/26/2015 06:15 am


Related issues

related to Bug #240: For Icom IC-T70A using Mac OS X Closed 07/11/2012

History

Updated by Nick Papadonis about 5 years ago

I tested the Radio with Mac 10.6.8 and have same issue. I installed official FTDI drivers for the Mac and the cable is properly detected as a USB device. I installed latest Chirp build from 2015-05-22. I tried to "cat" the serial device file in /dev/cu* and force radio into clone mode by pressing V/M/C + Power. When pressing PTT radio starts sending clone data and updating progress, however nothing is seen output from serial device file. I'm suspicious of the cable even though it's detected properly. If someone else has the IC-T70 would appreciate feedback into how you're programming this radio and if serial data can be seen on PC when pressing PTT and com program. Thanks

Updated by Nick Papadonis about 5 years ago

I'm attaching a recent debug log. It looks like there is no response (0 bytes) coming back from the radio. I'm wondering if this is a Mac issue, cable issue or perhaps the radio control codes changes in recent models?

[2015-05-25 23:52:42,981] chirp.detect - ERROR: Unexpected response from radio
[2015-05-25 23:52:44,056] chirp.drivers.ic9x_ll - INFO: Switching from 4800 to 38400
[2015-05-25 23:52:45,187] chirp.drivers.icomciv - DEBUG: 70 -> e0 (7):
000: fe fe 70 e0 19 00 fd 00 ..p.....

[2015-05-25 23:52:45,705] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:45,705] chirp.drivers.icomciv - DEBUG: 76 -> e0 (7):
000: fe fe 76 e0 19 00 fd 00 ..v.....

[2015-05-25 23:52:46,231] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:46,231] chirp.drivers.icomciv - DEBUG: 46 -> e0 (7):
000: fe fe 46 e0 19 00 fd 00 ..F.....

[2015-05-25 23:52:46,744] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:46,745] chirp.drivers.icomciv - DEBUG: 70 -> e0 (7):
000: fe fe 70 e0 19 00 fd 00 ..p.....

[2015-05-25 23:52:47,272] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:47,273] chirp.drivers.icomciv - DEBUG: 76 -> e0 (7):
000: fe fe 76 e0 19 00 fd 00 ..v.....

[2015-05-25 23:52:47,798] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:47,798] chirp.drivers.icomciv - DEBUG: 46 -> e0 (7):
000: fe fe 46 e0 19 00 fd 00 ..F.....

[2015-05-25 23:52:48,324] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:48,324] chirp.drivers.icomciv - DEBUG: 70 -> e0 (7):
000: fe fe 70 e0 19 00 fd 00 ..p.....

[2015-05-25 23:52:48,834] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:48,834] chirp.drivers.icomciv - DEBUG: 76 -> e0 (7):
000: fe fe 76 e0 19 00 fd 00 ..v.....

[2015-05-25 23:52:49,345] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:49,345] chirp.drivers.icomciv - DEBUG: 46 -> e0 (7):
000: fe fe 46 e0 19 00 fd 00 ..F.....

[2015-05-25 23:52:49,858] chirp.drivers.icomciv - DEBUG: Read 0 bytes total
[2015-05-25 23:52:49,860] chirp.ui.reporting - DEBUG: Reporting exception
[2015-05-25 23:52:49,860] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Unable to get radio model ---
[2015-05-25 23:52:49,860] chirp.ui.inputdialog - ERROR: Traceback (most recent call last):
File "/Applications/chirp-daily-20150502.app/Contents/Resources/chirp/chirp/ui/clone.py", line 175, in run
cs.radio_class = detect.DETECT_FUNCTIONS[vendor](cs.port)
File "/Applications/chirp-daily-20150502.app/Contents/Resources/chirp/chirp/detect.py", line 76, in detect_icom_radio
result = _detect_icom_radio(ser)
File "/Applications/chirp-daily-20150502.app/Contents/Resources/chirp/chirp/detect.py", line 68, in _detect_icom_radio
raise errors.RadioError("Unable to get radio model")
RadioError: Unable to get radio model

Updated by Nick Papadonis about 5 years ago

Update: I tested this with Windows 7 SP1 using v2.12 FTDI drivers and believe this is from what I can tell a genuine FTDI chip with proper PID. The FTDI USB to Serial converter shows up as COM6 and I'm getting the same errors downloading from the radio. I set Icom->Detect and get a message "Unable to detect radio model". The radio is powered on in VFO mode and I see no activity on the radio's LCD during the Download operation.

Looking at attached logs, it looks like Chirp is sending the radio a model identification frame, however is receiving back a 0 byte response. This makes me wonder if the frame is correct or possibly the identification command changed in a newer manufacturing run of this radio.

I'm also curious about the following log message:
chirp.drivers.ic9x_ll - INFO: Switching from 4800 to 38400

Is Chirp changing the baud rate of the COM port accidentally in earlier driver and forgetting to place it back to 9600?

Updated by Nick Papadonis about 5 years ago

Note: one more data point. I tested Chirp v0.1.12 and get the same results. Unable to detect radio model. My suspicion is a cable issue here. It's appreciated if anyone else can comment on their experience programming this model. Thanks

Updated by Nick Papadonis about 5 years ago

It appears that the last two cables I used were root cause of the problem. I used a cheap Prolific off Ebay, it was detected as a COM Port, however did not communicate with the radio. I used an expensive FTDI purchased off Ebay from a US Ham seller and it did not work. I purchased a Valley Enterprises FTDI from Amazon and it did not work. Finally, I gave up and purchased the RT Systems Cable and Software. I can confirm that Chirp 4.x worked with no special adjustments using the RT Systems cable and Windows 7. I confirmed that download and upload works. The radio properly displays the CLONE text automatically when Chirp initiates the transfer. This was not happening at all with the other cables.

Unfortunately, I lack proper test equipment to look at the cable, however my suspicion is perhaps the voltage levels were different between the working "RT Systems" cable and the Generic cables online.

Updated by Stanley Law over 4 years ago

@Nick where you ever able to get the FTDI Cable to work?

I too have the bluemax49ers ebay cable from KJ6ZWL and it makes my HT scan continuously. This happens on both Windows 7 x64 and Mac OS X (all versions 10.6+).

Besides having to purchase an RT Systems cable, have you had any luck with any other forms of remediation?

Updated by Adam Collins about 4 years ago

I can confirm the fix using a cable from RT Systems and Chirp. The cable from Valley Enterprises would not work on the ic-t70A.

Updated by Mark Dunkle almost 3 years ago

I think I have found the solution. The IC-T70 works with the Prolific chipset, not the FTDI chipset. I have encountered this problem with Alinco radios as well.
I have updated my listing for the IC-T70 on eBay and I offer the Prolific chip version of the OPC-478 as an alternative for everyone.

Updated by Mark Dunkle almost 3 years ago

I think I have found the solution. The IC-T70 works with the Prolific chipset, not the FTDI chipset. I have encountered this problem with Alinco radios as well.
I have updated my listing for the IC-T70 on eBay and I offer the Prolific chip version of the OPC-478 as an alternative for everyone.

Regards,
Mark Dunkle
BlueMAx49ers
KJ6ZWL

Updated by Mark Dunkle almost 3 years ago

I think I have found the solution. The IC-T70 works with the Prolific chipset, not the FTDI chipset. I have encountered this problem with Alinco radios as well.
I have updated my listing for the IC-T70 on eBay and I offer the Prolific chip version of the OPC-478 as an alternative for everyone.

Regards,
Mark Dunkle
BlueMax49ers

KJ6ZWL

Updated by Bernhard Hailer 5 months ago

  • Status changed from New to Closed
  • Target version set to chirp-daily
  • Model affected changed from IC-T70 to Icom IC-T70

Solution suggested. No more traffic on this ticket.

Also available in: Atom PDF