discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Problem with 8-bit option and dropped samples


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Problem with 8-bit option and dropped samples
Date: Mon, 20 Aug 2007 20:39:34 -0700
User-agent: Mutt/1.5.9i

On Mon, Aug 20, 2007 at 11:15:36PM -0400, Lisa Creer wrote:
> I'm testing the -8 option in various example programs, and haven't been
> successful in receiving valid data.  The following test resulted in a very
> brief, flat line being displayed, then absolutely no data showed on the
> graph, but the program continued to run.
> 
>  ./usrp_fft.py -f 100M -d 4 -8
> format = 0x288
> set_format = True

Have you tried increasing the gain?
What daughterboard are you using?
Do you have an antenna connected?  If so, what kind?

> I decided to try decimating by 4 without specifying the 8-bit option, and I
> received the 'uO' indicating that samples were dropped from the USRP to
> host, but data was displayed on the graph, and it was 16MHz wide.  What's
> going on?
> 
> ./usrp_fft.py -f 92.7M -d 4
> uOuOuOuOuOuOuOuOuOu

64 MS/s / 4 * 4 bytes/S = 64MB/s.  This won't fit across the USB,
hence the continuous overruns.

> I've also written a data capture script that simply writes data from the
> USRP to a file, and when I use the usrp.source_s () function (after using
> make_format, set_format) I get a few initial non-zero bytes, but the rest of
> the data file is zeroed out.

Have you tried using the existing usrp_rx_cfile.py program?  It's
known to work.

> Any idea what is happening here? I'm wondering if my signal is so weak, that
> the 8-bit option is truncating all the data off.

Could be.  It currently takes the high 8 bits of the 16-bit value.

[I thought that somebody had implemented the barrel shifter, but
checking rx_buffer.v, I don't see it.]

> When running usrp_wfm_rcv.py I can only get one strong FM radio station.

Seems unlikely, unless you're living in the middle of nowhere...

Have you tried:

 $ usrp_fft.py -f 95M -d 8

Should show lots of stations...


> Other questions are:
> 
> Is the 'uO' the only indication that samples have been dropped?

Yes.

> Does the number of 'uO's correspond to the number of samples dropped?

No.  Overrun detection is currently implemented by polling at
approximately 10Hz.  If you're trying to receive constantly streaming
data, you shouldn't see any uO's.

> What are the buffer sizes?

They're configurable in the constructor to usrp.source_c.
The default is generally reasonable.

What OS and distribution are you running on?

Eric




reply via email to

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