I have a Raspberry Pi 4 running Direwolf. I have a digirig that I am trying to interface with a Kenwood TM-271. Direwolf is opening up fine and showing it recognizes the Digirig as a sound card. Every other setup I have seen the soundcard will show up as 1 or 2, this one is coming up as 3. So I in the direwolf software I am pointing it to the 3. It doesn’t appear to be using the digirig, as I have built a interface cable to communicate with the Kenwood. I am using PTT, GRD, TXD, RXD. When I look at ALSA in the Pi itself, it is saying there is no card to control.
I am going cross eyed to try and figure out how to interface this digirig with the direwolf, but apparently I am missing a step. Does the digirig need to have drivers to talk to direwolf? Is it that card 3 that is causing the problem? I am assuming that the digirig will send ptt through the direwold program but maybe that is where i am missing a step. Any help would be apprecaited.
I don’t have any experience with Direwolf on Linux, check other related post to see if there’s good info: Topics tagged software-direwolf
As for Digirig, it doesn’t require any special drivers because its sound card is a standard device.
The PTT is handled via RTS signal of the serial port. The Silicon Labs CP2102 UART chip may need a driver if not automatically recognized by the system.
This is off topic to the OP, but on-topic to your comment, and moreso with general Linux usage.
Will you please consider getting experience with Linux based software?
Will you please consider talking with the developers of hamlib to get some kind of “digirig-generic” rig code to trigger the PTT with RTS on the serial port for the many applications that use hamlib?
We shouldn’t need application developers to implement the same thing twice, but they are often forced to. 30 minutes of hardware guys talking to the hamlib guys can save hundreds of hours for everyone else. I’m forced to develop something in my application that hamlib could certainly handle if it had a generic RTS toggle for a generic digirig device. Like a baofeng or VX-8DR which do not have CAT support.
Welcome to the forum. I think your requests are addressed to Denis K0TX, but I will comment.
If you look around our forum topics, you can see that all users, including you, are welcome to help others and give answers about Linux based software.
Likewise, the hamlib repo on Github probably accepts Pull Requests and issue submissions from anyone, including you.
Denis’ design for the Digirig is GPL, open to all to inspect, so he isn’t forcing any library or application developer to do anything in order to interact with his hardware. He’s already on your side, I think!
Yeah anyway mister Constrain, this was feedback to the product manufacturer to better support his customers. This isn’t a volunteer project, it’s a paid product. Too many hidden tips, tricks, and gotchas in amateur digital mode software ecosystem. When I pay a premium for a real slick piece of hardware and premade cable assemblies, last thing I want to do is hunt through forums to get it to work. I have 3 different radios I wanted to use this with and it’s made my initial experience bad, and I wanted to return it.
To my point, it’s very possible to use Hamlib with a RTS-PTT device like the digirig, although it wasn’t all that clear to begin with. MAYBE I am just stupid, how about that?
For any Linux users trying to use Digirig with hamlib/rigctl/rigctld (or other software that depends on them) with a radio that does NOT support CAT PTT (barring any actual hardware interface issues), you can use the following to force the digirig to trigger PTT (electrically connecting Ring 2 with Sleeve) when the command “T 1” is sent to the daemon:
Thanks, now that helpful information it is here in the forum. Denis may update the Docs. What would be the right title and tags for this thread so that future users could find the solution quickly? What radios does it apply to?
I feel your pain, but I doubt I’ll be able to tell hamlib folks anything about garden variety serial ports that is not already commonly known. After all this technology has been around since 1960’s and it is well documented and understood.
If hamlib didn’t implement something the way you hoped, then maybe they didn’t believe it’s important or maybe there is another way to achieve the same result. I would suggest talking to them directly as an app developer. I suspect you’ll be able to convey your concerns much better than I would on your behalf even after taking some time learning Linux based software.
When you have a moment I would love to hear about your project.
You are probably right. “The users should know better” is usually the reasoning: “after all, I know better.” - while forgetting the pain it took to get there.
I’d still encourage you to learn and use Linux based amateur software. I understand you’re a hardware guy and a businessman, as that’s the perspective that a lot of your blog posts are centered around.
Not knocking it (the hardware is very nice). I imagine most of your users are not looking to develop the next best 'noise free low latency open collector PTT circuit. Most just want to know how to get it to work without going too much into the technical weeds.
Looks like the issue is getting some traction in github. Hopefully will be resolved soon.
Thank you for your contribution to the hobby and please keep us posted on your progress with the app development.
