Error Correction Coding

Started by SP5WWP, December 02, 2019, 12:01:34 PM

Previous topic - Next topic

SP5WWP

I'm using a simple Hamming (7,4) now and apply it to every singly nibble. It obviously needs improvements. There is no bit re-ordering applied.
faydrus recommended using libcorrect (Reed-Solomon or convolutional coding). I can't run any of the example tests :(

KE0WVA

I would suggest either some sort of trellis code on the FSK signal, or a rate 1/2 LDPC over the entire frame.

SP5WWP

Quote from: KE0WVA on December 03, 2019, 12:18:54 PM
rate 1/2 LDPC over the entire frame

Can you write a piece of code doing that?

faydrus

Maybe start out with a Golay code? The coding gain is modest (~1-2dB), but it's fairly simple and doesn't require the generation of any special data structures (like LDPC does).

I've attached the Golay source code, originally from Wireshark, that I ported over to QMesh. Note that I haven't tested it yet with QMesh.

faydrus

SP5WWP,

Doesn't LDPC require generating an appropriate parity matrix for every configuration (coding rate, block size) you want to use? Do you have a good way to do that?


SP5WWP

Quote from: faydrus on December 03, 2019, 03:25:39 PM
LDPC require generating an appropriate parity matrix for every configuration

That's true. I think that using Golay code along with block interleaver might be enough. 128 payload + 4 padding bits is divisible by 12.

KE0WVA

December 04, 2019, 01:13:13 AM #6 Last Edit: December 04, 2019, 01:20:02 AM by KE0WVA
Quote from: SP5WWP on December 03, 2019, 12:36:05 PM
Can you write a piece of code doing that?

Codec2's github has some code for that here: https://github.com/drowe67/codec2/blob/master/src/ldpc_enc.c

Quote from: faydrus on December 03, 2019, 03:25:39 PM
SP5WWP,

Doesn't LDPC require generating an appropriate parity matrix for every configuration (coding rate, block size) you want to use? Do you have a good way to do that?

It's probably a good idea to hammer out the frame format before doing anything else, then.

Trellis coding occurs at the data link layer and doesn't rely on block sizes, so it might be a better option if we're dealing with variable block sizes.

SmittyHalibut

I’m thinking about the framing and the protocol. How important is it from an ECC stand point that every frame be a fixed size? (I know Protocol’s and networking, but not the math behind FEC.)
73 de KR6ZY
-Mark

SmittyHalibut

I just posted a proposal in the other thread for a 512 bit frame, only 288 bits of which are interesting:

SYNC: 32 bits  (Constant string, not worth error correcting)
Link Control: 32 bits (32 bits of a larger message sent over multiple frames.)
Voice Payloads: 4x 64 bit CODEC2 3200 frames, 256 bits total
CRC: 32 bits
FEC: 160 bits

Two questions:
1) Do we really need both CRC and FEC?  Can those instead be combined into a single 192 bit FEC field?

2) Can we do useful FEC on 288 bits of interesting payload with either 160 or 192 bits of FEC?
73 de KR6ZY
-Mark

SP5WWP

@SmittyHalibut:

1) I have answered that in the other thread.
2) 288? 32+4*64+32=320. 320/(320+160)=2/3 rate.

SP5WWP

January 02, 2020, 08:06:10 PM #10 Last Edit: January 02, 2020, 08:08:09 PM by SP5WWP

N6NZ

Quote from: KE0WVA on December 03, 2019, 12:18:54 PMI would suggest either some sort of trellis code on the FSK signal, or a rate 1/2 LDPC over the entire frame.

A trellis code would give continuous correction over a bit stream.  I am not sure that an LDPC code is going to be a good choice for digital voice -- LDPC codes work best on large blocks (like thousands of bits), which would introduce a lot of latency. And of course a decode failure would then create a large drop-out.  LDPC might be good for a data channel that also incorporates some kind of ARQ, though. 

Another poster mentioned Golay codes -- I need to refresh myself on what those are -- memory fade :/

SP5WWP

I have encoded the Link Information Channel (LICH) with 24,12 Golay (since its partitioned into 48-bit chunks). The rest is going to be convolutionally coded with constraint K=5 and punctured (exactly like in NXDN, but with a different puncturing matrix).

Check this thread for details (post #1):
https://m17project.org/forum/index.php?topic=6.msg6#msg6