Multiple Park Entries (2fer)

Feature Requests
#1

Hi again…

Have been doing some more testing. This time I was messing around with entering 2fer, 3fer etc park activation info to see the results.

I do understand if more than one park is put in the MY_SIG_INFO or SIG_INFO the data requires more manipulation on my part to parse this data.

Here are my observations:

  1. See the attached Ref #1 & #2 & 3 when I tried to enter the data here it would not recognize the space bar entry note the results.
  2. I could input the P2P data in Comments Ref #4 but that still requires data manipulation
  3. The adi file: Info is there but with out spaces and data must be parse for multiple adi files

All to say this is just not a clean way of doing this however I appreciate there is only so much real estate on the display and this be the only recourse…entry to comments field may be best for P2P… allowing space entries in box #1 & 2 would help with data parsing and prepare multiple adi files.

However programmers can come up with some pretty cool solutions so I put it on the table for your consideration.

de Curt

2fers
2fers1351×810 195 KB
ve3zn

1 Like
#2

IMHO when working another station who is activating multiple parks, the best solution is to simply enter the QSO multiple times–once for each park you are contacting. Ultimately that is how the log needs to be submitted anyway.

Perhaps a “clone QSO” feature would be helpful? Enter it once, copy it, and change the park numbers for the cloned copies.

In reality it doesn’t take long to enter a second or third QSO on-the-spot. It could also be done afterwards; just put the second, third, etc. park numbers in the comments field to remind you to add them later.

Another approach – more complex from a developer standpoint but easier for the user – would be to allow entry of multiple parks, separated by a space, in the Park field and have the app clone the QSO automatically with only one park number in each. This same feature could be used when contacting a park with multiple ops: enter two or more call signs, separated by a space, and the app would create duplicate QSOs for those, too. That would be amazing when the contacted party consists of two operators doing a 2fer… HAMRS could autogenerate all four QSO log entries after the user enters two call signs and two parks in the Call and Park fields, respectively.

1 Like
#3

The more difficult use case occurs when you, as an activator, are activating multiple parks simultaneously.

“Clone to another park” might be a helpful feature to insert in the Logbook display page for logs that use the POTA template. Place it right beneath “edit” and “Export ADI”. It could replace all of the park numbers with a different number, prompt for a new file name, and advance the QSO time stamp by one minute for all QSOs to avoid triggering the POTA log upload dupe alert. (Be careful with the 1-minute shift so you don’t trigger a new UTC day, however… go backwards if already at 2359 UTC.)

You need to submit separate ADI files for each park anyway to the regional coordinator, so this would be a clean way to do it.

Jarrett, if you build a WWFF template, note that this feature would not be needed; they don’t allow multi-park activations.

#4

Some great suggestions! That sure would reduce the manipulation of data…and make life so much easier for an activator. I don’t think most Hunters appreciate how much time it takes to manage Xfer’s for P2P and Activators multiple parks. Multiply that for both programs (WWFF & POTA) and it has the potential for many mistakes let alone time consuming!
73 Curt ve3zn

1 Like
#5

Ok. So there’s a lot going on here, and I think they all need to be tackled at some point. I think the easiest thing for me to tackle right now is receiving a 2FER p2p. I like the idea of if put a comma separated list into “Their Park” I can create however many QSOs need to be created. So,

  1. Type ‘K-1111, K-2222’ into Their Park
  2. Fill out the rest of the form as usual
  3. Press enter or click save
  4. Two QSOs will pop up into the log table that are exactly the same, except for Their Park.

Having said that, and going off of what @KZ3L said, if I coul do something similar for the ‘My Park’ field:

  1. Type 'K-3333, K-4444 into My Park
  2. Fill out the rest of the form as usual
  3. Press enter or click save
  4. Two QSOs will pop up into the log table that are exactly the same, except for the My Park (MY_SIG_INFO) in the ADIF field.

So if both of these were in place, you were activating 2 parks, and got a 2-fer park to park, you would end up with 4 Qsos, correct?

#6

Jarrett,

Two inputs on this:

  1. In the “their park” field, how about just using a space to separate the park numbers? It’s one less character to type.

  2. Personally, I would steer away from allowing entry of two or more park numbers into “my park.” If you as the activator are doing a multi-park activation, you will be submitting multiple logs to the regional coordinator. You would NOT want both of your parks combined within a single ADI file. That’s the reason I suggested a “clone log” feature accessible from the main Logbook list screen. That would simply duplicate the current log but replace all of the “MY_SIG_INFO” content with a different park number so you end up with two separate logs.

Ultimately, if the P2P contact is activating two parks, and so are you, you do end up with four QSOs. But two of them are in one of your logs and two are in another log.

Now if the other party is doing multi-op and multi-park, you should be able to enter multiple call signs and multiple park numbers and have the log auto-generate one QSO for each park and call combination. For example, the other party has two ops doing a twofer activation = 4 QSOs generated from a single entry.

#7

Yes this is a complicated one!.. I actually had to make a check list to remind me what to do in these circumstances when I activate… I think I have this straight …hopefully KZ3L will jump in with his thoughts!

Their Park: that would work however that doesn’t take care of the issue of advancing the second QSO time stamp by one minute for all QSOs to avoid triggering the POTA log upload dupe alert.

My Park: for each My park A separate log must be prepared and again that doesn’t take care of the issue of advancing the second QSO time stamp by one minute for all QSOs to avoid triggering the POTA log upload dupe alert. This process would put 2 entries for each QSO into the single log and all the QSOs would have to be separated for the 2 logs. Not sure what would be gained.

Now that you have fried this OM old brain I turn it back to you…lol

De Curt VE3ZN

#8

@KZ3L & @VE3ZN Ok. this has helped a ton! So it sounds like creating two qsos for the p2p 2-fer (or 3 for 3fer, etc. etc.) is the way to go as long as I increment each QSO by 1 minutes. That’s ane asy feature to do.

The second, activating multiple parks, really sounds like I need to provide a way to duplicate a log, and change the park field on all of the qsos - do those qsos in the duplicate log need their timestamp addressed in anyway?

1 Like
#9

To be honest, I’m not sure how important it is to increment the time stamp by one minute to avoid flagging dupes in the POTA database. I’ll ask the question on the Facebook group to see if this truly matters. The developers may have made some adjustments to fix that, since CALL+BAND+UTC DATE+PARK constitutes a unique QSO anyway.

As for duplicating a log, there may be an even more elegant solution.

If I understand it correctly, changing anything in my QSO info (my call, my park, the frequency, mode, and band) is immediately effective upon entry of any subsequent QSOs. These data fields are inserted immediately into each QSO.

But if the intent is to use a single log to represent a single activation, then perhaps it would make more sense to have some fields that apply to the ENTIRE log upon export rather than being inserted into each individual QSO.

For example, as it is currently designed, I could enter K-1940 as my park, and partway through the activation change it to K-1964. That would be a foul for log submission.

Why not have some fields exist outside of each QSO and apply to the entire log? Changing “My Park” would affect the entire log when exported to ADIF, as it should. Similarly, other activator fields (as I offered in another thread) such as the grid square, ITU/CQ Zone, State, etc. would and should apply to the entire log.

With that structure, the most elegant solution would be to allow the user to enter several parks in “My Park”. These would not, at the time of each log entry, be associated directly with each entry and the QSOs would NOT need be duplicated in the displayed log. But when exporting the ADIF from the Logbooks list, if there is more than one park in the “My Park” list, give the user the option to (1) export entire log as one ADIF or (2) export multiple logs, e.g. one per activated park.

I would still allow the option to clone to a different program (POTA → WWFF, for instance) from the Logbooks list.

#10

Ok… I hope the following makes sense for you these comments below are from my notes and I how I prepare my submissions: I have an Excel tool that I can import the adi file manipulate the data and export it back out to an adi file.

I saw KZ3L comments about time (adding 1 min). That is being worked on but I don’t think any thing has been implemented yet! You may want to email Jason wrt to this issue to get a status.

If I run three 2fers all in ONE DAY…i.e. VE-0364 & VE-4882; and VE-4874 & VE-4882; and VE-1339 & VE-4882: Note VE-4882 is a river (Rideau River in this case) that runs by all these locations. So 4 logs need to be submitted one for each of the parks 0364 & 4874 & 1339 and one large file for 4882. So first you would make an adif file for 0364 & 4874 & 1339 . Then you would merge the data from 0364 & 4874 & 1339 in to one large file for VE-4882. Once that is done you need to remove the dupes in 4882 because you’ll work the same station in 0364, & 4874 & 1339 in the same day. (Only 1 entry per callsign and band)

