[Lowfer] 474.2 kHz WSPR false decodes

[craig wasson]

Upon further review I see that with WSPR there are 81 bits sent per packet
with only 50 currently being used.

This means it would be easy to add a CRC check using either the 6 unused
bits in byte 6, or some part of currently unused bytes 7-9.  Only one bit
of byte 10 is actually sent so that is better reserved as a flag.

So - it's feasible to add a CRC check - it just needs to be perceived as a
requirement for future versions of the protocol.  I guess the question is -
would it be worth the effort to utilize some of these bits to prevent false
decodes?

Of course to maximize reception of very weak signals you would probably
want to log packets with errors since the call might still be valid - but
it should at least be flagged as potentially having an error.

Craig - N6IO



On Mon, Nov 23, 2015 at 1:27 PM, craig wasson <craig at wasson.com> wrote:

> Since my profession is data networking - WSPR frustrates me.  It has
> forward error correction, but that does not really prevent decoding bad
> packets.  It reduces the likelihood somewhat, but that is offset by making
> a totally unreadable packet somewhat readable - so you still get bad
> decodes.
>
> From reading the protocol specs there appears to be no error detection at
> all.  With only 50 bits of payload, there is not much room for a
> traditional checksum - or even a simple parity check.  I have not been able
> to figure out how the decoder knows when a potential packet is present as
> opposed to just random noise.  If anyone has any insight as to how the
> presence of a potentially valid WSPR packet is detected I'd appreciate the
> pointer.  I have a feeling it's buried in the FEC logic.
>
> It would be nice if a future WSPR packet format included some sort of
> error detection, but I'm at a loss as to where those extra bits may come
> from if you want to maintain backwards compatibility with existing
> formats.  About all I can think of is taking more advantage of the fact
> that the format of a valid call sign is somewhat specific and use this to
> shift a few bits around and create some sort of a checksum.  But the call
> is already fairly highly compressed - and in some cases replaced by a hash,
> so not a lot of room there.
>
> Craig - N6IO
>
>
>
> On Mon, Nov 23, 2015 at 11:41 AM, John Andrews <w1tag at charter.net> wrote:
>
>> Garry,
>>
>> Well, for one thing, the WG2XXO callsign is bogus for 630 meters, as it
>> belongs to a company with a grant up in the 2 GHz range.
>>
>> From some other recent activity, such as you mentioned, there are
>> suspicions of "pirates" in our midst, probably to be expected as the
>> possibility of a ham band gets more likely. Of course, U.S. call signs that
>> lack the "X" as the first letter in the suffix are definitely not real.
>>
>> Looking at the database, it appears that WG2XXM was sending on 475.710
>> during the periods that "WG2XXO" was decoded. That may be part of the
>> puzzle.
>>
>> John, W1TAG
>>
>>
>> On 11/23/2015 9:30 AM, Garry and Linda Hess wrote:
>>
>>> WSPR decodes are quite reliable in general. When false decodes occur
>>> they're usually not hard to identify - the callsign is bogus, the power
>>> level ridiculous, etc. However, recently I've seen a few decodes that
>>> appear reasonable by themselves, but when you look at others that have
>>> similar decodes the frequency is all over the map. For example, consider
>>> WG2XXO by searching the database as
>>>
>>> http://www.wsprnet.org/olddb?mode=html&band=2190&limit=200&findcall=WG2XXO&findreporter=&sort=date
>>> .
>>> Supposedly I decoded this station on Nov 19 from FN30. Strange no NE
>>> listeners reported it. The callsign is real but the FCC FORM 442
>>> indicates an address in NC not New England. Others have reported decodes
>>> for the same callsign but some of them are for 2 frequencies
>>> simultaneously and overall the frequency given varies wildly.
>>>
>>> Other suspect callsigns are WH2XKW, WH2WYT, and WH2WSX. Perhaps there
>>> are more.
>>>
>>> If anyone knows these stations are for real I'd like to hear about it.
>>> To me these "reasonable" decodes look like the result of RX overload/IM.
>>> Not sure what the other reporters are using for receive but my eprobe,
>>> despite impressive IM2 and IM3 specifications, produces IM products that
>>> can be ripe for misinterpretation. The problem may also relate to
>>> different decoding software between WSPR and WSPR-X. I've been using the
>>> latter.
>>>
>>> 73, Garry, K3SIW, EN52ta, Elgin, IL
>>> ______________________________________________________________
>>> Lowfer mailing list
>>> Home: http://mailman.qth.net/mailman/listinfo/lowfer
>>> Help: http://mailman.qth.net/mmfaq.htm
>>> Post: mailto:Lowfer at mailman.qth.net
>>> Post must be less than 50KB total for message plus attachment!
>>>
>>> This list hosted by: http://www.qsl.net
>>> Please help support this email list: http://www.qsl.net/donate.html
>>>
>> ______________________________________________________________
>> Lowfer mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/lowfer
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:Lowfer at mailman.qth.net
>> Post must be less than 50KB total for message plus attachment!
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>>
>
>