Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

Hi Bill and Mike, I’d like to correct the following: > The LDPC decoder will either produce a valid codeword, or nothing (an > erasure). The CRC is being used to detect these invalid codewords. to say, instead: The LDPC decoder will either produce a codeword from the list of codewords

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

Michael <mdblac...@yahoo.com>; WSJT software development <wsjt-devel@lists.sourceforge.net> Sent: Thursday, March 30, 2017 12:27 PM Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55 On 30/03/2017 18:13, Black Michael wrote: Doesn't look to me as though 0x1e7 is a go

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 18:13, Black Michael wrote: Doesn't look to me as though 0x1e7 is a good choice as it doesn't even cover HD=3 for 88 bits. 0x8f3 is much superior. Hi Mike, clearly I did not get my point across very well. There is a notation issue here. Koopman uses a self-admittedly quirky

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

, 2017 11:29 AM Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55 On 30/03/2017 17:05, Bill Somerville wrote: x12 + x8 + x7 + x6 + x5 + x2 + x + 1 I note that it doesn't have an even number of bits (yes that is confusing too) so apparently cannot detect all errors with

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 17:05, Bill Somerville wrote: /x^12 + x^8 //+ //x^7 //+ x^6 //+ x^5 //+ x^2 + x + 1 / I note that it doesn't have an even number of bits (yes that is confusing too) so apparently cannot detect all errors with an odd number of bits set according to this:

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 16:44, Bill Somerville wrote: that would be 0x0cf1 in the notation of Boost CRC as he uses a quirky "implicit +1" notation. Hi Mike & Steve, Oh dear, my message is even more ambiguous than these polynomial notations! Plus I inadvertently inverted it. Ouch! What I meant was

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

I guess our BER is approximated by how many transmitted messages fail CRC since it's real-life testing that really matters, right? To achieve 1/10 and it looks like we're doing CRC on 11*8=88 bits, right? So 10/88 = 1,136So, at most, only one out of every 1,136 messages would fail CRC to

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 16:36, Black Michael wrote: 0x80f gives slightly worse performance then either 0xc07 or 0x8f3 Hi Mike & Steve, that would be 0x0cf1 in the notation of Boost CRC as he uses a quirky "implicit +1" notation. 73 Bill G4WJS.

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

Hi Mike and Bill - The LDPC decoder will either produce a valid codeword, or nothing (an erasure). The CRC is being used to detect these invalid codewords. If the code is any good to begin with, an incorrect codeword will differ from the correct one in quite a few bits, i.e. we should see

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 15:45, Bill Somerville wrote: What I am not so sure of is if the Boost CRC library requires it to be specified as 0x080f or as 0x180f. Hi Steve & Mike, I can confirm that the highest order coefficient of the CRC polynomial never needs to be given so to use: /x^12 + x^11 +

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

I noticed Phillip has update his webiste since the 2004 publicationhttps://users.ece.cmu.edu/~koopman/crc/index.html Now recommends 0x8f3 as the best 12-bit poly. Testing 0xc06 gives this which shows 0xc06 cannot achieve HD=4 Poly=0xc06 startHD=3 maxHD=6# 0xc06  HD=3  len=79  Example: Len=80

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 16:02, Black Michael wrote: > Don't we expect a much higher BER? HI Mike, in this case the CRC is checked after FEC using LDPC so the error rates should be low. 73 Bill G4WJS. -- Check out the vibrant

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

Actually, reading his website it's even less clear what should be used He says these polynomials are only good for a low BER of 1/100,000. Don't we expect a much higher BER? de Mike W9MDB-- Check out the vibrant tech

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

AM Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55 Hi Mike and Bill -  OK - I clearly need to work out some CRC’s by hand and make sure that I understand what the routine is calculating.  In any case, I believe that what matters is the final undetected error rate that we achi

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 15:25, Black Michael wrote: Where'd you get 0x180d from?. Hi Mike, I took the polynomial that Steve used, 0x0c06, and applied his incorrect assumption that the lowest order coefficient was truncated and assumed to be 1: 0x0c06 x 2 + 1 = 0x180d = /x/^12 + /x/^11 + /x/^3 +

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

