pat
pat copied to clipboard
Optionally set mode with frequency
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.
I agree, this would be great...
I've even used an overly complicated BASH script a while ago just to handle this. xD
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 :)
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.
I'm working on it.
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.
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.
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.
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.
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.
+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.