Bill/Reino,
Thank you for the link.
I missed it when I was searching around for the protocol. At the time
of my writing, I had come to the conclusion that I had 22 chars to play
with.
I'm taking a look at it right now.
Warren
On Mon, Jan 11, 2021, 17:25 Bill Somerville <[email protected]> wrote:
> On 11/01/2021 20:39, [email protected] wrote:
> > Ladies and Gentlemen,
> >
> > I would like to make a suggestion for a new feature.
> >
> > It would be useful that instead of requiring you guys to hard
> > code in contest setups, that the owner of the contest could provide a
> > configuration file that hams could import into the software for the
> > decoder to parse
> >
> > Looking at the code, I realize that this would be a major effort,
> > but unfortunately, while I do know enough to understand generally what
> > is happening, I don't have enough experience to write it.
> >
> > On a sidenote, it may be useful on the main screen to have a
> > toggle to turn contest debugging on and off, or to select which
> > contest decoder to use.
> >
> > PSUDOCODE CONFIG EXAMPLE:
> >
> > Parks on the Air (POTA) {Completely making up this format, POTA
> > doesn't have a specified form.....yet}
> >
> > pota.xml
> >
> > <Contest_Format>
> > <Exchange1>
> > <word1>
> > <text>CQ</text>
> > </word1>
> > <word2>
> > <text>POTA</text>
> > <ADIF>MY_SIG</ADIF>
> > </word2>
> > <word3>
> > </Callsign>
> > </word3>
> > <word4>
> > <EventID1> <- Generates a text box in the configuration
> > area could also have EventID2 or 3 or 4
> > <TexLabel>Park ID Ex: K-1234</TextLabel>
> > <Validation>(K\-[1-9]\d{3}\d?$)</Validation>
> > <ValidationFailure>Park ID format must be like
> > K-1234</ValidationFailure> <- Text for error box
> > <ADIF>MY_SIG_INFO</ADIF>
> > </EventID1>
> > </word4>
> > </Exchange1>
> > <Exchange2>
> > <word1>
> > <word1>
> > </Callsign>
> > </word1>
> > <word2>
> > </Callsign>
> > </word2>
> > <word3>
> > <WordValidation>([A-Z]{2}\d{2})|POTA)</WordValidation>
> > (POTA does not require spotters be participating in POTA, so can be
> > Maidenhead or POTA)
> > <ADIFStoreCheck>
> > <Validation>POTA</Validation>
> > <ADIF>SIG</ADIF>
> > </word3>
> > <word4>
> > <WordValidation>^$.|(K\-[1-9]\d{3}\d?$)</WordValidation>
> > (Because POTA does not require spotters to be participating in POTA,
> > this could be empty or a Park ID
> > <ADIFStoreCheck>
> > <Validation>(K\-[1-9]\d{3}\d?$)</Validation>
> > <ADIF>SIG_INFO</ADIF>
> > </word4>
> > </Exchange2>
> >
> > Exchange 3,4,5,6 would be the signal reports and RRR/73 if the contest
> > required it or allowed it.
> >
> > Respectfully Submitted,
> >
> > ~Warren Halstead
>
> Warren,
>
> please study the permitted message types, which are constrained by the
> source encoding of the protocol message payloads, and give conforming
> example QSO exchanges that you are expecting this template to define.
> You can find details of the message source encoding in this document:
>
> https://physics.princeton.edu/pulsar/K1JT/FT4_FT8_QEX.pdf
>
> 73
> Bill
> G4WJS.
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
