CHIRP

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

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.

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(EGR) 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(EGR)_DJG7_CloneUtility_V1.4" for "DJ-G7EG(EGR) 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!

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

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.

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.

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

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

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?

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. [...]"

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

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.

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

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