Re: [wsjt-devel] FT8 notes

[Bill S. <g4...@cl...>]

HI Joe & Steve,

one quick win might be to implement a more CPU intensive decode at the 
Rx DF +/- a few Hertz when clicking the "Decode" button or double 
clicking the waterfall. I believe most of the logic to drive this is 
already in place.

73
Bill
G4WJS.

On 30/06/2017 15:34, Steven Franke wrote:
> Joe,
> Were these results obtained with 40 iterations for bp and norder = 3 for signals at or within 10 Hz of nfqso? If so, it might be interesting to see how the numbers would change if you dropped back to norder=2 for all signals.
> Steve
>
>> On Jun 30, 2017, at 9:25 AM, Joe Taylor<jo...@pr...>  wrote:
>>
>> Hi all,
>>
>> Thanks for a busy ~20 hours of many people testing FT8.  I now have accumulated a directory with 527 *.wav files, each of which has at least one visible FT8 signal.  The files were recorded at K1JT at either 14.079 or 50.313 MHz.
>>
>> Running the r7753 stand-alone slow-mode decoder jt9[.exe] on this collection of files produces 574 valid decodes and 0 false decodes with total execution time 39.8 s.  The average time to process a 15 s Rx sequence on this machine (Core i7-6700 @ 3.4 GHz) is thus 39.8/527 = 0.076 s.  Not bad!
>>
>> Here's the detailed execution-time breakdown from timer.out:
>>
>> Name                 Time  Frac     dTime dFrac    Calls
>> ----------------------------------------------------------
>> jt9                39.828  1.00     0.734  0.02        1
>>   read_wav           0.121  0.00     0.121  0.00    27404
>>   decft8            38.973  0.98     0.133  0.00      527
>>    sync8             4.191  0.11     4.191  0.11      527
>>    ft8b             34.648  0.87     0.051  0.00     2821
>>     bpd174           1.480  0.04     1.480  0.04     2821
>>     osd174          33.117  0.83    33.117  0.83     2210
>> ----------------------------------------------------------
>>                                     39.828  1.00
>>
>> Note that 83% of the execution time is spent in routine osd174, 11% in sync8, and 4% in bpd174 (a contraction for subroutine name bpdecode174).
>>
>> It turns out that only 14 of the 574 decodes were produced by osd174, the "ordered statistics" decoder.  The rest came from bpd174.  With osd174 deactivated, timer.out looks like this:
>>
>> Name                 Time  Frac     dTime dFrac    Calls
>> ----------------------------------------------------------
>> jt9                 6.641  1.00     0.891  0.13        1
>>   read_wav           0.168  0.03     0.168  0.03    27404
>>   decft8             5.582  0.84     0.094  0.01      527
>>    sync8             3.887  0.59     3.887  0.59      527
>>    ft8b              1.602  0.24     0.109  0.02     2821
>>     bpd174           1.492  0.22     1.492  0.22     2821
>>     osd174           0.000  0.00     0.000  0.00     2210
>> ----------------------------------------------------------
>>                                      6.641  1.00
>>
>> Now the average execution time for a 15 s Rx sequence is just 13 ms!
>>
>> We need to keep decoding time very short -- say, well under 1 s -- so that auto-sequencing, if not the human operator, can select proper responses to received messages.  Fortunately, we already have good baseline performance -- and we have a number of "knobs" to play with.
>>
>> 	-- Joe, K1JT