Hi Don, To add to what Joe and Bill have already said, I’d like to point out that Koopman’s tables are not particularly relevant for our application. The FT8 decoder always produces a valid 174-bit codeword that satisfies all parity checks. In other words, the decoder always return a codeword from the codebook defined by our (174,87) LDPC code. The purpose of the CRC is to help us determine when the decoder has returned the wrong codeword. As it turns out, the most likely number of incorrect bits in the 87-bit message+CRC block contained within incorrect codewords is 20. This is "off the charts” as far as Koopman’s tables go. I have not found any reason to believe that selecting a polynomial that is optimum for a Hamming distance (HD) of 4, say, has any bearing on how it would perform with typical incorrect codewords having HD=20. This is why we have resorted to long simulations to evaluate the performance that is available from different CRC polynomials. In fact, our simulations showed very little difference in the performance of various 12-bit CRCs from Koopman’s table. They all reduce the number of incorrect decodes by about a factor of 2^12=2048.
73, Steve k9an > On Jan 25, 2018, at 2:21 PM, Joe Taylor <j...@princeton.edu> wrote: > > Hi Don, > > Thanks for your message and your interest in FT8, etc. > > We're well aware of the tables of "good CRC polynomials" published by > Koopman, though admittedly we have not always used them to best advantage. > > Steve Franke, K9AN, did an extensive series of tests with different CRC > generators when used with the 75-bit information block in FT8. The CRC12 > used in FT8 is slightly sub-optimal, but the resulting increase in undetected > error rate is only a factor of 1.6. Since the error rate is already very > low, the consequences are not serious. > > -- Joe, K1JT > > On 1/25/2018 2:23 PM, Don Goldston wrote: >> Sirs, >> I have not delved into your software, and being old and retired I may not do >> so. From the superficial descriptions of FT8 I have found, your group seems >> to know very well what they are doing. >> https://users.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf >> Here is a link to a paper on CRCs that you should consider for future design >> work. The paper gives the best CRC of a given length for a data block of a >> given length. You can potentially have equal or better corruption detection >> with a smaller CRC, Examine table 3 carefully. I believe you could use an 8 >> bit CRC (0x97) for data blocks of up to length 119 bits and achieve a >> hamming distance of 4, which is equal to or better than the performance >> achievable with the optimal 12 bit CRC at data block lengths above 53 bits >> in length. >> It may be too late to impact FT8, but the principles outlined in the paper >> can save you a few bits in future development. >> As a general caution, be aware that previous published "standard" and "good" >> CRCs, may not be the best even at long block lengths. >> If you were already aware of this paper, please forgive me for wasting your >> time. >> Is there a more detailed description of the various modes available to >> members of this list? I am a new ham, but did waveform design and optimal >> detection for many years until I retired last May. I may be able to help >> in some manner. >> 73, >> Don Goldston, AE0AG > > ------------------------------------------------------------------------------ > 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
