Re: [wsjt-devel] The FT4 and FT8 Communication Protocols

[Joe Taylor]

Hi Dave,

On 6/12/2020 4:07 PM, Dave Crockett WB4DFW wrote:

I do home-based Mac and PC support for local folks but I’m the first to admit 
that reading the QEX piece reinforced the scope of what has been involved in 
developing WSJT-X is WAY beyond my skill level!  Kudos to Joe and the team for 
phenomenal work, especially at this time when the sunspots are down and lots of 
us are stuck at home more than usual!

Some weeks ago I customized my parting transmission when answering CQs to read 
“RR73 BE SAFE” and during the month of May, any contacts with the K2H stations 
were sent off with “RR73 HEROES”.  We’re all in this together in so many ways.

Tnx & 73 de Dave, WB4DFW

PS…Good to see the sharing of credit among Joe, Steve and Frank at the top of 
the software screen with the new version.


Many thanks! ... And make that "Joe, Steve and Bill".

-- Joe


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

Re: [wsjt-devel] The FT4 and FT8 Communication Protocols

[Joe Taylor]

Hi Paul,

On 6/12/2020 5:17 PM, Paul Kube K6PO wrote:

Question: am I understanding correctly that the standard message payload 
devotes two whole bits for callsign suffixes /p and /r? (So it is 
theoretically possible to have a call using both?) Since these suffixes 
are so rare in practice I wonder if in retrospect you think this is a 
perhaps regrettable use of the message payload.


No regrets.  These usages are definitely not rare if you operate in VHF 
contests.


No, it is not possible for a call to have both /P and /R.  Message type 
i3=1 allows /R on either or both callsigns, as required for support of 
NA VHF contests.  Similarly, message type i3=2 allows /P on either or 
both callsigns.


-- 73, Joe, K1JT


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

Re: [wsjt-devel] The FT4 and FT8 Communication Protocols

[Bill Somerville]

Hi Paul,

there's only one bit per callsign. The protocol doesn't support both /P 
and /R for the same callsign, neither does it support /P for one 
callsign and /R for the other. Note only standard callsigns can be 
augmented with /P or/R, and then only when used in certain specific 
message types, which in turn encode that bit.


Note also that /P and /R suffixes are supported for the message types 
that allow a non-standard callsign, there's nothing special about that 
usage.


73
Bill
G4WJS.
On 12/06/2020 22:17, Paul Kube wrote:
Question: am I understanding correctly that the standard message 
payload devotes two whole bits for callsign suffixes /p and /r? (So it 
is theoretically possible to have a call using both?) Since these 
suffixes are so rare in practice I wonder if in retrospect you think 
this is a perhaps regrettable use of the message payload.


73, Paul K6PO

On Fri, Jun 12, 2020 at 11:52 AM Joe Taylor > wrote:


If you're interested in how the FT4 and FT8 modes work, and how
they are
implemented in WSJT-X, you can find all the technical details in a
paper by Steve Franke, K9AN, Bill Somerville, G4WJS, and Joe Taylor,
K1JT, published in the July/August issue of QEX.

A copy has been posted on the WSJT web site here:
https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf

        -- 73, Joe, K1JT



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

Re: [wsjt-devel] The FT4 and FT8 Communication Protocols

[Paul Kube]

Interesting to see how FT4 outperforms FT8 (by a lot!) in the high-latitude
moderately disturbed channel model.

Question: am I understanding correctly that the standard message payload
devotes two whole bits for callsign suffixes /p and /r? (So it is
theoretically possible to have a call using both?) Since these suffixes are
so rare in practice I wonder if in retrospect you think this is a perhaps
regrettable use of the message payload.

73, Paul K6PO

On Fri, Jun 12, 2020 at 11:52 AM Joe Taylor  wrote:

> If you're interested in how the FT4 and FT8 modes work, and how they are
> implemented in WSJT-X, you can find all the technical details in a
> paper by Steve Franke, K9AN, Bill Somerville, G4WJS, and Joe Taylor,
> K1JT, published in the July/August issue of QEX.
>
> A copy has been posted on the WSJT web site here:
> https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf
>
> -- 73, Joe, K1JT
>
>
> ___
> 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] The FT4 and FT8 Communication Protocols

[Dave Crockett]

I do home-based Mac and PC support for local folks but I’m the first to admit 
that reading the QEX piece reinforced the scope of what has been involved in 
developing WSJT-X is WAY beyond my skill level!  Kudos to Joe and the team for 
phenomenal work, especially at this time when the sunspots are down and lots of 
us are stuck at home more than usual!  

Some weeks ago I customized my parting transmission when answering CQs to read 
“RR73 BE SAFE” and during the month of May, any contacts with the K2H stations 
were sent off with “RR73 HEROES”.  We’re all in this together in so many ways.

Tnx & 73 de Dave, WB4DFW

PS…Good to see the sharing of credit among Joe, Steve and Frank at the top of 
the software screen with the new version.

> On Jun 12, 2020, at 2:45 PM, Joe Taylor  wrote:
> 
> If you're interested in how the FT4 and FT8 modes work, and how they are 
> implemented in WSJT-X, you can find all the technical details in a
> paper by Steve Franke, K9AN, Bill Somerville, G4WJS, and Joe Taylor, K1JT, 
> published in the July/August issue of QEX.
> 
> A copy has been posted on the WSJT web site here:
> https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf
> 
>   -- 73, Joe, K1JT
> 
> 
> ___
> 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

