Mode setting from Call entry field in my tree

[Nate Bargmann]

Last night I pushed a patch to my Github SO2SDR tree that allows setting
the mode from the call field. From the commit message:

Some contests are mult-mode--Field Day, IARU Championship, state QSO
parties, etc.--thus a quick way to change modes is useful. At present
the selection is for CW, CWR, LSB, and USB. The mode name must be
followed by a single apostrophe ' which serves as a signal to end prefix
processing and to separate the optional passband width integer.

Examples:

Change mode to CW using Hamlib defined "normal" bandwidth: CW'

To change mode to USB using selected bandwidth: USB'2400

A trailing ':' character after the string, either CW': or USB'2400: will
set the mode and bandwidth on the _other_ radio.



I felt this was necessary as it is not always possible to use a computer
connected radio at Field Day. Using the Dummy rig and being able to set
the mode to other than CW is essential for proper logging in such cases.

I tried to use the ; character to denote the inactive radio but
enterFreq() chopped it off first so I chose to utilize : as the
character to denote mode change on the inactive radio. It's likely that
mode changes will be less frequent so this isn't likely to be too
painful as there probably isn't too much SO2R on FD. ;-)

As I wanted a way to denote a mode string to prefixCheck() the ' was
chosen to trail the mode name. It also serves as a separator for the
optional passband width integer. If the integer is not present then
RIG_PASSBAND_NORMAL is passed to the Hamlib backend. I found that this
exposed a bug in the K3 backend which I have fixed and pushed to the
Hamlib 1.2.15 branch. The Hamlib patch also checks for a passband
narrower or wider than that specified in the filters structure (shown in
dump_caps of rigctl) and keeps the passband width between those limits
for a given mode. I also pushed a similar patch for the K2 that needs
testing, if anyone is up to it.

I'm looking forward to discovering more bugs this Field Day. Ha!

73, de Nate >>

--

"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

[R. Torsten Clay]

I will have to take a detailed look at this. Was your thinking to have this
change modes by just typing that and not pressing enter? If so, then
prefixcheck is probably not the right place to put this. Right now enterfreq()
gets called when enter is pressed and the callsign does not seem to be
a real call (in enter()). Probably this is the right place to put this.

I am very used to using ; for second radio stuff, so using that here as well
would be better.

Tor

[Nate Bargmann]

* On 2012 17 Jun 22:58 -0500, R. Torsten Clay wrote:
> I will have to take a detailed look at this. Was your thinking to have this
> change modes by just typing that and not pressing enter?

No, Enter is still required. It's just that when the ' is seen, prefix
processing stops just as prefixCheck looks at strings of all digits for
frequency.

> If so, then prefixcheck is probably not the right place to put this.
> Right now enterfreq() gets called when enter is pressed and the
> callsign does not seem to be a real call (in enter()). Probably this
> is the right place to put this.

I created a companion enterMode() method that looks much the same as
enterFreq(). It's likely that the two could be combined. I was
interested in getting it working after a fashion before optimizing it.

> I am very used to using ; for second radio stuff, so using that here as well
> would be better.

I understand. That is why enterMode and enterFreq will need to be
combined since enterFreq is called first in my patch and chops the ;
character before enterMode gets to see it.

I didn't issue a pull request on this as I wanted your thoughts on it
first.

[R. Torsten Clay]

OK- I would rather it not go in prefixcheck then. Prefixcheck gets called for every
edit (keypress) of the call field, so it needs to stay as small/fast as possible. Note
that prefixcheck also does not get called when enter is pressed.

When enter is pressed and the call field doesn't have a legal call in it is when I check
for freq entry. Mode setting should be added there.

Tor

[Nate Bargmann]

* On 2012 18 Jun 08:45 -0500, R. Torsten Clay wrote:
> OK- I would rather it not go in prefixcheck then. Prefixcheck gets called
> for every
> edit (keypress) of the call field, so it needs to stay as small/fast as
> possible. Note
> that prefixcheck also does not get called when enter is pressed.

I was just following the code path that the frequency digits follow as
they are entered. I'll try it without prefixCheck in the path for the
mode.

> When enter is pressed and the call field doesn't have a legal call in it is
> when I check
> for freq entry. Mode setting should be added there.

Already done, but I'm thinking of moving it into the enterFreq() method
to support ; for both freq and mode change on the 2nd radio. Doing it
this way may allow for not having the ' delimiter either (which I really
don't like) so long as the validator doesn't false on entries like CW500
or USB2400 for setting mode and passband width simultaneously.

[R. Torsten Clay]

On Mon, Jun 18, 2012 at 11:59 AM, Nate Bargmann <n0...@n0nb.us> wrote:

* On 2012 18 Jun 08:45 -0500, R. Torsten Clay wrote:
> OK- I would rather it not go in prefixcheck then. Prefixcheck gets called
> for every
> edit (keypress) of the call field, so it needs to stay as small/fast as
> possible. Note
> that prefixcheck also does not get called when enter is pressed.

I was just following the code path that the frequency digits follow as
they are entered.  I'll try it without prefixCheck in the path for the
mode.

> When enter is pressed and the call field doesn't have a legal call in it is
> when I check
> for freq entry. Mode setting should be added there.

Already done, but I'm thinking of moving it into the enterFreq() method
to support ; for both freq and mode change on the 2nd radio.  Doing it
this way may allow for not having the ' delimiter either (which I really
don't like) so long as the validator doesn't false on entries like CW500
or USB2400 for setting mode and passband width simultaneously.

Yes, putting it in enterFreq would work.

Tor

[Nate Bargmann]

Just completed refactoring the set mode capability and have pushed the
changes to my tree, but have not issued a pull request. This modifies
the previous set mode patch and likely won't apply to an earlier commit.

For the good news, from the commit message:

Refactor set mode handling

Mode handling is now simpler using just the mode strings "CW", "CWR",
"LSB", or "USB". A passbandwidth integer of 2 to 5 digits is optional
(actual width may be used by a given Hamlib backend or adjusted within
certain limits) as is a trailing ';' for setting the inactive radio as
with setting operating frequency. Mode string is required to set
passband width otherwise operating frequency will be set.

Examples: Set mode to USB on active radio, "USB"<Enter>; Set mode to LSB
on inactive radio, "LSB;<Enter>"; set mode and bandwidth on active
radio, "CW500<Enter>"; and set mode and bandwidth on inactive radio,
"CWR1000<Enter>".


At some point more modes will probably be added to the regex strings I
used. Ideally, perhaps the .cfg files could be extended to list the
valid mode(s) for the event and the program would set the regex strings
accordingly. Too close to FD to try and hack that in now!

Hopefully, this is a bit cleaner and not requiring many new keystrokes.
:-) I hope to push up an improved reference manual before FD as well.