Re: The state QSO Party thread [TN QP]

2021-09-07 Thread Nate Bargmann
* On 2021 06 Sep 22:13 -0500, Doug Smith wrote:
> > Please don't blame Tlf here.  That is totally my doing as that is the
> > data I put in for that field in my local template.
> > 
> > Looking at the relevant Cabrillo V 3 specification[1], I see that
> > Location has three categories, ARRL sections as mentioned, IOTA island
> > name, and RDA number. That's it.  Now, if Tlf can be faulted to any
> > degree it would be that it does not validate this field against those
> > lists, at a minimum ARRL sections, I would think.
> 
> Not at all, it's not by any means TLF's fault!
> Just that sometimes you have to guide the users:)  I mean, that can go to an
> extreme, I used N1MM for the contest yesterday & the balloon help kept
> getting in the way...  (I guess there's a way to turn it off but that's too
> much work:)

I appreciate you bringing this up as it caused me to more carefully
examine that part of the Cabrillo spec that I had simply glanced over
and *assumed* I knew what I was doing.

> I'm not sure Colorado is using the same checking software.  You may not have
> a problem.

Hopefully, they'll be kind enough to let me know.  They may not have as
many logs to go through as I found far less activity and 3830 shows far
less logs than TN with a 24 hour head start.

> We use W3KM Cab Evaluator.

Ahh, apparently another single developer project with no obvious links
to SourceForge, GitHub, or GitLab to be found.  Okay, so some digging is
in order.

W3KM Cabrillo Evaluator[1]
Explicit Contest rules[2]
Cabrillo Log template[3]
Which has an embedded PDF[4] where in the Notes section at the bottom
number 4 states, " Cabrillo log filenames are urCall.log or urCall.cbr -
where urCall is your callsign."

May I humbly ask that either the software settings be checked or the
author (W3KM) be made aware of the bug of only allowing *.log?  Without
a public facing issue tracker and access to the source, it's not
possible for someone to noodle around and identify the bug for him.  A
*.cbr file should not be any problem given the examples he provides and
the official Cabrillo specification.

> (I used to use a collection of custom Perl
> scripts & a SQL database but it was a big pain to update when the rules
> changed, and when I wanted to push most of the work to someone else, getting
> Perl and SQL installed -- on a Windows box -- was more than I wanted to
> undertake...)

I can understand that as Windows is generally hostile toward open
standard software.  Windows users even more so.  ;-)

That said, I have a custom Perl script that processes the resulting .cbr
for the Kansas QP to generate some statistics and a summary for the 3830
site.  This year the script and Tlf agreed on the score.  Heh!

Unfortunately, Perl is essentially a dead language, not from the
standpoint of development as that continues, but it's not high on any
surveys that show language popularity that I've seen.  Expecting someone
to pick up the Camel Book these days is probably asking a bit much,
especially of a language that doesn't hide its Unix heritage at all.  I
don't blame you one bit for moving toward a prepackaged solution for a
Windows user.

> > That is generated by Tlf internally and can be changed.  However, WWOF
> > states either .log or .cbr is valid (bottom of the page)[2].  In that
> > light it would appear the adjudication software is overly restrictive.
> > 
> > Also, Tlf uses the .log extension for its internal log written to disk.

I need to point out that the .log extension is apparently not hard coded
in Tlf as the complete log file name is specified in its RULES file so
could conceivably be anything the user chooses.

> Again, a nit:)  I would concur the adjudication software is overly
> restrictive, and it has similar tendencies in other areas.  It is not
> exactly difficult to change a file extension:)

As above, even the author's examples allow for both extensions so I'm
inclined to look for a setting or consider such behavior a bug.

> (it's a whole lot easier than talking an entrant through sending
> something other than an ADIF file.  This year, we had someone scan a
> printout of his Cabrillo file & send us the JPEG!)

Words fail...

> I wasn't used to operating from a fixed station:), usually do this thing
> mobile where I'm signing /DAVI, /CHEA, etc..  & it's obvious I'm in
> Tennessee...

You were signing with TNQP so that was a clue.  Most ops out of state
will just call TN.  Taking a chance I unwittingly worked the K4A special
event that was not taking part in TNQP.

73, Nate

[1] https://www.qsl.net/w3km/cabrillo.htm
[2] https://qsl.net/w3km/explicit-rules.htm
[3] https://qsl.net/w3km/cab_template.htm
[4] https://qsl.net/w3km/template.pdf

-- 
"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 

Re: The state QSO Party thread [TN QP]

2021-09-06 Thread Doug Smith

On 9/6/21 8:35 PM, Nate Bargmann wrote:

* On 2021 06 Sep 17:41 -0500, Doug Smith wrote:

