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?
Another issue is underflow handling. Is there a way to gracefully
detect and handle underflow if the producer (codec) lacks behind or
stops? If unhandled, we would loose syncronization with the receiver.
–
Håvard Espeland
On 5/8/07, Håvard Espeland [email protected] 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:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/firmware/include/fpga_regs_standard.h
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.
Hopefully this will work out for you?
Another issue is underflow handling. Is there a way to gracefully
detect and handle underflow if the producer (codec) lacks behind or
stops? If unhandled, we would loose syncronization with the receiver.
As for this, I have absolutely no idea - so hopefully someone else
might be able to help you out.
Brian
Brian P. wrote:
You should be able to achieve that, but you have to do more than 1 or
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.
Tom