USRP 1 overflow problem

Hello All,

I have just started learning SDR and new to USRP as well for GNU radio.

SInce i am just a beginner, so i started with very basic examples
benchmark_tx.py and benchmark_rx.py on USRP1.

I am using daughter board WBX.

I am getting an overflow problem both for receiver and uhd_fft as well.
I tried to search on google but there was no clue for USRP1.

Please help me out to this very initial example problems.

Thank you, in advance.

Below is the command i am passing for tx and rx

benchmark_tx.py -a serial=49270a48 -f 2.2G -m gmsk -r 240 --tx-gain=20
–tx-amplitude=0.8

in another terminal for benchmark_rx i am passing this
benchmark_rx.py -a serial=4d05ac4b -f 2.2G -m gmsk -r 240 --rx-gain=20

forrx and alsofor uhd_fft it is printing the same oooooooo continues.

Thank you.

On Thu, Nov 20, 2014 at 5:32 AM, alok ranjan [email protected]
wrote:

benchmark_tx.py -a serial=49270a48 -f 2.2G -m gmsk -r 240 --tx-gain=20
–tx-amplitude=0.8

in another terminal for benchmark_rx i am passing this
benchmark_rx.py -a serial=4d05ac4b -f 2.2G -m gmsk -r 240 --rx-gain=20

forrx and alsofor uhd_fft it is printing the same oooooooo continues.

Thank you.

I wouldn’t call the benchmark examples the “very basic.” You still need
to
understand and calibrate a lot of your system before you can get it to
work. If you’re new, you should start with our tutorials:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials

These will explain a lot of what you’ll be dealing with when you get to
this advanced stuff.

Tom

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  1. Tom is absolutely right. Benchmark_tx is something that illustrates
    some very interesting aspects of GNU Radio, but it’s not something you
    start with, because the things you see won’t mean a thing to you. So
    do the guided tutorials, and if you feel like you’re missing out on
    some theoretical aspects, maybe pay the “suggested reading” page a
    visit.
  2. Overflows mean that your PC is too slow to keep up with the real
    time sample processing. Basically, this is nothing that you can solve
    by doing anything within the “basic” usage of GNU Radio. It just means
    your machine is too slow.

Greetings,
Marcus

On 11/20/2014 11:32 AM, alok ranjan wrote:

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUbgpFAAoJEAFxB7BbsDrL3SAH/AuKbB52xPpJ5Or39bZ9+2WY
VzjV24/O+aLNfmqFzuYd5bK18A11CAZ4elEbHcdtIhTYUVCapZIWTZe0b0d4ZjRz
Y0zEEJH+cKQkEpz+7TPcPa6kLsN8rhD7pAhUlSUHMOAcedNWOj5slLlx8+F85c3x
YpMRD1L6nZz4gMtNe1KVEEI4vKjZg5kdt5X9ddwQ12KoOyiNv2qGHZyne3OUedwr
mO95bXVuZ44iYg4yzSvXF72o/psIlcD3XrmPdMIW0WmTC8Yy41fnLMqp90jCCAjE
Y/esA72Moc9PBDhtWLX4YD7dCOADOvDnXcrlfiSRHBNNmSNoLPIIl6GCR+UxbHw=
=Q2X1
-----END PGP SIGNATURE-----

Further, I’m not sure that benchmark_tx/rx can actually do bit rates as
low as 240 bits/second, because the have a fairly-simple symbol-rate
model, and the USRP1 can only support sample rates down to 192k.

You said that uhd_fft also produced ‘O’ indications–what parameters
were you using with uhd_fft?

On 2014-11-20 10:35, Marcus Müller wrote:

by doing anything within the “basic” usage of GNU Radio. It just means
Version: GnuPG v1


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

Links: