Re: [wsjt-devel] FT8 notes

[Steven Franke]

Hi Joe, Bill, and all,

I thought you’d be interested in seeing an encouraging result from our tests 
the other day. Hopefully, a screenshot will be attached to this, showing two 
receive cycles that I recorded while you both (Joe and Bill) were deliberately 
transmitting CQs on nearly the same frequency during one of our 20m tests.

Joe was transmitting on 1500 Hz offset, and Bill was at 1512 Hz. With a few 
minor tweaks (mainly, just lowering the sync threshold) the decoder is able to 
decode these overlapping signals without even using subtraction. Nice!

Steve, k9an

--
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

Re: [wsjt-devel] FT8 notes

[Neil Zampella]

FWIW ... there has been at least >> 4 << different code releases today 
alone.  I ran the JTSDK build at 3:00 EDT and built v7752.   At 8:50 EDT 
or so, I built v7756.  The updates are flying as fast as the development 
team can test and update. This is one of the reasons why the development 
team actively discourages making local builds available.If someone 
downloads a build r7752, then has an issue, they come here with it, and 
the team has to ask questions about what revision was being used because 
invariably that information is missing. Then they come to find out 
that the issue was fixed in r7756.  If they were building on their own, 
they would have had the new version already.


Frankly, downloading and installing JTSDK is a snap if you just follow 
the directions as listed on the download page.Respect the developers 
wishes.


Neil, KN3ILZ


On 6/30/2017 4:29 PM, Dani EA4GPZ wrote:

El 30/06/17 a las 19:06, Joe Taylor escribió:


Anyone is welcome to build WSJT-X from source code, and use the results
on the air.  But please DO NOT post your pre-built binaries for others
to download.  This causes needless support problems for us.  We have no
way of knowing exactly what you did.  And if all you post is some sort
of binary, you're violating our GPL license.

Hi Joe,

I don't want to get into an argument here, and I understand the reason
for frowning upon people posting pre-built binaries, but I just wanted
to clarify the statement about the GPL license.

I'm not a lawyer, so I might not be 100% correct on this, but, as far as
I know, you can redistribute binaries for GPL software without the
accompanying source code. However, you should be ready to provide the
source code _if_ you are asked to do so by whoever got your binary. No
need to send any source code if you're not asked to do so. Also, if the
code you have compiled is available online (say, from the WSJT SVN) and
you have not modified it (as it is the case with pre-built binaries of
the SVN trunk), it might be enough to point the user to the location of
the source online.

73,

Dani EA4GPZ.






--
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

Re: [wsjt-devel] FT8 notes

[Robert Nobis]

Hi Joe,

That is a great approach. For some other products the developers seem to want 
the average user to debug the software for them, and they release multiple 
versions of their product over a very short period of time. The net result is 
there are a lot of very unstable products floating  around.

WSJT-X is a great product and the latest “release version" is very stable.

Thank you.


Bob Nobis 
n7...@nobis.net


> On Jun 30, 2017, at 14:48, Joe Taylor  wrote:
> 
> Hi Dani,
> 
> Thanks for your comments.
> 
> As far as I am concerned, a more important reason than possible licensing 
> issues is the simple fact that when  we deem a development version ready (or 
> nearly ready) for general use, we post "official" installation packages.
> 
> Until that time, we're in something more like an "early testing" stage. Yes, 
> we can use some tests FROM PEOPLE WHO SEND US REPORTS.  But we're not yet 
> ready to support and encourage widespread use.  That will come, soon enough!
> 
>   -- Joe, K1JT
> 
> On 6/30/2017 4:29 PM, Dani EA4GPZ wrote:
>> El 30/06/17 a las 19:06, Joe Taylor escribió:
>>> Anyone is welcome to build WSJT-X from source code, and use the results
>>> on the air.  But please DO NOT post your pre-built binaries for others
>>> to download.  This causes needless support problems for us.  We have no
>>> way of knowing exactly what you did.  And if all you post is some sort
>>> of binary, you're violating our GPL license.
>> Hi Joe,
>> I don't want to get into an argument here, and I understand the reason
>> for frowning upon people posting pre-built binaries, but I just wanted
>> to clarify the statement about the GPL license.
>> I'm not a lawyer, so I might not be 100% correct on this, but, as far as
>> I know, you can redistribute binaries for GPL software without the
>> accompanying source code. However, you should be ready to provide the
>> source code _if_ you are asked to do so by whoever got your binary. No
>> need to send any source code if you're not asked to do so. Also, if the
>> code you have compiled is available online (say, from the WSJT SVN) and
>> you have not modified it (as it is the case with pre-built binaries of
>> the SVN trunk), it might be enough to point the user to the location of
>> the source online.
>> 73,
>> Dani EA4GPZ.
>> --
>> 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
> 
> --
> 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
> 

--
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

Re: [wsjt-devel] FT8 notes

[Joe Taylor]

Hi Dani,

Thanks for your comments.

As far as I am concerned, a more important reason than possible 
licensing issues is the simple fact that when  we deem a development 
version ready (or nearly ready) for general use, we post "official" 
installation packages.


Until that time, we're in something more like an "early testing" stage. 
Yes, we can use some tests FROM PEOPLE WHO SEND US REPORTS.  But we're 
not yet ready to support and encourage widespread use.  That will come, 
soon enough!


-- Joe, K1JT

On 6/30/2017 4:29 PM, Dani EA4GPZ wrote:

El 30/06/17 a las 19:06, Joe Taylor escribió:


Anyone is welcome to build WSJT-X from source code, and use the results
on the air.  But please DO NOT post your pre-built binaries for others
to download.  This causes needless support problems for us.  We have no
way of knowing exactly what you did.  And if all you post is some sort
of binary, you're violating our GPL license.


Hi Joe,

I don't want to get into an argument here, and I understand the reason
for frowning upon people posting pre-built binaries, but I just wanted
to clarify the statement about the GPL license.

I'm not a lawyer, so I might not be 100% correct on this, but, as far as
I know, you can redistribute binaries for GPL software without the
accompanying source code. However, you should be ready to provide the
source code _if_ you are asked to do so by whoever got your binary. No
need to send any source code if you're not asked to do so. Also, if the
code you have compiled is available online (say, from the WSJT SVN) and
you have not modified it (as it is the case with pre-built binaries of
the SVN trunk), it might be enough to point the user to the location of
the source online.

73,

Dani EA4GPZ.


--
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



--
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

Re: [wsjt-devel] FT8 notes

[Dani EA4GPZ]

El 30/06/17 a las 19:06, Joe Taylor escribió:

> Anyone is welcome to build WSJT-X from source code, and use the results
> on the air.  But please DO NOT post your pre-built binaries for others
> to download.  This causes needless support problems for us.  We have no
> way of knowing exactly what you did.  And if all you post is some sort
> of binary, you're violating our GPL license.

Hi Joe,

I don't want to get into an argument here, and I understand the reason
for frowning upon people posting pre-built binaries, but I just wanted
to clarify the statement about the GPL license.

I'm not a lawyer, so I might not be 100% correct on this, but, as far as
I know, you can redistribute binaries for GPL software without the
accompanying source code. However, you should be ready to provide the
source code _if_ you are asked to do so by whoever got your binary. No
need to send any source code if you're not asked to do so. Also, if the
code you have compiled is available online (say, from the WSJT SVN) and
you have not modified it (as it is the case with pre-built binaries of
the SVN trunk), it might be enough to point the user to the location of
the source online.

73,

Dani EA4GPZ.


--
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

Re: [wsjt-devel] FT8 notes

[Joe Taylor]

David, Jay, and others --

We have been through this here before.

Anyone is welcome to build WSJT-X from source code, and use the results 
on the air.  But please DO NOT post your pre-built binaries for others 
to download.  This causes needless support problems for us.  We have no 
way of knowing exactly what you did.  And if all you post is some sort 
of binary, you're violating our GPL license.


Soon enough, when desirable new features have been added to the program, 
we build and post "release candidate" installation packages that 
everyone can use.  Such a time is not far off.


In the meantime, please "build your own", or be patient.

-- Joe, K1JT

On 6/30/2017 12:40 PM, Jay Hainline wrote:

Just some food for thought.

Some of these development builds could be compiled into a exe install
package once in a while and made available from the sourceforge site or
maybe a link from the WSJT home page or wsjtx.net for those who want to try
the new mode but are intimidated at installing JTSDK and building their own.
If you make it available from an "official" site, maybe it will discourage
3rd party users of doing it on their own.

73 Jay KA9CFD

-Original Message-
From: David Tiller [mailto:dtil...@captechconsulting.com]
Sent: June 30, 2017 14:57
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] FT8 notes

All,

Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and
uploaded it here:
https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc

If you're a macOS user, I'll try to keep recent builds in the same directory
(if that's ok w/ Joe, et al, re: unofficial builds).

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Jun 30, 2017, at 10:45 AM, Joe Taylor <j...@princeton.edu> wrote:


Hi Steve,

Yes, 40 iterations for bp.

With norder=2 hardwired for everything I still get 574 good decodes.  So

at least in jt9.exe, with no attempt to move nfqso around, using norder=3
produces no more decodes.


Here are the timer results with norder=2:

Name Time  Frac dTime dFracCalls
--
jt933.832  1.00 0.691  0.021
  read_wav   0.164  0.00 0.164  0.0027404
  decft832.977  0.97 0.055  0.00  527
   sync8 4.148  0.12 4.148  0.12  527
   ft8b 28.773  0.85 0.090  0.00 2821
bpd174   1.641  0.05 1.641  0.05 2821
osd174  27.043  0.8027.043  0.80 2210
--
33.832  1.00

-- Joe

On 6/30/2017 10:34 AM, 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 <j...@princeton.edu> 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 dFracCalls
--
jt939.828  1.00 0.734  0.021
  read_wav   0.121  0.00 0.121  0.0027404
  decft838.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.8333.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 dFracCalls
--
jt9 6.641  1.00 0.891  0.131
  read_wav   0.168  0.03 0.168  0.0327404
  decft8

Re: [wsjt-devel] FT8 notes

[Jay Hainline]

Just some food for thought. 

Some of these development builds could be compiled into a exe install
package once in a while and made available from the sourceforge site or
maybe a link from the WSJT home page or wsjtx.net for those who want to try
the new mode but are intimidated at installing JTSDK and building their own.
If you make it available from an "official" site, maybe it will discourage
3rd party users of doing it on their own.

73 Jay KA9CFD

-Original Message-
From: David Tiller [mailto:dtil...@captechconsulting.com] 
Sent: June 30, 2017 14:57
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: Re: [wsjt-devel] FT8 notes

All,

Since Joe mentioned revision 7754, I unofficially built it for OSX 10.9+ and
uploaded it here:
https://drive.google.com/open?id=0B4DphHV_ItCZbjZDdmt2NnR2cHc

If you're a macOS user, I'll try to keep recent builds in the same directory
(if that's ok w/ Joe, et al, re: unofficial builds).

--
David Tiller
Sr. Architect/Lead Consultant | CapTech
(804) 304-0638 | dtil...@captechconsulting.com



On Jun 30, 2017, at 10:45 AM, Joe Taylor <j...@princeton.edu> wrote:

> Hi Steve,
> 
> Yes, 40 iterations for bp.
> 
> With norder=2 hardwired for everything I still get 574 good decodes.  So
at least in jt9.exe, with no attempt to move nfqso around, using norder=3
produces no more decodes.
> 
> Here are the timer results with norder=2:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt933.832  1.00 0.691  0.021
>  read_wav   0.164  0.00 0.164  0.0027404
>  decft832.977  0.97 0.055  0.00  527
>   sync8 4.148  0.12 4.148  0.12  527
>   ft8b 28.773  0.85 0.090  0.00 2821
>bpd174   1.641  0.05 1.641  0.05 2821
>osd174  27.043  0.8027.043  0.80 2210
> --
>33.832  1.00
> 
>   -- Joe
> 
> On 6/30/2017 10:34 AM, 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 <j...@princeton.edu> 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 dFracCalls
>>> --
>>> jt939.828  1.00 0.734  0.021
>>>  read_wav   0.121  0.00 0.121  0.0027404
>>>  decft838.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.8333.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 dFracCalls
>>> --
>>> jt9 6.641  1.00 0.891  0.131
>>>  read_wav   0.168  0.03 0.168  0.0327404
>>>  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

Re: [wsjt-devel] FT8 notes

[Steven Franke]

Joe,

OK. 

osd can only be successful if it is given candidates. I’m noticing now that the 
current sync threshold is high enough where bp probably doesn’t fail all that 
often. In any case, more candidates fed to osd would only increase the fraction 
of time spent in that routine. It doesn’t seem likely that osd is going to be 
able to pull it’s weight. I’m fine if you want to just remove the call to osd 
all together, at least for now.

Steve


> On Jun 30, 2017, at 9:45 AM, Joe Taylor  wrote:
> 
> Hi Steve,
> 
> Yes, 40 iterations for bp.
> 
> With norder=2 hardwired for everything I still get 574 good decodes.  So at 
> least in jt9.exe, with no attempt to move nfqso around, using norder=3 
> produces no more decodes.
> 
> Here are the timer results with norder=2:
> 
> Name Time  Frac dTime dFracCalls
> --
> jt933.832  1.00 0.691  0.021
>  read_wav   0.164  0.00 0.164  0.0027404
>  decft832.977  0.97 0.055  0.00  527
>   sync8 4.148  0.12 4.148  0.12  527
>   ft8b 28.773  0.85 0.090  0.00 2821
>bpd174   1.641  0.05 1.641  0.05 2821
>osd174  27.043  0.8027.043  0.80 2210
> --
>33.832  1.00
> 
>   -- Joe
> 
> On 6/30/2017 10:34 AM, 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  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 dFracCalls
>>> --
>>> jt939.828  1.00 0.734  0.021
>>>  read_wav   0.121  0.00 0.121  0.0027404
>>>  decft838.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.8333.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 dFracCalls
>>> --
>>> jt9 6.641  1.00 0.891  0.131
>>>  read_wav   0.168  0.03 0.168  0.0327404
>>>  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
>>> 
>>> --
>>> 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
>>> 

Re: [wsjt-devel] FT8 notes

[Bill Somerville]

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  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 dFracCalls
--
jt939.828  1.00 0.734  0.021
  read_wav   0.121  0.00 0.121  0.0027404
  decft838.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.8333.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 dFracCalls
--
jt9 6.641  1.00 0.891  0.131
  read_wav   0.168  0.03 0.168  0.0327404
  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



--
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

Re: [wsjt-devel] FT8 notes

[Steven Franke]

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  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 dFracCalls
> --
> jt939.828  1.00 0.734  0.021
>  read_wav   0.121  0.00 0.121  0.0027404
>  decft838.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.8333.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 dFracCalls
> --
> jt9 6.641  1.00 0.891  0.131
>  read_wav   0.168  0.03 0.168  0.0327404
>  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
> 
> --
> 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


--
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

[wsjt-devel] FT8 notes

[Joe Taylor]

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 dFracCalls
--
 jt939.828  1.00 0.734  0.021
  read_wav   0.121  0.00 0.121  0.0027404
  decft838.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.8333.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 dFracCalls
--
 jt9 6.641  1.00 0.891  0.131
  read_wav   0.168  0.03 0.168  0.0327404
  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

--
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

Re: [wsjt-devel] FT8 Notes

[pjsg-wsjt]

One FT8 record in pskreporter (RA9HO heard by I3RGH). Hopefully the 
first of many!


Congratulations.

Philip

On 29/06/2017 21:58, Tim Carlson wrote:

I just made my first FT8 QSO with WB4KDI as well.  I agree - very cool.

-Tim - KD0GYG

On Jun 29, 2017, at 6:43 PM, C. Gary Rogers > wrote:


Just made first FT8 QSO with WB4KDI…Way cool!!!…73 Gary

On Jun 29, 2017, at 7:56 PM, Dave 'Doc' Corio > wrote:


Managed 5 or 6 QSOs with the new mode so far. Two things I notice:

1. Even when the cursor on the wide graph is directly on a FT8 
signal it does not decode to the received window unless the text 
includes my call sign. Not major, but took a bit to realize why I 
wasn't "decoding".


2. Your must be VERY fast to answer a call with the short 
decode-to-transmit time! The quick QSOs are amazing, but with only a 
second or so to decide to answer or not really captures your attention!


Thanks, Devs!
73 - Dave - KB3MOW



--
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

Re: [wsjt-devel] FT8 Notes

[Tim Carlson]

I just made my first FT8 QSO with WB4KDI as well.  I agree - very cool.

-Tim - KD0GYG

> On Jun 29, 2017, at 6:43 PM, C. Gary Rogers  wrote:
> 
> Just made first FT8 QSO with WB4KDI…Way cool!!!…73 Gary
> 
>> On Jun 29, 2017, at 7:56 PM, Dave 'Doc' Corio > > wrote:
>> 
>> Managed 5 or 6 QSOs with the new mode so far. Two things I notice:
>> 
>> 1. Even when the cursor on the wide graph is directly on a FT8 signal it 
>> does not decode to the received window unless the text includes my call 
>> sign. Not major, but took a bit to realize why I wasn't "decoding".
>> 
>> 2. Your must be VERY fast to answer a call with the short decode-to-transmit 
>> time! The quick QSOs are amazing, but with only a second or so to decide to 
>> answer or not really captures your attention!
>> 
>> Thanks, Devs!
>> 73 - Dave - KB3MOW
>>  -- 
>> 
>> 
>>  
>> 
>>   Virus-free. www.avast.com 
>> 
>>  
>> --
>> 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
> 
> --
> 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

--
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