Re: The state QSO Party thread
This weekend brings the Alabama QSO Party today 1500z through 0300z tomorrow (late evening in the US). For out state participants the rules are reasonably straight forward with the only twist being that while mults count once per the event, they do count per mode. As there are 67 counties, there are 67 mults for both CW and phone so a total available of 134 for a mixed mode entry! Going through the list of Tlf mult commands I do not see anything that counts mults per mode. This is a feature enhancement that should be addressed. QSO Party rules authors are inventive. At this time I've no files to share as I'm not sure if I'll have any operating time today. 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: The state QSO Party thread [TN QP]
* 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]
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 [CO QP files]
* On 2021 06 Sep 14:43 -0500, Nate Bargmann wrote: > The WYSIWYG multiplier method was confused by the fact I was entering > two values in the exchange field--the other op's name and county. If I > worked another station in the same county WYSIWYG counted it as a new > mult. I may have avoided some of the pain had I taken the advice of the RULES section of the man page and did more prior testing. My outcome may have been different had I used the NO_RST option in my rules file. I shall keep that in mind for the future. I guess it pays (eventually) to edit the documentation. ;-) 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: The state QSO Party thread [TN QP]
* 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]
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]
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 # # # #
Re: The state QSO Party thread [CO QP files]
Overall Tlf did better than propagation into CO from this location. The WYSIWYG multiplier method was confused by the fact I was entering two values in the exchange field--the other op's name and county. If I worked another station in the same county WYSIWYG counted it as a new mult. The other suspected issue was working the same station on a band/mode but in a new county which the rules allow for point credit but Tlf scored as 0 points. Neither of these were show stoppers as both introduced errors into Tlf's scoring of the event. For the good side, I created an North American QSO Party Cabrillo template (specified by the CO QP rules) that I will merge with the main template file. One bug did surface here since in the rules file the CABRILLO-EXCHANGE parameter is taken as a single string and is not split for Cabrillo output as the received exchange is. The parameter is apparently limited to 10 characters as a string any longer than that is truncated even when the field in the Cabrillo template is specified to be longer. The CO QP rules state all fields should start at the same column number as the NAQP template available online[1]. I did some manual adjustment to line things up which I probably could have avoided if CABRILLO-EXCHANGE did not truncate its input. ADIF export appears to be fine although I've not uploaded it to LoTW or eQSL yet. Tlf still has a few rough edges that I think we can work out in the future. My updated files are attached. 73, Nate [1] http://ncjweb.com/NAQP_Cabrillo_Template.txt -- "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=coqp LOGFILE=coqp-2021.log CONTEST_MODE CABRILLO=NAQP CABRILLO-CONTEST=COQP CABRILLO-EXCHANGE=NATEKS # Station Cabrillo template CABRILLO-TEMPLATE=coqp-naqp.cbr # #CABRILLO-CATEGORY-BAND=ALL #CABRILLO-CATEGORY-MODE=MIXED #CABRILLO-CATEGORY-POWER=LOW # ## ## # Messages F1= to F12= # # Message CQ_TU_MSG=# # Message S_TU_MSG= # ## # % = call # # @ = hiscall # # # = serial# # [ = RST # # + = increase cw speed # # - = decrease cw speed # ## ## # F1=CQP % F2=@ DE % F3=NATE KS F4=TU F5= @ F6=% F7=@ SRI QSO B4 GL F8=AGN F9= ? F10= QRZ? F11= PSE K F12=CQP % # CQ_TU_MSG=TU % S_TU_MSG=TU NATE KS # ALT_1=NATE ALT_2=KS #ALT_3= #ALT_4= #ALT_5= #ALT_6= #ALT_7= #ALT_8= #ALT_9= #ALT_0= # #SEND_DE # # # Scoring rules# # # MIXED RECALL_MULTS SSBPOINTS=1 CWPOINTS=2 SECTION_MULT_ONCE WYSIWYG_ONCE MULT_LIST=coqp.txt ### END # # Cabrillo format descriptions for various contests # used for North American QSO Party, Colorado QSO Party [NAQP] QSO=FREQ,5;MODE,2;DATE,10;TIME,4;MYCALL,15;EXC_S,14;HISCALL,15;EXC1,10;EXC2,3 #Cty Abb. ADA ALA ARA ARC BAC BEN BOU BRO CHA CHE CLC CON COS CRO CUS DEL DEN DOL DOU EAG ELP ELB FRE GAR GIL GRA GUN HIN HUE JAC JEF KIO KIC LAK LAP LAR LAA LIN LOG MES MIN MOF MON MOT MOR OTE OUR PAR PHI PIT PRO PUE RIB RIG ROU SAG SAJ SAM SED SUM TEL WAS WEL YUM # *Rare Counties # County Name # 1 Adams # 2 Alamosa* # 3 Arapahoe # 4 Archuleta* # 5 Baca # 6 Bent* # 7 Boulder # 8 Broomfield # 9 Chaffee # 10 Cheyenne* # 11 Clear Creek # 12 Conejos* # 13 Costilla* # 14 Crowley # 15 Custer* # 16 Delta* # 17 Denver # 18 Dolores # 19 Douglas # 20 Eagle # 21 El Paso # 22 Elbert # 23 Fremont* # 24 Garfield # 25 Gilpin # 26 Grand # 27 Gunnison* # 28 Hinsdale # 29 Huerfano # 30 Jackson* # 31 Jefferson # 32 Kiowa # 33 Kit Carson # 34 Lake* # 35 La Plata # 36 Larimer # 37 Las Animas* # 38 Lincoln # 39 Logan* # 40 Mesa # 41 Mineral # 42 Moffat # 43 Montezuma # 44 Montrose* # 45 Morgan* # 46 Otero # 47 Ouray* # 48 Park* # 49 Phillips* # 50 Pitkin* # 51 Prowers # 52 Pueblo # 53 Rio Blanco* # 54 Rio Grande* # 55 Routt* # 56 Saguache* # 57 San Juan* # 58 San Miguel* # 59 Sedgwick # 60 Summit* # 61
Re: The state QSO Party thread
* On 2021 05 Sep 09:14 -0500, Thomas Beierlein wrote: > Hi Nate, > > Am Fri, 3 Sep 2021 21:08:50 -0500 > schrieb Nate Bargmann : > > > > > For some of these events it may be necessary to simply use Tlf as a > > logger as anything resembling accurate scoring may not be possible > > given the notion that stations are usually worked once or once per > > band/mode. State QSO parties often have mobile operators that move > > from county to county and the rules allow outstate participants to > > work those mobiles again for point and multiplier credit when they > > move to a new county. Some rules also permit working such a station > > once but logging it twice when it is on a county line or at the > > junction of multiple counties. So far as I'm aware, Tlf would treat > > additional such contacts on a given band/mode as a dupe. > > > > Please have a look at IGNOREDUPES in the man page for that. I do use that in all of my events settings which then allows logging the station again but with zero point credit. Normally, this is desired behavior. In the particular case I describe such is not the correct behavior, however, it really only affects scoring not what will ultimately be written to the Cabrillo file. Case in point, last night I had one operator give me two counties for the exchange. The Colorado QP rules state that a second QSO be logged for the additional county, etc. Here Tlf incorrectly scored it as zero points but WYSIWYG did count it as a mult. I have a lot of work to do to clean up a log with just 22 QSOs in it! I am also formulating some thoughts on WYSIWYG and that aspect of Tlf and will probably open a feature request in the issue tracker in the not too distant future. 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: The state QSO Party thread
Hi Nate, Am Fri, 3 Sep 2021 21:08:50 -0500 schrieb Nate Bargmann : > > For some of these events it may be necessary to simply use Tlf as a > logger as anything resembling accurate scoring may not be possible > given the notion that stations are usually worked once or once per > band/mode. State QSO parties often have mobile operators that move > from county to county and the rules allow outstate participants to > work those mobiles again for point and multiplier credit when they > move to a new county. Some rules also permit working such a station > once but logging it twice when it is on a county line or at the > junction of multiple counties. So far as I'm aware, Tlf would treat > additional such contacts on a given band/mode as a dupe. > Please have a look at IGNOREDUPES in the man page for that. 73, de Tom -- "Do what is needful!" Ursula LeGuin: Earthsea --
Re: The state QSO Party thread
On 9/3/21 10:08 PM, Nate Bargmann wrote: One of the aspects of amateur radio I've considered to get more active in are the various state QSO parties. To that end, I'm starting this thread to exchange information toward configuring Tlf for these events and discover areas where Tlf can be improved. Part of the sharing I plan is to provide my files after figuring out whether they work! Also, in the long run I hope to maintain a page on the Tlf Wiki documenting these events. Eventually a database of sorts of configuration files will exist for these events and we may even add them to the repository. One issue I ran into in the past with the Ohio QSO party was that the county abbreviations were 4 characters. I think I still have a patch to extend mults to 4 characters, but maybe a more general solution is needed. 73, Gary
Re: The state QSO Party thread [CO QP files]
Attached are the files I plan to use tomorrow for the Colorado QP as an outstate participant. One possible problem will be the counting of mults by Tlf. As signal reports are not used the exchange is name + county for instate participants and name + two letter state abbreviation for me. I suspect that Tlf will count a new mult for each station in a county given a quick test I did (log file attached), even though only the county should count as the mult. All suggestions welcome. The event starts at 1300z but I know I will only operate a few hours at most. 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 80SSB 04-Sep-21 02:56 0001 W0LD 59 59 LOREN BOU LOREN BO 1 3982.0 80SSB 04-Sep-21 02:56 0002 K0OJ 59 59 OJ WLDOJ WLD 1 3982.0 80SSB 04-Sep-21 02:57 0003 K0LD 59 59 LARRY BOU LARRY BO 1 3982.0 80CW 04-Sep-21 02:58 0004 W0KJ 599 599 JOE WLD JOE WLD 2 3981.3 #Cty Abb. ADA ALA ARA ARC BAC BEN BOU BRO CHA CHE CLC CON COS CRO CUS DEL DEN DOL DOU EAG ELP ELB FRE GAR GIL GRA GUN HIN HUE JAC JEF KIO KIC LAK LAP LAR LAA LIN LOG MES MIN MOF MON MOT MOR OTE OUR PAR PHI PIT PRO PUE RIB RIG ROU SAG SAJ SAM SED SUM TEL WAS WEL YUM # *Rare Counties # County Name # 1 Adams # 2 Alamosa* # 3 Arapahoe # 4 Archuleta* # 5 Baca # 6 Bent* # 7 Boulder # 8 Broomfield # 9 Chaffee # 10 Cheyenne* # 11 Clear Creek # 12 Conejos* # 13 Costilla* # 14 Crowley # 15 Custer* # 16 Delta* # 17 Denver # 18 Dolores # 19 Douglas # 20 Eagle # 21 El Paso # 22 Elbert # 23 Fremont* # 24 Garfield # 25 Gilpin # 26 Grand # 27 Gunnison* # 28 Hinsdale # 29 Huerfano # 30 Jackson* # 31 Jefferson # 32 Kiowa # 33 Kit Carson # 34 Lake* # 35 La Plata # 36 Larimer # 37 Las Animas* # 38 Lincoln # 39 Logan* # 40 Mesa # 41 Mineral # 42 Moffat # 43 Montezuma # 44 Montrose* # 45 Morgan* # 46 Otero # 47 Ouray* # 48 Park* # 49 Phillips* # 50 Pitkin* # 51 Prowers # 52 Pueblo # 53 Rio Blanco* # 54 Rio Grande* # 55 Routt* # 56 Saguache* # 57 San Juan* # 58 San Miguel* # 59 Sedgwick # 60 Summit* # 61 Teller* # 62 Washington # 63 Weld # 64 Yuma RULES=coqp # # # # # 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
Re: The state QSO Party thread [KS QP files]
As promised, here are the files I use as an instate participant in the Kansas QSO Party. Thanks to Tom for putting together the code that allows the "sections_mult" file ksqp.txt to hold the Kansas county abbreviations that all count toward the KS mult. The rest is all rather straight forward Tlf configuration. I will note that our rules allow using the cluster so it is one of the rare times I use it during an event. 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=ksqp LOGFILE=ksqp_2021.log CONTEST_MODE CABRILLO=UNIVERSAL 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 KQP % F2=@ DE % F3=@ 5NN MSH F4= TU F5=@ F6=% F7=@ SRI QSO B4 GL F8=AGN F9=? F10=QRZ? F11=PSE K F12=CQ KQP % # CQ_TU_MSG=TU % S_TU_MSG=TU 5NN MSH # #ALT_0= ALT_1=DE N0N, DE N0NB OP #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=/home/nate/logs/wav/N0N/kqp/F1.wav VKM2=/home/nate/logs/wav/N0N/kqp/F2.wav VKM3=/home/nate/logs/wav/N0N/kqp/F3.wav VKM4=/home/nate/logs/wav/N0N/kqp/F4.wav #VKM5= VKM6=/home/nate/logs/wav/N0N/kqp/F6.wav #VKM7= VKM8=/home/nate/logs/wav/N0N/kqp/F8.wav #VKM9= VKM10=/home/nate/logs/wav/N0N/kqp/F10.wav VKM11=/home/nate/logs/wav/N0N/kqp/F11.wav VKM12=/home/nate/logs/wav/N0N/kqp/F12.wav VKSPM=/home/nate/logs/wav/N0N/kqp/SPM.wav VKCQM=/home/nate/logs/wav/N0N/kqp/CQM.wav # # # # Scoring rules# # # MIXED RECALL_MULTS SSBPOINTS=2 CWPOINTS=3 SECTION_MULT_ONCE MULT_LIST=ksqp.txt ### END # # DX DX # Canada provinces AB BC MB NB NL NT NS NU ON PE QC SK YT # US states (50) AL AK AZ AR CA CO CT DE FL GA HI ID IL IN IA KS KY LA ME MD MA MI MN MS MO MT NE NV NH NJ NM NY NC ND OH OK OR PA RI SC SD TN TX UT VT VA WA WV WI WY # KS counties (105) KS:ALL,AND,ATC,BAR,BRT,BOU,BRO,BUT,CHS,CHT,CHE,CHY,CLK,CLY,CLO,COF,COM,COW KS:CRA,DEC,DIC,DON,DOU,EDW,ELK,ELL,ELS,FIN,FOR,FRA,GEA,GOV,GRM,GRT,GRY,GLY KS:GRE,HAM,HPR,HVY,HAS,HOG,JAC,JEF,JEW,JOH,KEA,KIN,KIO,LAB,LAN,LEA,LCN,LIN KS:LOG,LYO,MRN,MSH,MCP,MEA,MIA,MIT,MGY,MOR,MTN,NEM,NEO,NES,NOR,OSA,OSB,OTT KS:PAW,PHI,POT,PRA,RAW,REN,REP,RIC,RIL,ROO,RUS,RSL,SAL,SCO,SED,SEW,SHA,SHE KS:SMN,SMI,STA,STN,STE,SUM,THO,TRE,WAB,WAL,WAS,WIC,WIL,WOO,WYA RULES=ksqp # # # # # 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=N0N # # # # # # 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
