discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] USRP-Overrun Problem


From: Eder Matthias
Subject: Re: [Discuss-gnuradio] USRP-Overrun Problem
Date: Tue, 11 May 2010 10:56:41 +0200

-------- Original-Nachricht --------
> Datum: Sun, 9 May 2010 20:30:59 -0700
> Von: Eric Blossom <address@hidden>
> An: "Marcus D. Leech" <address@hidden>
> CC: address@hidden
> Betreff: Re: [Discuss-gnuradio] USRP-Overrun Problem

> On Sun, May 09, 2010 at 04:01:48PM -0400, Marcus D. Leech wrote:
> > On 05/09/2010 02:57 PM, Eder Matthias wrote:
> > > 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
> > >
> > >
> > 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

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 http://portal.gmx.net/de/go/maxdome01



reply via email to

[Prev in Thread] Current Thread [Next in Thread]