locked Re: WSPR Spot validation #WSPR


Bill Somerville
 

Mike,

other than the hash code table, the WSPR decoder is stateless and very rarely provides decodes with correct calls but corrupt grids. This can indeed happen with Type 2 and Type 3 messages due to hash collisions, although that would overwhelmingly produce false decodes where both the grid and call were valid but did not belong with each other, i.e. the wrong call printed. At least one of the cases cited had an unlikely grid for any station, I suggest that may be a false decode (which would have a correctly formatted grid) which was interpreted as a Type 2 or Type 3 message and a hash code lookup attached a valid but unrelated call to it.

73
Bill
G4WJS.

On 03/11/2021 13:57, Michael Black via groups.io wrote:

There are two points...one is bad decodes...the other is inaccurate grid reports which perhaps come from some internal error like not clearing the grid when a new call is decoded so an old grid gets used by default?

MikeĀ  W9MDB




On Wednesday, November 3, 2021, 08:55:29 AM CDT, Bill Somerville <g4wjs@...> wrote:


Mike,

please review the thread so far, you may have missed the point.

73
Bill
G4WJS.

On 03/11/2021 13:43, Michael Black via groups.io wrote:
We're trying to avoid bad decodes with bogus callsigns...not grids which could be a rover or somebody temporarily operating who frequently does not update their QRZ location.

The examples given were all bad decodes with invalid callsigns.


Mike



On Wednesday, November 3, 2021, 08:40:24 AM CDT, Roland <roland@...> wrote:


People are moving, changing locations for many reasons. Therefore I think a year is a long period of time for a client-side call/locator cache.


Join main@WSJTX.groups.io to automatically receive all group messages.