I’m involved with very lossy links and low signal strengths using gmsk
and dqpsk and would like to add a layer of reed-solomon encoding in
place of the current CRC check.
My plan was to use reed solomon in a standard (255,223) configuration
and use PKSC#7 padding in 223 byte blocks where the last N bytes up to
223 are filled with the value N and if the block is precisely full,
you’d have to waste a full block of 223 bytes with the value 223. In our
lossy circumstance, this kind of waste (even though fairly rare that
you’d have a packet precisely 223 characters) would be worthwhile for
the added redundancy of the r/s.
In any case, in reading the associated python code, I noticed that the
data sent over the USB seems to have to be in multiples of 128, but it
also seemed to imply that it had to be multiples of 512. The current
padding mechanism seems to take into account the bits/sample and
samples/symbol as well.
What I really need to know is whether my simple 256 byte system (223
before r/s, 256 after r/s) would suffice if I kept track of whether the
current block was at a 512 byte boundary and if not would have to add
another 256 byte packet of padding. In other words, do I need to take
into account the bits/sample and samples/symbol if our data length is
always a multiple of 256 (or 512)?
How might I take all that is required into account if not?
Thanks in advance!
P.S. the amount of wasted bandwidth isn’t really as important as quality
packets (correctable packets at least) in lower SNR environments.
