search

la5nta / pat

A cross-platform Winlink client written in Go
https://getpat.io
MIT License
490 stars 86 forks source link

Optionally set mode with frequency #185

Open DougCollinge opened 4 years ago

DougCollinge commented 4 years ago

This is a feature request that applies to few others. Pat assumes that the transceiver will always be in USB mode, which is appropriate 99% of the time. But I have two stations that use LSB with ARDOP so I have to manually switch the mode. Of course it's very easy forget and not switch to LSB and also not to switch back to USB.

So it would be convenient to have another mode= parameter on the url along with freq=

I could probably manage this myself, since no-one else is likely to care.

DC7IA commented 4 years ago

I agree, this would be great...

I've even used an overly complicated BASH script a while ago just to handle this. xD

martinhpedersen commented 4 years ago

This seems like a reasonable feature to add without too much complication.

I think we should name the parameter rig_mode to further avoid confusion (pactor is also referred to as a "mode" in many places, but I've chosen the term "transport" in Pat for this reason).

Should be a rather small patch. PRs will be very much appreciated :)

martinhpedersen commented 4 years ago

Later we can add logic to allow the user to enable a default rig_mode per transport, or something like that. But I think we should do that in a later release.

DougCollinge commented 4 years ago

I'm working on it.

DougCollinge commented 4 years ago

PRs submitted for wl2k and pat. I don't know how to link an issue to a PR so I haven't done that. Forgive me if I have transgressed against the Laws of Go Style because this the first time I have worked in Go. I tried to follow your own style but I may have messed up for sure.

DougCollinge commented 4 years ago

OK, I fixed a problem and committed it to the PR. It's a bit crude at the moment - doesn't do the fancy colour change but I don't think that would be too hard to add.

DougCollinge commented 4 years ago

I put up that PR but we should probably have a discussion about this. The main issue is preserving and restoring frequency and mode. The current code in "develop" sort of half does this: if you hit "Connect" and type in your connect parameters on the web form then the frequency will be saved and restored after the connect is finished. But if you pull down the RMS list and click on a station listing it sets the frequency on the relevant rig but doesn't save what it had before so what is restored is whatever was last clicked on in the RMS list.

I think it properly ought to save what the frequency (and mode) was before you hit "Connect" but that is complicated by not knowing which rig is going to be involved at that time. E.g., you might have ax.25 and ardop interfaces running with different rigs and either or both of them could have its frequency changed depending on what you do in the Connect dialog. You could preserve the relevant parameters on all rigs on going into Connect and restore them on leaving if they had been changed.

Another way would be to detect when the frequency is about to be changed on any rig and it has not yet been preserved, preserve it once only, then restore that when the connect process is finished for any reason, connect finished, abandoned, or aborted.

DougCollinge commented 4 years ago

Then, of course, another strategy would be just to not save anything - simply leave the rig in the state it was last used in and expect users to reconfigure it however they want to use it next. This would not be bad, IMHO. I'm guessing that you almost always want to set the band or frequency or whatever when you sit down to use the rig manually.

DougCollinge commented 3 years ago

I agree, this would be great...

I've even used an overly complicated BASH script a while ago just to handle this. xD

@DC7IA I have a patch for this feature, which I am currently using. It requires new functionality in the hamlib interface in la5nta/wl2k, for which there is currently a pull request. I haven't put up the PR for the feature yet because it will always fail until wl2k/hamlib is updated.

mattwood2000 commented 2 years ago

+1 for this. I have been putting together an emcom setup and was just about to tackle the problem of switching between ARDOP on HF and AX25 on VHF. Mode switch is really a necessary component. Will apply your patch for now until the strategy and functionality is mainlined.