Once the dupes are removed there is another issue that needs to be dealt with before you make your final adi file for VE-4882. It’s a database issue again with respect to time. The TIME_ON for the all the merge QSOs in the VE-4882 would have the same time as the 0364 & 4874 & 1339 adi files . So to correct that the convention is to add 1 minute to the TIME_On for each of the QSO’s in the VE-4882 EXCEL file before you make the ADI file.

I hope this useful. Not sure there is an easy solution but anything that helps will make data manipulation much easier. : )

de Curt VE3ZN

#11

Here’s what I believe to be the right answer on time adjustments: they aren’t necessary. The bottom line is that the approach discussed above will work just fine WITHOUT changing time stamps for the QSOs. I’ll explain below.

If two QSOs with the same Call Sign are entered into the same log, and there is a difference between them (e.g. a different park number in each associated SIG_INFO field), they will not be rejected as a duplicate when imported to the POTA database. The QSO entries are different. There is no need to change the time stamp. Upon retrospect, I’ve done it this way numerous times and never had a problem. I always got credit for both QSOs without changing the time stamp, as long as a different park number was entered into the SIG_INFO field.

The idea to change the time stamp arose when submitting multi-park logs. If the logs are identical in every way, except for the file name, the POTA upload utility rejects the logs as duplicates.

  • Technically speaking, ADIF logs submitted to POTA don’t require the MY_SIG and MY_SIG_INFO fields. Instead, the park numbers are conveyed through the naming convention of the file name. This presents a problem though–if an activator submits a log without those fields populated, and simply changes the file names to reflect the other park(s), the log contents end up being identical.

  • One solution was to offset the QSO times in one of the logs by one minute, so the file contents would be different.

  • The other approach, specifically cited/recommended in the POTA FAQs, is to include the MY_SIG_INFO field in the ADIF file and simply change the park number reflected in that field. By including MY_SIG_INFO in the logs and changing it for each, the log file contents are now different from each other and no funny business is needed to modify time stamps or anything else.

  • I attached a screen shot of the FAQ that addresses this.

    image
    image1125×2436 344 KB

#12

Curt, I would suggest not worrying about the use case you describe where multiple two-fers involving one of the same parks (like a trail, VE-4882 in your example) are completed in the same UTC day.

First off, I think that is pretty rare. Secondly, I think that would be almost too complex for a user to even understand or navigate an interface to accommodate this. And thirdly, the activator has two relatively simple alternatives. Either:

  1. Upload three logs for VE-4882. They will all be credited against the same UTC day and will appear as a single activation, which would be correct.

  2. Combine all three VE-4882 logs using a text editor, ADIF Master, another logging program, etc.

Just my opinion…

#13

So, we’ve talked about a lot in this thread, and THANK you for giving me insight it’s crucial - it sounds like, at the very least, I can move forward with capturing park 2fers, based on entering a number of marks in the ‘Their park’ field, and however many I find, creating a QSO for each with everything the same in the QSO except the SIG_INFO field. Correct?

#14

Agree! And recommend doing the same if multiple call signs are entered for a QSO (multi-op activation).

I believe that should work perfectly.

1 Like
#15

Awesome. Can do. You guys rock. Let me get this going, and we can then circle back around to activating multiple parks and what that looks like.

#16

Multiple parks in ‘Their Park’ has been added in 0.9.9! You can read about it here: 0.9.9 Released - 4/4/2021

1 Like
#17

I’ve activated dozens of times before HAMRS using either HAMLog73 or ACLog. Never have I incremented by one minute and had something rejected. Either I am fortunate or the one minute thing is one of those “things” that get passed around long enough that they become gospel. Also, IIRC, my 7 coordinator didn’t think it necessary. I hope I’m correct on that as it’s really a LOT of added work when you activate a couple/few hundred contacts at an activation.
73, Bill/WA7WS

#18

To my knowledge there is only one use case requiring a change to the log such as incrementing the time.

If you are activating a twofer, and submit the IDENTICAL file under two different file names (i.e. you simply copied the file and renamed it), it will be rejected by the POTA uploader. It thinks the file is being uploaded in error. This could happen if the only data fields present in your file are the call, band, mode, date, and time. Making a change, such as incrementing the QSO time by a minute, would make these files different from each other and avoid the duplicate log upload error.

However, most apps, including HAMRS, include the activator’s park number in the MY_SIG_INFO field. The activator needs to do a search-and-replace using the second park in the twofer to create the second file before submitting it. Once this is done, no other changes need to be made (except for giving the second file a new name reflecting the second park) since the contents of the files are no longer identical.