Hi Pavel and all, I’ll echo what Joe said. The Fano and Jelinek algorithms each implement a search over the same tree (using the same branch metrics). They will visit almost the same nodes on the tree during their search, and they will converge to the same result in almost all cases. The stack algorithm needs fewer iterations (about 1/2) than the Fano algorithm to produce the same number of decodes. This is mainly because the Fano algorithm wastes time by backtracking when it follows a branch that doesn’t lead to the best solution, whereas the stack algorithm doesn’t backtrack.
Although the stack algorithm requires about half as many iterations to do the same work as Fano, it does about twice as much work per iteration. As a result — In our comparisons on intel processors, stack and Fano came out at about the same execution time when they were compared on the basis of equal decoding performance. I can imagine that it could work out differently on different hardware, as you are seeing on your small embedded system. In any case, the standard wsprd uses Fano with 10000 iterations - so, as Joe suggested, you might get very acceptable results if you use 5000 iterations with the -J option, i.e. using -JC 5000. - I note that you were using the -w option. Presumably, you have figured out that this increases decoding time because the decoder has to search over +- 150 Hz rather than the default +/- 110Hz. - One of the earlier mailing-list messages that you referenced earlier pointed to a discussion of some my observations that showed that Fano produced more false decodes than Jelinek. I should point out that we subsequently found a small bug in Fano that was causing this — the last tail zero was not being decoded. Once we fixed that bug, stack and Fano had equivalent false-decode behavior. - Thanks for the data on the effect of moving from double-precision to float in wsprd. It does seem that float should be sufficient. I will do a few tests to convince myself of that and if it looks good I’ll incorporate your changes into wsprd. - Regarding the write_c2 routine. This was used for debugging purposes with the -c option to write a c2 file after subtracting the signals that were decoded on the first pass. I have an octave program that reads the file and then plots the spectrum. Note that WSJT-X has its own routines for reading and writing .c2 files, so the inconsistency in write_c2 does not affect the ability of WSJT-X to read and write .c2 files. Anyway, I will take a look at that too as time permits. Thanks Pavel, Steve k9an > On Mar 30, 2016, at 3:07 PM, Joe Taylor <[email protected]> wrote: > > Hi Pavel, > > Thanks for the additional information. Your choices make good sense. > > Do keep in mind that the sequential decoders in wsprd and wsprd_exp have > an easy-to-use tuning parameter, "maxcycles". In wsprd_exp.c it's > defined on line 628: > > unsigned int maxcycles=10000; //Decoder timeout limit > > You can probably speed up your decodes by nearly a factor of 2 by > changing the number to 5000. The cost will likely be less than 0.5 dB > in sensitivity, perhaps ~1% in number of decodes. > > -- Joe, K1JT > > On 3/30/2016 3:26 PM, Pavel Demin wrote: >> Hi Joe, >> >> Thank you for confirming that switching to floats should be relatively safe. >> >> I started to use wsprd_exp after reading the following threads on this >> mailing list: >> https://sourceforge.net/p/wsjt/mailman/message/34326507/ >> https://sourceforge.net/p/wsjt/mailman/message/34334059/ >> >> Looks like wsprd_exp already worked very well more than six months ago >> and wsprd_exp -J produced more decodes than wsprd. >> >> Since I'm running wpsrd_exp on a small embedded system (Red Pitaya) and >> decoding eight WSPR bands simultaneously, other factors like simple >> installation and high performance are also important for me. >> >> Out of the box, wpsrd_exp is more than 20% faster than wpsrd on my >> system and I can easily install wpsrd_exp (but can't wpsrd) with just >> two commands: >> svn co svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx/lib/wsprd >> make -C wsprd CFLAGS='...' wsprd_exp >> >> All in all, the experimental status of the wsprd_exp code fits very well >> the experimental status of my multiband WSPR receiver and I'm having a >> lot of fun with both :-) >> >> Best regards, >> >> Pavel >> >> Joe Taylor wrote: >>> Hi Pavel and all, >>> >>> Thanks for your effort on optimizations in wsprd. The change from >>> doubles to floats has been on our "To Do" list for many weeks. We >>> didn't get around to it because the potential gains (though desirable) >>> were not likely to be huge. Floats have enough precision for use in all >>> the long arrays. >>> >>> Is there a reason why you worked with wsprd_exp rather than wsprd? Our >>> "production code" is wsprd; wsprd_exp is an experimental version that >>> uses the "Jelinek" rather than "Fano" algorithm for sequential decoding >>> of the convolutional code. >>> >>> -- Joe, K1JT >>> >> >> >> ------------------------------------------------------------------------------ >> Transform Data into Opportunity. >> Accelerate data analysis in your applications with >> Intel Data Analytics Acceleration Library. >> Click to learn more. >> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
