I have created a branch and have got most of the way to a functional way to add your own postcode district and to log the contest exchanges, which are grid reference and postcode district.
However, there’s a couple of more difficult aspects to completing this feature:
The requested log format is REG1TEST (pp. 89 onwards), which PoLo doesn’t currently support. While the contest does accept Cabrillo uploads, these are converted to REG1TEST on a “best effort” basis and there’s no definition of which fields in a Cabrillo log your QSOs’ grid reference and postcode district should be placed in. So, we would probably have to add support for the REG1TEST format.
One other aspect already discussed is that it might be quite hard to support the scoring of Backpackers, which is based on the distance of each QSO (with multipliers for 4-digit grid and postcode districts, plus DXCCs). This would also be new to PoLo; I’m not sure how feasible it would be without requesting at least a 6-digit grid for every QSO. The REG1TEST format has a “claimed score” field in the header so I’m not sure if we should be submitting with that as a blank.
(There are other loggers that support REG1TEST so we could review if any have compatible licences and borrow their approach. We could also see if any of them would support postcode district in an ADIF import, then PoLo could do a cop-out solution of exporting ADIF, then having the user deal with score calculation and REG1TEST output in other software.)
For small screens, there is logic in MainExchangePanel that hides the RST fields if there isn’t much space. When we add fields for grid and postcode district, this is triggered so the RST fields can’t be used. However they are part of the contest exchange for Backpackers, so we really ought to include them. If we’re going to, we need to decide how best to do this e.g. make the area scrollable left-right, or maybe allow extensions to take over the area where the QSO partner name and location are currently shown if they need to:
Supporting REG1TEST should not be too hard, but it would be very helpful to find some good sample files.
We also have code to find the distance between to grids, so it’s a matter of figuring out how precise the contest requires this to be.
And as to RST fields, does the contest require a “real RST report”? Do they require this to match between logs? or do they do what 99% of contests do and just go for 59 both ways?
I would really like to not having scrollable fields. So if we can just omit RST, it would make our lives easier.
Yes that’s a good point, it didn’t occur to me that everyone probably sends 59 anyway - you can tell I don’t contest! The rules don’t specify anything about a “real” RST so my guess would be it’s a “59”. I will see if I can source some example files and find out which fields definitely need to be populated in REG1TEST.
For the distance, it looks like the scoring is based on kilometers so I would guess 6-digit grid is the norm.
This is not for RSGB Backpackers; I have separately asked the contest coordinator which fields their upload system actually uses, so hopefully PoLo doesn’t have to provide everything in this example file. I will update here when he comes back to me.
The example file above was generated by UcxLog 6.03; looks like N1MM also supports the format along with a list of other contest loggers I haven’t encountered before.
Notes:
Name, address, PSect, BBS address (!), rig, antenna etc. are all things that PoLo does not currently collect, so hopefully they are not required (or we can get the user to edit on a PC between PoLo export and upload).
Band and power are per-QSO in PoLo, but assumed fixed in REG1TEST. We could just take the first or last QSO and use the data from that.
Claimed scores, multipliers etc. in the header are all fully populated in this example. This is what we want to avoid if possible, so PoLo doesn’t have to know the rules of the contest…
Scores and “new” flags are also fully populated in each QSO.
Each QSO defines an “exchange” separate to “WWL” (i.e. grid). The example field doesn’t populate the “exchange” field at all; for Backpackers we can use the postcode district here.
Regarding your inquiry about REG1TEST fields, the adjudication system will calculate the score, multipliers, bonuses, and claimed score when the log is uploaded. Therefore, it’s unnecessary to populate these fields.
Additionally, the QSO points will be calculated by the system. However, please note that a zero score in the QSO lines of the EDI file indicates a “not claimed” QSO, as per the specification. The points for such QSOs will not be calculated and will remain zero.
So it looks like we get off easy in this one. No need to work out multipliers, bonuses or even points per QSO - if we leave them all blank the system will figure it out on upload.
Yeah, I had hoped to get around to some code this weekend but life has gotten in the way! I think data entry for Backpackers is working, next step is for me to merge your REG1TEST support into my Backpackers branch then I should be able to write the output file and check it over for issues.
If we can get an example output file which we think is good, I will ask for it to be run through the contest system as a test to validate it. The last thing we want is for loads of people to use PoLo for the contest then find the files aren’t right!
