CHIRP

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

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.

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.

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

Strange indeed. Looks like we have to review the specifics for the DR-235. Thank you!

Thanks, let me know if you need further testing/informations

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.

please ignore this "This gets even better when i activate the "enable developer options" check, now"

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.

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: ----------------------------

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.