Hi Paul,
it is a known defect in WSJT-X v2.0.0, already fixed for the next release.
Note your callsign does not have a unique hash code, hash codes are a
one-way function, a.k.a. lossy compression. Many callsigns can have the
same hash code, the point is to represent a callsign using less bits
that necessary to exactly represent the callsign, which is necessary if
the callsign is non-standard, or the other callsign is non-standard. A
standard callsign requires 28 bits to store, a non-standard callsign in
WSJT-X v2.0.0 FT8 and MSK144 modes can take up to 58 bits to store.
73
Bill
G4WJS.
On 16/01/2019 01:15, Paul Kube wrote:
Bill,
Then I don't understand why the hashcode for my call isn't used. It is
known, or my call wouldn't be correctly decoded in those two received
messages. Or so it seems to me.
73, Paul K6PO
On Tue, Jan 15, 2019 at 4:11 PM Bill Somerville <g4...@classdesign.com
<mailto:g4...@classdesign.com>> wrote:
On 16/01/2019 00:02, Paul Kube wrote:
> But why is my call hashed wrong in my own Rx Frequency window?
Hi Paul,
hash codes are just numbers, what you see is a lookup of a table
indexed
by the hash code. The wrong call is being looked up and printed.
There
is nothing wrong with the hash code, just a problem with how it is
translated to a callsign.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
