[Top][All Lists]

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

Re: [Discuss-gnuradio] USRP Rev4 FX2 firmware question. InitializingFIFO

From: Ryan Seal
Subject: Re: [Discuss-gnuradio] USRP Rev4 FX2 firmware question. InitializingFIFOs ?
Date: Sat, 21 Mar 2009 12:03:13 -0400
User-agent: Opera Mail/9.64 (Linux)

In DSP based radar related systems I've worked on, gating typically occurs as close as possible to the data acq side, rather than close to the CPU or intermediate data transfer circuitry. Can't you zero ADC input inside the FPGA on the alignment that you need and basically let the system "push zeros" during the off time? Or some way that avoids stopping/starting the USB chip? Once you stop/start the USB chip I would think there are driver issues to worry about also -- and if you migrate to USRP2, then same thing, except with the GbE PHY.

Maybe I mis-understand your objectives; one reason for a full system stop would be power consumption. Is that an issue?


Hi Jeff,

The gating is done in the FPGA; it simply controls the the decimated strobe signal. I don't want to push zeros because that's a waste of bandwidth that could be put to use (we should be able to run at bandwidths higher than 8MHz, depending on the duty cycle of the gate). The problem, as I understand it at this point, is that the FX2 buffers contain garbage starting up. If you use the C++ library to interface the USRP, you will see that there is always a few hundred samples of garbage when the system is started. This is NOT due to filter delays or anything like that, since these are computed in 5 or 6 samples. We run experiments for several hours at a time, so I don't need to start/stop the USB chip. I simply need to make sure that the system initializes with empty buffers. These buffers should be empty when I start my program, and should again be cleared when I stop my program. Just to provide a little more information:

We might, for example, transmit 50usec coded pulses into the atmosphere on a 1 msec IPP, meaning that we repeat this process every msec. Using the gate, I can start sampling at say 100km, and stop precisely at 300km. We might continue this process for 12 hours or more. So I start my program at noon, with empty buffers, and stop my program at midnight, which should, once again, clear the buffers.

The gating seems to work as expected, as I said, I am gating the decimated strobe, which simply passes data through the receive chain when the gate is high. This, in turn, fills the fpga receive buffer at a reduced rate, due to the gate. When enough samples are placed in the buffer, the packet ready signal is asserted and tells the FX2 to read this buffer into its own buffer. It seems that this FX2 buffer already contains some samples, if this were not the case, I wouldn't receive a random number of samples that came from another experiment previously run. Long story short, If the FX2 fifos were empty at the system start, I would receive a fixed number of garbage samples due to filling the delay taps in the filters, which is perfectly normal.

When the data comes off of the USB bus, we have several buffers that hold one-second data tables, with each table containing a header that describes the parameters related to data taken at that particular second. This table is 2 dimensional, the rows represent the IPP (1 msec in the example I gave earlier), and the columns contain the time samples collected during the gate for the specified ranges. This is all very standard stuff. If the system starts up with an unknown number of samples setting in the buffer, life becomes difficult when trying to align things.

I am not 100% sure that this is the problem, but when debugging with a logic analyzer, everything in the FPGA looks good, so this is my best guess, and I think I've seen someone mention this FX2 problem before, somewhere.


Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

reply via email to

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