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
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
wrote:
> On 16/01/2019 00:02, Paul Kube 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,
Have a look at this QSO between me (K6PO) and K8CHY/4:
[image: hashdecode.PNG]
The strangeness is in my transmissions at 23 and 230030, where
appears instead of . When my QSO partner's transmissions are decoded,
appears as it should. I guess he was able to decode my transmissions
all
