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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
