[wsjt-devel] Error in PSK spots

[Mike Lewis]

I was watching FT8 6M spots on HamSpots.net.  I switched my rig which was on 
40m to 6M.  There was no activity on 6m but the 40m contacts last heard got 
reported as 6M band stations.   This was likely due to my switching in the 
middle of a decode cycle.

21m

CM2RSV

50315.21

-16

FT8

Cuba

K7MDL

21m

N8AWG

50314.58

-06

FT8

OH

United States

K7MDL

21m

K4SHA

50314.88

-11

FT8

AL

United States

K7MDL

21m

K2TW

50315.12

-19

FT8

NJ

United States

K7MDL

21m

KJ6TAG

50314.26

-11

FT8

CA

United States

K7MDL

21m

CM8NMN

50315.38

-15

FT8

Cuba

K7MDL



Switching in the middle could result I think either/or pre  and post switch 
data.  I believe this is a bug and suggest dumping spots when a band change is 
made in that decode cycle.

73,

Mike K7MDL
___
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]

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] Version 1 to Version 2 Conversion Paper

[Bill Frantz]

I have written a short paper about the conversion from from 
release 1 to release of the FT8 protocol and invite people to 
review the initial draft. It is mainly oriented toward software engineers.




Flag Day with FT8
Bill Frantz, AE6JV
West Valley Amateur Radio Association
Northern California DX Club
Northern California Contest Club

Abstract

Recently a community of over 20,000 users did a conversion 
between release 1 and release 2 of a amateur radio digital 
communications protocol called FT8. The old version of the 
protocol was not compatible with the new version, resulting in a 
flag day event for users. However, the conversion was rapid 
proceeded smoothly. Lessons from this conversion should be 
useful for other software projects.



Please let me know of any errors or omissions.

Thanks - Bill AE6JV

---
Bill Frantz| If you want total security, go to prison. 
There you're
408-356-8506   | fed, clothed, given medical care and so on. 
The only

www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower



___
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