Configure and launch modems when needed

[s0lesurviv0r]

Hi there, I'm filing this feature request in order to gauge the level of support for this feature. I'm more than willing to contribute a PR if the maintainers feel it's a good fit.

I'd like PAT to:

• Support configurable application paths (e.g. for ardopc, rigctld, vara, etc)
• Search for applications in common locations if not explicitly configured
• Launch/terminate said modems (and/or rigctld) with desired settings when needed

The goal is to only have to launch PAT and from there choose modem type and hit connect.

I'm also very curious to know if anyone's attempted this before and/or if there are any pitfalls/pointers they can share. Thanks again!

[xylo04]

I'd be generally in support. This is the way Winlink Express works and would be easier for many people's use cases.

I'll note, when working on systems with systemd (Ubuntu, Raspberry Pi) I personally set up systemd user services to launch the modems in the background independently from Pat, but that doesn't cover every use case.

[s0lesurviv0r]

Awesome. Good to hear. My reasoning for having PAT launch the applications is that I need them on-demand. I have two laptops and they're not always plugged into a rig. When I want to operate I want to be able to plug in my rig and then just use PAT from there. I feel this feature will help the more tactical use cases.

I'll start putting together a PR. Thanks again!

[martinhpedersen]

I'm not sure I fully understood the use-case for this. Pat is built to handle modems/rigctl starting up and shutting down. There is no need to restart Pat after you start/stop a modem.

Also, the modems you normally use can be configured to auto-start on boot or when a usb device (e.g. radio) is plugged in to the computer (using udev on Linux).

The only thing I can see is that this would save a "click" (start/stop the modem) if a user for some reason only want the modem to run when in operation, but still want Pat to run continuously on the same machine.

Are there any other use-cases?

I suspect it might be complicated to implement this feature cross-platform, and in a generic way. Some modems have dependencies on other services (e.g. the X server). Also, some are forking, some deamonizes and some are ment to run in the foreground. All this complexity is handled very well by the operating system's service manager (systemd, Services, Launcher etc). Having Pat run a script is simple, but managing another app's running state is a very complex problem I think.

What are we really trying to resolve by implementing this? I think we need to discuss the scope of the feature before we invest a lot of time in implementation and code review 😊

[xylo04]

I almost mentioned it: yes, using udev to launch modems when the radio is plugged in is also a viable and clean solution for a portable/flexible station, but only in certain cases. udev only works on Linux; macOS has diskutil activity; and in Windows after a casual search I can't even find a way to run arbitrary scripts/programs based on USB connect/disconnect. Also, the device IDs for many ham radio devices is left as "generic serial device" and clashes with things like GPS receivers in udev, so it takes some fiddling to get those working properly.

I'm not sure I would personally use Pat to launch modems, but I think there's clear evidence for the need based on e.g. https://github.com/km4ack/patmenu2. Not everyone wants to mess around with udev rules.

That said, I agree with your points about thinking through the scope and difficulty of managing other subprocesses.

[s0lesurviv0r]

Thanks for the feedback. Here are some points that should illustrate how I operate and why I think this feature would be beneficial:

1. In a tactical setting, having operation be a simple as possible (just launching PAT) would ensure that the user doesn't have to go over an entire on-paper/in-memory checklist, especially during an emergency event. These extra steps may not seem like much to ask of an at-home operator with a dedicated Winlink machine and rig, but quickly add liability to portable and tactical operator.
2. I've operated in temperatures below 0 C and over 40 C. In these cases, and to piggyback on the previous point, reducing the amount of steps needed would go a long way. In freezing temperatures, reducing time and keystrokes helps a lot. I really wouldn't want to be debugging why the udev rules didn't kick in or having multiple terminals open for the foreground modems/etc.
3. I'm constantly opening and closing my laptop, causing it to suspend/hibernate/sleep/etc. Depending on the kernel and OS distribution, the behavior of these modems is unpredictable.
4. As @xylo04 mentioned, udev rules are only on Linux (which if fine for me personally because that's all I use).
5. My experience with udev rules is that they're a little brittle and inflexible, not to mention I could probably dial something in for myself personally but would be able to pass on that effort to anyone else.
6. This feature will reduce the barrier to entry for less software inclined hams. I understand this doesn't solve every issue as modems will still have to be downloaded and installed. However, we can build on this feature and maybe allow auto configuration and auto discovery of modems.

I appreciate the concerns and agree that it's not straight forward. However:

1. Winlink Express supports launching modems on demand. All of those modems are foreground processes that I know of.
2. We can choose to only support foreground process modem (non-forking) like ardopc. I'm hoping that one day PAT will support direwolf for direct Packet Winlink (instead of through the AX.25 stack) and direwolf can run as a foreground process.
3. From my experience the Golang os/exec, path, and path/filepath packages are robust enough to handle these use cases cross-platform.

If these points seem acceptable I'm always happy to write up some sort of implementation plan so we can come to an agreement on that first.

[martinhpedersen]

Sorry for the delayed response @s0lesurviv0r.

Sounds reasonable to discuss this further, and write up some implementation plan. Maybe we could write the implementation plan as a PR (a markdown file) so that we can comment and discuss. We should probably start by writing down the scope of this feature, how the configuration params should work and an overview of the most common use-cases.

It would also be interesting to discuss how this would work differently than patmenu2, and the advantages of implementing it as part of Pat. How do you see this? 🙂

Thanks!

[s0lesurviv0r]

I think I should now apologize for my late response. My job was extra busy this last week. I'll submit a PR with a Markdown next week so we can all hash out the details. Thanks again!