Hi Steve,
As it turns out, the most likely number of incorrect bits in the 87-bit
> message+CRC block contained within incorrect codewords is 20.
After reading Don message I was just figuring out this number for the LDPC
code used by FT8 :-)
What Don probably misinterpreted is that Koopman's table assume that
messages are uncoded, which is indeed true for most embedded networking
applications but is not the case when a message undergoes some further,
block oriented forward error correction coding process, as in example it
happens for ALL of the protocols used by WSJT-X (or by NASA deep-space
applications).
@Don: if you protect some information with a CRC and then you *code* the
result using an ECC (error correction code) what you get after decoding the
ECC is something which may have a very large hamming distance from the
original information+crc packet. In these cases the HD of the CRC
polynomial is usually much less than the average error pattern weight and,
on average, the chance that the error pattern passes the CRC test, that's
to say the probability that an error goes undetected, is just inversely
propoprtional to 2^L where L is the CRC polynomial degree. That's why when
a system uses an ECC what really matters to counterfeat undetected errors
is the CRC polynomial degree, not the polynomial coefficents unless their
are choosen in a very bad way of course.
73
Nico / IV3NWV
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Mail
priva di virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_2711666899474482065_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2018-01-25 23:13 GMT+01:00 Steven Franke <s.j.fra...@icloud.com>:
> 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
