Adif Standard Version Supported by Aclog
|
If I understand you right, you want to have ONE FIELD........ that can have
toggle quoted message
Show quoted text
either a POTA activator park #, a POTA hunter park #, or an SKCC #..... and you want this single field to recognize the difference? I don't see how, not within AC-Log. But good luck with that..... Vy73 - Mike - KD5KC. El Paso, Texas - DM61rt. SOTA W5T-Texas Association Manager. -----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Tom Moore via groups.io Sent: Saturday, December 14, 2024 16:56 PM To: [email protected] Subject: [N3FJPSoftwareUsers] Adif Standard Version Supported by Aclog Hi, I am trying to get an understanding of the format Aclog uses to write the adif files in that you can use to import and export data into. What version of the adif format does this software conform to and if there are fields I wish to use that are in later versions of the format that are not currently defined can I define these as custom fields and then have them exported when I export the records? In my specific use case I would like to log a contact as either a pota or skcc contact in a way that depending on the form I am using I am either in skcc or pota operating mode where the number I enter into the field gets put into skcc or pota for a specific park number. Longer out I would also like to find a way to log contacts in a way for pota to show if I was an activator or a hunter. Thanks, Tom |
开云体育Well, to the best of my knowledge - which isn't 100# guaranteed correct, but I would use three OTHER fields. ? ? Vy73 ?– ?Mike ?– ?KD5KC – WRFF851 – ?El Paso – Texas ?– ?DM61rt. ? SOTA W5T-Texas Association Manager.
? The canyons are calling, colorful and deep. ?But I have promises to keep. And miles to go still in my Jeep...? ?And miles to go still in my Jeep... ? ? ADVENTURE: ?The respectful pursuit of trouble.? ? An EXIT is really an ENTRANCE to someplace new. ? It isn’t an ADVENTURE until something goes wrong! ? ? ? ? -----Original Message----- ? Ni, What I would do is create two data entry forms. One for skcc and another for pota. Each form would have a field labeled either pota or skcc and I would put the park or skcc number into the field depending on the type of operating I happen to be doing at the time. One type of field that may not be defined as of yet is if I am operating pota there may not be a field definition to log if I am an activator or hunter when entering data in. ? Tom ? -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Mike Olbrisch via groups.io Sent: Saturday, December 14, 2024 7:03 PM Subject: Re: [N3FJPSoftwareUsers] Adif Standard Version Supported by Aclog ? If I understand you right, you want to have ONE FIELD........ that can have either a POTA activator park #, a POTA hunter park #, or an SKCC #..... and you want this single field to recognize the difference? ? I don't see how, not within AC-Log.? But good luck with that..... ? ? Vy73 - Mike - KD5KC. El Paso, Texas - DM61rt. SOTA W5T-Texas Association Manager.
? ? ? -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Tom Moore via groups.io Sent: Saturday, December 14, 2024 16:56 PM Subject: [N3FJPSoftwareUsers] Adif Standard Version Supported by Aclog ? Hi, I am trying to get an understanding of the format Aclog uses to write the adif files in that you can use to import and export data into. What version of the adif format does this software conform to and if there are fields I wish to use that are in later versions of the format that are not currently defined can I define these as custom fields and then have them exported when I export the records? ? In my specific use case I would like to log a contact as either a pota or skcc contact in a way that depending on the form I am using I am either in skcc or pota operating mode where the number I enter into the field gets put into skcc or pota for a specific park number. ? Longer out I would also like to find a way to log contacts in a way for pota to show if I was an activator or a hunter. ? Thanks, Tom ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
|
Hmmmmm? The latest ADIF definitions that both Mike and Scott reference have recently defined actual POTA fields: POTA_REF and MY_POTA_REF. Yes, we could use those labels on "other" fields instead of SIG_INFO and MY_SIG INFO, and the results would look more descriptive.? However, do we know if the management of the actual POTA.APP logs use those fields now?? ...off to another rabbit hole...
?
Meanwhile, MANY THANKS to Scott for his excellent software!
--
72 de N4REE, Bob Easton - QRP CW forever |
开云体育I have an “IN” with one of the POTA-IT guys.? I’ll ask.? I’ll come back with an answer ASAP! ? Vy73 ?– ?Mike ?– ?KD5KC – WRFF851 – ?El Paso – Texas ?– ?DM61rt. ? SOTA W5T-Texas Association Manager.
? The canyons are calling, colorful and deep. ?But I have promises to keep. And miles to go still in my Jeep...? ?And miles to go still in my Jeep... ? ? ADVENTURE: ?The respectful pursuit of trouble.? ? An EXIT is really an ENTRANCE to someplace new. ? It isn’t an ADVENTURE until something goes wrong! ? ? ? ? From: [email protected] <[email protected]> On Behalf Of N4REE - Bob
Sent: Monday, December 23, 2024 8:06 AM To: [email protected] Subject: Re: [N3FJPSoftwareUsers] Adif Standard Version Supported by Aclog ? Hmmmmm? The latest ADIF definitions that both Mike and Scott reference have recently defined actual POTA fields: POTA_REF and MY_POTA_REF. Yes, we could use those labels on "other" fields instead of SIG_INFO and MY_SIG INFO, and the results would look more descriptive.? However, do we know if the management of the actual POTA.APP logs use those fields now?? ..off to another rabbit hole... ? Meanwhile, MANY THANKS to Scott for his excellent software! -- 72 de N4REE, Bob Easton - QRP CW forever |
|
Yes Kevin.? We just had an exchange this morning. The answer is "development is working on it." They also mention that there's no time frame.
?
Now, consider this: Currently, the logging requirements that Kevin links to show a list of "Optional Fields" which contains variations of the SG_INFO that we have been discussing. By calling them "optional," I infer that they don't matter at all and aren't used as part of the POTA program ... at least, not now.? So, we could change the labels in N3FJP to whatever we like.? Being mildly pedantic, I'll go with the new POTA_REF labels.
?
--
72 de N4REE, Bob Easton - QRP CW forever |
|
Let's put an end to the speculation. ADIF is specifically addressed here:
Which states in part: "Optional ADIF fields support park-specific information. These data are processed for your activation location and park-to-park contacts, primarily when an activator is located at multiple parks during the same UTC day or when many operators contribute to contacts for a club callsign or special event callsign. When the MY_SIG and MY_SIG_INFO fields are missing or invalid, the POTA uploader will prompt the user for the needed information during the upload process." The database front end can extract the basic activation information from the file name if the published file name format is adhered to by activators. The SIG* fields are a fallback in that respect. However they do help with identification of park-to-park contacts. You don't actually need SIG and MY_SIG if you are uploading just POTA. If you work multiple programs and use the same log they are handy to keep things sorted. Naturally it will take some time to migrate the use base when the new fields are implemented. To the best of my knowledge the database will support both the SIG* fields and the new ones. Please bear in mind that the POTA developers are all volunteers with day jobs and families. And they like to get on the air in their spare time as much as the rest of us do. Have patience. They will get there. On Mon, 23 Dec 2024 08:45:27 -0800 "N4REE - Bob via groups.io" <N4REE@...> wrote: Now, consider this: Currently, the logging requirements that Kevin links to show a list of "Optional Fields" which contains variations of the SG_INFO that we have been discussing. By calling them "optional," I infer that they don't matter at all and aren't used as part of the POTA program ... at least, not now.? So, we could change the labels in N3FJP to whatever we like.? Being mildly pedantic, I'll go with the new POTA_REF labels. -- 73 -Jim NU0C |
|
Here's the deal.
Currently, the POTA database is using ADIF version 3.1.3. The database is undergoing a rewrite which will incorporate the latest ADIF version, but that may not go on line until late next year at the earliest. So, for now, the MY_SIG_INFO and SIG_INFO fields are valid and POTA_REF is not yet implemented and is ignored for now.
?
MY_SIG_INFO entries with the park number activated (the dash is ALWAYS required) is recommended for ease of processing, however, in the case of multi-park activations, it is required to prevent the log from being rejected as a duplicate. We typically get 2-3 tickets per day for multi-park activations that result in duplicate log rejection for missing MY_SIG_INFO entries.
?
SIG_INFO entries containing the distant park number are recommended for Park-to-Park contacts to ease processing. Generally, the parser will match the contacts between logs without it. If the distant station is in a multi-park location, a separate contact record is required containing SIG_INFO entries for each park number to prevent the contact from being rejected as a duplicate.
?
Here's a recap for POTA log submission.
?
Required: CALL, BAND, MODE, QSO_DATE, TIME_ON. The log will not process at all without these.
?
Recommended: MY_SIG_INFO, MY_STATE (for multi-state parks), OPERATOR. On uploading, you will be prompted for these if they are not in the log.
?
Specific use cases:
?
MY_SIG_INFO is required for multi-park activations (two-fer, three-fer, etc.) to prevent duplicate log rejection.
SIG_INFO is recommended for P2P to ease processing, required if the other station is a multi-park location.
STATION_CALLSIGN is assumed to be the same as OPERATOR for single user activations. It is required for club or Special Event Station activations where the call used on the air differs from the operator's call or there are multiple operators.
?
All other fields (FREQ, GRIDSQUARE, COUNTY, RST, etc.) are basically ignored.
?
Filenames are basically ignored. In some cases, information missing from the log may be gleaned from the filename, but do not rely on it.
?
I hope this clarifies things. Any additional questions should be referred to the POTA Helpdesk at help@....
?
73,
Michael WA7SKG
POTA 7th Area Coordinator
POTA Helpdesk Agent
?
?
? |
开云体育Sir,?? ---?? OUTSTANDING INFO !!!?? Thank you so much for the reply.? This makes it all clear, for now maintain My_Sig_Info and Sig_Info in our AC-Log database.? At some time in the future the newer ADIF names will become active, and then we can change our field names. ? Vy73 ?– ?Mike ?– ?KD5KC – WRFF851 – ?El Paso – Texas ?– ?DM61rt. ? SOTA W5T-Texas Association Manager.
? The canyons are calling, colorful and deep. ?But I have promises to keep. And miles to go still in my Jeep...? ?And miles to go still in my Jeep... ? ? ADVENTURE: ?The respectful pursuit of trouble.? ? An EXIT is really an ENTRANCE to someplace new. ? It isn’t an ADVENTURE until something goes wrong! ? ? ? ? From: [email protected] <[email protected]> On Behalf Of Michael WA7SKG
Sent: Tuesday, December 24, 2024 12:20 PM To: [email protected] Subject: Re: [N3FJPSoftwareUsers] Adif Standard Version Supported by Aclog ? Here's the deal. Currently, the POTA database is using ADIF version 3.1.3. The database is undergoing a rewrite which will incorporate the latest ADIF version, but that may not go on line until late next year at the earliest. So, for now, the MY_SIG_INFO and SIG_INFO fields are valid and POTA_REF is not yet implemented and is ignored for now. ? MY_SIG_INFO entries with the park number activated (the dash is ALWAYS required) is recommended for ease of processing, however, in the case of multi-park activations, it is required to prevent the log from being rejected as a duplicate. We typically get 2-3 tickets per day for multi-park activations that result in duplicate log rejection for missing MY_SIG_INFO entries. ? SIG_INFO entries containing the distant park number are recommended for Park-to-Park contacts to ease processing. Generally, the parser will match the contacts between logs without it. If the distant station is in a multi-park location, a separate contact record is required containing SIG_INFO entries for each park number to prevent the contact from being rejected as a duplicate. ? Here's a recap for POTA log submission. ? Required: CALL, BAND, MODE, QSO_DATE, TIME_ON. The log will not process at all without these. ? Recommended: MY_SIG_INFO, MY_STATE (for multi-state parks), OPERATOR. On uploading, you will be prompted for these if they are not in the log. ? Specific use cases: ? MY_SIG_INFO is required for multi-park activations (two-fer, three-fer, etc.) to prevent duplicate log rejection. SIG_INFO is recommended for P2P to ease processing, required if the other station is a multi-park location. STATION_CALLSIGN is assumed to be the same as OPERATOR for single user activations. It is required for club or Special Event Station activations where the call used on the air differs from the operator's call or there are multiple operators. ? All other fields (FREQ, GRIDSQUARE, COUNTY, RST, etc.) are basically ignored. ? Filenames are basically ignored. In some cases, information missing from the log may be gleaned from the filename, but do not rely on it. ? I hope this clarifies things. Any additional questions should be referred to the POTA Helpdesk at help@.... ? 73, Michael WA7SKG POTA 7th Area Coordinator POTA Helpdesk Agent ? ? ? |
Mike Olbrisch
N4REE - Bob
Jim Shorney
Michael WA7SKG