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

[Eric Blossom]

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
gnuradio-core/src/utils/read_complex_binary.m

> 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
opened.

> 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

Eric