[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Brian Padalino
Subject: Re: [Discuss-gnuradio] r/s encoding and padding on gmsk
Date: Sat, 19 May 2007 13:48:33 -0400

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

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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]