How to retune a daughterboard/bring up the sample rate on USRP?

Hello, I’m new to this mailing list and gnuradio.
sorry if I fail follow certain etiquettes…
what I’m trying to do now is to have a transmitter that hops around
under
1ms, which needs to have 1MHz bandwidth and hop around in 10MHz range
total
(at least).
the problem I’m having is that I can’t get the USRP motherboard to
generate
that high of frequency.
I need the motherboard to generate at least up to 10MHz range because
the
signal needs to be hopped around pretty fast…
and has to be passed on to 2.4GHz range using RFX2400.
This is the error message I get:

File “multiplytest.py”, line 86, in
test_signal = my_top_block()
File “multiplytest.py”, line 46, in init
fmtx = blks2.nbfm_tx (self.sample_rate/10, self.sample_rate,
tau=75e-6,
max_dev=1e5)
File “/usr/lib/python2.6/dist-packages/gnuradio/blks2impl/nbfm_tx.py”,
line 69, in init
40) # stopband atten dB
File “/usr/lib/python2.6/dist-packages/gnuradio/optfir.py”, line 44,
in
low_pass
taps = gr.remez (n + nextra_taps, fo, ao, w, “bandpass”)
File
“/usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py”,
line 352, in remez
return _gnuradio_swig_py_general.remez(*args, **kwargs)
RuntimeError: gr_remez: insufficient extremals – cannot continue

i looked up gr_remez, and I haven’t really found a solution to get USRP
to
have 10MHz bandwidth.
I did find that the frequency has to do with self.sample_rate, and the
highest rate I got was 2 Mega, which in turn can generate up to 1MHz
because
of the nyquist rate.
I know the interpolation rate has to be in multiples of 4 ( 4, 8, 12,
…)
and the USRP rate hast to be 128Mega to match the USB data flow rate (I
don’t know if that’s the right term).
I have my code attached.
Another way I’m looking at is to change the center frequency of the
daughterboard, but I haven’t been able to figure out to make that happen
fast enough.

so the questions are,
How to get the sample rate up to the maximum (which should be 32MHz in
theory)?

How to retune the daughterboard while it’s running?

Any help/suggestions would be great!

I am using USRP1 and RFX2400.

http://old.nabble.com/file/p31947513/multiplytest.py multiplytest.py

Thanks for reading this.


View this message in context:
http://old.nabble.com/How-to-retune-a-daughterboard-bring-up-the-sample-rate-on-USRP--tp31947513p31947513.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On 06/28/2011 07:48 PM, Minhoo K. wrote:

This is the error message I get:
low_pass
highest rate I got was 2 Mega, which in turn can generate up to 1MHz because
How to get the sample rate up to the maximum (which should be 32MHz in

Thanks for reading this.

The maximum sample rate across the USB bus is 8Msps. The samples travel
across as complex (I and Q) with a default of
16-bits I and 16-bits Q. That’s 32Mbyte/second, which is close to
the limit of what USB-2.0 is capable of. Alternatively, if you’re
willing to use 8-bits ‘I’ and 8-bits ‘Q’, you can theoretically move
16Msps across the bus. But your host machine has to be capable to
supporting that data rate in the face of whatever heavy computations
it’s also doing.

Also, getting re-tuning to happen in under 1ms is going to be a
challenge. It’s unlikely that you’ll get the PLL synthesizer on the
RFX2400 to
re-lock in under 1ms.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On Tue, Jun 28, 2011 at 4:48 PM, Minhoo K. [email protected] wrote:

and has to be passed on to 2.4GHz range using RFX2400.
File “/usr/lib/python2.6/dist-packages/gnuradio/optfir.py”, line 44, in
I did find that the frequency has to do with self.sample_rate, and the


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Hi Minhoo,

  • By 10MHz, do you mean -10MHz to 10MHz at baseband or -5MHz to 5MHz.
    The
    former requires a sampling rate of at least 20MHz, which the USRP cannot
    do.
    The latter requires 10MHz, which the USRP can do. This restriction on
    sampling frequency is due to the USB bandwidth.

  • At best the USRP can do -8MHz to 8MHz at baseband, or 16MHz sampling.
    Check out the pfb (polyphase filter banks) based blocks for dealing with
    multi-rate applications

–Colby

On 06/28/2011 08:27 PM, Josh B. wrote:

You should be able to re-adjust the digital frequency shift very
quickly, which can go +/- 32MHz. On USRP1, this is implemented in the
DAC (not the FPGA DSP). You can do this w/ tune_request_t in uhd, no
idea about libgnuradio-usrp

-Josh

This raises an interesting question–is “advanced” tune_request_t
‘exposed’ to GRC? When I looked recently, it didn’t look like it.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

Also, getting re-tuning to happen in under 1ms is going to be a
challenge. It’s unlikely that you’ll get the PLL synthesizer on the
RFX2400 to
re-lock in under 1ms.

You should be able to re-adjust the digital frequency shift very
quickly, which can go +/- 32MHz. On USRP1, this is implemented in the
DAC (not the FPGA DSP). You can do this w/ tune_request_t in uhd, no
idea about libgnuradio-usrp

-Josh

On 06/28/2011 06:29 PM, Marcus D. Leech wrote:

‘exposed’ to GRC? When I looked recently, it didn’t look like it.

Yes. But from grc, there isnt a convenience constructor and it can be
hard to fill out struct members. But you could make a module with a
function that produces the request struct from parameters (or just add
it to the gr-uhd swig init.py).

-Josh