❌

Reading view

There are new articles available, click to refresh the page.

A New Approach To Winlink

βœ‡KC8JC
KC8JC

This Again?

I have twisted and worked my way around this problem for some time now and this probably isn’t the last time that I will revisit this topic. However, my station is evolving and as a result, I’m going to make some notes here and share what I know so that other folks can make use of it. Honestly? It’s more so that I will remember how I got here when I inevitably screw something up and have to back it out.

Why Are We Doing This Again?

My solution for the home setup, was to run Win11 on a stick PC that I could interface with the IC-7100 for Winlink email and Other Stuff. Now, what is Other Stuff? In ham radio, we have an unhealthy relationship to old and busted Windows-Only software. It’s changing slowly, but there are still weird packages that find their way into my hands that I β€œneed” to use for This or That.

With the shift from the barely usable Win10 to the What Is This Nightmare Of Constant Advertising Win11, MS pushed me too far. Every time I touch what used to be the Start Menu, I get an advertisement or some unwanted tidbit of news with a picture of a politician or other pop culture nuisance. On top of that, they’d now like me to have an β€œAI” that follows me around and trains itself using my hardware?

We’re done here.

CrossOver

I don’t know how the link came to me, but I found my way to WG1V’s site and encountered a very different approach to solving the Winlink/Vara/All That Stuff conundrum.

https://www.wg1v.org/posts/2023-12-27-Winlink-and-Pat-on-M1-Mac

The author simply runs CrossOver on their Mac and all of the stuff works.

Now, back in the day, as a Frothy Linux Zealot, I was a reluctant user of Wine to address some needs I had in my day job. I wrestled with it and made it work. Over time, running VMs to handle this stuff seemed to become the new hotness and I didn’t even think about CrossOver for the Mac. The trouble with a VM is that it’s still a full install of Windows and still antagonistic to my desired mental state. Would CrossOver really do the trick?

In a word: Yes.

Following the instructions at the above link, I got VARA HF and ARDOP up and running on my Mac which is what I attach to my shiny new IC-7300 in my shack. It worked out of the box with no fiddling. Full disclosure: I hadn’t updated brew in some time so that took a minute, but with that done, everything else fell into place.

What about the Other Stuff? Most of the radio software out there that might be used for programming an HT for example, is built on ancient frameworks that happen to run reliably under CrossOver. I even pulled up some piece of software that I used to program my DMR HT and it worked out of the box. That outcome was unexpected, but most welcome.

Now What?

To send Winlink mail, I kick off rigctrl and pat with its HTTP UI from a command line and launch either ARDOP or VARA from CrossOver and send my Winlink mail. This gets me two big wins: No Windows and No Winlink Express. This is called Winning.

I have been noodling with my Surface Go to make sure that I can use the 7300 under my Ubuntu setup as well. I want my two main computing devices to be fully ready to run any rig I’ve got that can do a digital mode. On Ubuntu, it will be ARDOP and pat as well. For me, that’s a well-oiled setup with the IC-705. I need to take a minute to add the IC-7300 to the configuration. No big deal, just 10 minutes or so when I get it.

The outcome of all of this is that I now have a single shack computing device that is my Mac and I can do all of the things that I do in one place. Simplifying things is good. And I’ve even got this little stick PC that I can throw something on for an internal fileserver or something.

The Future

In an ideal world, someone (maybe me someday?) will get ARDOP running on a Mac. ARDOP is under active development again and these are exciting times for that modem. I can’t wait to see where it goes! But for now, I will leverage it in this new ecosystem with CrossOver. It works and that’s what matters.

Final

It’s probably pretty clear that I’m willing to work with all flavors of software in different evironments. I’m not opposed to paying for useful software, though my first stop will always be Free/Open solutions. The sticking point here is that I don’t have a lot of time to mess around with some of this stuff and this approach gets me from A to B rather quickly. Again, Winning.

Thanks for reading along!

Loading

ICOM IC-9700 and IC-7300 coexisting in Linux

βœ‡x8x.net
GI7UGV

I’ve just added an IC-9700 to the desk alongside the IC-7300, they look very nice together and very similar. Unfortunately the Audio and Serial devices also look very similar in Linux!

Both radio sound cards appear as PCM2901 making it hard to differentiate between them, and my previous udev rule to create a symlink for the IC-7300 ttyUSB device on /dev/ic7300 picked up the 9700 instead.

My previous udev serial rule created a symlink to /dev/ttyUSBx from /dev/ic7300 when a device with the 7300’s serial adapter idVendor and idProduct was seen like so:

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4β€³, ATTRS{idProduct}==”ea60β€³ SYMLINK+=”ic7300β€³

This worked fine until the 9700 was plugged in as it also has the same idVendor and idProduct number. We can narrow this down easily as another available attribute is β€œserial” which contains the radios unique serial number along with its name.

We can get the serial numbers using udevadmΒ  (or better with lsusb below) against each of the /dev/ttyUSBx devices, the 9700 has two serial devices, the first works fine with hamlib for control but not sure what the second serial device at the moment.

$ udevadm info –attribute-walk –path=/sys/bus/usb-serial/devices/ttyUSB4 | grep IC-
ATTRS{serial}==”IC-9700 13000000 A”

