Hello all,
I have XCVR2450 USRP’s. I have been trying to send the data between two
USRP’s. I have made some changes to the python code in uhd_interface.py
where I have changed the gain to 25 and set the frequency for
transmitter and receiver to 2.435G. I have run uhd_fft program only to
find that my sample rate of 50k is not being supported. I am unable to
know how to set the sample rate and sps for my device. Because of that,
I have been receiving some errors like
I also have attached a graph of uhd_fft program. I think I have got a
wave which represents a transmission gain of 25 and received gain of 15
because I have specified it in the uhd_interface.py program. Please
advice as to where I can change these settings so that I might be able
to receive packet in a right order. Thank you
Hi,
what Jeon writes is correct so far, but two comments:
You can check XCVR2450’s dsp rate
XCVR2450 is your daughterboard, not your USRP. The mainboard has a
master clock rate. 100M is a good example, because it’s the MCR of the
USRP N2x0.
But in case of LFTX, LFRX, it is 200k.
As explained above, it’s not a feature of the daughterboard, but of your
USRP. My assumption would be the minimum rate for you is 100M/512 =
192.something kHz
And as Jeon pointed out, you should see a warning on the console, saying
which sampling rate was actually used.
Now, I’m not quite sure what tools you’re using that use the
uhd_interface.uhd_transmitter and uhd_interface.uhd_receiver, but if
it’s one of the benchmark_* scripts, you will need to adjust symbol rate
or samples_per_symbol, or likely both, to yield a valid sampling rate.
Note before the text: my answer might have some incorrect terminologies.
I am unable to know how to set the sample rate and sps for my device.
DSP rate should be an integer multiple of sampling rate
You can check XCVR2450’s dsp rate by uhd_usrp_probe command. Let’s say
it
is 100M (not a true value!)
If you set sampling rate to 30k, 100M/30k = 3.333k, not an integer
There is some lower limit of sampling rate
Since I’ve never used XCVR2450, I don’t know the exact value of it.
But in case of LFTX, LFRX, it is 200k.
If 50k that you’ve set is below such lower limit, you can see warning
message on the console.
Hi,
Thanks for the advice. I am sorry that I didn’t understand what you have
said. So what you suggest is that I need to make some changes to the
benchmark scripts. But I have changed gain and frequency already in the
uhd_interface program. Do i need to use the gnuradio-companion for
uhd_interface program? Because, I am giving all the commands in the
terminal itself. Please suggest me further. Excuse me if I am asking
some noob doubts because I am new to gnuradio.
Besides the problem I had above, there seems to be a new one. Till that
day, I used to get some output, but today, when I tried to run the
./benchmark_tx.py -f 2.435G command, I am getting the following error
Traceback (most recent call last):
File “./benchmark_tx.py”, line 147, in
main()
File “./benchmark_tx.py”, line 111, in main
tb = my_top_block(mods[options.modulation], options)
File “./benchmark_tx.py”, line 49, in init
options.antenna, options.verbose)
File
“/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py”,
line 135, in init
freq, gain, antenna)
File
“/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py”,
line 62, in init
self._rate, self._sps = self.set_sample_rate(bitrate, sps)
File
“/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py”,
line 70, in set_sample_rate
asked_samp_rate = bitrate * req_sps
TypeError: unsupported operand type(s) for *: ‘float’ and ‘NoneType’
But the receiver is working just fine. I don’t know what mistake is
present in my benchmark transmission file. Please help me with this. I
am attaching the same benchmark scripts.
File
“/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py”,
line 70, in set_sample_rate
asked_samp_rate = bitrate * req_sps
TypeError: unsupported operand type(s) for *: ‘float’ and ‘NoneType’
This is what you want to track down. See what req_sps is in the file
mentioned above, and where it’s set.
If your receiver is working, this seems like some simple Python bug.
But the receiver is working just fine. I don’t know what mistake is
present in my benchmark transmission file. Please help me with this. I
am attaching the same benchmark scripts.
If you want to attach files, I suggest you subscribe to the mailing list
instead of using ‘ruby forum’. Most people handle the mailing list in
this way.
you will have to inspect the error, and it will tell you that the
“options” object has no attribute “lo_offset”. This means that the
script tries to access member of the options variable that isn’t there.
Also, this allowed me to find out which benchmark_tx (there’s two in GNU
Radio) you’re working with.
This is a bit strange, because the option “–lo-offset” is definitely
there, added by uhd_transmitter.add_options. Having had a look at the
file you uploaded to ruby-forum (please PLEASE don’t use ruby-forum), it
is really missing these lines that add the “–lo-offset” option. These
were added in 2013. Is it possible that you use a modern
narrowband/benchmark_tx.py with a narrowband/uhd_interface.py from
before 2013?
All in all, only you have worked with your code; I think it will really
really pay if you work yourself through these errors to figure out
what’s wrong – if you didn’t mix up versions like I suspected above, I
have no idea what goes wrong, and you can’t keep coming back to the
mailing list with every single Python error. Doing this “the hard way”
yourself will have a lot of benefits for you: You will be faster overall
(because I’m pretty sure this is not the last python problem you’ll
encounter), because you won’t have to rely and wait on other people
reading your error messages, and simultaneously you’ll develop the
skills necessary to write your own python code.
You should just use matching versions of these files… kind of
obviously.
I wonder how this mix up happened; generally, you should just use the
versions of things as they come with exactly your GNU Radio
installation; probably, these files are under
/usr/share/gnuradio/examples/digital or so.
Thanks for the reply Marcus. It seems that you were right about my
mixing up different versions of the script files. So I guess that I need
to add any program lines in my script to remove that error is there any
other way? Please help with this one issue. And I will work towards the
python codes as you suggested.
I am sorry to have misunderstood you. I am sorry to bother you like
this. I got the point now. So do I need to install the GNU radio again
for this mix-up not to happen?
So do I need to install the GNU radio again
No, as I said. These files /come with GNU Radio/, and I’m assuming you
did not go ahead and use root privileges to overwrite the originals. You
just need to take the originals (probably in
/usr/share/gnuradio/examples/digital), and copy them to wherever you
want to work with them.
I can’t, however, tell whether you’ve intentionally modified the files
under /usr/share… ; that’s something you know, not I
Also, as I have already asked you: please stop using Ruby-forum, and
sign up under https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Ruby forum just guesses to which email you’re replying, so everyone else
gets your emails in strange thread hierarchies, and it’s nearly
impossible to follow discussions on the mailing list with you.
Best regards,
Marcus
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.