Hi Richard,
On 7/25/2017 4:58 PM, Richard Lamont G4DYA wrote:
On 25/07/17 00:17, Joe Taylor wrote:
Ubuntu MATE 16.04 amd64
1.7.1-devel r7939
Auto seq and call 1st enabled
Tried it and it looks as though FT8 now has a two-pass decoder, which is
nice.
Since you're providing feedback on development code, you should not need
to guess or make inferences about such things. Use the SVN commit
messages to see what is being added or changed.
The most recent relevant SVN commit message I could see was "r7911 More
work on deep decoding". From that I could only infer that it was a work
in progress.
Sorry, I'm sure those commit messages can seem rather cryptic. Here's a
particular one relevant to what you were asking about:
-------------------------------------------------------------------------
r7861 | k9an | 2017-07-12 17:49:39 -0400 (Wed, 12 Jul 2017) | 1 line
Use quarter-symbol steps for time sync. Lower sync threshold. Implement
subtraction and two pass decoding. Use osd2 only near nfqso.
-------------------------------------------------------------------------
... and there are several more having to do with "AP decoding", i.e.,
decoding with benefit of accumulating a priori information.
However, some things appeared out of sequence in the Rx window.
Out of order?? Please explain.
The timestamps appear out of chronological order (see further comments
below).
SP1HN's sudden jump from 1879 Hz to 1379 Hz and back again in mid-QSO
seems unlikely.
215645 Tx 1880 ~ CQ G4DYA IO82
215700 -12 1.3 1879 ~ G4DYA SP1HN JO73
215715 Tx 1880 ~ SP1HN G4DYA -12
215700 -11 0.3 1882 ~ G4DYA RA3WII KO71
215730 4 0.3 1883 ~ G4DYA RA3WII KO71
215730 3 0.9 1379 ~ G4DYA SP1HN R-12
215745 Tx 1880 ~ SP1HN G4DYA RRR
215815 Tx 1880 ~ SP1HN G4DYA RRR
215800 4 1.3 1880 ~ G4DYA SP1HN 73
215815 Tx 1880 ~ SP1HN G4DYA 73
Your copied lines came from the right-hand window. They contain both Rx
and Tx messages. The time label on a received message is the time of
the start of its Rx sequence. The time label on a Tx message is the
time this transmission actually started.
Your received messages are these:
215700 -12 1.3 1879 ~ G4DYA SP1HN JO73
215700 -11 0.3 1882 ~ G4DYA RA3WII KO71
215730 4 0.3 1883 ~ G4DYA RA3WII KO71
215730 3 0.9 1379 ~ G4DYA SP1HN R-12
215800 4 1.3 1880 ~ G4DYA SP1HN 73
They are all in proper chronological order.
Your Tx messages are these:
215645 Tx 1880 ~ CQ G4DYA IO82
215715 Tx 1880 ~ SP1HN G4DYA -12
215745 Tx 1880 ~ SP1HN G4DYA RRR
215815 Tx 1880 ~ SP1HN G4DYA RRR
215815 Tx 1880 ~ SP1HN G4DYA 73
They are also in proper chronological order.
The seemingly out-of-order times that you noted simply reflect the fact
that (for example) this decode
215700 -11 0.3 1882 ~ G4DYA RA3WII KO71
was not displayed until after the start of the following 15 s sequence,
by which time your new transmission had already started.
... I have noticed that the r7939/r7944 decoder is currently too slow to
be usable on my machine, which uses a Core 2 Duo E6700 CPU (2 x 2.66 GHz
cores), even with nothing much else running.
I think you understand now that this is definitely NOT the case. The
first decode at your Rx frequency should always be available well before
the start of the next 15-second sequence, even on a rather slow
machine. Decodes from "Pass 2" will take longer -- possibly 2 or even 3
s -- but that should seldom get in your way of making QSOs.
Finally, you asked
Is there a way to measure decode times accurately?
To get accurate time for decoding all the signals in a .wav file you can
do the following:
1. Settings -> General: check "Monitor off at startup".
2. Exit and restart WSJT-X.
3. Set RxFreq and Decode depth as desired.
3. File -> Open; select a .wav file, e.g., your 170725_194345.wav
4. Program will decode all available signals.
5. Exit WSJT-X
6. Use your favorite text editor to open the file "timer.out" in the
same directory as your WSJT-X logs.
Here are the "timer.out" results on two Windows machines in my shack,
using your file as input.
1. Win 10 64 bit, Core i7-6700 quad CPU, 3.4 GHz 8 GB, made in 2017:
Name Time Frac dTime dFrac Calls
----------------------------------------------------------
decoder 0.594 1.00 0.000 0.00 1
decft8 0.594 1.00 0.008 0.01 1
sync8 0.023 0.04 0.023 0.04 2
ft8b 0.563 0.95 0.406 0.68 223
ft8_down 0.008 0.01 0.008 0.01 223
bpd174 0.086 0.14 0.086 0.14 125
osd174 0.063 0.11 0.063 0.11 108
----------------------------------------------------------
0.594 1.00
2. Win 7 32-bit, Core 2 6600 CPU, 2.4 GHz, 2 GB, made in 2009:
Name Time Frac dTime dFrac Calls
----------------------------------------------------------
decoder 1.250 1.00 0.000 0.00 1
decft8 1.250 1.00 0.008 0.01 1
sync8 0.070 0.06 0.070 0.06 2
ft8b 1.172 0.94 0.773 0.62 223
ft8_down 0.016 0.01 0.016 0.01 223
bpd174 0.195 0.16 0.195 0.16 125
osd174 0.188 0.15 0.188 0.15 108
----------------------------------------------------------
1.250 1.00
Labels under "Name" in the first column are function names in the FT8
decoder. We use this tool to help us find "bottlenecks" in the code.
At you can see, most of the time is now spent in function ft8b() and two
functions that it calls.
Total time for 16 valid results was 0.594 s on the fast machine, 1.250
on the slow one. The first decode, close to the specifies RxFreq, would
most likely be out in less than 1/16 of that time. Probably less than
0.1 s, on both machines.
Most likely we will be able to further tune the FT8 decoder so that it
is both faster and better. But I think it's fast enough, already -- and
its sensitivity is already close to our theoretical expectations.
-- 73, Joe, K1JT
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
