Nice Reed-Solomon library! Very good use of generic programming in the way you have templated things. And your EZCOD is a clever way of using forward error correction.
I noticed a problem with your RS_CCSDS template. It is correct for the CCSDS (255, 223) code as written, but wrong for the CCSDS (255, 239) code. CCSDS specifies two R-S codes, in their terms, an E=16 and E=8 code. CCSDS shifts the first consecutive root between their codes to keep the polynomial coefficients symmetric to simplify hardware implementation. You can see this in the CCSDS 131-0-B-3 spec, page 4-2 in the code generator polynomial product terms of g(x) in 4.3.4.
https://public.ccsds.org/Pubs/131x0b3e1.pdf
I also added a comment about how this library is a conventional R-S encoder, but CCSDS specifies a Berlekamp R-S encoder (once again to simplify hardware implementation).
I will submit a pull request to merge these changes.
Nice Reed-Solomon library! Very good use of generic programming in the way you have templated things. And your EZCOD is a clever way of using forward error correction.
I noticed a problem with your RS_CCSDS template. It is correct for the CCSDS (255, 223) code as written, but wrong for the CCSDS (255, 239) code. CCSDS specifies two R-S codes, in their terms, an E=16 and E=8 code. CCSDS shifts the first consecutive root between their codes to keep the polynomial coefficients symmetric to simplify hardware implementation. You can see this in the CCSDS 131-0-B-3 spec, page 4-2 in the code generator polynomial product terms of g(x) in 4.3.4.
https://public.ccsds.org/Pubs/131x0b3e1.pdf
I also added a comment about how this library is a conventional R-S encoder, but CCSDS specifies a Berlekamp R-S encoder (once again to simplify hardware implementation).
I will submit a pull request to merge these changes.