Thanks for the reply Joe
I had not made a note of the conditions under which the "OOO" turns into
"OO O", but I did see it again today while listening on 1296. I saw in
the felt window (not averaged):
2042 -6 5.0 1147 ## PA3FXB DK0ZAB JO61 OO O f
2034 -15 4.9 1177 ## PL9CHJ T86ABK NB09 OO O a2
Both do have 6 character calls. The first one is a good decode with correct identification
of the two stations in QSO. The second one is almost certainly spurious! The number of
characters sounds like a plausible explanation for the added spaces with some sort of
"tab" coming after a particular character count maybe?
Incidentally I also saw these:
2120 -23 4.5 1381 #* / E-NK901W-2H f
2126 -17 -3.4 1313 #* WAFH2PXLE85M4 f
Both quite clearly spurious decodes, so not really a problem. The human brain sometimes
comes in useful ...
Then I looked back though my all.txt file and found many examples, such as:
1016 -14 1.5 1264 ## KA1GT SM3RPQ JP74 OO O d12
1443 -9 1.5 802 ## KA1GT UP70A MO13 OO O d11
0825 -17 4.5 784 ## KA1GT W8MM EM79 OO O d12
0154 -20 2.6 1003 ## UA3TCF OK1DFC JN79 OO O f
0942 -30 2.1 1762 ## KA1GT F6KKR JN08 OO O d12
So it looks like all 6+6 call combinations split the "OOO". However 5+5
combinations and even 5+4 combinations also split the "OOO" when it's a Deep
Search decode. So it does indeed look like it's some sort of character count issue
that's inserting a tab or spaces. Looking at the text in a text editor that will show
tabs and whitespace, it appears that it's whitespace that is being inserted.
Not a problem now that I know it's a bug, not a feature!
Thanks and 73
From: Joe Taylor <joe(a)princeton.edu>
Sent: Sunday, April 5, 2020 4:16 PM
To: Bob Atkins <ka1gt(a)hotmail.com>om>; moon-net(a)mailman.pe1itr.com
<moon-net(a)mailman.pe1itr.com>om>; Russ <k2txb(a)comcast.net>
Cc: 'Doug Grant' <dougk1dg(a)gmail.com>
Subject: Re: [Moon-Net] WSJT-X average window behavior
On your oddball decode from WSJT-X with everything turned up to 11 and
1858 -30 2.6 1283 ## KA1GT OZ1CTZ JO46 OO O d32
Here's a hypothesis, and a question. Does the "split OOO" always occur
when your QSO partner's callsign has six characters? I suspect it's
just a matter of an "off by one" error in the character index when the
"d32" tag gets moved out to its position at end of line.
As you guys are discovering, message averaging was added onto the JT65
portions of WSJT-X late in the game, and has never been thoroughly
tested. As I wrote to Doug, it would be a big help if someone provided
us with a set of *.wav files which, when read back into WSJT-X, would
reproduce the bad behavior you have described. Bob? Russ? Can you do
This reflector is a bit of an oddity, itself. I sent a reply to Doug
and to moon-net about three hours ago. I haven't seen that reply yet,
posted on Moon-Net; but evidently others have seen it.
-- Joe, K1JT
On 4/5/2020 15:52, Bob Atkins via Moon-net wrote:
I think averaging works quite well, but you have to
know how to spot the
false decodes or old decodes from the real ones. Not usually that hard
if you check DT, the end of line decode info and have some idea of what
the decode should be. Leave averaging off unless you need it, reboot the
program from time to time (as needed). If you have things set for
maximum decode sensitivity then you will get quite a few false/spurious
decodes. If I leave things on overnight with averaging, DS and AP all on
there are often a few bogus/spurious decodes waiting for me. Some have
my call in them, some have plausible DX callsigns, some don't. You just
have to learn what's real and what's not.
Neither WSJTx window is as clean and free from extraneous decodes as it
could be, but software is never perfect and if you're operating at the
limits of detectability with everything turned up to "11", a few
spurious results are to be expected.
I'm still trying to figure out of there's any meaning to the extra
spaces in this decode:
1858 -30 2.6 1283 ## KA1GT OZ1CTZ JO46 OO O d32
Note it's "OO O", not "OOO". It's a low
but was confirmed with higher confidence (and higher signal strength)
and correct "OOO" on a subsequent transmission. If you look at the time
stamp, the DT, the sync indicator (#* and ##) and the end of line codes,
you can almost always figure out if a decode is valid. I've seen the
oddly spaced "OO O" more than once.
*From:* Moon-net <moon-net-bounces(a)mailman.pe1itr.com> on behalf of Russ
via Moon-net <moon-net(a)mailman.pe1itr.com>
*Sent:* Sunday, April 5, 2020 3:05 PM
*To:* moon-net(a)mailman.pe1itr.com <moon-net(a)mailman.pe1itr.com>
*Cc:* 'Doug Grant' <dougk1dg(a)gmail.com>
*Subject:* Re: [Moon-Net] WSJT-X average window behavior
Hi Doug.Yes, averaging does not work very well in WSJT-X.I still use it
when I am trying with a very weak station, but I’ve learned how to
detect when it has given me false information, usually.The biggest clue
is that the time delta is almost always shown as 1.5 on the bogus
decodes.I have seen it show decodes on contacts made several days ago,
and even on contacts that I didn’t even decode anything real, again with
the bad DT value.I have seen those bad decodes show up in the middle of
an ongoing contact, and sometimes when I come back to the computer after
letting it idle for long periods receiving nothing (not even pointed at
To minimize the problem, I keep averaging turned off all the time except
when I feel I really need it.As soon as I am done with a contact where I
do use averaging, I uncheck the averaging box and click the ‘clear
average’ button.Even that is not enough sometimes.It seems like WSJT-X
holds those bad decodes somewhere it it’s memory.I have had to resort to
shutting down WSJT-X and then restarting it.I think this will make it
totally forget, but I am not sure…
I’ve complained to the WSJT-X developers about this but was told that
they are working on ‘other stuff’ now.
73, Russ K2TXB
*From:*Moon-net <moon-net-bounces(a)mailman.pe1itr.com> *On Behalf Of
*Doug Grant via Moon-net
*Sent:* Sunday, April 05, 2020 12:30 PM
*Subject:* [Moon-Net] WSJT-X average window behavior
After using WSJT V9 for a few years I recently started using WSJT-X as a
second decoder. Sometimes it is better, sometimes not. It has the
advantage that it decodes when one station is calling another (V9 only
does this for strong stations).
One issue I am having is that the Average window in X sometimes shows
stations that I decoded way earlier...sometimes an hour or more earlier
and on a different frequency.
If I click Clear Avg or double-click Erase, the window clears. But a
while later, old decodes once again start to show up in the Average window.
V9 does not have this problem.
I have been using V2.0...today I moved to V2.1.2 and maybe that will be
better. Waiting for MR here.
Has anyone else experienced this behavior?
Does anyone know if that was a bug in the earlier version and fixed in
2.1.2 or can some one suggest what setting I may have set incorrectly?
Thanks & 73,
Moon-Net posting and subscription instructions are at