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. _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
