Re: ARRL 160m

[Drew Arnett]

Tabbing back to the callsign field to ESM my call (S) 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) is a bit optimistic maybe, but in S, 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  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
> > 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 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 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_TU_MSG macro
> instead of F3.  To go along with this would be enabling a notion of CQ
> and S 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, having the + key send "TU" then log was awkward as
> convention seems to prefer the S 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
>

Re: ARRL 160m

[Nate Bargmann]

* 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
> 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 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 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_TU_MSG macro
instead of F3.  To go along with this would be enabling a notion of CQ
and S 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, having the + key send "TU" then log was awkward as
convention seems to prefer the S 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



signature.asc
Description: PGP signature

Re: ARRL 160m

[Drew Arnett]

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.

I worked a couple of stations during auto CQ, and the rest in S
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.

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.

Best regards,

Drew
n7da

On Sun, Dec 8, 2019 at 3:35 PM Nate Bargmann  wrote:
>
> Well, first off, the use of cwdaemon and Tlf via Hamlib on the same
> serial port (real motherboard port) worked perfectly without a problem
> throughout my operating time.  I missed Saturday evening due to having
> aggravated my hip yesterday and had to lay down.  I was up around 0830z
> this AM and worked a bit over an hour and had to lay down for a while
> and then again from about 1140z to 1420z or thereabouts.  The hip is
> feeling batter!
>
> My CT changes didn't get used much as I saw I had Alt-1 set for the
> exchange I wanted to send in S mode so that I didn't have to edit the
> F3 message all the time.  Making sure that Enter didn't log an
> incomplete contact did prove useful in the wee hours...
>
> ESM mode for running worked perfectly.
>
> Combining Escape to halt the CW message and clearing the input fields is
> a double edged sword.  When there is text in the call and exchange
> fields and the cursor is in the exchange field and a CW message is in
> progress, the first ESC stops the TX and the second clears the exchange
> field and the third clears the call field.  This is fine so far as it
> goes.  When the call field has characters in it and the cursor is in the
> call field and the exchange field is empty, a single ESC stops the TX
> AND clears the call field!  That led to several ARGH! moments.  I think
> that a better algorithm could be worked out.
>
> Scoring is completely wrong but ARRL 160 is difficult to score.  Tlf
> several times counted an incorrect multiplier.  For one I worked a KG4
> in VA and Tlf scored it as the KG4 mult when it should have determined
> that the VA meant it was conus.  Another time or two I fat fingered an
> exchange and removed the text from the mult column but even a :RES
> command had no apparent effect.  Also, it seemed as though coming back
> from an :EDI command resulted in Tlf forgetting any previous dupes even
> though they're marked as zero points.
>
> In the end, the main thing is that the Cabrillo file is correct and ARRL
> will take care of the scoring.
>
> Overall, I enjoyed using Tlf again.
>
> 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
>

ARRL 160m

[Nate Bargmann]

Well, first off, the use of cwdaemon and Tlf via Hamlib on the same
serial port (real motherboard port) worked perfectly without a problem
throughout my operating time.  I missed Saturday evening due to having
aggravated my hip yesterday and had to lay down.  I was up around 0830z
this AM and worked a bit over an hour and had to lay down for a while
and then again from about 1140z to 1420z or thereabouts.  The hip is
feeling batter!

My CT changes didn't get used much as I saw I had Alt-1 set for the
exchange I wanted to send in S mode so that I didn't have to edit the
F3 message all the time.  Making sure that Enter didn't log an
incomplete contact did prove useful in the wee hours...

ESM mode for running worked perfectly.

Combining Escape to halt the CW message and clearing the input fields is
a double edged sword.  When there is text in the call and exchange
fields and the cursor is in the exchange field and a CW message is in
progress, the first ESC stops the TX and the second clears the exchange
field and the third clears the call field.  This is fine so far as it
goes.  When the call field has characters in it and the cursor is in the
call field and the exchange field is empty, a single ESC stops the TX
AND clears the call field!  That led to several ARGH! moments.  I think
that a better algorithm could be worked out.

Scoring is completely wrong but ARRL 160 is difficult to score.  Tlf
several times counted an incorrect multiplier.  For one I worked a KG4
in VA and Tlf scored it as the KG4 mult when it should have determined
that the VA meant it was conus.  Another time or two I fat fingered an
exchange and removed the text from the mult column but even a :RES
command had no apparent effect.  Also, it seemed as though coming back
from an :EDI command resulted in Tlf forgetting any previous dupes even
though they're marked as zero points.

In the end, the main thing is that the Cabrillo file is correct and ARRL
will take care of the scoring.

Overall, I enjoyed using Tlf again.

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



signature.asc
Description: PGP signature

Re: [Tlf-devel] Tlf with ARRL 160m, some thoughts

[Nate Bargmann]

* On 2015 06 Dec 09:53 -0600, Thomas Beierlein wrote:
> Hi Nate and others,
> 
> let me first congrats to your 160m results. Well done.

Thanks, Tom.

I was a bit disappointed to not make a complete QSO with C6AUM early
this morning.  He couldn't quite pull me out this year so I never had a
chance to see Tlf count a 5 point QSO.  I did have one dupe call me this
AM and Tlf correctly scored it at zero points.

