Re: [wsjt-devel] WSJT-X low SNR performance

[Steven Franke]

Hi Joe,

I get it. That’s a really neat case. 

It just dawned on me that having improved the SNR of the sync tone correlation 
by 3 dB, we should be able to raise the detection threshold a bit and possibly 
reduce the number of spurious (false detections) vectors. That might speed 
things up a bit. 

Enjoy the conference!

Steve k9an

> On Nov 2, 2015, at 3:10 PM, Joe Taylor  wrote:
> 
> Hi Steve,
> 
> On 11/2/2015 3:59 PM, Steven Franke wrote:
>> Wait. What? Very cool example, but I’m confused.
>> 
>> When the user changes messages in mid-stream, my assumption
>> was that the program would jump to the beginning of the new
>> message symbol-stream, i.e. start at the beginning of a new
>> message. But then the second message would decode with a
>> big dt, which doesn’t show on your screenshot. So is the
>> program smart enough to just seamlessly start sending the
>> new symbols while retaining continuity on the sync sequence?
> 
> Correct.  The sync sequence continues un-interrupted; only the data 
> symbols are changed.
> 
> Let's say the Tx message was changed half-way through, at about t=25s. 
> Data symbols up to that time -- say, 31 of them -- correspond to the 
> first message.  The remaining 32 data symbols will be those of the 
> second message.  All 63 sync symbols are as they should be for a normal 
> (unmodified) message.
> 
> Suppose all data symbols in the wrong
> The signal was pretty strong, so data symbols in the "right" half of the 
> message are nearly all received without error.  Those in the "wrong" 
> half nearly all produce a hard error.  Still, that's only about 30 hard 
> errors -- so there's a good chance that sfrsd will decode both messages 
> correctly.
> 
>   -- Joe, K1JT
> 
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Bill Barrett]

HI Joe-


Just thought I would report it.
It's not bothering me as I know what causes it.
May be an issue for others if the on JT9 with a lot of additional JT9
stations.

I See you on 160 tonight.
Looks like Eu is coming through for the northern US stations.
SA here so far.

73; Good DX

Bill W2PKY


On Mon, Nov 2, 2015 at 6:47 PM, Joe Taylor  wrote:

> Hi Bill,
>
> OK, I now understand what you're reporting.  Version 1.6.1 r5910 is
> quite a while back, code-revision wise.
>
> I tried to reproduce your effect with the current revision, r6041.  I do
> see a small difference that depends on Rx freq: maybe one or two
> additional decoding seconds, with a total of around 15 decodes.
>
> I can't tell you the exact reason for this dependence, without
> additional work.  I don't see it as especially important -- but would
> like to understand why it's apparently "working harder" when Rx Freq is
> high.  I'll look into it further, when time permits.
>
> -- 73, Joe, K1JT
>
> On 11/2/2015 6:10 PM, Bill Barrett wrote:
> > Hi Joe-
> >
> > My observation is that the total time to decode the received signals is
> > influenced by the setting of the RX frequency.
> > IE if setting the RX @ 300 Hz all decoding [65&  9] proceeds rapidly.
> > if setting the RX to 2K or above the JT9 prints are delayed
> significantly.
> > My computer is a 4Ghz CPU with 8 Ex units.
> > Hope this helps.
> >
> > Bill W2PKY
> >
> > On Mon, Nov 2, 2015 at 4:27 PM, Joe Taylor  wrote:
> >
> >> Hi Bill,
> >>
> >> I'm not sure that I understand your point.  In JT9+JT65 mode, JT9
> >> decoding is attempted only at frequencies above the "blue line" marker,
> >> set by the "JT65  JT9" spinner control.  Decoding is always started
> >> first at the selected Rx frequency and mode, so the decode you care most
> >> about -- presumably the station you're trying to work -- comes out first
> >> among all those in its mode.  If you have a slow computer (or for some
> >> other reason) some decodes come out after the top of the minute, it's
> >> not a big concern.
> >>
> >> Have I mis-understood what was bothering you?
> >>
> >>  -- 73, Joe, K1JT
> >>
> >> On 11/2/2015 4:08 PM, Bill Barrett wrote:
> >>> Hello JT Developers-
> >>>
> >>> Running 1.6.1 5910, noticed when mode is set to JT65 + 9
> >>> and the RX frequency is greater than 1500 the JT9 decoding takes a long
> >>> time.
> >>> If the RX is above 2000 and there are a few JT9 prints the last one
> could
> >>> come at second 59.
> >>>
> >>> Regularly decode signals -26 -27 -28.
> >>>
> >>> 73, Bill W2PKY
> >>>
> >>>
> >>> On Mon, Nov 2, 2015 at 3:28 PM, Joe Taylor   wrote:
> >>>
>  Hi all,
> 
>  Here's an amusing screen shot.
> 
>  WSJT-X was running with 2-pass decoding enabled for JT65.  Note the
> two
>  decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx
> >> message
>  from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in mid-transmission.  The
>  decoder gets the "73" message in its first pass, and the "-21" message
> >> in
>  the second pass.
> 
>    -- Joe, K1JT
> 
> 
> 
> >>
> --
> 
>  ___
>  wsjt-devel mailing list
>  wsjt-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> >>>
> >>>
> >>>
> >>>
> >>
> --
> >>>
> >>>
> >>>
> >>> ___
> >>> wsjt-devel mailing list
> >>> wsjt-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >>
> >>
> >>
> --
> >> ___
> >> wsjt-devel mailing list
> >> wsjt-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >>
> >
> >
> >
> >
> --
> >
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Joe Taylor]

Hi Bill,

OK, I now understand what you're reporting.  Version 1.6.1 r5910 is 
quite a while back, code-revision wise.

I tried to reproduce your effect with the current revision, r6041.  I do 
see a small difference that depends on Rx freq: maybe one or two 
additional decoding seconds, with a total of around 15 decodes.

I can't tell you the exact reason for this dependence, without 
additional work.  I don't see it as especially important -- but would 
like to understand why it's apparently "working harder" when Rx Freq is 
high.  I'll look into it further, when time permits.

-- 73, Joe, K1JT

On 11/2/2015 6:10 PM, Bill Barrett wrote:
> Hi Joe-
>
> My observation is that the total time to decode the received signals is
> influenced by the setting of the RX frequency.
> IE if setting the RX @ 300 Hz all decoding [65&  9] proceeds rapidly.
> if setting the RX to 2K or above the JT9 prints are delayed significantly.
> My computer is a 4Ghz CPU with 8 Ex units.
> Hope this helps.
>
> Bill W2PKY
>
> On Mon, Nov 2, 2015 at 4:27 PM, Joe Taylor  wrote:
>
>> Hi Bill,
>>
>> I'm not sure that I understand your point.  In JT9+JT65 mode, JT9
>> decoding is attempted only at frequencies above the "blue line" marker,
>> set by the "JT65  JT9" spinner control.  Decoding is always started
>> first at the selected Rx frequency and mode, so the decode you care most
>> about -- presumably the station you're trying to work -- comes out first
>> among all those in its mode.  If you have a slow computer (or for some
>> other reason) some decodes come out after the top of the minute, it's
>> not a big concern.
>>
>> Have I mis-understood what was bothering you?
>>
>>  -- 73, Joe, K1JT
>>
>> On 11/2/2015 4:08 PM, Bill Barrett wrote:
>>> Hello JT Developers-
>>>
>>> Running 1.6.1 5910, noticed when mode is set to JT65 + 9
>>> and the RX frequency is greater than 1500 the JT9 decoding takes a long
>>> time.
>>> If the RX is above 2000 and there are a few JT9 prints the last one could
>>> come at second 59.
>>>
>>> Regularly decode signals -26 -27 -28.
>>>
>>> 73, Bill W2PKY
>>>
>>>
>>> On Mon, Nov 2, 2015 at 3:28 PM, Joe Taylor   wrote:
>>>
 Hi all,

 Here's an amusing screen shot.

 WSJT-X was running with 2-pass decoding enabled for JT65.  Note the two
 decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx
