Ok… lol. I think due to a long week at work, and just, my general newness to logging in general, I’ve really confused myself regarding when to use station_callsign and when to use operator. Tell me if I’m correct here: When operating by myself, my call (KB0ICT) should be output as station_callsign. When I’m operating with as a club - and I’ll say, I’ve never done this, I don’t exactly know how it works, which call you’re using on the air etc. - the club call becomes station_callsign and my callsign becomes operator.
So in my mind when looking at a log template having the fields ‘My Call’ and ‘Club Call’, maybe doesn’t jive with how they are intended to be used according to the ADIF spec:
operator - the logging operator’s callsign if station_callsign is absent, operator shall be treated as both the logging station’s callsign and the logging operator’s callsign
station_callsign - the logging station’s callsign (the callsign used over the air) if station_callsign is absent, operator shall be treated as both the logging station’s callsign and the logging operator’s callsign
For simplicity, does it make sense to always use operator as my personal callsign, and the one I pre-populate with whatever profile you are using, and leave station_callsign as the ‘optional’ field used for when you’re operating under a club call?
I feel like for new hams like myself, if I were to not label them ‘My Call’ and ‘Club Call’, and label them ‘Operator Callsign’ and ‘Station Callsign’ that would be extremely confusing, where as my call and club call provide some clarity.
This is what I get for coming back to this on a friday night after a looooong week of engineering, but I know you guys will set me straight
STATION_CALLSIGN should never be optional. That represents the legal identification used on the air.
For Field Day specifically, for the primary field day station, ARRL only cares about the call used on the air, which is the STATION_CALLSIGN in ADIF.
In your template, you should label it the same way ARRL does in their cover sheet: “Field Day Call Used:” and store it in the STATION_CALLSIGN field.
The OPERATOR field really is irrelevant for the primary Field Day log except for personal logging reference, or in the event the log will also be submitted to another program, like POTA if running Field Day at a qualifying park. In that case, entering the operator’s callsign will allow the operator to get POTA credit, too.
Personally, I would label and link as such:
“FD Call Used:” = STATION_CALLSIGN
“Operator’s Call:” = OPERATOR
“FD Call Used” would be mandatory. “Operator’s Call” would be optional.
*** break break ***
Be aware that clubs sometimes have a “Get on the Air” station. That is a different station callsign and should be logged in a separate log to tabulate those independently. Not sure if you’ve thought that through at all. Plus, the GOTA station does require a list of operators.
So it might be good to have a main field day station template, and a separate field day GOTA template. The GOTA template would use these fields:
“GOTA Station Call:” = STATION_CALLSIGN
“Operator” = Operator
Thank you so much for taking the time to write this out. I need to do an audit and make sure this is consistent across everything I’ve done, but this was extremely helpful. I can’t thank you enough.
ARRL doesn’t want the ADIF. Like other contests, it is the Cabrillo file (or a dupe sheet) they want for the main log, and a completed table for the GOTA entries (see link above) that contains operator calls and names. (By the way, will your template support operator names?)
Are you planning to generate files to support this entry form? Or will you export the ADIFs for the end user to import into another utility to generate the dupe sheets/cabrillo files and summary stats?
Unfortunately, contest reporting is very different from your typical ADIF-centric logging. I will have to defer to others with more contesting experience to elaborate any further on Cabrillo logs and other submission formats. Perhaps exporting an ADIF log into other contesting software, such as N1MM+, is an option… but that falls beyond my experience base.
You may have already thought through these issues; if so, I’ll step back and wait to see what you come up with.
