Running Multiple Digirigs on Raspberry Pi 4 or 400?

Is there a way for a Raspberry Pi 4 or 400 to support more than one Digirig? If so, is it possible to ensure that each Digirig appears with predictable device names? I currently have a udev rule that provides a fixed name for the CAT port (which has a unique USB SerialNumber attribute) but no such SerialNumber attribute exists for Digirig’s USB audio interface. Is there some method I can use to ensure the various digi mode software programs point to the correct audio interface such that I don’t have to verify and possibly have to change configuration settings each time I use it?

I do not use linux on the Raspberry Pi4 with Digirig, but I do not want your question to go unanswered too long. More than one Digirig, sure. Predictable naming of devices on reboot or reconnect? Less certain. In my experience with Linux, you can usually find a way. If not, maybe with your BIOS.

Have you checked linux user resources? Perhaps some of our experts here like @Drew_Rinella , @kbmccrory and @K0TX will consider your post.

73 Constrainted

1 Like

You’re too kind, but I’m no expert!

I have run 2 transceivers (1 VHF on FLDIGI and 1 HF on JS8Call) with a Pi3B+, each with its own digirig. It was very slow, so I returned back to separate computers for each. But, it can be done. I’ve also made this work on the Inovato Quadra, too.

As far as setting the sound card order, this is a problem, as Linux seems to set them in semi-random order at startup. You can set the order that different sound cards load in, but I have not found a way to isolate and number multiple USB sound cards. I assume this would take some programming that is way over my head.

I’ve found that, if I force the loading order of the HDMI and AV jack on RPi, then the USB sound cards will usually fall into place in the same order as your original setup each time. Typically when they load in the wrong order, its after an update. Rebooting has solved this each of the rare times this has happened to me. I run my portable bag off a Pi 3B+ using a digirig and a USB speaker, both of which are viewed by the system as snd_usb_audio. The last time those cards flopped on me was probably over 8 months ago.

2 Likes

Drew, thank you very much for the information. You are spot on in that there seems to be no straightforward way of disambiguating between the USB sound cards.

I’m thinking that the next step is to go ahead and purchase the second Digirig, capture a verbose output of the lsusb command for both sound devices, and hope that some less obvious attribute exists that I can trigger off of.

1 Like

Thank you so much for your assistance!

1 Like

Status update. Here is an update, such as it is, to the issue of running multiple Digirigs on a Raspberry Pi 4 or 400. I ordered another Digirig and it arrived today in the mail. Comparing the output of lsusb -v -s on the two interfaces with their respective bus and devices numbers shows that, as expected, the serial ports are easily distinguished based on their iSerial IDs. Smooth sailing as far as the CAT port is concerned.

Unfortunately, there is absolutely nothing in the audio port USB Device Descriptor that would enable you to distinguish one from the other. There does appear to be a potential solution using the KERNELS== tag in a udev rule but even if that works it would be an ugly solution because it would bind the udev rule to a specific USB port on the computer - if you move the Digirig interface to a different USB port the rule would not be invoked and you would lose the symlink.

For the moment we’ve at least confirmed that the nature of the problem is as originally suspected: There appear to be no obvious or clean ways to disambiguate the audio interfaces from each other when multiple Digirigs are connected to the same linux machine.

The search continues.

If you were running a PC, I would encourage you to check your BIOS. In my experience with expensive i86_64 motherboards, the BIOS has capabilities with peripherals that the OS does not. I do not know if the same applies to ARM.

73 Constrainted