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

[Jeff Brower]

Ryan-

Could you hack the FX2 firmware and reprogram it to clear its internal buffers 
and/or reset pointers and counters on
Reset?  Or if that's already being done, then do it again at some point 
depending on a signal from the FPGA and/or
host driver?

I found some threads discussing FX2 firmware changes (for example 
http://www.ruby-forum.com/topic/106235,
http://osdir.com/ml/gnu.radio.general/2005-05/msg00011.html).  Cypress and 
others seem to offer a low-cost eval board
for FX2 development.

-Jeff

>> 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?
>>
>> -Jeff
>>
>
> 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.
>
> Ryan
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>