R/s encoding and padding on gmsk

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.

On 5/18/07, Brett L. Trotter [email protected] wrote:

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.

On Sat, May 19, 2007 at 01:48:33PM -0400, Brian P. wrote:

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
^
|
Should be bits/symbol----------------+

it seems like it should work. Give it a shot.

Brian

This should work. You just need to adjust your padding such that the
final output of your modulated packet is a multiple of 128 complex
samples (== 512 bytes across the USB). [This restriction is one of
the things that will be fixed in the inband signaling code…]

Eric

http://www.db.net/~db/gnuradio-freebsd.tgz

Is the gr-radio-astronomy patch a FreeBSD fix, or generic?

ppdev.c:

I don’t see why the include of sstream is conditional on the various pp
methods.

The diff seems to add code for Linux as well, but I wonder if that’s an
artifact of how diff chose to deal with before/after.

Other than that question and nits, at first glance this looks fine, but
you’re probably over that pesky copyright assignment threshold…

On Mon, May 21, 2007 at 03:01:57PM -0400, Diane Bruce wrote:

http://www.db.net/~db/gnuradio-freebsd.tgz

Thanks!

I’ll take a look at them later today or tomorrow.

Eric

On Wed, May 23, 2007 at 09:44:37AM -0400, Clark P. wrote:

Thanks,
Clark

First off, vmware is not a supported platform.
If it works for you, great. If not, please try to reproduce the
alleged problem on real hardware.

Also, even if vmware was supported, you haven’t provided us the first
clue about vmware version or host OS and version.

For those of you who are fans of virtualization, I’d be much more
interested in hearing about Xen than vmware :wink:

Thanks,
Eric

I have my USRP installed and running fine (Ubuntu 6.06 in vmware). I’ve
installed gnuradio companion and it appears to run, at least I can see
the
block diagrams from the examples. However, I don’t get any FFT displays
or
sound out of any of the examples. It just says running blah blah in the
status window.

Any ideas for troubleshooting? Should I be able to execute the .xml
files
manually to get more debug info?

Thanks,
Clark


Like the way Microsoft Office Outlook works? You’ll love Windows Live
Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_outlook_0507

Hi,

On Wed, May 23, 2007 at 09:06:17AM -0400, Greg T. wrote:

Is the gr-radio-astronomy patch a FreeBSD fix, or generic?

Somehow the original comments that were supposed to be attached
got dropped, they follow here.

Hi,

I have some diffs for gnuradio on FreeBSD. It runs fine.
I also have a gnuradio port for FreeBSD waiting to be committed, if
you know anyone that needs it, they can contact me.

diffs attached.

These three diffs add detection of parallel port code on FreeBSD
and add parallel bus support to ppdev.cc

patch-config.h.in
patch-configure.ac
patch-gnuradio-core_src_lib_io_ppio_ppdev.cc

I might have other diffs that might be useful for portability.

You probably have already fixed this one. I will have to check svn

patch-gr-radio-astronomy_src_python_usr_psr_receiver.py

  •    self.audiodev = options.audio_dev
    
  •    self.audiodev = options.audio_source
    

The astronomy patches are generic,
And, yes I see it has been already fixed in svn.
http://gnuradio.org/trac/browser/gnuradio/trunk/gr-radio-astronomy/src/python/usrp_psr_receiver.py
line 98.

So, that diff may be safely ignored.

ppdev.c:

I don’t see why the include of sstream is conditional on the various pp
methods.

You could move it as simply:

-#ifdef HAVE_LINUX_PPDEV_H
+#if defined(HAVE_LINUX_PPDEV_H)
#include <sys/ioctl.h>
#include <linux/ppdev.h>
#include <linux/parport.h>
-#include
+#elif defined(HAVE_DEV_PPBUS_PPI_H)
+#include <sys/ioctl.h>
+#include <dev/ppbus/ppi.h>
+#include <dev/ppbus/ppbconf.h>
#else
// #warn “ppio_ppdev is not functional on this platform”
#endif

+#include

However, then the original code did not include sstream when no pp
method was found. It’s up to you guys if you want to always include
sstream even when a pp method is not found.

The diff seems to add code for Linux as well, but I wonder if that’s an
artifact of how diff chose to deal with before/after.

That is an artefact.

Other than that question and nits, at first glance this looks fine, but

I would point out, that there are very little changes.

void
ppio_ppdev::write_control (unsigned char v)
{
unsigned char ctrl = v ^ CP_ACTIVE_LOW_BITS;
if (ioctl (d_fd, PPWCONTROL, &ctrl) != 0){
perror (“ppio_ppdev: PPWCONTROL”);
throw std::runtime_error (“PPWCONTROL”);
}
}

void
ppio_ppdev::write_control (unsigned char v)
{
unsigned char ctrl = v ^ CP_ACTIVE_LOW_BITS;
if (ioctl (d_fd, PPISCTRL, &ctrl) != 0){
perror (“ppio_ppdev: PPISCTRL”);
throw std::runtime_error (“PPISCTRL”);
}
}

One could do something like (not tested):

#elif defined(HAVE_DEV_PPBUS_PPI_H)
#include <sys/ioctl.h>
#include <dev/ppbus/ppi.h>
#include <dev/ppbus/ppbconf.h>
#define PPWCONTROL PPISCTR
#else

and

void
ppio_ppdev::write_control (unsigned char v)
{
unsigned char ctrl = v ^ CP_ACTIVE_LOW_BITS;
if (ioctl (d_fd, PPISCTRL, &ctrl) != 0){
perror (“ppio_ppdev: write_control”);
throw std::runtime_error (“write_control”);
}
}

Noting that ppio_ppdev::ppio_ppdev (int which)

would need a conditional still around the IEEE1284_MODE_COMPAT

Note I wanted the error messages to bear some relationship with reality.

you’re probably over that pesky copyright assignment threshold…

I’ll look into it today.

  • Diane

Update: I’m not exactly sure what I did to fix but disabling the ESD
(sound
mixer?) seems to have fixed it. All the GRC examples now run except that
they have choppy audio. This appears to be a vmware related issue
because it
happens in command line too.

To: Clark P. [email protected]
or
First off, vmware is not a supported platform.
Eric
Clark
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Like the way Microsoft Office Outlook works? You’ll love Windows Live
Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_outlook_0507

the

Clark

Thanks,
Eric

Sorry, my host os is win xp pro and I’m using the vmware player beta
2.0. My
usrp benchmark gets 16 MByte/s reliably and sometimes 32 MByte/s.

Also, I was able to run the GRC wfm_recv_tvrx.grc.xml demo okay except
for
choppy audio which apparently is unrelated to GRC because the same
happens
with the command line version. But programs like “phone tones.grc.xml”
don’t
do anything?

Thanks,
Clark


PC Magazine’s 2007 editors’ choice for best Web mail—award-winning
Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

Another update:
If I enable/disable sound or serial port from the vmware player menu bar
the
audio is fine for several 10s of seconds. So this is clearly a vmware
player
issue.

As for utilization, I can run the 320 kHz wide FM demodulation example
inside vmware/ubuntu on a winxp host and the system reports about 20%
utilization of my 1.5GHz processor. So it seems to me that I get about
90%
efficiency on both USB2.0 and the processor running gnuradio inside
vmware,
i.e. 10% penalty for virtualization.

From: Eric B. [email protected]
the

Thanks,
interested in hearing about Xen than vmware :wink:
don’t do anything?


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


PC Magazine’s 2007 editors’ choice for best Web mail—award-winning
Windows
Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs