Hello,
i’m newbe at Gnuradio and i started with a simple FM receiver project.
I use a USRP1 interface with a TV Rx rev3 daugtherboard and gnuradio
3.3, installed on a Ubuntu 9.04 distribution.
The CPU is a AMD X2 4800+, ramsize is 1GB.
The good news: The FM-receiver works very well.
The bad news: “uOuOuOuO”-messages
The USRP parameters are:
freq: 102,4 MHz
decimation: 256
Realtime scheduling is enabled too.
The decimation factor of 250 devides the full usb bandwith of 64MB/s to
256kB/s.
In my point of view, this should be no problem for the pc to read this
amount of data.
Nevertheless i get many of the overrun messages (“uO”).
The effect of the lost messages is hearable to (of course!). I can hear
a cyclic! click.
That means, that the pc isn’t able to read the USB data fast enough. But
why?
The CPU load is about 15% of each core. But gnuradio isn’t listed in the
process-list. So i cannot say what load is produced by gnuradio itself.
Does anybody can give me any hint, where the problem could be?
Thank you for your help.
Matthias
On Sun, May 09, 2010 at 08:57:28PM +0200, Eder Matthias wrote:
Nevertheless i get many of the overrun messages (“uO”).
Thank you for your help.
Matthias
Could be that the clock in your audio card is slower than the clock in
the USRP, and thus the pipeline backs up. (aka, “The two-clock
problem”)
Eric
On 05/09/2010 02:57 PM, Eder Matthias wrote:
Nevertheless i get many of the overrun messages (“uO”).
I’d look at the existing USRP example FM receiver to get some hints
about how to handle
the two-clock/two-buffer problem.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Nevertheless i get many of the overrun messages (“uO”).
Thank you for your help.
Matthias
Could be that the clock in your audio card is slower than the clock in
the USRP, and thus the pipeline backs up. (aka, “The two-clock problem”)
Eric
Thank you for your fast answer.
If my audio card is slower than usrp clock, what can i do to solve the
problem?
On Sun, May 09, 2010 at 04:01:48PM -0400, Marcus D. Leech wrote:
amount of data.
Does anybody can give me any hint, where the problem could be?
Thank you for your help.
Matthias
I’d look at the existing USRP example FM receiver to get some hints
about how to handle
the two-clock/two-buffer problem.
The proper fix needs to go in the audio sources and sinks.
Although there is an “ok_to_block” constructor argument, most of the
implementations ignore it. Please feel free to fix.
Eric
Eder Matthias wrote:
Well, as I unterstand, the main problem is, that the audio sink has got another clock than USRP has. That means that packets are lost, whan the audio sink buffer is full.
Ok so far, i can follow you.
But what can i do to solve this problem.
The best way would be to synchronise the two clocks. But how can this be done?
This is a well known problem in the HAM radio world as well.
In some hardware (QS1R, HPSDR) the problem was solved adding a D/A
converter clocked by a clock
taken from the A/D, therefore removing the needs of a PC audio card.
In a more general way, because, usually, the clock synchronization in
hardware is not easily
feasible, you need to use a software resampler.
However, due to the drift between the two clocks, in order to avoid
slips, the scaling factor has to
be dynamically changed.
The only software (with source available), at least the only I am aware
of, to implement this
adaptive resampler is WinRad
(http://www.sdrham.com/winrad/download_source.html) written by Alberto
I2PHD.
*am*
-------- Original-Nachricht --------
Datum: Sun, 9 May 2010 20:30:59 -0700
Von: Eric B. [email protected]
An: “Marcus D. Leech” [email protected]
CC: [email protected]
Betreff: Re: [Discuss-gnuradio] USRP-Overrun Problem
The bad news: “uOuOuOuO”-messages
In my point of view, this should be no problem for the pc to read this
The proper fix needs to go in the audio sources and sinks.
Although there is an “ok_to_block” constructor argument, most of the
implementations ignore it. Please feel free to fix.
Eric
To be honest: I don’t see your point.
Well, as I unterstand, the main problem is, that the audio sink has got
another clock than USRP has. That means that packets are lost, whan the
audio sink buffer is full.
Ok so far, i can follow you.
But what can i do to solve this problem.
The best way would be to synchronise the two clocks. But how can this be
done?
Matthias
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter Aktuelle Nachrichten aus Politik, Wirtschaft & Panorama | GMX