On 14/06/2011 2:52 PM, Tiago Rogério Mück wrote:
Hi,
Have anyone taken a look at this ?
We are still struggling to find a solution to this problem. Any tip
would help a lot.
Thanks,
Tiago
Em 27 de maio de 2011 16:51, Tiago Rogério Mück <[email protected]
<mailto:[email protected]>> escreveu:
Hi,
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 the Cypress.
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).
Thanks.
Regards,
Tiago.
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
FPGA work.
And the remainder, who *do* muck with the FPGA code, usually do so on
the USRP2/N2xxx family.
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
