Hi,
I'm new here. I've been having fun learning the ins and outs of FT8.
Just wanted to point out a couple of possible bugs I found with WSJT-X's
ft8code[.exe] program. It's difficult to search previous discussions to
find open issues or what kind of priorities the devs have, so apologies if
these are repeats etc.
I'm using ft8code.exe from 2.7.0-rc6 on Windows, and the 2.7.0-rc6 source
code
There are two ways to encode 'RR73' in a 15-bit GRID4. One is as a special
reversed code for RR73, and the other is as the grid square RR73 in the
Arctic Ocean.
In ft8code, and as far as I can tell in the main wsjtx app too, 'RR73' is
always encoded as the grid location, not the special RR73 code, despite
code which specially checks for it.
Example:
*❯ .\ft8code.exe "aa9go vk3pgo RR73" Message
Decoded Err
i3.n3----------------------------------------------------------------------------------------------------
1.
AA9GO VK3PGO RR73 AA9GO VK3PGO RR73
1. Standard msgSource-encoded message, 77
bits:01010010010110100110011110110111000100000100010100100010100111111001110101001*
...
Ignoring the final 3 bits which encode the message type, the next last 15
bits are the GRID4: 111111001110101
111111001110101 (=32,373), is a grid square. That is, it's less
than MAXGRID4=32400).
RR73 (the special code) is 111111010010011 (=32,403)
>From what I can read of the source code, I get the sense the initial
intention was to preferentially use the special code over the grid square
representation—it checks especially for it—then after some code dealing
with some toggles to add /R and /P suffixes to callsigns, it forgets that
it's already flagged the field for the RR73 code and discovers it's a grid
square and encodes it as such.
So I'm assuming this is a bug and not the original intention. Not a huge
bug, and it has little effect, but either way I'd love some clarification
to better understand the protocol and software.
Initially I thought this was only a bug with ft8code[.exe] but after
testing with WSJT-X, and comparing the audio output to the symbols from
that ft8code reports, it seems it transmits with the grid square encoding
too. (I couldn't work out a better way to confirm what symbols wsjt is
TXing than capturing the audio output in Audacity and looking at the
spectrogram)
Here's the patch to encode using the special code for RR73 rather than the
maidenhead grid. Note this patch is untested and I've never programmed in
Fortran:
patch for packjt77.f90 (change within subroutine pack77_1):
*1196c1196< if(is_grid4(grid4)) then---> if(is_grid4(grid4) .and.
irpt.ne.4) then*
Have dug through the source code some more and other places which deal with
RR73 appear to bias the special code. Examples from the source code
include: cablog, fix_contest_msg, fox_tx, subroutine ft8_a7d in ft8_a7.f90,
q65_hist, etc, but I'm eyeballing code I don't fully understand.
If you're worried about compatibility after changing this, I can repoort
that FT8_Lib packs the same input string using the special RR73 code, not
the grid square. The discrepancy between that implementation and this one
is how I first noticed this issue. It's a difference of just 5 of the 77
payload bits.
For reference, here's the expected (not the actual) output, with the 5 bits
flipped:
*❯ .\ft8code.exe "aa9go vk3pgo RR73"...*
*Source-encoded message, 77 bits:*
*01010010010110100110011110110111000100000100010100100010100111111010010011001*
*...*
Hope that's something helpful, and not something that's already been
discussed and decided on.
On second thoughts I'll put the other issue in another post.
Cheers,
Peter ("Pengo Wray") VK3PGO
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
