Bug #4355

Failed to read from Alinco DJ-G7

Added by Klaus Noack over 3 years ago. Updated 5 months ago.

Status:Closed Start date:01/01/2017
Priority:Normal Due date:
Assignee:Mathias Weyland % Done:

0%

Category:-
Target version:-
Chirp Version:daily Platform:All
Model affected:Alinco DJ-7G EG

Description

After selecting "Download from Radio" an error occured: Failed to communicate with radio: invalid literal for int() with base 16: '\x8a6'

debug.log (20.9 kB) Klaus Noack, 01/01/2017 04:56 pm

Chirp.log (6.3 kB) Klaus Noack, 01/02/2017 11:45 am

ERW-4C.jpg (1.9 MB) Klaus Noack, 01/02/2017 11:45 am

alinco_djg7_baud_rate_1.patch (3.2 kB) Mathias Weyland, 01/09/2017 06:47 am

Alinco_DJ-G7EG_20171024.img (105.9 kB) Emiel v, 10/24/2017 10:38 am


Related issues

related to Bug #5275: Improper treatment of unknown fields for Alinco DJ-G7 Closed 10/24/2017

Associated revisions

Revision 2850:5d1703ad859f
Added by Mathias Weyland over 3 years ago

Alinco DJ-G7: Try slower baud rate if default rate fails (#4355)

Alinco support is suggesting to use lower baud rates if the programming
software fails to communicate with the radio reliably. This patch
alters the code for the Alinco DJ-G7 radio such that if falls back to
19200 baud if the default of 57600 baud does not work. The user must
set his radio to 19200 baud for this mechanism to kick in. Dialog boxes
were added accordingly using the chirp_common.RadioPrompts() feature.

History

Updated by Mathias Weyland over 3 years ago

Klaus

Can I ask you to check the firmware version of your unit? I implemented the support for this radio by reverse engineering the communication between my own DJ-G7EG and the official programming software. Alinco states that their own software is to be used with "firmware version 4_10 or higher" and there's the possibility that whatever breaks the official programming software in older firmware versions also fails with chirp.

(Please do not upload an image from a new-firmware radio into an old-firmware radio). When this radio was implemented into chirp, I did not know how a unit with an old firmware would respond. Hence it was not possible to check and warn the user if he is required to upgrade. Your debug.log fixed that such that it would be possible to add such a check, which I would be willing to implement. Maybe there's a way for you to hold off a firmware upgrade for a few more days in order to test this. This only holds if you're indeed running an old firmware though.

Thanks again and happy new year! Matt

Updated by Mathias Weyland over 3 years ago

As a quick follow-up: I just talked to a friend and he strongly suggested not to upgrade the firmware because apparently this has some implications that might potentially be nasty. I'm just writing this because I mentioned firmware and potential firmware upgrades but I don't want you to brick your radio.

Updated by Klaus Noack over 3 years ago

The Firmware of my unit is EG5.100 (never changed by my).

It seems to be newer than the firmware on the download-site of Alinco.
So it is impossible for me to make an upgrade and a downgrade is normaly not a good idea.

There seems to be two kinds of DJ-7G EG: "DJ-G7EG European model" and "DJ-G7EG Universal model".
I don't know which one I have. The Serial-No. seems to be M004083 if it helps. Bought Dec 2013.

BTW the original cloning software of Alinco also does not work.
- "EG_DJG7_CloneUtility_V1.4" for "DJ-G7EG Universal model" the reads sometimes the first memory then "Port error".
- "E_DJG7_CloneUtility_V1.7" for "DJ-G7EG European model" returns always with "Error".

TIA for Your help and also a happy new year!

Updated by Mathias Weyland over 3 years ago

Interesting, I did not expect this to be EG5.100. My own radio, purchased last year, has the same firmware version. I was not able to find a firmware that recent online, but I have been testing the code with older versions and it always worked. Of course I fully agree, it would be a bad move to try to downgrade the firmware.

I haven't fully understood what's going on with the serial communication. Breaking down the log we have:

[2017-01-02 01:40:38,500] chirp.drivers.alinco - DEBUG: PC->R: (12) 'AL~DJ-G7EG\r\n'
[2017-01-02 01:40:38,516] chirp.drivers.alinco - DEBUG: R->PC: ( 6) 0D8A4F4B0D0A

Which is the software checking if the Radio is indeed a DJ-G7EG. The correct response should be '\r\nOK\r\n'. However your radio replies with

>>> line='0D8A4F4B0D0A'
>>> [chr(int(line[i:i+2],16)) for i in range(0, len(line), 2)]
['\r', '\x8a', 'O', 'K', '\r', '\n']

That's all fine except for the second byte. Instead of sending the newline 0x0a, you're getting 0x8a. At least that's what ends up in chirp -- somehow the MSB gets flipped from '0' to '1'.

The software tries to ID the radio three times. Next time it tried, we got this:

[2017-01-02 01:40:39,530] chirp.drivers.alinco - DEBUG: PC->R: (12) 'AL~DJ-G7EG\r\n'
[2017-01-02 01:40:39,546] chirp.drivers.alinco - DEBUG: R->PC: ( 6) '\r\nOK\r\n'

This is the expected result, so the software continues by pulling the first chunk of memory (address 0x0200):

[2017-01-02 01:40:39,546] chirp.drivers.alinco - DEBUG: PC->R: (11) 'AL~F00200R\r'
[2017-01-02 01:40:39,592] chirp.drivers.alinco - DEBUG: R->PC: (132) 0D8A363430303634303036343030363430303634303036B430303634303036B4303036343030363430303030303030303030303030303030303030B0303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030300D0A

Again, this should start with '\r\n' and the second byte ends up being 0x8a instead of 0x0a (= \n). Note that the issue is not constrained to that newline, since you also have a bunch of 'B0' that should be '30'. Again flipping the MSB in '30' yields 'B0'. This is quite strange indeed, I guess I have to consult a few other developers to make sense out of that. In the mean time, may I ask what kind of programming cable you are using and if you're confident that the cable is good?

As for the official cloning software, I only ever managed to get V 1.4 (which curiously identifies as V 1_3_3 in the title bar) to work with my radio. I suspect that this is the version that would work with yours too. It might be the case that the cloning software is encountering the same problem: When that 0x0a gets flipped to 0x8a, it gets confused and aborts. As with the 'OK' response in the log, this somehow seems to work every now and then (second try was successful) which would explain why the software sometimes manages to read the first block. While unrelated to chirp, the cloning software allows you to read individual chunks instead of the whole image which might be another thing you could maybe try.

Regards

Matt

Updated by Klaus Noack over 3 years ago

Hi Matt,

The cable was bought as a ERW-4C and a EDS-14 with the Radio but I never used them... I don't know how to check them :-(

The docking station of my Laptop has a real RS232 (COM1) but the problem is the same, so the USB2Serial adapter seems to be OK.
I attached the new striped debug.log. Most of the errors are flipping the MSB but at least on time a 0x34 changes to 0xBE.

My cloning software also shows 1_3_3 in the title bar. Sometimes reading small parts with it seems to be OK, but very rarely.
I opened my ERW-4C and attached a picture if you want to compare it with yours.

Regards
Klaus

Updated by Mathias Weyland over 3 years ago

Hm OK it's getting hard not to blame the hardware. Looking at the schematic, it seems as if the radio uses one single pin for serial RX and TX in a half-duplex fashion. If I'm not mistaken, this would imply automatic echoing of whatever is send to the cable. Maybe this is another thing you could try to rule out your cable is bad (i.e. stress-testing the cable). I've also been told that a programming cable for (or compatible to) the Yaesu VX-3 would work too. If you have one of those this might be worth a shot.

Updated by Klaus Noack over 3 years ago

OK it seems the problem is the hardware and not CHIRP - so you can close this bug report.
I have no comparable cable here so can not check whether it is a problem of the radio or the cable.
I have also found the schematic of the cable. Perhaps I build my own, but this may take a time.
Thanks again for your effort.

Updated by Mathias Weyland over 3 years ago

  • Status changed from New to Closed

I'm closing the ticket as suggested. Thank you

Updated by Klaus Noack over 3 years ago

I have got an answer from Alinco due to their program also doesn't work.
They told me to use a lower speed for transfer data (rotate Dial while holding MONI key; eg. to "CLONE 19200bps").
I found no way to use a lower speed in their program, but if I changed in chirp/drivers/alinco.py the BAUD_RATE to 19200 the download from the radio works :-)
But now I see that you only support the smaller character for the memory names...

