Re: [Discuss-gnuradio] r/s encoding and padding on gmsk

[Brian Padalino]

On 5/18/07, Brett L. Trotter <address@hidden> wrote:
> 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.

> From a strictly USRP point of view, the FX2 only knows how to do burst
transfers of 512-byte packets over USB and to/from the FPGA.  These
are the actual samples that are going to get interpolated and sent on
out the DACs, so this takes into consideration both bits/sample and
samples/symbol.

> 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)?

Since you picked such a nice number (256), you can probably get away
with just doing 8 or 16-bits per sample and 2 samples per symbol.  The
2 samples per symbol would get your 256 to 512, and by using at least
8-bits per sample you're up to 512-byte packets - anything more would
be self-aligning I'd assume.

Someone should probably qualify my statement, but as far as I know -
it seems like it should work.  Give it a shot.

Brian

PS - On a side note, I am not sure you have a choice in the number of
bits per sample as I believe they are fixed at 16 right now.  Someone
should also qualify that statement.