P2P Contact

[kylekrieg]

How does a P2P contact get logged in the fast entry window?

[jmMeessen]

Hello,

Thank you for your interest, @kylekrieg .
The principle is that you enter the reference (SOTA, WWFF, or POTA) of the other station after his call .

like 1407 dl0dan/p dlff-0002 dl/al-044 (this assumes that the band and mode has been defined earlier as the other global data)

I hope that this clarifies.
Note that I made assumptions of what you meant with "P2P" and "fast entry window". If I was wrong, please correct me by clarifying your question.

73 de ON4KJM

[kylekrieg]

I think you answered it. Just so we are on the same page, this would be a log that would be accepted?

{ Sample POTA log }

Header

mycall aa0z
operator aa0z
myPota K-0001

Log

date 2022-04-09
40m cw
1202 n0ssc k-1234
1203 w0mag k-5678 k-7890

[rsuzuki0]

Does this generate the SIG_INFO field in the ADIF according to POTA requirements?

[jmMeessen]

( I am currently with limited internet, so bear with me)

Hello @rsuzuki0
I believe that the POTA ADIF is following the specification, as far as I remember. This is where the test happens: https://github.com/on4kjm/FLEcli/blob/master/fleprocess/adif_write_test.go#L111

The first structure describe the input fields, the ADIF structure describes the expected result. Please point me the correct syntax if my assumption was wrong.

[nicheath]

@kylekrieg @rsuzuki0 looks right to me comparing to the sample adif here: POTA sample log

ADIF Export for Fast Log Entry by DF3CB <PROGRAMID:3>FLE <ADIF_VER:5>3.1.0 <EOH> <STATION_CALLSIGN:4>AA0Z <CALL:5>N0SSC <QSO_DATE:8>20220409 <TIME_ON:4>1202 <BAND:3>40m <MODE:2>CW <RST_SENT:3>599 <RST_RCVD:3>599 <MY_SIG:4>POTA <MY_SIG_INFO:6>K-0001 <SIG:4>POTA <SIG_INFO:6>K-1234 <OPERATOR:4>AA0Z <EOR> <STATION_CALLSIGN:4>AA0Z <CALL:5>W0MAG <QSO_DATE:8>20220409 <TIME_ON:4>1203 <BAND:3>40m <MODE:2>CW <RST_SENT:3>599 <RST_RCVD:3>599 <MY_SIG:4>POTA <MY_SIG_INFO:6>K-0001 <SIG:4>POTA <SIG_INFO:6>K-7890 <OPERATOR:4>AA0Z <EOR>

[nicheath]

So I was playing around with this again and it looks like the the ADIF output is indeed missing the first P2P of the second QSO.

The second record should have the following elements. (A double check by @kylekrieg would be helpful here.)

<STATION_CALLSIGN:4>AA0Z <CALL:5>W0MAG <QSO_DATE:8>20220409 <TIME_ON:4>1203 <BAND:3>40m <MODE:2>CW <RST_SENT:3>599 <RST_RCVD:3>599 <MY_SIG:4>POTA <MY_SIG_INFO:6>K-0001 <SIG:4>POTA <SIG_INFO:6>K-5678 <SIG:4>POTA <SIG_INFO:6>K-7890 <OPERATOR:4>AA0Z <EOR>

See N0AW qso line in sample POTA adif.

[nicheath]

So I did some testing with my last pota activation, uploading a log in the format of the POTA sample ADIF having multiple parks in one record e.g. <sig:4>POTA <sig_info:7>GB-0022 <sig:4>POTA <sig_info:7>GB-0711 and POTA did not count that as two qsos.

All that to say that I don't think POTA's example of 2 parks in one adif record works with their system. Therefore, it is probably best to support this the same way HAMRS and other loggers do and make two separate ADIF records for each P2P.

It would be nice to have a command line switch to turn off that kind of feature for importing into master logbooks like LOTW.