$ udevadm info –attribute-walk –path=/sys/bus/usb-serial/devices/ttyUSB5 | grep IC-
ATTRS{serial}==”IC-9700 13000000 B”

$ udevadm info –attribute-walk –path=/sys/bus/usb-serial/devices/ttyUSB1 | grep IC-
ATTRS{serial}==”IC-7300 03000000β€³

An easier way to get the serial numbers is by running lsusb as root as follows, thanks to PA3MET for the pointer!

# lsusb -vvvvv | egrep "9700|7300"
iSerial 3 IC-9700 13000000 B
iSerial 3 IC-9700 13000000 A
iSerial 3 IC-7300 03000000

We can take these and create appropriate udev rules for adding symlinks for the radios serial devices including the unique serial numbers. Here is an extract from my /etc/udev/rules.d/99-hamlib.rules file:

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4β€³, ATTRS{idProduct}==”ea60β€³, ATTRS{serial}==”IC-7300 03000000β€³, SYMLINK+=”ic7300β€³

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4β€³, ATTRS{idProduct}==”ea60β€³, ATTRS{serial}==”IC-9700 13000000 A”, SYMLINK+=”ic9700a”

SUBSYSTEM==”tty”, ATTRS{idVendor}==”10c4β€³, ATTRS{idProduct}==”ea60β€³, ATTRS{serial}==”IC-9700 13000000 B”, SYMLINK+=”ic9700b”

Take care if copying the above text as the quotation marks are displaying incorrectly in WordPress. If you copy it as is you will need to replace them all with proper quotation marks.

A reload of udev rules with β€œudevadm trigger” and we have our serial devices available from convenient symlinks so no chasing about ttyUSB device names:

$ ls -l /dev/ic*
lrwxrwxrwx 1 root root 7 Apr 4 14:27 /dev/ic7300 -> ttyUSB1
lrwxrwxrwx 1 root root 7 Apr 4 14:27 /dev/ic9700a -> ttyUSB4
lrwxrwxrwx 1 root root 7 Apr 4 14:27 /dev/ic9700b -> ttyUSB5

Next up is the sound cards. I use quite a lot of different programs and need to easily switch and adjust my audio inputs/outputs using pavucontrol. The problem here is both audio devices have the same name, PCM2901, meaning I can’t easily tell what sound card belongs to what radio.

There’s no way to differentiate the sound cards like with the serial above as they return the exact same information and attributes. The only way to differentiate them from what I can see is with the physical USB port they are plugged in to. This is fine here as it’s a desktop and they will remain plugged in to the same ports. If you plug the radios in to a different USB socket you will need to update the paths again.Β 

We can list the devices with the following command, this shows both the IC-7300 and IC-9700 sound cards. I’ve removed some other sound cards from the output, as we’re just looking for the β€œBurr-Brown_from_TI_USB_Audio_CODEC” entries here

$ pacmd list-sources | egrep β€œname:|sysfs”

name: <alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.2.monitor>
sysfs.path = β€œ/devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.4/3-2.4:1.0/sound/card4”
name: <alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.2>
sysfs.path = β€œ/devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.4/3-2.4:1.0/sound/card4β€³
name: <alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.3.monitor>
sysfs.path = β€œ/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.4/3-3.4:1.0/sound/card5”
name: <alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.3>
sysfs.path = β€œ/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.4/3-3.4:1.0/sound/card5β€³

We are looking to extract the unique portion from device paths above, here we can see the paths differ atΒ 3-3/3-3.4/3-3.4Β andΒ 3-2/3-2.4/3-2.4. We will want to identify which entry belongs to which radio so run it with the USB disconnected then connected to identify which device matches which radio.

We can then run the following to apply a device description of IC9700 to the IC-9700 sound card source and sink which will show against the audio device in pulse applications instead of PCM2901.

The 3-3.4 below is referencing the end of the USB port discovered above.

pacmd update-source-proplist $(pacmd list-sources | egrep β€œname:.*Burr-Brown*|3-3.4” | grep -B 1 sysfs.path | grep name | sed β€œs/.*<\(.*\)>/\1/” | grep -v monitor) device.description=IC9700

pacmd update-sink-proplist $(pacmd list-sinks | egrep β€œname:.*Burr-Brown*|3-3.4” | grep -B 1 sysfs.path | grep name | sed β€œs/.*<\(.*\)>/\1/”) device.description=IC9700

And the same for the IC7300 with 3-2.4:

pacmd update-source-proplist $(pacmd list-sources | egrep β€œname:.*Burr-Brown*|3-2.4” | grep -B 1 sysfs.path | grep name | sed β€œs/.*<\(.*\)>/\1/” | grep -v monitor) device.description=IC7300

pacmd update-sink-proplist $(pacmd list-sinks | egrep β€œname:.*Burr-Brown*|3-2.4” | grep -B 1 sysfs.path | grep name | sed β€œs/.*<\(.*\)>/\1/”) device.description=IC7300

The audio devices should now be available using the name we set above in pavucontrol and other applications. This can be put in a script to run manually or at system startup.

❌