For years I was the adjudicator for the TNQP and still am the backup guy.  I
haven't run Nate's log through the checking software yet but it looks
straightforward & I don't remember having significant issues with TLF output
in the past.


Hi Doug.

That is great to know.


One thing I did notice is the LOCATION: tag in the Cabrillo header is
"Kansas".  N1MM puts one's ARRL section on this tag, and the adjudication
software we use will kick out a log that doesn't have a valid ARRL section.
(in Nate's case, "KS" -- but if you're in New York which has multiple ARRL
sections, "NY" will NOT work.  It needs to be NLI or ENY or WNY or NNY.)

The LOCATION: tag is interchangeable with the ARRL-SECTION: tag but it must
contain a valid ARRL section either way.  For entrants outside the U.S. and
Canada, the appropriate entry is "DX".

It might be a bit more trouble to fix than it's worth, but it would be
helpful both for the adjudicators and new-to-QSO-Party entrants if somehow
one could be forced (or at least guided) to enter a valid section.

This really doesn't make a whole lot of sense, but that's the way the
third-party packages work.


Please don't blame Tlf here.  That is totally my doing as that is the
data I put in for that field in my local template.

Looking at the relevant Cabrillo V 3 specification[1], I see that
Location has three categories, ARRL sections as mentioned, IOTA island
name, and RDA number. That's it.  Now, if Tlf can be faulted to any
degree it would be that it does not validate this field against those
lists, at a minimum ARRL sections, I would think.


Not at all, it's not by any means TLF's fault!
Just that sometimes you have to guide the users:)  I mean, that can go 
to an extreme, I used N1MM for the contest yesterday & the balloon help 
kept getting in the way...  (I guess there's a way to turn it off but 
that's too much work:)




Thanks for the good info and insight, Doug.  I've not seen much
commentary over the years of those in your position so this kind of
feedback is very helpful.  I think I'll need to resubmit my CO QP log as
I made the same error.


I'm not sure Colorado is using the same checking software.  You may not 
have a problem.


We use W3KM Cab Evaluator.  (I used to use a collection of custom Perl 
scripts & a SQL database but it was a big pain to update when the rules 
changed, and when I wanted to push most of the work to someone else, 
getting Perl and SQL installed -- on a Windows box -- was more than I 
wanted to undertake...)



Final nit pick:)  The file we received was N0NB.cbr.  N1MM uses the .log
extension.  Obviously it is not a big deal for the adjudicator to rename the
file:)  (the adjudication software ignores any files without the .log
extension)


That is generated by Tlf internally and can be changed.  However, WWOF
states either .log or .cbr is valid (bottom of the page)[2].  In that
light it would appear the adjudication software is overly restrictive.

Also, Tlf uses the .log extension for its internal log written to disk.


Again, a nit:)  I would concur the adjudication software is overly 
restrictive, and it has similar tendencies in other areas.  It is not 
exactly difficult to change a file extension:)  (it's a whole lot easier 
than talking an entrant through sending something other than an ADIF 
file.  This year, we had someone scan a printout of his Cabrillo file & 
send us the JPEG!)



Again, none of this is serious.  Nate, thanks for entering!  (and thanks for
working me on 80 meters.  100 watts to a VOCF antenna 1.8m above ground
behind a fence.  "VOCF"=VERY off-center fed.)


You had a very good signal here, Doug, s9+ as I recall.  Funny thing, I
wasn't sure you were instate or not so I looked up your call before I
hit F6!  Then today going back through the TN QP rules there is your
call in a few places.  D'oh!


I wasn't used to operating from a fixed station:), usually do this thing 
mobile where I'm signing /DAVI, /CHEA, etc..  & it's obvious I'm in 
Tennessee...





Re: The state QSO Party thread [TN QP]

2021-09-06 Thread Nate Bargmann
* On 2021 06 Sep 17:41 -0500, Doug Smith wrote:
> For years I was the adjudicator for the TNQP and still am the backup guy.  I
> haven't run Nate's log through the checking software yet but it looks
> straightforward & I don't remember having significant issues with TLF output
> in the past.

Hi Doug.

That is great to know.

> One thing I did notice is the LOCATION: tag in the Cabrillo header is
> "Kansas".  N1MM puts one's ARRL section on this tag, and the adjudication
> software we use will kick out a log that doesn't have a valid ARRL section.
> (in Nate's case, "KS" -- but if you're in New York which has multiple ARRL
> sections, "NY" will NOT work.  It needs to be NLI or ENY or WNY or NNY.)
> 
> The LOCATION: tag is interchangeable with the ARRL-SECTION: tag but it must
> contain a valid ARRL section either way.  For entrants outside the U.S. and
> Canada, the appropriate entry is "DX".
> 
> It might be a bit more trouble to fix than it's worth, but it would be
> helpful both for the adjudicators and new-to-QSO-Party entrants if somehow
> one could be forced (or at least guided) to enter a valid section.
> 
> This really doesn't make a whole lot of sense, but that's the way the
> third-party packages work.