[wsjt-devel] The FT4 and FT8 Communication Protocols

[Joe Taylor]

If you're interested in how the FT4 and FT8 modes work, and how they are 
implemented in WSJT-X, you can find all the technical details in a
paper by Steve Franke, K9AN, Bill Somerville, G4WJS, and Joe Taylor, 
K1JT, published in the July/August issue of QEX.


A copy has been posted on the WSJT web site here:
https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf

-- 73, Joe, K1JT


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

Re: [wsjt-devel] WSJT-X V2.2.1 wsprd decode performance report + recommended wsprd command line flags

[Steven Franke via wsjt-devel]

Hi Rob,

WSJT-X v2.2.1 uses the following command line options for the Deep decoding 
setting: " -C 500 -o 4 -d “.  The “-d” option may be too intensive for 
low-powered machinese.  

You’ll notice that the number of Fano iterations is limited to only 500. 
Testing here indicated that this virtually eliminated false decodes from the 
Fano decoder which, in turn, results in a much cleaner hashtable.txt file. 
Almost all of the very small number of good decodes that are obtained with your 
more aggressive setting "-C 5000" that are not obtained with “-C 500” end up 
being picked up by the OSD algorithm anyway.

In addition to a cleaner hashtable.txt, v2.2 includes the decoded grid square 
in the hashtable. This is used to validate decodes produced by the OSD 
algorithm.  This largely eliminates the false decodes with valid callsigns and 
incorrect grids that were occasionally produced by v2.1.2.

73 Steve k9an

> On Jun 11, 2020, at 3:49 PM, Rob Robinett  wrote:
> 
> With the release of the enhanced wsprd decoder, I have published version 2.9g 
> of my  'wsprdaemon' system (http://wsprdaemon.org/)  and upgraded some of the 
> 25+ WD sites to run it.
> 
> In addition to running wsprd 2.2.1, wsprdaemon can run both that new wsprd 
> and old wsprd 2.1.x and compare the number of spots extracted by them from 
> the same 2 minute wav file.
> Unfortunately, the Raspberry Pi4 at worldwide top spotter OE9GHV doesn't have 
> quite enough CPU power to execute both wsprds (i.e. complete execution of 48 
> wsprds in one 2 minute wspr cycle) on all of the 24 antenna+band receive 
> channels at that site.
> 
> However at US top spotter KD2OM the i86 CPU running WD has no problem 
> performing the 66 decodes required to document the decode performance on the 
> 33 antenna+channels at that site
> You can see in the following table of spots decoded in the last 16 hours at 
> KD2OM, that the 20M DI (dipole) antenna channel decoded almost 6% more spots 
> using the new wsprd, while on other bands the difference is in the range of 
> 2.5-4.5%.
> 
> So my question is:  would a change to the flags passed to the new wsprd 
> further enhance decode performance, even if it costs more CPU time?
> I am currently passing the same flags and values to 2.2.1 as I do to 2.1.1, 
> e.g. /usr/bin/wsprd -c -C 5000 -o 4 -f 14.0956 200611_2036.wav
> During the transition from 2.0.x to 2.1.x Steve suggested adding '-o 4'.  
> Would the performance of the 2.2.1 wsprd benefit from a similar change?
> 
> Thanks,
> 
> Rob
> 
> 
> plex@Plexserver:~$ show-spots
> BAND ANT NEW_WSPRD OLD_WSPR
>   10  BE9 new9 old   0.00%
>   10  DI   21 new   20 old   5.00%
>   10  VE4 new4 old   0.00%
>   12  BE1 new1 old   0.00%
>   12  DI5 new5 old   0.00%
>   15  BE   91 new   91 old   0.00%
>   15  DI  124 new  122 old   1.64%
>   15  VE   95 new   95 old   0.00%
>   17  BE   95 new   95 old   0.00%
>   17  DI  416 new  413 old   0.73%
>   17  VE  120 new  119 old   0.84%
>   20  BE 1992 new 1953 old   2.00%
>   20  DI 4304 new 4073 old   5.67%
>   20  VE 2351 new 2297 old   2.35%
>   30  BE 1563 new 1514 old   3.24%
>   30  DI 2968 new 2874 old   3.27%
>   30  VE 1853 new 1812 old   2.26%
>   40  BE 3126 new 3048 old   2.56%
>   40  DI 3625 new 3555 old   1.97%
>   40  VE 2758 new 2700 old   2.15%
>   60  BE6 new5 old   20.00%
>   60  DI0 new0 old   -nan%
> 60eu  BE8 new7 old   14.29%
> 60eu  DI2 new2 old   0.00%
>   80  BE  296 new  283 old   4.59%
>   80  DI  523 new  505 old   3.56%
> 80eu  BE   85 new   83 old   2.41%
> 80eu  DI  104 new  104 old   0.00%
>  160  BE  211 new  192 old   9.90%
>  160  DI  242 new  240 old   0.83%
>  630  BE  108 new  101 old   6.93%
>  630  DI   25 new   25 old   0.00%
> 2200  BE   17 new   14 old   21.43%
> plex@Plexserver:~$
> 
> -- 
> Rob Robinett
> AI6VN
> r...@robinett.us
> mobile: +1 650 218 8896
> ___
> 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