[Top][All Lists]

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

Re: [Discuss-gnuradio] Bug in usrp_rx_cfile.py?

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Bug in usrp_rx_cfile.py?
Date: Thu, 30 Mar 2006 13:08:24 -0800
User-agent: Mutt/1.5.9i

On Thu, Mar 30, 2006 at 12:11:01PM -0800, John Windish wrote:
> I think I have found a bug in usrp_rx_cfile.py...

> I created an m-file for matlab to format data files that are
> generated by usrp_rx_cfile.py (attached).

Thanks.  FYI, there's already one in

> When I process a data file (sample file attached) there is a huge
> oscillation which occurs at about the 400th sample.

> Noting that the data before the oscillation is moving slowly, it
> looks to me like usrp_rx_cfile.py begins to capture data BEFORE the
> new parameters for the capture are set-up.  (The capture I did prior
> to this one had a lower decimation rate, which given my hypothesis
> on the problem, would give the resultant data).  I'm guessing the
> huge oscillation occurs when the new parameters are put into effect,
> and after that, data is captured properly.

> Looking through the code, I may be missing an easy way to correct
> this (if it is indeed the issue).  Has anybody else encoutered an
> issue similar to this one?

I've heard similar reports in the past.

The problem won't be in usrp_rx_cfile.  It'll be somewhere in the
usrp_standard / fusb_linux / FX2 firmware / FPGA code.  There's
probably some buffer that's not flushed when the USRP is closed or

> For reference, the data that I attached was captured with a
> decimation rate of 32 with 20k samples.  The previous capture was
> done with a decimation rate of 16 and 20k samples.
> I'm running Fedora Core 4 on a Pentium based machine.
> Thanks for any insight or help.  

For a work-around, I suggest you drop the first 1M samples.

> John


reply via email to

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