>> message
 from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in mid-transmission.  The
 decoder gets the "73" message in its first pass, and the "-21" message
>> in
 the second pass.

   -- Joe, K1JT



>> --

 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel


>>>
>>>
>>>
>>>
>> --
>>>
>>>
>>>
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> --
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
>
> --
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Greg Beam]

I would think, and I may be way off base here, the RCVR band-pass would 
have an affect on this also.

My 1000MP has INRAD filters with Very Sharpe skirts. When operating both 
JT65+9, I've seen decode times slow down a tad. I just assumed ( maybe 
incorrectly ) WSJT-X was looking at what I had set with the controls, 
having no way of knowing what mechanical IF filter settings I had engaged.

I don't know of a way to quantify the speeds in real time, so, this may 
be just confusing the issue :-(

For the most part, all of the new multi-pass enhancements have worked 
fine business for me; On the 1000MP and 2000D, apart from a time problem 
I had that later was found to be Windows insider pre-view update 
trashing my time settings.

73's
Greg, KI7MT



On 11/2/2015 16:10, Bill Barrett wrote:
> Hi Joe-
>
> My observation is that the total time to decode the received signals is
> influenced by the setting of the RX frequency.
> IE if setting the RX @ 300 Hz all decoding [65 & 9] proceeds rapidly.
> if setting the RX to 2K or above the JT9 prints are delayed significantly.
> My computer is a 4Ghz CPU with 8 Ex units.
> Hope this helps.
>
> Bill W2PKY
>
> On Mon, Nov 2, 2015 at 4:27 PM, Joe Taylor  > wrote:
>
> Hi Bill,
>
> I'm not sure that I understand your point.  In JT9+JT65 mode, JT9
> decoding is attempted only at frequencies above the "blue line" marker,
> set by the "JT65  JT9" spinner control.  Decoding is always started
> first at the selected Rx frequency and mode, so the decode you care most
> about -- presumably the station you're trying to work -- comes out first
> among all those in its mode.  If you have a slow computer (or for some
> other reason) some decodes come out after the top of the minute, it's
> not a big concern.
>
> Have I mis-understood what was bothering you?
>
>  -- 73, Joe, K1JT
>
> On 11/2/2015 4:08 PM, Bill Barrett wrote:
>  > Hello JT Developers-
>  >
>  > Running 1.6.1 5910, noticed when mode is set to JT65 + 9
>  > and the RX frequency is greater than 1500 the JT9 decoding takes
> a long
>  > time.
>  > If the RX is above 2000 and there are a few JT9 prints the last
> one could
>  > come at second 59.
>  >
>  > Regularly decode signals -26 -27 -28.
>  >
>  > 73, Bill W2PKY
>  >
>  >
>  > On Mon, Nov 2, 2015 at 3:28 PM, Joe Taylor >  wrote:
>  >
>  >> Hi all,
>  >>
>  >> Here's an amusing screen shot.
>  >>
>  >> WSJT-X was running with 2-pass decoding enabled for JT65.  Note
> the two
>  >> decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his
> Tx message
>  >> from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in
> mid-transmission.  The
>  >> decoder gets the "73" message in its first pass, and the "-21"
> message in
>  >> the second pass.
>  >>
>  >>  -- Joe, K1JT
>  >>
>  >>
>  >>
> 
> --
>  >>
>  >> ___
>  >> wsjt-devel mailing list
>  >> wsjt-devel@lists.sourceforge.net
> 
>  >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>  >>
>  >>
>  >
>  >
>  >
>  >
> 
> --
>  >
>  >
>  >
>  > ___
>  > wsjt-devel mailing list
>  > wsjt-devel@lists.sourceforge.net
> 
>  > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
> 
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
>
> --
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Bill Barrett]

Hi Joe-

My observation is that the total time to decode the received signals is
influenced by the setting of the RX frequency.
IE if setting the RX @ 300 Hz all decoding [65 & 9] proceeds rapidly.
if setting the RX to 2K or above the JT9 prints are delayed significantly.
My computer is a 4Ghz CPU with 8 Ex units.
Hope this helps.