Please don't blame Tlf here.  That is totally my doing as that is the
data I put in for that field in my local template.

Looking at the relevant Cabrillo V 3 specification[1], I see that
Location has three categories, ARRL sections as mentioned, IOTA island
name, and RDA number. That's it.  Now, if Tlf can be faulted to any
degree it would be that it does not validate this field against those
lists, at a minimum ARRL sections, I would think.

Thanks for the good info and insight, Doug.  I've not seen much
commentary over the years of those in your position so this kind of
feedback is very helpful.  I think I'll need to resubmit my CO QP log as
I made the same error.

> I don't see that Nate worked any of our mobiles more than once on the same
> band/mode.  We don't allow county-line operations in our contest. (well,
> technically they're permitted but only if you can figure out how to park
> your car so the radio *and* the antenna are both exactly on the border!)  If
> he had, the adjudication software would have accepted multiple 40CW QSOs
> with W4NZ as valid if different counties had been logged.

The differences in the QPs is one of the fun parts.  Being used to KS QP
this branching out is useful.

> Final nit pick:)  The file we received was N0NB.cbr.  N1MM uses the .log
> extension.  Obviously it is not a big deal for the adjudicator to rename the
> file:)  (the adjudication software ignores any files without the .log
> extension)

That is generated by Tlf internally and can be changed.  However, WWOF
states either .log or .cbr is valid (bottom of the page)[2].  In that
light it would appear the adjudication software is overly restrictive.

Also, Tlf uses the .log extension for its internal log written to disk.

> Again, none of this is serious.  Nate, thanks for entering!  (and thanks for
> working me on 80 meters.  100 watts to a VOCF antenna 1.8m above ground
> behind a fence.  "VOCF"=VERY off-center fed.)

You had a very good signal here, Doug, s9+ as I recall.  Funny thing, I
wasn't sure you were instate or not so I looked up your call before I
hit F6!  Then today going back through the TN QP rules there is your
call in a few places.  D'oh!

73, Nate

[1] https://wwrof.org/cabrillo/cabrillo-v3-header/
[2] https://wwrof.org/cabrillo/cabrillo-specification-notes/

-- 
"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: The state QSO Party thread [TN QP]

2021-09-06 Thread Doug Smith
For years I was the adjudicator for the TNQP and still am the backup 
guy.  I haven't run Nate's log through the checking software yet but it 
looks straightforward & I don't remember having significant issues with 
TLF output in the past.



One thing I did notice is the LOCATION: tag in the Cabrillo header is 
"Kansas".  N1MM puts one's ARRL section on this tag, and the 
adjudication software we use will kick out a log that doesn't have a 
valid ARRL section.  (in Nate's case, "KS" -- but if you're in New York 
which has multiple ARRL sections, "NY" will NOT work.  It needs to be 
NLI or ENY or WNY or NNY.)


The LOCATION: tag is interchangeable with the ARRL-SECTION: tag but it 
must contain a valid ARRL section either way.  For entrants outside the 
U.S. and Canada, the appropriate entry is "DX".


It might be a bit more trouble to fix than it's worth, but it would be 
helpful both for the adjudicators and new-to-QSO-Party entrants if 
somehow one could be forced (or at least guided) to enter a valid section.


This really doesn't make a whole lot of sense, but that's the way the 
third-party packages work.



I don't see that Nate worked any of our mobiles more than once on the 
same band/mode.  We don't allow county-line operations in our contest. 
(well, technically they're permitted but only if you can figure out how 
to park your car so the radio *and* the antenna are both exactly on the 
border!)  If he had, the adjudication software would have accepted 
multiple 40CW QSOs with W4NZ as valid if different counties had been 
logged.



Final nit pick:)  The file we received was N0NB.cbr.  N1MM uses the .log 
extension.  Obviously it is not a big deal for the adjudicator to rename 
the file:)  (the adjudication software ignores any files without the 
.log extension)



Again, none of this is serious.  Nate, thanks for entering!  (and thanks 
for working me on 80 meters.  100 watts to a VOCF antenna 1.8m above 
ground behind a fence.  "VOCF"=VERY off-center fed.)



On 9/6/21 3:45 PM, Nate Bargmann wrote:

Sorry this is after the fact as the Tennessee QP was yesterday.

Overall, this was easy for Tlf as the exchange was signal report and
county (instate) and signal report and state/province (outstate).  The
only difference from the KS QP was making the mults per band rather than
once.

