on4kjm / FLEcli

Multi-platform "Fast Log Entry"(FLE) processing tool
MIT License
30 stars 9 forks source link

P2P Contact #79

Open kylekrieg opened 2 years ago

kylekrieg commented 2 years ago

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

jmMeessen commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

jmMeessen commented 1 year ago

( 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 commented 3 months ago

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

` ADIF Export for Fast Log Entry by DF3CB

FLE 3.1.0 AA0Z N0SSC 20220409 1202 40m CW 599 599 POTA K-0001 POTA K-1234 AA0Z AA0Z W0MAG 20220409 1203 40m CW 599 599 POTA K-0001 POTA K-7890 AA0Z `
nicheath commented 3 months ago

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 commented 2 months ago

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.