Bug in usrp_rx_cfile.py?

[John_Windish]

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). 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?

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.

John

[John_Windish]

On Thu, 2006-03-30 at 12:11 -0800, John Windish wrote:

I think I have found a bug in usrp_rx_cfile.py…

Looks like a few blocks of stale data like you surmised. You can
strip off the first 500 samples with dd like:

dd ibs=8 skip=500 if=N20kD32.dat of=N20kD32_stripped.dat

[John_Windish]

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

[John_Windish]

On Thu, Mar 30, 2006 at 02:53:46PM -0800, [email protected]
wrote:

I did this for a while, and got tired of it.

- Larry

Thanks Larry!

When I get some breathing room I’ll back port whatever changes are
required.

Eric

[John_Windish]

Friends -

On Thu, Mar 30, 2006 at 01:08:24PM -0800, Eric B. wrote:

opened.
I ran into this in my work, that is derived from USRP.
Resetting n-1 buffers isn’t good enough. :-p
You have to reset the FPGA buffer, the Cypress FX buffer,
and the host USB stack. My model code is at
http://recycle.lbl.gov/~ldoolitt/xguff.html

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

I did this for a while, and got tired of it.

- Larry