I opened an issue against my repository this morning where I worked the
ONE (Ontario East) section and Tlf counted it as NE (Nebraska).  When I
did work an NE station later, no additional mult was counted.  I need to
go through the logic on that one.

> Am Sat, 5 Dec 2015 08:31:39 -0600
> schrieb Nate Bargmann :

> > Sort out the cases where some cty.dat entities are ARRL sections or
> > entities.  For the most part this would affect ARRL 160, ARRL FD, and
> > ARRL SS where all US territories are counted as an ARRL section.  For
> > other events such as ARRL DX they are entities rather than sections,
> > as I recall, so there may need to be an addition rules file keyword
> > and some logic added.
> > 
> What kind of support do you have in mind? Some new scoring keywords?

Right now as I incompletely understand the logic, the issue appears a
bit tricky and I don't have a solution handy at the moment.  What I did
was a trick offered on this list a year ago and I simply deleted the
conflicting entities from a local copy of cty.dat placed in the working
directory.

Since I didn't actually get a chance to try this in the contest since
the only one of those entities I heard, KP2 in VI, did not hear me, I
can only go by my tests before the contest.  In those tests with an
unmodified cty.dat, with the DX_&_SECTIONS keyword in the rules file Tlf
chose to apply the mult for the entity rather than the section even
though it took my entry in the exchange field.  More testing is needed.

Perhaps the solution is to include two section files in the
distribution, one with all the sections and the other with just the
mainland sections for ARRL DX.  I think the logic would still need to be
looked at in the case where a US entity appears in cty.dat, did the op
enter a section abbreviation for the exchange, if so, then count it as a
section, etc.

As the next event where this will be an issue is over six months away,
there is some time for me to study this more.

73, 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

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

Re: [Tlf-devel] Tlf with ARRL 160m, some thoughts

[Thomas Beierlein]

Hi Nate and others,

let me first congrats to your 160m results. Well done.

Am Sat, 5 Dec 2015 08:31:39 -0600
schrieb Nate Bargmann <n...@n0nb.us>:


> Now a few things I'll put on my TODO list.
> 
> Editing keys.  Once characters are in the call field the left arrow
> enters edit mode.  I'd like the  key to do the same while
> jumping the cursor to the first character in the field.  Often a
> person only copies the suffix of the call and being able to jump to
> the front of the string with one key press rather than several is
> probably expected behavior.
> 
> As with  above, the  key should exit edit mode and position
> the cursor after the last character.  This will likely be a synonym of
>  in this case and is an intuitive key press for many users.
> 
Ok, sounds reasonable. Just go ahead and send a pull request when done.
Please remember to also add the description for the added keys to
tlf.1.in. 

> Sort out the cases where some cty.dat entities are ARRL sections or
> entities.  For the most part this would affect ARRL 160, ARRL FD, and
> ARRL SS where all US territories are counted as an ARRL section.  For
> other events such as ARRL DX they are entities rather than sections,
> as I recall, so there may need to be an addition rules file keyword
> and some logic added.
> 
What kind of support do you have in mind? Some new scoring keywords?

> I do have a rules file for ARRL 160m USA in my repository and it is
> in a pending pull request to Tom.  Also in that pull request is a fix
> for the MULT_LIST rules parameter where the file will be loaded from
> the installed files if it doesn't exist in the local working
> directory. This will avoid having to copy a file such as arrlsections
> into the working directory each time when a distributed mults file is
> used.

Thanks for providing the rule file and the MULT_LIST patch. In meantime
both is in tlf's master branch. 


73, de Tom DL1JBE

> For keying the CW I am using the updated winkeydaemon.pl from Wilbert,
> PE7T, with my HamGadgets MK-1.  I did patch it to enable the debug
> command line switch.  It too has been working flawlessly.  I can
> create and push the code to a repository on GitHub if anyone is
> interested.
> 
> Control of my K3 with Hamlib has worked flawlessly as well.
> 
> 73, Nate
> 



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--


___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel

[Tlf-devel] Setting up ARRL 160m rules file

[Nate Bargmann]

It's probably my unfamiliarity with Tlf.

I am setting up a rules file for the upcoming ARRL 160m contest as a USA
entrant.  For stations in W/VE (any ARRL/RAC section) the scoring is two
points for working stations in another ARRL/RAC section (including 'DX'
such as KH6, KL7, KP4, KV4, etc.) and five points for other DXCC
entities.

Now, the real time scoring isn't all that important, I suppose, as ARRL
will score the log based on what is in the Cabrillo file.  I do want to
be sure that Tlf honors any entity that appears in CTY.DAT that I record
a section abbreviation as one that is a section mult and not a DX mult.

I am still poking around in the source, but so far have set my rules file
as:

#
# ARRL 160m CONTEST (Stateside) #
#
#
CONTEST=arrl160m_usa
LOGFILE=arrl160m.log
CONTEST_MODE
CABRILLO=UNIVERSAL
#
MULT_LIST=arrlsections
DX_&_SECTIONS
RECALL_MULTS
#

73, 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

___
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel