M17 Project Forum
Remove CRC from Audio Payload Frame - Printable Version

+- M17 Project Forum (https://forum.m17project.org)
+-- Forum: M17 (https://forum.m17project.org/forumdisplay.php?fid=3)
+--- Forum: Technical (https://forum.m17project.org/forumdisplay.php?fid=4)
+--- Thread: Remove CRC from Audio Payload Frame (/showthread.php?tid=182)

Remove CRC from Audio Payload Frame - WX9O - 03-27-2021

Hi guys,

I suggested a while ago removing the CRC  from the audio frame in order to reclaim more bits for error correction, changing the puncture table.

I'd like to revisit that.  Today, the CRC provides little value.  I only use it to check whether the end of stream (EOS) bit is valid.  Otherwise it is ignored.  The audio data is passed as is to the Codec2 decoder whether the CRC is valid or not.

Using a 16-bit CRC to protect one bit is not a good use of bits.  Our decoders have to be able to handle an end of stream condition when the EOS bit is incorrect in any event.  The lack of a valid sync word on the next frame has the same effect.

Encryption is the only place where a frame number is meaningful.  When using encryption the decoder can track the frame numbers and can detect a valid frame sequence.

If we drop the CRC, we will be encoding 18 bytes, 144 bits + 4 flush bits into 148 * 2 = 296 bits. This needs to be punctured to 272 with a simple 11/12 puncture matrix. The current puncture matrix is ~ 5/6.

Kind Regards,

Rob Riggs WX9O
Mobilinkd LLC

RE: Remove CRC from Audio Payload Frame - SP5WWP - 03-29-2021

Obviously, there's a tradeoff between having a CRC and having extra error correction capability. I think it might be a good idea to get rid of the frame CRC.

How did you puncture 296 bits into 272 with an 11/12 matrix?