Thanks, all, for the information. I had not run into a situation where the
"wrong code-word" distance was so high, but it absolutely makes sense, as
does the 1/2048 ratio. I appreciate y'all taking the time to educate me.
I'm old, but not too old to learn - yet!
73,
Don AE0AG
On Thu, Jan 25, 2018 at 3:13 PM, Steven Franke <s.j.fra...@icloud.com>
wrote:
> 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
>
------------------------------------------------------------------------------
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