Bill W2PKY

On Mon, Nov 2, 2015 at 4:27 PM, Joe Taylor  wrote:

> Hi Bill,
>
> I'm not sure that I understand your point.  In JT9+JT65 mode, JT9
> decoding is attempted only at frequencies above the "blue line" marker,
> set by the "JT65  JT9" spinner control.  Decoding is always started
> first at the selected Rx frequency and mode, so the decode you care most
> about -- presumably the station you're trying to work -- comes out first
> among all those in its mode.  If you have a slow computer (or for some
> other reason) some decodes come out after the top of the minute, it's
> not a big concern.
>
> Have I mis-understood what was bothering you?
>
> -- 73, Joe, K1JT
>
> On 11/2/2015 4:08 PM, Bill Barrett wrote:
> > Hello JT Developers-
> >
> > Running 1.6.1 5910, noticed when mode is set to JT65 + 9
> > and the RX frequency is greater than 1500 the JT9 decoding takes a long
> > time.
> > If the RX is above 2000 and there are a few JT9 prints the last one could
> > come at second 59.
> >
> > Regularly decode signals -26 -27 -28.
> >
> > 73, Bill W2PKY
> >
> >
> > On Mon, Nov 2, 2015 at 3:28 PM, Joe Taylor  wrote:
> >
> >> Hi all,
> >>
> >> Here's an amusing screen shot.
> >>
> >> WSJT-X was running with 2-pass decoding enabled for JT65.  Note the two
> >> decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx
> message
> >> from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in mid-transmission.  The
> >> decoder gets the "73" message in its first pass, and the "-21" message
> in
> >> the second pass.
> >>
> >>  -- Joe, K1JT
> >>
> >>
> >>
> --
> >>
> >> ___
> >> wsjt-devel mailing list
> >> wsjt-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >>
> >>
> >
> >
> >
> >
> --
> >
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Chris Sullivan]

No doubt he did that because HA3LI sent him R-nn instead of just -nn when
WB9OTX answered his CQ. I've not been able to figure out why some people do
that, but if I'm not paying full attention I get caught out the same way.

I'm really looking forward to using the new decoder!

73,
Chris VE3NRT

-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu] 
Sent: Monday, November 02, 2015 3:29 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] WSJT-X low SNR performance

Hi all,

Here's an amusing screen shot.

WSJT-X was running with 2-pass decoding enabled for JT65.  Note the two
decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx message
from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in mid-transmission.  The
decoder gets the "73" message in its first pass, and the "-21" message in
the second pass.

-- Joe, K1JT


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Joe Taylor]

Sorry, I sent this message in a garbled form.

Meant to delete the line "Suppose all data symbols in the wrong", just 
above the last paragraph.

-- Joe

On 11/2/2015 4:10 PM, Joe Taylor wrote:
> Hi Steve,
>
> On 11/2/2015 3:59 PM, Steven Franke wrote:
>> Wait. What? Very cool example, but I’m confused.
>>
>> When the user changes messages in mid-stream, my assumption
>> was that the program would jump to the beginning of the new
>> message symbol-stream, i.e. start at the beginning of a new
>> message. But then the second message would decode with a
>> big dt, which doesn’t show on your screenshot. So is the
>> program smart enough to just seamlessly start sending the
>> new symbols while retaining continuity on the sync sequence?
>
> Correct.  The sync sequence continues un-interrupted; only the data
> symbols are changed.
>
> Let's say the Tx message was changed half-way through, at about t=25s.
> Data symbols up to that time -- say, 31 of them -- correspond to the
> first message.  The remaining 32 data symbols will be those of the
> second message.  All 63 sync symbols are as they should be for a normal
> (unmodified) message.
>
> Suppose all data symbols in the wrong
> The signal was pretty strong, so data symbols in the "right" half of the
> message are nearly all received without error.  Those in the "wrong"
> half nearly all produce a hard error.  Still, that's only about 30 hard
> errors -- so there's a good chance that sfrsd will decode both messages
> correctly.
>
>   -- Joe, K1JT
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Joe Taylor]

