[CQ-Contest] Software Column in NCJ - Need Ideas

[Björn Ekelund]

A popular alternative to this, supported by several contest loggers, is to
send the last received
exchange as your exchange.

Speaking for the development team behind http://www.dxlog.net, we would be
more than
happy to support any pseudo-random exchange scheme.

Björn SM7IUN

Den sön 16 jan. 2022 kl 00:01 skrev Paul O'Kane <pokane at ei5di.com>:

> On 12/01/2022 15:55, Pete Smith N4ZR wrote:
>
> > Do you have specific software packages, or kinds of software, that
> > you'd like to see written about in NCJ? How about subjects *about*
> > software, and the influence of software on contesting?  One topic I'm
> > thinking about is call history files
>
> Call history files have contributed to the dumbing-down of contesting
> over the last 30 years or so.  It seems to me that there is little or no
> point in having on-air exchange elements that are known and pre-filled -
> CQ WW being the prime example.  And, no, I'm under no illusions - CQ WW
> will not change.
>
> The issue with fixed exchange elements is just that - they are fixed for
> the duration of the contest. They include, apart from the ubiquitous
> 59(9), zones, states, counties, districts, locators, IOTA references,
> and so on.  If you don't copy them the first time you'll probably get or
> hear them later.  Even if you don't, there are plenty of online
> resources that have the information, including licensing databases and
> QRZ.com.  And, yes, I know these are all against the rules.
>
> There is one exchange element that forces operators to copy it, and get
> it right, before logging the QSO - one that is impossible to deduce
> later without collusion with other operators concerned.  In 2017 the
> UK/EI Contest Club (ukeicc.com) ran a "random number" contest, as proof
> of concept.  The "new" number to be sent in each QSO was displayed by
> the logging software, but the number received could not be predicted,
> and had to be copied.
>
> The exchange (the number sent) was a pseudo-random number - with 4
> digits (always 4 digits, no leading zeros) between 1000 and 9999.  This
> number was a repeatable combination of the previous call logged and the
> previous number sent.  Being repeatable lets the adjudication software
> identify responsibility for errors or discrepancies between logs.
>
> The received number has to be copied and logged in real-time. Unlike
> serials, it is not possible to guess/generate it by listening to
> subsequent QSOs.  Without collusion (seeing other logs), an incorrect
> received number could not be "corrected".
>
> The concept worked, but was limited by the fact that it was not
> supported by N1MM+.  Any appropriate algorithm will work but, for it to
> be accepted, the N1MM+ crew would have to lead the way.  The other
> contest loggers would soon follow.  Note that knowledge of exactly how
> the "random number" calculation is done will not help anyone who didn't
> copy it on air.
>
> Here's what a "random-number" contest QSO might look like
>
> ei5di:   EI5DI TEST
>
> k1ki:    K1KI
>
> ei5di:   K1KI 3906
>
> k1ki:    7044
>
> ei5di:   TU EI5DI
>
> If you would more information, or to see it in operation, please contact
> me directly (pokane at ei5di.com), not via this mailing list.  I can
> demonstrate it on TeamViewer or Zoom.
>
> How about it - who will get the ball rolling?
>
> 73,
> Paul EI5DI
>
>
>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest at contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
>