FM Receiver

Hi

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 ?

Thank you very much,

Francois

View this message in context:
http://old.nabble.com/FM-Receiver-tp31009069p31009069.html
Sent from the GnuRadio mailing list archive at Nabble.com.

gr_fir_ccc: using SSE

aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU

These characters being printed means that you have mismatched sample
rates between your USRP device and sound card. Could this be the case?

-josh

Hi Josh,

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

Francois

Josh B.-2 wrote:


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/FM-Receiver-tp31009069p31009164.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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.

The parametes of interest to fix this problem are

cat /proc/sys/kernel/sched_rt_runtime_us
output = 950000

cat /proc/sys/kernel/sched_rt_period_us
output = 1000000

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.

al fayez

On Thu, Feb 24, 2011 at 7:17 PM, Anoth [email protected]
wrote:

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.

Tom

On Thu, Feb 24, 2011 at 10:28 PM, Anoth [email protected]
wrote:

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:

req_sr = SR
act_sr = uhd.get_samp_rate()
resamp_rate = req_sr / act_sr
resampler = blks2.pfb_arb_resampler(resamp_rate)

Unless, of course, it’s “resamp_rate = act_sr/req_sr”. I’ve been
working too long today to reason that out.

I’m sure there is a way to do this in GRC by knowing the name of the
UHD device and using it; I’ve just never done it.

Tom

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

Tom R. wrote:

Here
rates correctly.

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/FM-Receiver-tp31009069p31010011.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi again,

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

Sent from the GnuRadio mailing list archive at Nabble.com.
[email protected]



View this message in context:
http://old.nabble.com/FM-Receiver-tp31009069p31046251.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi,

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

aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/FM-Receiver-tp31009069p31046181.html
Sent from the GnuRadio mailing list archive at Nabble.com.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs