Bug #8093
openAlinco DR-235T: Unexpected response from radio
Added by Hamtaro Uhuhuh almost 4 years ago. Updated over 3 years ago.
0%
Description
Hi, i'm trying to read/write memories from my Alinco DR-235T but i encountered some issues:
OS: Windows 10 x64
Version: chirp-daily-20200711
Radio: Alinco DR-235T MK III
USB Cable: Icom OPC-478
When i try to read from the radio i get the error: Unexpected response from radio. The error appears every time both on Windows and Ubuntu 20.04
If i try to read the radio by setting as model DR-135T or DR-435T everything works fine but i'm not able to write 220MHz frequencies (of course, the expected range of those radio is different...)
Files
Updated by Hamtaro Uhuhuh almost 4 years ago
This debug log includes the logging when selecting model as DR-135T, it works on reading memories
Updated by Bernhard Hailer almost 4 years ago
- Status changed from New to Feedback
- Platform changed from Windows to All
These family of Alinco radios belong to the sort which dislikes FTDI chipsets when connected through Chirp for some reason. What kind of serial cable are you using - does the Icom OPC-478 use FTDI? You can look this up in Windows Device Manager. If it is FTDI, then your best bet is to find a cable with a (genuine!) Prolific chip. The cheap ones with fake Prolifics will give you additional grief.
Some generic information about cables here:
CableGuide
CableGuide FTDI OEM Cables
[RTSystemsCablesAndMavericks]
If there's no solution to be found in any of them, please read: How To Report Issues and provide a debug log. Thank you!
Windows notes: If you are using a generic cable with a Prolific chip, you will very likely need to downgrade your driver to version 3.2.0.0.
It can be found at http://www.miklor.com/COM/UV_Drivers.php
MacOS notes: this OS is apparently very picky about USB to Serial cables. From what I heard, only (genuine) FTDI-based cables can be made work.
You must have the KK7DS Python runtime for Mac OSX installed.
Also see MacOS Tips!
Linux notes: Linux generally is quite good with USB to Serial converter drivers. The most likely cause for grief is a connector which doesn't provide good electrical contact.
Bluetooth notes: connections often suffer from timing issues, please try a cable instead.
Updated by Hamtaro Uhuhuh almost 4 years ago
Thanks for the informations, i'd like to exclude the cable because if i only change the model in the "Download from radio" menu the download routine works fine. i've already attached both log files, the firts one with chirp set as DR-235 (reporting the error) and the second one with the software set as DR-135 and reading the memories successfully
Updated by Bernhard Hailer almost 4 years ago
I know. The problem is that the issue with the cable appears to be related to serial timing. Some radios might just be within the tolerance window, and some other fail - that might even happen within the same family of radios. I have a couple of them, in my case all happen to fail with FTDI cables. So, please check whether you have an FTDI cable - that might be the problem.
Updated by Bernhard Hailer almost 4 years ago
I just reviewed the logs again, though. I'm not sure, but perhaps your DR-235 is not allowing cloning? Thing is, it does report an error when the first memory block is requested.
[2020-07-17 19:42:12,900] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR235\r\n' [2020-07-17 19:42:12,921] chirp.drivers.alinco - DEBUG: R->PC: ( 6) '\r\nOK\r\n' [2020-07-17 19:42:12,921] chirp.drivers.alinco - DEBUG: PC->R: (11) 'AL~F0000R\r\n' [2020-07-17 19:42:13,183] chirp.drivers.alinco - DEBUG: R->PC: ( 9) '\r\nERROR\r\n'
I haven't played with mine for a while; maybe the manual gives some pointers.However, it also could be that the radio didn't get the command right due to a transmission error. So checking for the chipset in your cable is still recommended.
Updated by Hamtaro Uhuhuh almost 4 years ago
this is a bit strange, as i said, if i tell chirp that the connected radio is a DR-135 or DR-435 everything works just fine, by modifying the frequency range in the "alinco.py" file i'm also able to use any other model to read the 220mhz channels. Using any other models only works to read, nwhen trying yo write memories it shows: "i'm not able to talk to this radio".
i've also checked and i'm using a PL2303 cable with original chip (as the tools from Prolific website said). btw i also used a chinese usb to ttl adapter with same risults
Updated by Bernhard Hailer almost 4 years ago
Strange indeed. Looks like we have to review the specifics for the DR-235. Thank you!
Updated by Hamtaro Uhuhuh almost 4 years ago
Thanks, let me know if you need further testing/informations
Updated by Bernhard Hailer almost 4 years ago
I had a quick look into the drivers. All Alincos use the same driver, and the DR-135, 235, and 435 (and also the DR-06) use even the same subclass. They are all using the same command set. There's no difference.
Even weirder: the radio does come back with the string '\r\nERROR\r\n' - it doesn't like the command 'AL~F0000R\r\n' which is used the same on the other radios. Chirp doesn't find a ':' in the response string and reports an "unexpected response".
Let me ask you this: what exactly did you change in the "alinco.py" file to read the 235 with another model selection? Perhaps this points us somewhere.
Updated by Hamtaro Uhuhuh over 3 years ago
There you go, i did a couple of attempts and created two new models:
- DR235-MODA: this doesn't work and shows "Unecpexted response from radio"
@[2020-07-18 10:47:06,454] chirp.ui.clone - DEBUG: Clone thread started
[2020-07-18 10:47:06,454] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR235\r\n'
[2020-07-18 10:47:06,473] chirp.drivers.alinco - DEBUG: R->PC: ( 6) '\r\nOK\r\n'
[2020-07-18 10:47:06,473] chirp.drivers.alinco - DEBUG: PC->R: (11) 'AL~F0000R\r\n'
[2020-07-18 10:47:06,734] chirp.drivers.alinco - DEBUG: R->PC: ( 9) '\r\nERROR\r\n'
[2020-07-18 10:47:06,734] chirp.ui.reporting - DEBUG: Reporting exception
[2020-07-18 10:47:06,734] chirp.ui.common - ERROR: -- Exception: --
[2020-07-18 10:47:06,734] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 256, in run
File "chirp\drivers\alinco.pyo", line 199, in sync_in
File "chirp\drivers\alinco.pyo", line 141, in _download
File "chirp\drivers\alinco.pyo", line 121, in _download_chunk
RadioError: Unexpected response from radio@
- DR235-MODB: i copied this from the DR435 and only changed frequency range, this configuration is able to read memories from the radio but when trying to write is shows "i can't talk to this model"
@[2020-07-18 10:50:27,132] chirp.ui.mainapp - DEBUG: Opening port after pre_upload prompt.
[2020-07-18 10:50:27,210] chirp.ui.clone - DEBUG: Clone thread started
[2020-07-18 10:50:27,210] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR435\r\n'
[2020-07-18 10:50:27,470] chirp.drivers.alinco - DEBUG: R->PC: ( 0) ''
[2020-07-18 10:50:28,470] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR435\r\n'
[2020-07-18 10:50:28,729] chirp.drivers.alinco - DEBUG: R->PC: ( 0) ''
[2020-07-18 10:50:29,729] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR435\r\n'
[2020-07-18 10:50:29,986] chirp.drivers.alinco - DEBUG: R->PC: ( 0) ''
[2020-07-18 10:50:30,987] chirp.ui.reporting - DEBUG: Reporting exception
[2020-07-18 10:50:30,987] chirp.ui.common - ERROR: -- Exception: --
[2020-07-18 10:50:30,990] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 254, in run
File "chirp\drivers\alinco.pyo", line 212, in sync_out
RadioError: Failed to communicate with radio: I can't talk to this model
[2020-07-18 10:50:30,990] chirp.ui.common - ERROR: ----------------
[2020-07-18 10:50:30,990] chirp.ui.clone - ERROR: Clone failed: Failed to communicate with radio: I can't talk to this model
[2020-07-18 10:50:31,039] chirp.ui.clone - DEBUG: Clone thread ended
[2020-07-18 10:50:31,039] chirp.ui.reporting - DEBUG: Reporting model usage: Alinco_DR435T,upload,True
[2020-07-18 10:50:31,040] chirp.ui.reporting - DEBUG: Reporting exception
[2020-07-18 10:50:31,040] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Failed to communicate with radio: I can't talk to this model ---
[2020-07-18 10:50:31,040] chirp.ui.inputdialog - ERROR: Traceback (most recent call last):
File "chirpw", line 68, in
AttributeError: 'NoneType' object has no attribute 'split'@
I guess is because it's trying to talk to a DR435 instead.
This gets even better when i activate the "enable developer options" check, now
Updated by Hamtaro Uhuhuh over 3 years ago
please ignore this "This gets even better when i activate the "enable developer options" check, now"
Updated by Bernhard Hailer over 3 years ago
Hmm. Just thinking - is your DR-235 perhaps a non-US version? Unlikely, because I believe 220 MHz isn't available to hams in other regions.
Still, please share the image you loaded down from the DR-235 using the DR-435 driver. The driver checks for a few things in the image before accepting the model. Perhaps something is different in your radio compared to the models used for development. Probably a small thing.
Updated by Hamtaro Uhuhuh over 3 years ago
there I am, I got quite busy in the last days...
Btw, with the latest Daily 20200718 I can finally read memories from the radio selecting DR-235 as model but the download still fails:
[2020-07-26 13:59:40,079] chirp.ui.memedit - ERROR: Editing new item, taking defaults [2020-07-26 13:59:40,217] chirp.ui.editorset - DEBUG:changed [2020-07-26 13:59:53,155] chirp.ui.mainapp - DEBUG: Opening port after pre_upload prompt. [2020-07-26 13:59:53,282] chirp.ui.clone - DEBUG: Clone thread started [2020-07-26 13:59:53,283] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR235\r\n' [2020-07-26 13:59:53,299] chirp.drivers.alinco - DEBUG: R->PC: ( 6) 38E1BAE9C30A [2020-07-26 13:59:54,299] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR235\r\n' [2020-07-26 13:59:54,318] chirp.drivers.alinco - DEBUG: R->PC: ( 6) '\r\nERRO' [2020-07-26 13:59:55,319] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR235\r\n' [2020-07-26 13:59:55,335] chirp.drivers.alinco - DEBUG: R->PC: ( 6) '5\r\n\r\nO' [2020-07-26 13:59:56,336] chirp.ui.reporting - DEBUG: Reporting exception [2020-07-26 13:59:56,336] chirp.ui.common - ERROR: -- Exception: -- [2020-07-26 13:59:56,338] chirp.ui.common - ERROR: Traceback (most recent call last): File "chirp\ui\clone.pyo", line 254, in run File "chirp\drivers\alinco.pyo", line 212, in sync_out RadioError: Failed to communicate with radio: I can't talk to this model [2020-07-26 13:59:56,338] chirp.ui.common - ERROR: ---------------- [2020-07-26 13:59:56,338] chirp.ui.clone - ERROR: Clone failed: Failed to communicate with radio: I can't talk to this model [2020-07-26 13:59:56,414] chirp.ui.clone - DEBUG: Clone thread ended [2020-07-26 13:59:56,502] chirp.ui.reporting - DEBUG: Reporting model usage: Alinco_DR235T,upload,True [2020-07-26 13:59:56,503] chirp.ui.reporting - DEBUG: Reporting exception [2020-07-26 13:59:56,503] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Failed to communicate with radio: I can't talk to this model --- [2020-07-26 13:59:56,505] chirp.ui.inputdialog - ERROR: Traceback (most recent call last): File "chirpw", line 68, in AttributeError: 'NoneType' object has no attribute 'split' [2020-07-26 13:59:56,505] chirp.ui.inputdialog - ERROR: ----------------------------
Updated by Hamtaro Uhuhuh over 3 years ago
Bernhard Hailer wrote:
Hmm. Just thinking - is your DR-235 perhaps a non-US version? Unlikely, because I believe 220 MHz isn't available to hams in other regions.
Still, please share the image you loaded down from the DR-235 using the DR-435 driver. The driver checks for a few things in the image before accepting the model. Perhaps something is different in your radio compared to the models used for development. Probably a small thing.
The radio is a US version, bought last summer at HamRadio Outlet.