-devel@lists.sourceforge.net Sent: Thursday, March 30, 2017 9:09 AM Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55 On 30/03/2017 14:47, Black Michael wrote: Don't they mean the high order bit and not the low order one? Hi Mike & Steve, I believe Mike is correct. When using 8-bit, 16-b

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

Hi Mike and Bill - OK - I clearly need to work out some CRC’s by hand and make sure that I understand what the routine is calculating. In any case, I believe that what matters is the final undetected error rate that we achieve by using the CRC to detect incorrect codewords identified by the

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 15:06, Bill Somerville wrote: > That, I think, means that the polynomial should be specified as 0x180d > for the intended CRC. Having said that, 0x080f looks more promising. 73 Bill G4WJS. -- Check out

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 14:47, Black Michael wrote: Don't they mean the high order bit and not the low order one? Hi Mike & Steve, I believe Mike is correct. When using 8-bit, 16-bit, 32-bit, 64-bit etc sums the highest order bit will always require a register one bit wider but that bit is also

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

| de Mike W9MDB From: Steven Franke <s.j.fra...@icloud.com> To: Joe Taylor <wsjt-devel@lists.sourceforge.net> Sent: Thursday, March 30, 2017 8:35 AM Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55 > On Mar 30, 2017, at 8:15 AM, Bill Somerville &l

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

> On Mar 30, 2017, at 8:15 AM, Bill Somerville wrote: > > On 30/03/2017 13:59, Black Michael wrote: >> You may want to check your polynomial. I do believe 0xc06 should be 0xc07 >> -- you never want a zero x^0 term. Hi Mike, The polynomial argument provided to the

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 13:59, Black Michael wrote: You may want to check your polynomial. I do believe 0xc06 should be 0xc07 -- you never want a zero x^0 term. https://en.wikipedia.org/wiki/Polynomial_representations_of_cyclic_redundancy_checks What's the logic behind using a 12-bit CRC? Is there a

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

From: Bill Somerville <g4...@classdesign.com> To: wsjt-devel@lists.sourceforge.net Sent: Wednesday, March 29, 2017 6:42 PM Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55 On 30/03/2017 00:12, Bill Somerville wrote: > BTW the error message actually gives a better solu

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 30/03/2017 00:12, Bill Somerville wrote: > BTW the error message actually gives a better solution than any you > have offered which is to use -fpermissive for the file which allows > the code without the C++11 mandated error message for this undefined > behaviour producing construct. Even

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 29/03/2017 23:47, Black Michael wrote: Boost has been a PITA for yearscomplex+complicated code. There were versions that weren't very portable for many years and broke across compiler upgrades and such like we're seeing now. Our philosophy was to simply get it to work for our app and

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

any times over time. IMHO I would not include boost just to get a CRC function.   de Mike W9MDB  From: Bill Somerville <g4...@classdesign.com> To: wsjt-devel@lists.sourceforge.net Sent: Wednesday, March 29, 2017 4:42 PM Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 5

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

On 29/03/2017 22:18, Black Michael wrote: This fixes the compile problem. Had the same problem on Ubuntu 16.10 with gcc 6.2.0 The ~ returns an int, not an unsigned int. I think the older compilers just let this slide and presumably shifted the sign bit out. Hi Mike, yes, it is one of the

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

This fixes the compile problem.  Had the same problem on Ubuntu 16.10 with gcc 6.2.0 The ~ returns an int, not an unsigned int.  I think the older compilers just let this slide and presumably shifted the sign bit out. https://www.dropbox.com/s/epumxiqrsufji7k/crc.diff?dl=1 de Mike W9MDB

Re: [wsjt-devel] wsjt-devel Digest, Vol 37, Issue 55

GCC on Fedora Core 25 On Wed, Mar 29, 2017, 11:09 wrote: > Send wsjt-devel mailing list submissions to > wsjt-devel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit >