I am using an USRP N210 with GNU radio, UHD and GRC on Ubuntu 10.10. I
have
connected a WBX daughterboard to the USRP. I want to receive and, of
course,
listen the radio thanks to this system. I have built a flow graph and
when I
execute it, I only heard noise and can see this message in the terminal
:
linux; GNU C++ version 4.4.5; Boost_104200;
UHD_002.20110206225409.aea6ac1
gr_fir_fff: using SSE
Current recv sock buff size: 50000000 bytes
Warning:
error in pthread_setschedparam
Failed to set thread priority 0.5 (realtime):
Performance may be negatively affected.
See the general application notes.
Warning:
error in pthread_setschedparam
Failed to set thread priority 0.5 (realtime):
Performance may be negatively affected.
See the general application notes.
mboard0 MIMO master
Warning:
error in pthread_setschedparam
Failed to set thread priority 0.5 (realtime):
Performance may be negatively affected.
See the general application notes.
gr_fir_ccc: using SSE
aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU
I have looked on the internet and tried different things but nothing has
changed. Could someone give me an hand to solve with problem ?
Yes, I have already though about that and I tried to match the sample
and
sound card rates without success (but I might made a mistake). I have
also
read on the Internet that it might come from the sound card which cannot
support all rates but I did not find anything more about that subject.
Here
the python code generated by GRC : http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py
I have run into this problem on the Beagleboard … here’s my
explanation for what I think is happening and the fix. What’s happening
is GNU Radio is trying to run as a real time thread which if you’re root
or you’ve given your Linux username permission to have rtprio privileges
but for some reason I also ran into the problem where I can’t get
realtime scheduling privileges.
now sched_rt_period_us controls the scheduling period in your processor
and sched_rt_runtime_us controls how much of that period is reserved for
realtime processing. When you read the associated driver documentation
it says to disable this segmenting for the realtime period partitioning
you need to set sched_rt_runtime_us to -1 or you can completely disable
this feature in your kernel by “make menuconfig” in your kernel driver
directory … my preference is not to mess with drivers so I set it to
-1 with
echo -1 > sched_rt_runtime_us
now when you run
cat /proc/sys/kernel/sched_rt_runtime_us
output = -1
Now you should be able to use realtime scheduling in GNU Radio. I’m not
sure if this is a good fix because it might give background processes
realtime privileges which would defeat the purpose of the realtime
designation … for me I’m running console Linux on the Beagleboard so
it’s an acceptable solution. As an alternative approach you might try
to use the Linux “nice” and “renice” programs to tweak thread priority
but I personally wans’t successful with this approach.
Francois
I think Josh is right and it’s a sampling rate error. When you set the
sampling rate of the USRP, ask the UHD driver what the current
sampling rate is. Use what it returns to you to adjust the sampling
rate properly. I ran into this same issue and solved it by using the
pfb_arb_resampler block (Polyphase Resampler in GRC) to adjust the
rates correctly.
Yes, you must be right, I must have made a mistake when I set up the flow
graph. How do you know the sample rate delivered by the UHD and how is the
Polyphase Resampler implemented into the flow graph ?
Francois
Not entirely sure how to do this in GRC… When you set the sample
rate of the UHD device, you can request back what it was actually set
to using “get_samp_rate”. So if you were doing this just in Python,
you can have:
Yes, you must be right, I must have made a mistake when I set up the
flow
graph. How do you know the sample rate delivered by the UHD and how is
the
Polyphase Resampler implemented into the flow graph ?
I resolved my problem without using the Polyphase Resampler. It was a
sample
rate issue which did not match the requirements of the audio card.
Anyway,
thank you a lot for your help.
Francois
Anoth wrote:
Access types:
2 channels YES
192000 NO
Polyphase Resampler implemented into the flow graph ?
resamp_rate = req_sr / act_sr
sound card rates without success (but I might made a mistake). I have
I think Josh is right and it’s a sampling rate error. When you set the
I agree that it is a sample rate issue. The USRP sends too many data to
the
computer which becomes overrun. As you said, I put a Polyphase Resampler
between the USRP and the WBFM receive blocks ( http://old.nabble.com/file/p31046181/fm_receiver.py fm_receiver.py ).
But,
when I execute the flow graph, I get this message :
PCM name: hw:0,0
Access types:
MMAP_INTERLEAVED YES
MMAP_NONINTERLEAVED NO
MMAP_COMPLEX NO
RW_INTERLEAVED YES
RW_NONINTERLEAVED NO
Formats:
S16_LE YES
Number of channels
min channels: 2
max channels: 2
2 channels YES
Sample Rates:
min rate: 8000 (dir = 0)
max rate: 48000 (dir = 0)
8000 YES
16000 YES
22050 YES
32000 YES
44100 YES
48000 YES
96000 NO
192000 NO
audio_alsa_sink[hw:0,0]: using S16_LE
gr_fir_ccf: using SSE
Done
Nothing happens and I can no longer see the FFT sink window. By the way,
sorry for the delay of my response, but I have not worked on this
project
for a couple of days.
Francois
Tom R. wrote:
Unless, of course, it’s “resamp_rate = act_sr/req_sr”. I’ve been
cannot
rate properly. I ran into this same issue and solved it by using the