[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
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