Roger Rehr W3SZ w3sz73 at gmail.com
Fri Nov 4 21:33:20 CET 2016

HI Ed,

Thanks for the note and the great comments.  I have a couple of
comments-on-your-comments that I think would be of general interest,
which I interspersed below.

> Its my understanding that one can record the soundcard audio stream 
> as a .wav file which you could then run on WSJT or MAP65, and compare 
> how well they decode.  I am less concerned that the signal level 
> reported is the same, than that the decoding thresholds are 
> equal.  (actually I am not that concerned as I have excellent 
> performance from MAP65 and WSJT10, both using the KV decoder.
But there is no need to make such a recording.  With the system which
Alex and I use to compare MAP65 and WSJT, the real-time signals as they
are received and sent to both programs are identical.  There is no
reason to make a recording to use for input.

You might say that other stations that couldn't do the proper evaluation
of MAP65 and WSJT in real-time as Alex and I did might want to make such
a recording in order to evaluate their systems.  But note that you can't
use one recording to directly feed MAP65 and WSJT, as they have
different input requirements.  MAP65 requires as input a 96000 Hz
sampling rate wideband signal, while WSJT requires a narrowband (2.4-5
kHz wide) signal at 11025 Hz sampling rate.  So if you made a single
recording to feed to both, it would need to be a 96000 Hz sampling rate
wideband signal that you fed into a Linrad master which you then used to
send timf2 data to MAP65, and that same instance of Linrad would also
have to produce processed audio reduced to a narrow band signal at 11025
Hz sampling rate to feed WSJT.  That would be essentially an identical
system to what Alex and I use for our tests, but with a recorded
wideband file instead of off the air signals used for input to Linrad.
(Actually it would be slightly simplified, using the master Linrad to
produce the audio signal for WSJT instead of using a slave Linrad to
feed multiple WSJT instances).   So if the station had the capability of
doing the experiment with a recorded file, that station could have also
done it in real-time. 
> I am a little surprised that WSJT-X is usable for eme; my take was 
> that it was designed for HF?
I was experimentally using a WSJT-X development version (v 1.7.0-rc1
r7219).  As an example of how this looked during the EME contest, I have
put a screen grab taken by me during the first leg of the ARRL 2016 EME
contest at:

You will see 5 instances of WSJT-X running as well as MAP65 (and a few
other, irrelevant-to-this-discussion programs).

WSJT-X worked well for me during the contest with two caveats. 

The first caveat is simply that I did not use WSJT-X for transmitting at
all, because MAP65 took care of that.  So I can't report on the transmit
function of WSJT-X.

The second caveat is that there was some interesting behavior (with me
using both averaging and Deep Search simultaneously) where, once WSJT-X
had "decoded"/produced a message, the "Average Decodes" window would
sometimes continue to show that decode  recurring as a new message with
new time stamps, sequence after sequence, even though I had in fact
changed frequency and there was no possibility of my continuing to
receive that message.  This is just another example of the fact that
operator attention and intervention are necessary when using the WSJT
modes, as with any other mode of operation.  I mention it here only
because the frequency of such messages requiring "operator attention"
was much greater than I was used to seeing with WSJT or earlier versions
of WSJT-X without this averaging.  An example of this issue is seen on
this screen grab: 


I had completed working EI4DQ at 1340 and I changed frequency
immediately after that (he was at 144.117).  I worked K3RWR, completing
at 1400 on 144.135 and K1JT, completing at 1409 on 144.108.  So I was
NOT receiving ON 144.117 after 1340, and there was no way any instances
of WSJT-X could receive signals from EI4DQ after 1340.  But if you look
at WSJT-X-135 you will see in the "Average Decodes" window apparent new
decodes of EI4DQ at 1342, 1345, 1348, 1353, and 1403.  And if you look
at WSJT-X-Elecraft, you will see in the "Average Decodes" window new
decodes of EI4DQ at 1342, 1344, 1348, 1353, 1357, 1400, 1402, and 1403. 
During some of these periods I was transmitting, and in none of these
periods was either my WSE Linrad receiver or my Elecraft receiver on
EI4DQ's frequency.  Some of these "decodes" of EI4DQ were during odd
periods, and I believe that during this time he was only transmitting
during even periods.  So there is no possibility that these were real
decodes.  You can see other examples of messages from other stations
appearing in the "Average Decodes" window that also occurred across a
time span during which I hopped through multiple receive frequencies,
often without transmitting, so that there is no way that these stations
would have been similarly frequency hopping following my receiver from
frequency to frequency, and no way that these messages were "real".  I
tried using "Erase" and "Clear Avg" to stop these repeating messages,
but that did not seem to stop it in every case.  I believe that the "d#"
designation for the "Average Decodes" messages in question indicates
that they are a product of deep search, and the numeral indicates the
depth of the search required to produce the message.  And I also believe
that the "f#" designation means that the FT decoder produced the
message.  But I do not know any of that for certain.  My memory is that
this phenomenon was not limited to "deep search" messages, but my
recollection on that point may be faulty, and in this screen grab the
false messages are limited to messages with the "d#" designation.

It is quite possible that this interesting behavior is due to lack of
knowledge or user error on my part.  It could also be that it was an
issue in the version of WSJT-X devel that I used and which has since
been corrected.  WSJT-X development is now well beyond the version of
WSJT-X that I used.  It may well be that this is just another example of
why some user attention/intervention is still important with the WSJT
modes as it is with any other mode, as has been pointed out so many
times to us simple users by the experts.  But I mention this interesting
behavior here so that anyone who is experimenting with a pre-release
version of WSJT-X during the next leg of the contest knows that they
might see this behavior.  There are two bottom lines here:  User
attention and intervention are necessary with any mode of operation, and
the WSJT modes are no exception.  And don't necessarily believe it if
WSJT-X tells you that another station is following you up and down the
band trying to work you as you "search and pounce" on other stations who
are calling CQ.   :)
> Yes, keep comparisons for same decoding sw.
No, I disagree on this one.  The appropriate objective now is to see how
the currently available version of MAP65 compares with the best
available alternative, and that means comparing (MAP65 with the KV
decoder) with (WSJT-X with the FT decoder).   Again, the comparison of
(MAP65 with the KV decoder) and (WSJT with the KV decoder) has already
been done with data including huge numbers of decodes by both Alex and
me.  There is no reason to repeat those experiments with what is a
soon-to-be-obsolete piece of software (WSJT) in order to show the same
result yet again when that result is clear and already 4 years old.  But
a comparison between (WSJT-X using the Franke-Taylor) decoder and (MAP65
with the KV decoder) is a useful comparison to make, because those
programs are what people will be using until MAP65 gets the new
decoder.  When there is a version of MAP65 with the FT decoder available
to us, then comparing MAP65-FT to WSJT-X-FT will be appropriate, and I
am sure that several of us will be doing that comparison at that time.
> That will be another topic.  Be interested to read about and try using.
Thanks!  I hope that that there will be an opportunity to do that soon! 
But the WSJT-X / MAP65 developers have quite a lot on their collective
plate at this time, so I am not holding my breath.  It will come when it
does and we can all enjoy the great gifts that the developers have
already given us until then.

Thanks again for the great comments, Ed, and

Very 73,
Roger W3SZ

More information about the Moon-net mailing list