Hi Bill,

I'm not sure that I understand your point.  In JT9+JT65 mode, JT9 
decoding is attempted only at frequencies above the "blue line" marker, 
set by the "JT65  JT9" spinner control.  Decoding is always started 
first at the selected Rx frequency and mode, so the decode you care most 
about -- presumably the station you're trying to work -- comes out first 
among all those in its mode.  If you have a slow computer (or for some 
other reason) some decodes come out after the top of the minute, it's 
not a big concern.

Have I mis-understood what was bothering you?

-- 73, Joe, K1JT

On 11/2/2015 4:08 PM, Bill Barrett wrote:
> Hello JT Developers-
>
> Running 1.6.1 5910, noticed when mode is set to JT65 + 9
> and the RX frequency is greater than 1500 the JT9 decoding takes a long
> time.
> If the RX is above 2000 and there are a few JT9 prints the last one could
> come at second 59.
>
> Regularly decode signals -26 -27 -28.
>
> 73, Bill W2PKY
>
>
> On Mon, Nov 2, 2015 at 3:28 PM, Joe Taylor  wrote:
>
>> Hi all,
>>
>> Here's an amusing screen shot.
>>
>> WSJT-X was running with 2-pass decoding enabled for JT65.  Note the two
>> decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx message
>> from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in mid-transmission.  The
>> decoder gets the "73" message in its first pass, and the "-21" message in
>> the second pass.
>>
>>  -- Joe, K1JT
>>
>>
>> --
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>
>
>
> --
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Joe Taylor]

Hi Steve,

On 11/2/2015 3:59 PM, Steven Franke wrote:
> Wait. What? Very cool example, but I’m confused.
>
> When the user changes messages in mid-stream, my assumption
> was that the program would jump to the beginning of the new
> message symbol-stream, i.e. start at the beginning of a new
> message. But then the second message would decode with a
> big dt, which doesn’t show on your screenshot. So is the
> program smart enough to just seamlessly start sending the
> new symbols while retaining continuity on the sync sequence?

Correct.  The sync sequence continues un-interrupted; only the data 
symbols are changed.

Let's say the Tx message was changed half-way through, at about t=25s. 
Data symbols up to that time -- say, 31 of them -- correspond to the 
first message.  The remaining 32 data symbols will be those of the 
second message.  All 63 sync symbols are as they should be for a normal 
(unmodified) message.

Suppose all data symbols in the wrong
The signal was pretty strong, so data symbols in the "right" half of the 
message are nearly all received without error.  Those in the "wrong" 
half nearly all produce a hard error.  Still, that's only about 30 hard 
errors -- so there's a good chance that sfrsd will decode both messages 
correctly.

-- Joe, K1JT

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Bill Barrett]

Hello JT Developers-

Running 1.6.1 5910, noticed when mode is set to JT65 + 9
and the RX frequency is greater than 1500 the JT9 decoding takes a long
time.
If the RX is above 2000 and there are a few JT9 prints the last one could
come at second 59.

Regularly decode signals -26 -27 -28.

73, Bill W2PKY


On Mon, Nov 2, 2015 at 3:28 PM, Joe Taylor  wrote:

> Hi all,
>
> Here's an amusing screen shot.
>
> WSJT-X was running with 2-pass decoding enabled for JT65.  Note the two
> decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx message
> from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in mid-transmission.  The
> decoder gets the "73" message in its first pass, and the "-21" message in
> the second pass.
>
> -- Joe, K1JT
>
>
> --
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Steven Franke]

Wait. What? Very cool example, but I’m confused. 

When the user changes messages in mid-stream, my assumption was that the 
program would jump to the beginning of the new message symbol-stream, i.e. 
start at the beginning of a new message. But then the second message would 
decode with a big dt, which doesn’t show on your screenshot. So is the program 
smart enough to just seamlessly start sending the new symbols while retaining 
continuity on the sync sequence?

