1. #FST4
  2. #fst4 LDPC Coding order

locked #fst4 LDPC Coding order #FST4

Andy Talbot
 

During the study of FST4 coding and getting its generation onto a PIC device,   
it took a while to spot a little aspect of the signal that was blindingly obvious, and is almost certainly stated somewhere and is no-doubt quite intentional ...

The important bits are transmitted first; the 77 message bits followed by the CRC, then the parity bits.   So in a strong signal error-free situation, if the first 42% of the transmission is received without errors, and the CRC matches, no further work with the parity bits is needed.

Unlike other modes that have the message interleaved throughout and need a spread of bits from the entire duration to decode properly.

70% of the PIC coding is done.  So far I can turn 77 source bits into a CRC and 139 parity bits.  The next stage is grouping these into symbols and inserting sync and it's done.  The PIC device I'm using is a 16F1827.  This has enough program memory (4K) to comfortably hold the 1.2K needed for the parity matrix and leave plenty for coding and generation - and more than enough RAM.
The parity encoding stage wasted a couple of hours as I'd initially coded it as XOR + XOR  without thinking, rather than AND + XOR
Julian
 

Are FST4W and wspr the same as FST4 wrt the position of error coding?

What is the position with all the other modes in wsjt -  which modes have an interleved ECC and which are separate?

Julian, G3YGF


On 16/04/2021 08:30, Andy TALBOT wrote:

During the study of FST4 coding and getting its generation onto a PIC device,   
it took a while to spot a little aspect of the signal that was blindingly obvious, and is almost certainly stated somewhere and is no-doubt quite intentional ...

The important bits are transmitted first; the 77 message bits followed by the CRC, then the parity bits.   So in a strong signal error-free situation, if the first 42% of the transmission is received without errors, and the CRC matches, no further work with the parity bits is needed.

Unlike other modes that have the message interleaved throughout and need a spread of bits from the entire duration to decode properly.

70% of the PIC coding is done.  So far I can turn 77 source bits into a CRC and 139 parity bits.  The next stage is grouping these into symbols and inserting sync and it's done.  The PIC device I'm using is a 16F1827.  This has enough program memory (4K) to comfortably hold the 1.2K needed for the parity matrix and leave plenty for coding and generation - and more than enough RAM.
The parity encoding stage wasted a couple of hours as I'd initially coded it as XOR + XOR  without thinking, rather than AND + XOR

William Smith
 

This is really cool, neat to see this on a PIC!

73, Willie N1JBJ

On Apr 16, 2021, at 3:30 AM, Andy TALBOT <andy.g4jnt@...> wrote:

During the study of FST4 coding and getting its generation onto a PIC device,   
it took a while to spot a little aspect of the signal that was blindingly obvious, and is almost certainly stated somewhere and is no-doubt quite intentional ...

The important bits are transmitted first; the 77 message bits followed by the CRC, then the parity bits.   So in a strong signal error-free situation, if the first 42% of the transmission is received without errors, and the CRC matches, no further work with the parity bits is needed.

Unlike other modes that have the message interleaved throughout and need a spread of bits from the entire duration to decode properly.

70% of the PIC coding is done.  So far I can turn 77 source bits into a CRC and 139 parity bits.  The next stage is grouping these into symbols and inserting sync and it's done.  The PIC device I'm using is a 16F1827.  This has enough program memory (4K) to comfortably hold the 1.2K needed for the parity matrix and leave plenty for coding and generation - and more than enough RAM.
The parity encoding stage wasted a couple of hours as I'd initially coded it as XOR + XOR  without thinking, rather than AND + XOR
1 - 3 of 3