Re: ARRL 160m

[Drew Arnett]

Tabbing back to the callsign field to ESM my call (S&P) or resend
their exchange info (run) seems fine to me.

Enter in the exchange field logging it and all even before exchange is
sent and confirmed (S&P) is a bit optimistic maybe, but in S&P, not a
big penalty to delete that logged entry if the band dropped out or QRM
or something meant the QSO didn't get completed.  Don't need to do
that most of the time.

Drew
n7da

On Sun, Dec 8, 2019 at 5:48 PM Nate Bargmann <address@hidden> wrote:
>
> * On 2019 08 Dec 10:07 -0600, Drew Arnett wrote:
> > I played for a couple of hours with the 160m contest as well from a
> > very noisy location, so not very many QSOs.  Worked a big gun east of
> > the Mississippi, but no KG4 for me.  :-)  Didn't consult with Nate for
> > rules or config file.  Just grabbed the distributed arrl160m_usa rules
> > and merged a bit from my own files from the last contest.
>
> Like I noted, this KG4 was a 2x1 in VA so no GITMO for me either.
>
> > I worked a couple of stations during auto CQ, and the rest in S&P.
> > Messages and ESM both worked great.  I guest operated at another
> > station for a bit during CQ WW.  They weren't using ESM.  Wasn't bad
> > using the function keys, but I missed ESM as someone how can touch
> > type.
>
> For me, using ESM in S&P is a bit disconcerting as when Enter is pressed
> after receiving the running stations exchange, the QSO is logged before
> my exchange is even sent, let alone confirmed.  This is why I did a bit
> of work so that in CT mode the Enter key only logs the QSO when both
> fields have something it them.
>
> My S&P sequence was as follows:
>
> :CFG and uncomment CTCOMPATIBLE in logcfg.dat, Tlf reloads and resets
> the configuration.
>
> Type in the running station's call.
>
> Press F6 to send my call.
>
> Type in his exchange, if DX only a signal report is sent so type a space
> character in the exchange field, otherwise ARRL section is typed.
>
> Press Alt-1 which is set to "TU +5NN- KS" (I left F3 set to "@ +5NN- KS".
>
> Press Enter once he sends TU or CFM or whatever.
>
>
>
> Out of that sequence, what I would consider changing would be if the
> exchange field is empty that Enter sends mycall (F6), similar to ESM.
>
> I would also consider changing Insert to send the S&P_TU_MSG macro
> instead of F3.  To go along with this would be enabling a notion of CQ
> and S&P in CT mode so the messages sent would be mostly the same as ESM,
> but with different keystrokes and with Enter logging when there are
> characters in each field.
>
> Also, in S&P, having the + key send "TU" then log was awkward as
> convention seems to prefer the S&P station to send "TU exchange" these
> days.
>
> > I've noticed that clear the call field behavior of the ESC key as
> > well.  If there is an alternate behavior that makes sense and doesn't
> > make ESM worse, I'd love to consider it.  It is slightly annoying, but
> > I didn't fret over it too much, as I figured it was good practice for
> > short term callsign memory.  If getting a fill is taking time, it
> > might push the limits of my short term memory, though.
>
> My short term memory is working hard enough being two to three
> characters behind his sending!  Losing the callsign just because he
> decided to start sending his call again a few milliseconds after I fired
> the exchange macro and wanting to stop it to get back in sync with him
> is annoying.
>
> I could imagine ESC working like this:
>
> If the callsign and exchange fields have characters in them, ESC works
> just as now but stopping the TX and successively clearing the fields on
> additional presses.
>
> If the callsign field has characters and the exchange field is empty
> with the cursor in either, then ESC stops TX.  The second press would
> clear the callsign and make sure the cursor is in the callsign field.
>
> The tricky part is, what if there is no TX, I think the current behavior
> is to clear the fields immediately, exchange then callsign on successive
> presses.
>
> Since this would be new behavior, it's likely that it should be disabled
> by default and enabled with a keyword command as many are probably used
> to the current behavior.
>
> 73, Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>