On 14/06/2011 2:52 PM, Tiago Rogério Mück wrote:
The problem you'll have is that 99% of the people on this list use
the "stock" FPGA images, and never venture into doing custom
Have anyone taken a look at this ?
We are still struggling to find a solution to this problem. Any
tip would help a lot.
Em 27 de maio de 2011 16:51, Tiago
Rogério Mück <address@hidden>
We have been working with an (old) USRP1 and doing some
modifications in the FPGA code. After our modifications (we
added an extra layer of DDCs to perform channel separation in
the FPGA), the things didn't work as expected.
In some Gnuradio applications the USRP stops sending samples
after some time. For example, usrp_fft.py runs just fine all
the time, but usrp_rx_cfile.py and usrp_wfm_rcv.py work for
some secs and then the USRP stops sending samples.
I added some pics of our preliminary debugging. In the
figures, the yellow, blue and red signals refer to the
have_pkt_rdy, RD and OE signals, respectively. After some
time, the Cypress stops setting RD and OE signals in response
to the assertion of have_pkt_rdy (first figure). Latter, the
USB FIFO in the FPGA overflows and then have_pkt_rdy goes down
(figure 2). So it seems the problem is not with our
modifications in the FPGA code but with something related to
Have someone ever had a similar problem ? Any clue in how to
solve this would help a lot. We are using Gnuradio 3.2.2.
The funny thing is that usrp_fft.py works perfectly (we double
checked all *.py to make sure our new bitstream is always
being loadded and our new DDCs are being properly configured).
And the remainder, who *do* muck with the FPGA code, usually do so
on the USRP2/N2xxx family.