CHIRP

Okay, thanks. It's getting absolutely nothing from the radio, so I suspect cabling or radio configuration issues. I don't have this radio though so I'm copying the author to see if he has suggestions.

Also, unrelated, but note that tomorrow's build will be dropping support for python 3.9, which I see you're running in bullseye (by default).

Dan Smith wrote in #note-3:

Okay, thanks. It's getting absolutely nothing from the radio, so I suspect cabling or radio configuration issues. I don't have this radio though so I'm copying the author to see if he has suggestions.

Also, unrelated, but note that tomorrow's build will be dropping support for python 3.9, which I see you're running in bullseye (by default).

So it looks like I'll have to locate and buy Alinco's programming cable and try again (and also figure out how to upgrade python3 since there's no newer version in the repositories.) Thanks, Dan. 73 de DW7GDL.

I think it's probably a cable/physical layer issue as well. I saw that the
USB device is a CH340. I have read elsewhere (
https://www.transmission1.net/viewtopic.php?t=59212) some folks using those
USB-serial chips have an issue with it due to the strong PU resistance on
the TX line. I tested with a homebrew cable from this schematic (
http://n0dim.com/Documents/Build-a-OPC-478U-Clone-200727.pdf) and used an
FTDI USB-serial chip and used a 47k PU.

On Fri, Apr 12, 2024, 9:04 PM Jay Mottern redmine@chirpmyradio.com wrote:

Yeah, there has been a sharp increase in the number of seriously terrible aftermarket cables recently, so it's easy to believe that's the problem I think. It's unfortunate for sure.

Note that upgrading to debian bookworm will get you python 3.11.

Nope, the baud rate is set by chirp. Also, your debug log indicates that it's actually talking to the radio now, but the model string (DR735TE) is different from what the driver expects (DR735TN). Is yours the european version perhaps? I imagine we can make the driver just accept either string, but I'll defer to Jacob for that. Happy to cook up a test driver for you to try if that's the case.

It says it's a T on the box and manual and I was able to put it into
crossband repeater mode once, but I bought it in the Philippines so
heaven knows what firmware they put into it. Usually, radios from the
Big Three purchased here are US versions but this is my first ever
Alinco (I'm usually a Yaesu guy.) Maybe it's an Asian or Japanese
version that's an odd hybrid of the T and E?

If a modification to make CHIRP support both versions of the radio is
what's needed to let me access it from my computer, and if it isn't
going to brick my radio, I'm all for it and will be happy to help test it.

73.

On 4/21/24 09:31, Dan Smith wrote:

Yaesus are really fragile when it comes to this sort of thing. I'm not sure about Alincos because I don't have has much experience with them, which has me a bit timid. I certainly can't promise it's safe. I think the best thing would be to wait for Jacob to opine about robustness. Perhaps we can also just download an image from it and see if it looks basically identical. Certainly most of the geo-variants are identical, but there's one example I can think of (a Yaesu of course) that has multiple things under the same badge but that differ quite a bit between the variations.

How can I download an image from the radio?

Off-topic but I wish all radios were as simple as my Retevis RT95 VOX.
Unfortunately I needed a dual band radio with a 6 pin mini DIN data jack
and the Alinco is the only one I could find unless you count the
counterfeit Yaesu FT-7900Rs from China. No one with a used radio that
had that jack was willing to part with them, so now I'm stuck with the
Alinco.

I can program it from the radio and mic and it works OK, but when
something doesn't work properly I miss being able to look at everything
in CHIRP so I can see what I did wrong. :)

By the way, I was able to use Alinco's "memory editor" in Windows 10
yesterday to communicate with the radio, but unfortunately (or
fortunately, maybe, as I dislike Windows) the only way I could get
Bookworm to install was to do a full disk installation which wiped out
my Windows partitions. All Alinco's app did was save the memory and
settings to a .csv file anyway.

73.

On 4/21/24 10:32, Dan Smith wrote:

Okay, so, the two channels you added look reasonably similar to the format of the example file we have in the tree. However, as you probably noticed, the rest of the file is "blanked" in a different way than the example file, which is why you see all the failed-to-load memories after that.

So at the very least, we'll need a variant driver for the other one that handles that difference. But, let's wait for Jacob to (hopefully) chime in after he has a chance to have a look.

OK, I've been waiting for almost 2 weeks. I can wait longer. No rush,
and thanks for your work. 73.

On 4/21/24 12:08, Dan Smith wrote:

Now that I'm finally able to download from the radio I tried a couple of
experiments, just FYI. (More data for you even if it turns out not to be
relevant to the issue.)

After a complete, factory reset I set advanced set menu item 33, memory
channel mode selection, to MEMORY L/R to give me separate memories for
the left and right VFOs. I added a bunch of marine band VHF channels to
the one on the left (I plan to use the left VFO as a scanner) and
entered 439.9875MHz in the right VFO as I plan to use it along with the
6 pin mini DIN TNC jack as a wide-range POCSAG paging transmitter for
DAPNET (https://hampager.de/) then downloaded an image in CHIRP. The far
left column in the image was entirely red and none of my programmed
frequencies appeared. I recall that yesterday when I used Alinco's
memory editor tool there was a long list of I assume common memory
channels, followed by a list of ones whose memory names began with an L,
followed by another whose names began with an r (lower case) and these
were where my programmed frequencies appeared. (I wish I had saved that
csv file before I lost my Windows installation during the Linux upgrade.)

I changed menu item 33 to MEMORY COMMON and reprogrammed all of the
frequencies then downloaded in an image in CHIRP again. This time all of
my frequencies show up but all the rows afterward are red in the first
column, just like the earlier image with the two repeaters. Furthermore,
when I try to enter a name for 439.9875 in CHIRP it says Invalid edit:
unable to find a supported tuning step for 439.987500. (The tuning step
for the right VFO is set to 12.5.)

Don't know if this is helpful or not.

73.

On 4/21/24 12:08 PM, Dan Smith wrote:

(While you're in there, is it possible to make the row with the column
titles slightly taller? Titles with two words one atop the other, like
"tone mode" and "tone squelch", are partially cut off on the top and
bottom.)

This has nothing to do with the driver, it's a core CHIRP thing. It is probably a result of whatever GTK theme ends up getting loaded for you, and as you probably know, linux UI themes are a huge surface to cover. If you can show me a screenshot and also maybe indicate what themes you're running I might be able to have a look at this. But, we should keep it separate from the driver work.

@Jay Boehme, glad to hear it worked. @Daniel Fiechter, I will tidy up these changes, test, and drop them in a PR in the next week or so.

Should I open a new bug report about 12.5KHz not being recognized as a
valid tuning step?

On 4/24/24 00:23, Jacob Calvert wrote:

The 12.5kHz step thing is driver-specific so it's related. I haven't tried to reproduce or look at why the driver is rejecting it. Jacob, I'd like to get this fix out as soon as we can, so if you don't have time to look into the 12.5kHz thing before you get it into a PR I can have a look.

I think I know the problem for the tuning step also. I can get it into the
same PR, but I am traveling until next week and won't be able to test it
until then, but if you want to fix it before then please do and I'll just
PR for the European version addition and factory reset fixes.

73

On Tue, Apr 23, 2024, 6:36 PM Jay Mottern redmine@chirpmyradio.com wrote:

Can I just land the latest version here? You said you had cleanups to do, but I haven't diff'd it to see what those are. Not a huge deal to wait, but I can do the paperwork of landing it and working in the 12.5kHz thing so you don't have to.

I meant to comment here that I just applied the change here (fixing a few things it regressed related to detection and logging the model string). I also added 12.5 to the available tuning step list, which seemed to work for me. We can do further cleanups if necessary and if the 12.5 fix wasn't actually sufficient, please open another bug.

Thanks!