Re: [wsjt-devel] Strange hash collision?

[Bill Somerville]

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 > 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

Re: [wsjt-devel] Strange hash collision?

[Paul Kube]

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:
> > 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.
>
> 73
> Bill
> G4WJS.
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Strange hash collision?

[Bill Somerville]

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.


73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Strange hash collision?

[Paul Kube]

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 right. But why is my call hashed wrong in my own Rx Frequency window?

-- Paul K6PO
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel