[Top][All Lists]

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

Re: [Discuss-gnuradio] GMSK minimum bitrate

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] GMSK minimum bitrate
Date: Tue, 08 May 2007 21:40:15 -0400
User-agent: Thunderbird (Windows/20070221)

Brian Padalino wrote:
On 5/8/07, Håvard Espeland <address@hidden> wrote:
We're writing a gmsk radio module with low bitrate (<5 kbps) and
continuous constant bitrate transmission using Gnuradio 3.0.3 and USRP.
The code is based on the digital/tx_voice.py example, and I have two
unanswered questions.

By hacking on the example, pick_bitrate fails to return a lower bitrate
than 35.714kb/sec. Is it possible to support a precisely defined lower
bitrate, or is there a technical limitation?

You should be able to achieve that, but you have to do more than 1 or
2 samples per symbol.

All the TX samples are sent out of the AD9862 at a rate of 128MHz.
The FR_INTERP_RATE register within the FPGA has a maximum value of
1024 which is the maximum amount of interpolation between samples that
are given to the FPGA.

See here:

Just doing some off the cuff calculations, I believe that if you set
the interpolation rate to the maximum (1024), and the number of
samples per symbol to 25, you should be able to achieve 5kbps.
Unfortunately, that won't work. We've limited the maximum number of samples per symbol to 7; more is impractical, and while it should work theoretically in the M&M clock recovery loop, it might have some practical problems with a number that high.

The way I've solved this issue is to put an extra interpolator into the transmit_path.py file right before it goes to the USRP to take up the extra slack. You'll want to hack the pick_bitrate.py file, too, so you can automatically select the appropriate interpolation rates for the USRP and the interpolator in the code. It's just adding another nested loop in the brute-force search that's currently done. The optimization goals of the pick_bitrate calculation are to minimize the samples per symbol and the interpolation factor in the code (or to maximize the interpolation done in the USRP to offload the processing to it).

You'll then require the complimentary process of decimating in the receiver.

We'd talked briefly about putting this in as a general solution in the digital modulation examples, but we never got around to it. I think my old development branch to play with this is still hanging out in limbo, a couple thousand revisions old by now.


reply via email to

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