Builds removed. -- David Tiller Sr. Architect/Lead Consultant | CapTech (804) 304-0638 | [email protected]
On Jun 30, 2017, at 1:06 PM, Joe Taylor <[email protected]> wrote: > 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:[email protected]] >> Sent: June 30, 2017 14:57 >> To: WSJT software development <[email protected]> >> 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 | [email protected] >> On Jun 30, 2017, at 10:45 AM, Joe Taylor <[email protected]> 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 dFrac Calls >>> ---------------------------------------------------------- >>> jt9 33.832 1.00 0.691 0.02 1 >>> read_wav 0.164 0.00 0.164 0.00 27404 >>> decft8 32.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.80 27.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 <[email protected]> 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 dFrac Calls >>>>> ---------------------------------------------------------- >>>>> jt9 39.828 1.00 0.734 0.02 1 >>>>> read_wav 0.121 0.00 0.121 0.00 27404 >>>>> decft8 38.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.83 33.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 dFrac Calls >>>>> ---------------------------------------------------------- >>>>> jt9 6.641 1.00 0.891 0.13 1 >>>>> read_wav 0.168 0.03 0.168 0.03 27404 >>>>> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