Updated by Mathias Weyland over 3 years ago

Ha nice to see progress! In particular when it seems that chirp is becoming superior to the official program in some aspects :-). I think I can address the "small character" issue you're having since this seems to be something that is within the realm of what I can change. Unfortunately though I'm not entirely sure what you mean. Chirp should be able to handle upper case characters ("ABC") in addition to lower case ones ("abc") already but I'm probably misunderstanding your issue. If you think this would be an important feature, I'd be more than happy to give it a try. I'd like to ask you to open a new case for that though to keep things neat. Ideally with a description of what the program should do vs. what it does and how to get to the point where the lack of feature or an error message shows. Also if chirp is mis-parsing something, another one of those debug.log files would be amazing since they allow me to trace down where things to wrong. From memory, the channel names are coded with two bytes per character. In all my test runs, the second byte was always 0x00 and I had assumed this was for repersenting Japanese symbols or something. But let's discuss this in the new ticket.

Regards and thanks! Matt

Updated by Klaus Noack over 3 years ago

I would open a new ticket for the characters.

An annotation for this report. Is it possible to select the COM port speed in CHIRP?

Updated by Mathias Weyland over 3 years ago

  • Status changed from Closed to In Progress
  • Assignee set to Mathias Weyland

Reopening because I like this idea. Making the baud rate fully settable by the user would involved quite a bit of GUI work that I'm not really comfortable doing yet. However, another approach is implemented for few radios already and I think it would fit this use case quite nicely: Just try different baud rates, starting with the default baud rate. If the software cannot talk to the radio with the default baud rate, it now just errors after three attempts. But instead it could just add another three rounds with the lower baud rate, e.g. 19200. I'll see what I can do to add this to to the DJ-7G code.

Updated by Mathias Weyland over 3 years ago

This is a preliminary patch to support and auto-detect the lower baud rate in addition to the default. It also adds prompt dialogs to instruct the user how to set up the radio properly for the programming process. I will not have the opportunity to test this with an actual radio until next week end, so it was written blind and there's going to be a bug somewhere.

Klaus, not sure if you want to test this on your own. If you feel like doing it, just revert your BAUD_RATE change and apply the patch and give it a try. It should behave exactly as you described initially when you keep you radio at 57600. When you set it to 19200, it should behave like when you change BAUD_RATE manually except for that there will be a ~3 second delay during which it is trying to communicate at the fast rate. There should also be an entry in the log file informing you that it's dropping to the low baud rate. If you don't want to give it a try, that would be perfectly OK. In that case I'd try it myself as soon as I get access to the gear required to do it.

Updated by Klaus Noack over 3 years ago

Is working here as specified!

The 19200 was my first try (the middle of 57600 and 4800) and not the suggestion of Alinco. They said only: "[...] Combination of ERW-4 with a modern, faster PC sometimes cause trouble communicating. [...]"

Updated by Klaus Noack over 3 years ago

FYI: I tried only reading up to now due to #4381.

Updated by Pieter Smit over 3 years ago

Hi Klaus, Mathias,
I am experiencing the same problem as Klaus has and would like to apply the patch that Mathias supplied.
Can you explain how to apply the patch to Chirp please. Is there some documentation I should refer to for this as well as how to create the debug.log and chirp.log files?
Thanks very much,
Pieter.

Updated by Mathias Weyland over 3 years ago

Hi Pieter

I wanted to add a few more changes to the initial patch before I submit it for inclusion into the daily build. Unfortunately though I did not get around adding those extra changes yet, so I submitted the patch as-is and will add the other changes in a separate patch at a later stage.

For you, this means that the latest as well as future daily builds come with the "try slow baud rate if the normal one fails" patch already built in -- no need for you to patch anything. Just grab the latest daily here:

http://trac.chirp.danplanet.com/chirp_daily/

The log file can be created by starting chirpw with the --log debug.log parameter.

HTH and regards -- Matt

Updated by Emiel v almost 3 years ago

Hi, maybe this observation might help:

1 Channels written by Chirp work well on my DJ-G7EG.
2 Those channels only show "mode" and "step" when the clone utility 2.05 reads them from the DJ-G7EG.
All other fields remain empty! (and it works only with "one memory read"; "memory read" doesn't work).
3 Chirp sees all fields of records it reads from the DJ-G7EG which were made by the clone utility 2.05.
4 Records made by the clone utility and send to DJ-G7EG, can be altered by Chirp, send to the DJ-G7EG by Chirp; and all fields will show in the clone utility 2.05

It seems that the clone utility (and I think manual entering in the DJ-G7EG as well) might add / sets a hidden field for each record?

See the attached file: records 1-111 were made by chirp; records 202-212 were made by the clone utility

I hope this helps 73 Emiel PA2EM

Using a DJ-G7EG firmware 5.10 ; Chirp 20-10-2017 ; clone utility 2.05 from Alinco website

Updated by Mathias Weyland almost 3 years ago

Emiel, thanks for contributing to the bug report!

I believe this is an issue that is different from the one that is being tracked in this ticket. Therefore, I opened a new ticket for the bug that you reported (#5275). The good news is that I think I know what is causing this and a fix seems to be easy. In the new bug's description, I have written a description of what I believe is going on. Could you maybe quickly check if this is in line with what you did? (It has to do with defining memory channels in chirp that were previously empty / not used). Also can we continue the discussion about this new issue there? That would help me to keep things organized.

And thanks for the image file, that is very helpful. Let's see if I can cobble together a patch after dinner.

Regards and thanks!

Matt

Updated by Bernhard Hailer 5 months ago

  • Status changed from In Progress to Closed
  • Platform changed from Windows to All

This appears to be complete.

Also available in: Atom PDF

prevent spam