Hi Joe, Thanks. I'm downloading the data now and will do some test runs later this evening.
73's Greg, KI7MT On 07/30/2015 07:01 AM, Joe Taylor wrote: > Hi Greg, > > I have updated Makefile.win32 in ^/branches/wsjtx so that it builds > Steve's new wsprd_exp.exe correctly. > > I have made a tarfile with the set of WSPR *.wav files I used most > recently. It is now posted at > > http://physics.princeton.edu/pulsar/K1JT/wspr_data.tgz > > It's about 1 GB in size. > > -- Joe, K1JT > > On 7/29/2015 11:52 PM, KI7MT wrote: >> Hi Steve, Joe, >> >> I hit another show stopper error also. I'll look at what Joe is using in >> ^/branches/wsjtx_exp and see what the diff's are from the main devel >> branch. >> >> By chance, do you all have a standard set of WSPR .wav files that your >> using to compare with? Would be nice to be able to use a standard set >> for testing. >> >> 73's >> Greg, KI7MT >> >> >> >> On 07/29/2015 07:36 PM, Steven Franke wrote: >>> Greg - >>> The windows Makefile has not been updated for the stack decoder. I’ve only >>> tested it on linux and osx. It looks like the Makefile in Joe’s >>> experimental branch is close to what would be needed - though it shouldn’t >>> need the extended stacksize anymore since we moved the big arrays to heap >>> storage. >>> Steve k9an >>> >>>> On Jul 29, 2015, at 1:22 AM, Greg Beam<ki7m...@gmail.com> wrote: >>>> >>>> Hi Joe, Steve, >>>> >>>> This is off list. >>>> >>>> I tried to build wsprd_exp on Windows (using Qt 5.2.1 Tool-Chain, not the >>>> 5.5 Tool-Chain) and ran into an error. I'm using >>>> ^/branches/wsjtx/lib/wsprd folder, and Makefile.win32, is that the correct >>>> location and Makefile file? >>>> >>>> Here's the error I'm getting: >>>> ----- >>>> wsprd_exp.o:wsprd_exp.c:(.text.startup+0x244c): undefined reference to >>>> `jelinek' >>>> collect2.exe: error: ld returned 1 exit status >>>> Makefile.win32:34: recipe for target 'wsprd_exp' failed >>>> mingw32-make: *** [wsprd_exp] Error 1 >>>> ---- >>>> >>>> Any Ideas? >>>> >>>> 73's >>>> Greg, KI7MT >>>> >>>> >>>> >>>> On 7/28/2015 1:49 PM, Steven Franke wrote: >>>>> Hi Greg and Joe, >>>>> >>>>> As Joe said, the stack decoder is only in wsprd_exp and it requires a >>>>> command-line argument (-J) to activate it, as the default algorithm in >>>>> wsprd_exp is the Fano algorithm. >>>>> >>>>> The tests conducted by me and Joe show that my implementation of >>>>> Jelinek’s stack-bucket algorithm doesn’t seem to provide any significant >>>>> advantage over the Fano decoder in the wspr application. I am still >>>>> inclined to replace the current wsprd with the Fano version of wsprd_exp. >>>>> All of my tests indicate that the default configuration of wsprd_exp >>>>> produces more decodes in less time than wsprd does. This is due to >>>>> improvements in the sync algorithm and not due to anything related to the >>>>> sequential decoder. However --- when Joe compared wsprd to wsprd_exp >>>>> (Fano) he didn’t find any significant difference between the two. If you >>>>> decide to do some tests, Greg, it’d be interesting to see if you see any >>>>> difference between wsprd and wsprd_exp (with the default settings). >>>>> >>>>> Steve >>>>> >>>>>> On Jul 28, 2015, at 2:22 PM, Joe Taylor<j...@princeton.edu> wrote: >>>>>> >>>>>> Hi Greg, >>>>>> >>>>>> The experimental ("Jelinek") decoder is currently being built only as >>>>>> wsprd_exp. >>>>>> -- Joe >>>>>> >>>>>> On 7/28/2015 3:08 PM, Greg Beam wrote: >>>>>>> Hi Joe, Steve, >>>>>>> >>>>>>> Are these updates in the main wsprd binary, or do we still need to build >>>>>>> the wsprd_exp binary and copy it over to wsprd to test the changes? >>>>>>> >>>>>>> 73's >>>>>>> Greg, KI7MT >>>>>>> >>>>>>> On 7/28/2015 12:22 PM, Joe Taylor wrote: >>>>>>>> Hi Steve, >>>>>>>> >>>>>>>> Nice job with implementation of a sequential decoder using the Jelinek >>>>>>>> Stack Algorithm! >>>>>>>> >>>>>>>> I have now run some reasonably thorough tests of it, comparing results >>>>>>>> with the default Fano decoder in wsprd. I confirm essentially all of >>>>>>>> your basic conclusions. Jelinek with maxcycles=5000 produces nearly >>>>>>>> the >>>>>>>> same results, in the same execution time, as Fano with maxcycles=10000. >>>>>>>> >>>>>>>> In my tests the command-line "-d" option produced about 7-8% more >>>>>>>> decodes, at the cost of roughly 5 x longer execution time. Again, this >>>>>>>> was true for both Fano and Jelinek. >>>>>>>> >>>>>>>> Now we know... which is good! >>>>>>>> >>>>>>>> -- 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