As usual, my files are attached.

73, Nate





Re: The state QSO Party thread [TN QP]

2021-09-06 Thread Nate Bargmann
Sorry this is after the fact as the Tennessee QP was yesterday.

Overall, this was easy for Tlf as the exchange was signal report and
county (instate) and signal report and state/province (outstate).  The
only difference from the KS QP was making the mults per band rather than
once.

As usual, my files are attached.

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


# General contest mode #

#
CONTEST=tnqp
LOGFILE=tnqp_2021.log
CONTEST_MODE
CABRILLO=UNIVERSAL
CABRILLO-CONTEST=TN-QSO-PARTY
CABRILLO-EXCHANGE=KS
# Station Cabrillo template
CABRILLO-TEMPLATE=tnqp-naqp.cbr
#
CALLMASTER=MASTER.SCP
#
##
##
#  Messages F1= to F12=  #
#  Message CQ_TU_MSG=#
#  Message S_TU_MSG=   #
##
#  % = call  #
#  @ = hiscall   #
#  # = serial#
#  [ = RST   #
#  + = increase cw speed #
#  - = decrease cw speed #
##
##
#
F1=CQ TQP %
F2=@ DE %
F3=5NN KS
F4= TU
F5=@
F6=%
F7=@ SRI QSO B4 GL
F8=AGN
F9=?
F10=QRZ?
F11=PSE K
F12=CQ TQP %
#
CQ_TU_MSG=TU %
S_TU_MSG=TU 5NN KS
#
#ALT_0=
ALT_1=KS
#ALT_2=
#ALT_3=
#ALT_4=
#ALT_5=
#ALT_6=
#ALT_7=
#ALT_8=
#ALT_9=
#
#SEND_DE
#
#
#   #
#  Voice Keyer Files#
#(F1 to F12)#
#
#
#VKM1=
#VKM2=
#VKM3=
#VKM4=
#VKM5=
#VKM6=
#VKM7=
#VKM8=
#VKM9=
#VKM10=
#VKM11=
#VKM12=
#VKSPM=
#VKCQM=
#
#
#
#  Scoring rules#
#
#
MIXED
RECALL_MULTS
THREE_POINTS
SECTION_MULT
MULT_LIST=tnqp.txt
### END #

RULES=tnqp
#
#
#   #
#   TLF-LOGCFG.DAT v. 1.1.0 #
#   #
#  Uncomment the options you#
#  want to enable. See tlf.doc  #
#  for a description of the #
#  options. You can keep diff-  #
#  erent versions for different #
#  contests. I keep separate#
#  configuration files for  #
#  each contest. If you enable  #
#  more than 1 mutually exclu-  #
#  sive options, the last one   #
#  will be efective.#
#   #
#   #
#
#
#CTCOMPATIBLE
#
#
#   #
#   EDITOR  #
#   #
#
#
#EDITOR=joe
EDITOR=vim
#EDITOR=e3
#EDITOR=mcedit
#
#
#   #
#  CALL #
#   #
#
#
CALL=N0NB
#
#
#
#   #
#  Time offset from UTC #
#   #
#
#
TIME_OFFSET=0
TIME_MASTER
#
#
#   #
#  LAN PORT #
#   #
#
#  addnode only OTHER nodes !!
#
#ADDNODE=10.0.0.115
#ADDNODE=192.168.1.2
#
THISNODE=A
#
LAN_DEBUG
#
#
#   #
#  KEYERPORT#
#   #
#
#
NETKEYER
NETKEYERPORT=6789
NETKEYERHOST=127.0.0.1
#
#
#   #
#  KEYERPARAMETERS  #
#   #
#
#---speed (6 ... 60 wpm)
CWSPEED=24
#---weight (-5 ... 5 ms)
WEIGHT=1
#---cq delay (in 0,5 s)
CQDELAY=10
#---txdelay (ms)
TXDELAY=2
#---sidetone (200...800, 0 = mute)
CWTONE=800
#
#   #
#  PACKET INTERFACE #
#   #
#
#
# use tnc instead of telnet #
#TNCPORT=/dev/ttyS0
#TNCPORT=/dev/ttyUSB1
#TNCSPEED=2400
#
# get clusterinfo from network ##
#FIFO_INTERFACE
#
#
#   #
#  RADIO CONTROL#
# (comment out if not present)  #
# Rigmodel = Hamlib index, here #
#   for ten tec OMNI VI #
#
#
RADIO_CONTROL
RIGMODEL=2029
RIGSPEED=38400
RIGPORT=/dev/rig
RIGPTT
#
SSBMODE
#
#RIT_CLEAR
#
#SHOW_FREQUENCY
#
#
#   #
#  INFORMATION WINDOWS  #
#   #
#