This is a well known phenomena - surely you've seen
it discussed on the LF groups over the years.
All efficient communications schemes first of all remove
all redundancy from a message, before adding in tehe
controlled redundancy for the forward error correction (FEC).
One inevitability of this is that when the very occasional
burst of random noise or interference passes all the
requirements of the FEC in the decoder, the resulting
completely random message chucked out looks perfectly valid.
WSPR compresses callsigns and locators is such as way that
any random version of that compressed bit pattern regerates to
something that looks valid. So any randomly generated
message will be a callsign and a locator.
Any strong FEC will most of the time only chuck out correct
messages, or nothing. But just once in a while - bearing in
mind that each reception session with just pure noise /
interference present is actually thorwing thousands of
possible solutions at the decoder. So by the simple laws of
probability, you know for certain that occasionally somethign
will get past.
Of course, what everyone then ignores is that there is a
third level of error correction applied - the intel of teh
operator. You look at the result, and see that 0L9 is not in
locator square AA, so you know its false. I suppose it is
possible that the software could incorporate a lookup table of
valid call vs. Loc. but its easier to just let teh operator
filter out those false messages.
So, the fact the "... software is free .." is nothing to do
with the false decodes. Its a mathematical inevitability of
efficicient coding and heavy FEC.
BTW, trawling through the WSPR database to try to find what
you reported, it's [zero]L9 not [oscar]L9
ie 0L9 not OL9 which is an even more unlikely call
prefix, not Czech at all
Andy G4JNT