Steve k9an

> On Nov 2, 2015, at 2:28 PM, Joe Taylor  wrote:
> 
> Hi all,
> 
> Here's an amusing screen shot.
> 
> WSJT-X was running with 2-pass decoding enabled for JT65.  Note the two 
> decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx message 
> from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in mid-transmission.  The 
> decoder gets the "73" message in its first pass, and the "-21" message in the 
> second pass.
> 
>   -- Joe, K1JT
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Joe Taylor]

Hi all,

Here's an amusing screen shot.

WSJT-X was running with 2-pass decoding enabled for JT65.  Note the two 
decodes of WB9OTX at Freq = 1856 Hz.  Evidently he changed his Tx 
message from "HA3LI WBtOTX -21" to "HA3LI WBtOTX 73" in 
mid-transmission.  The decoder gets the "73" message in its first pass, 
and the "-21" message in the second pass.


-- Joe, K1JT
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Joe Taylor]

Hi Steve,

Thanks once more for your excellent work on the JT65 decoder!!

I have confirmed your results using the test program jt65[.exe].  I then 
went ahead and merged your changes into v1.6.1 of WSJT-X; it's now 
performing at least as well as the WSJT decoder for the S/N=-24 dB files 
produced by SimJT.  At the same time, its two-pass algorithm beats all 
previous JT65 decoders on any crowded HF band.

I haven't yet decided how best to organize the necessary on-screen 
controls to allow user-selection of decoding parameters optimized for HF 
or EME-style operation.  SVN revision 6038 uses one possible approach. 
On the Settings | Advanced tab you can select 2-pass decoding, or not; 
the setting defaults to ON.  If a band is not crowded so you don't need 
the second pass, you can turn it off and decoding will finish more quickly.

Using full-symbol coherent integration is definitely the right thing to 
do for JT65A.  I had experimented with half-symbol integration because 
on EME bands where the B and C sub-modes are used there's enough Doppler 
spread that you need either that approach or some post-FFT
smoothing of the spectra.

I haven't yet looked into why it might be that fitting for the "banana 
coefficient" a(3), and then ignoring the fitted value, seems to help.

I've got a busy week here -- a conference celebrating the 100th 
anniversary of Einstein's general relativity theory -- so I probably 
won't get back to this until next week.

-- Joe, K1JT

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Steven Franke]

Joe,

I just noticed that the snr that the modified jt65 reports for the -24db files 
is now about -21 db. I think that it's because the program derives its snr 
estimate from the pilot-tone and not from the symbols. We expect a 3db 
improvement in going from half-symbol to full-symbol coherent integration for 
the pilot-tone analysis. This should produce something like a 1/sqrt(2) 
reduction in the rms uncertainty of our f0 and dt estimates - and that’s about 
what I saw. Of course, the snr associated with the symbols has not changed… 

Steve k9an

> On Oct 31, 2015, at 5:40 PM, Steven Franke  wrote:
> 
> Joe  - 
> I should add that I manually change the configuration of the jt65 program 
> between the -24db test and the hf test as follows:
> 
> for -24dB data (eme-like) conditions:
>   in jt65a_exp.f90:
>  I used only one decoding pass and nsubtract=0
>   in jt65.f90:
>   ntrials=1
>   nfa=1250
>   nfb=1290
> 
> for hf data:
>   in jt65a_exp.f90
>  2 decoding passes and nsubtract=1 only on the first pass
>   in jt65.f90:
>  ntrials=1000
>  nfa=200
>  nfb=3000
> 
> If you try to run the -24dB data using the hf settings, it becomes 
> intolerably slow.
> Steve k9an
> 
> 
>> On Oct 31, 2015, at 3:47 PM, Steven Franke  wrote:
>> 
>> Joe - 
>> For reference, here is the bash script that I used to convert my JTSim files 
>> to 16-bits at 12kS/s. You’d have to change the directory name, of course.
>> Steve
>> 
>> #!/bin/bash
>> for i in $( cd ../JT65-24db; ls A*.WAV); do
>> echo $i;
>> sox --ignore-length ../JT65-24db/$i -r 12000 -b 16 ./$i;
>> done 
>> 
>> 
>> --
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> 
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Steven Franke]

Joe  - 
I should add that I manually change the configuration of the jt65 program 
between the -24db test and the hf test as follows:

for -24dB data (eme-like) conditions:
   in jt65a_exp.f90:
  I used only one decoding pass and nsubtract=0
   in jt65.f90:
   ntrials=1
   nfa=1250
   nfb=1290

for hf data:
   in jt65a_exp.f90
  2 decoding passes and nsubtract=1 only on the first pass
   in jt65.f90:
  ntrials=1000
  nfa=200
  nfb=3000

If you try to run the -24dB data using the hf settings, it becomes intolerably 
slow.
Steve k9an


> On Oct 31, 2015, at 3:47 PM, Steven Franke  wrote:
> 
> Joe - 
> For reference, here is the bash script that I used to convert my JTSim files 
> to 16-bits at 12kS/s. You’d have to change the directory name, of course.
> Steve
> 
> #!/bin/bash
> for i in $( cd ../JT65-24db; ls A*.WAV); do
> echo $i;
> sox --ignore-length ../JT65-24db/$i -r 12000 -b 16 ./$i;
> done 
> 
> 
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Chase Turner]

These developments are really due to the talent of Steve, K9AN, and not
Joe- don't lose sight of that. Steve has made incredible progress- let's
hope he finds some more tricks up his sleeve!

-Chase

On Sat, Oct 31, 2015 at 6:05 PM, Michael Black  wrote:

> Color me impressed and shiver-me-timbers.
> Only been running this a short while but it's decoding stuff I can't even
> see now buried in QRM!
>
> Great job guys!!
>
> 73
> Mike W9MDB.
>
>
> On Sat, Oct 31, 2015 at 3:43 PM, Steven Franke 
> wrote:
>
>> Hi Joe and all,
>>
>> I’ve just committed a batch of modified routines associated with my
>> attempts to improve the low-SNR performance of wsjt-x.
>>
>> I did a number of experiments aimed at identifying why wsjt-x was not
>> performing as well as wsjt on our low-snr test files. I used the jt65 test
>> program and the usual set of 1000 .wav files, each of which contains a
>> single simulated signal with -24dB snr. The original batch of test files
>> was generated using JTSim, and contain 8-bit data at 11.025kS/s. I used the
>> *nix program “sox” to convert the files to 16-bits at 12kS/s.
>>
>> I started by doing some tests that convinced me that the solution would
>> involve decreasing the estimation errors for both f0 and dt. In order to
>> get to the bottom of this with my sanity intact, I ended up making the
>> changes necessary to remove all empirical dt offsets and also all
>> zero-padding at the beginning of data arrays. Negative dt’s are handled by
>> testing indices to ensure that they remain within the bounds of the
>> relevant arrays.
>>
>> At present, the convention is that dt is referenced to the beginning of
>> the wav file. So a transmission that starts at 1.0 second into the file
>> will have a time stamp of 1.0. It will be a simple matter to subtract 1
>> from the displayed value to make the numbers equivalent to what the current
>> wsjt-x prints out.
>>
>> I gave up tracking the effect of each and every change - but I believe
>> that the most significant ones are:
>> (i) Using full-symbol coherent integration when calculating ccf between
>> data and sync sequence instead of the prior scheme which did half-symbol
>> integration and then summed the powers from the two half-symbols
>> (ii) Added a “peakup” step to the final dt calculated using
>> 1/16-of-a-symbol steps. This gets us to sub-1/16-symbol accuracy which
>> makes a noticeable improvement at low SNR’s.
>> (iii) For reasons that I don’t understand - on my data, it seems to be
>> slightly better to fit for a(1),a(2),a(3), but then ignore a(3) when
>> tweaking the frequency.
>>
>> Since I had to make a significant number of changes, I’ve confined them
>> to renamed routines that have the _exp appended to the normal filename.
>> These modified routines are invoked in the Makefile.jt65, but they are not
>> yet used in 1.6.1. I’d like to know that you can reproduce my improved
>> results and that you are comfortable with the changes before we consider
>> moving them into wsjt-x.
>>
>> Here’s a summary of the improvement on my data:
>>
>> -24 dB files, ntrials=1
>>   before changes: 639/1000 (this is what the current 1.6.1 gives)
>>   after changes: 827/1000
>>
>> 333 hf .wav files recorded on 20m, 2 passes, ntrials=1000
>>   before: 4044
>>   after: 4150
>>
>> Steve k9an
>>
>>
>>
>>
>> --
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>
>
>
> --
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>


-- 
Chase Turner
W4TI
http://w4ti.com
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Michael Black]

Color me impressed and shiver-me-timbers.
Only been running this a short while but it's decoding stuff I can't even
see now buried in QRM!

Great job guys!!

73
Mike W9MDB.


On Sat, Oct 31, 2015 at 3:43 PM, Steven Franke 
wrote:

> Hi Joe and all,
>
> I’ve just committed a batch of modified routines associated with my
> attempts to improve the low-SNR performance of wsjt-x.
>
> I did a number of experiments aimed at identifying why wsjt-x was not
> performing as well as wsjt on our low-snr test files. I used the jt65 test
> program and the usual set of 1000 .wav files, each of which contains a
> single simulated signal with -24dB snr. The original batch of test files
> was generated using JTSim, and contain 8-bit data at 11.025kS/s. I used the
> *nix program “sox” to convert the files to 16-bits at 12kS/s.
>
> I started by doing some tests that convinced me that the solution would
> involve decreasing the estimation errors for both f0 and dt. In order to
> get to the bottom of this with my sanity intact, I ended up making the
> changes necessary to remove all empirical dt offsets and also all
> zero-padding at the beginning of data arrays. Negative dt’s are handled by
> testing indices to ensure that they remain within the bounds of the
> relevant arrays.
>
> At present, the convention is that dt is referenced to the beginning of
> the wav file. So a transmission that starts at 1.0 second into the file
> will have a time stamp of 1.0. It will be a simple matter to subtract 1
> from the displayed value to make the numbers equivalent to what the current
> wsjt-x prints out.
>
> I gave up tracking the effect of each and every change - but I believe
> that the most significant ones are:
> (i) Using full-symbol coherent integration when calculating ccf between
> data and sync sequence instead of the prior scheme which did half-symbol
> integration and then summed the powers from the two half-symbols
> (ii) Added a “peakup” step to the final dt calculated using
> 1/16-of-a-symbol steps. This gets us to sub-1/16-symbol accuracy which
> makes a noticeable improvement at low SNR’s.
> (iii) For reasons that I don’t understand - on my data, it seems to be
> slightly better to fit for a(1),a(2),a(3), but then ignore a(3) when
> tweaking the frequency.
>
> Since I had to make a significant number of changes, I’ve confined them to
> renamed routines that have the _exp appended to the normal filename. These
> modified routines are invoked in the Makefile.jt65, but they are not yet
> used in 1.6.1. I’d like to know that you can reproduce my improved results
> and that you are comfortable with the changes before we consider moving
> them into wsjt-x.
>
> Here’s a summary of the improvement on my data:
>
> -24 dB files, ntrials=1
>   before changes: 639/1000 (this is what the current 1.6.1 gives)
>   after changes: 827/1000
>
> 333 hf .wav files recorded on 20m, 2 passes, ntrials=1000
>   before: 4044
>   after: 4150
>
> Steve k9an
>
>
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X low SNR performance

[Steven Franke]

Joe - 
For reference, here is the bash script that I used to convert my JTSim files to 
16-bits at 12kS/s. You’d have to change the directory name, of course.
Steve

#!/bin/bash
for i in $( cd ../JT65-24db; ls A*.WAV); do
 echo $i;
 sox --ignore-length ../JT65-24db/$i -r 12000 -b 16 ./$i;
done 


--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel