When I want to customize RFNOC blocks, like adding an FFT block in Gnuradio generate OOOOOOOOOOO? When I change the RFNOC image core in USRP from the below link, the FFT block does not work in Gnuradio, For the Gain block same problem... https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 My environment is Ubuntu 20.04 ,Gnuradio 3.8.1, UHD 4.1.0.5, gr-ettus, (I build all Gnuadio, UHD, and.... from source, Original RFNOC block works but the custom block that I added does not work correctly? My question is when I rebuild and synthesize bitstream FPGA I should compile all Gnuradio, UHD, and ....from scratch? What work should I do? I study all links and videos but my problem still remains... I saw these links that they had my problem... https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11087.html https://lists.gnu.org/archive/html/discuss-gnuradio/2020-11/msg00077.html I to describe the problem in this mail..... https://lists.ettus.com/empathy/thread/76SR2TPUUXQPBWUXIWVGVIIHHHWTFRJF I shared the RFNOC image core that I added FFT but it doesn't work... Can anyone guide me? Thanks in advance

You do not need to recompile GNURadio and UHD from scratch each time you build an FPGA bitstream. 'O' means overflow (the data is coming in from the radio faster than you are streaming it to the host). Did you also test that it still works without FFT block in the RFNoC graph while keeping everything else the same (including using the same bitfile)? Did you configure the SPP setting to match the FFT size? This is a requirement of the FFT block. Wade On Sat, May 28, 2022 at 1:16 AM sp h <stackprogramer@gmail.com> wrote: > When I want to customize RFNOC blocks, like adding an FFT block in > Gnuradio generate OOOOOOOOOOO? > When I change the RFNOC image core in USRP from the below link, the FFT > block does not work in Gnuradio, For the Gain block same problem... > https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 > > My environment is Ubuntu 20.04 ,Gnuradio 3.8.1, UHD 4.1.0.5, gr-ettus, > (I build all Gnuadio, UHD, and.... from source, Original RFNOC block works > but the custom block that I added does not work correctly? > > My question is when I rebuild and synthesize bitstream FPGA I should > compile all Gnuradio, UHD, and ....from scratch? > What work should I do? I study all links and videos but my problem still > remains... > > I saw these links that they had my problem... > https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11087.html > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-11/msg00077.html > > I to describe the problem in this mail..... > https://lists.ettus.com/empathy/thread/76SR2TPUUXQPBWUXIWVGVIIHHHWTFRJF > > I shared the RFNOC image core that I added FFT but it doesn't work... > Can anyone guide me? Thanks in advance > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >

Yes! Thanks very much. Did you also test that it still works without FFT block in the RFNoC graph > while keeping everything else the same Yes, I did it, without FFT block, The GRC Gnuradio that includes a Radio core, DDC, RX streamer, and GUI time sink work successfully. I mention that I don't have problem with the default RFNOC block in USRP...All my problems is in customizing RFNOC image core like adding FFT, Gain, and so on... Did you configure the SPP setting to match the FFT size? This is a > requirement of the FFT block. I work with RFNOC image core for x300(a yml file) and set the route or connection between RFNOC blocks according to the link below... https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 I did both of the methods: 1:Example: Adding an FFT Block 2:Example: Adding an FFT Block to the Receive Chain But both of them I faced with OOOOOOOOOOO. I can not understand SPP? Can you explain more? What's SPP? FFT size I set to 64,128,256 and sample rate I test different values.... yet my problem is not solved... You can screenshot of my GRC file... [image: Screenshot from 2022-05-30 08-39-06.png] On Sun, May 29, 2022 at 8:18 PM Wade Fife <wade.fife@ettus.com> wrote: > You do not need to recompile GNURadio and UHD from scratch each time you > build an FPGA bitstream. > > 'O' means overflow (the data is coming in from the radio faster than you > are streaming it to the host). Did you also test that it still works > without FFT block in the RFNoC graph while keeping everything else the same > (including using the same bitfile)? > > Did you configure the SPP setting to match the FFT size? This is a > requirement of the FFT block. > > Wade > > On Sat, May 28, 2022 at 1:16 AM sp h <stackprogramer@gmail.com> wrote: > >> When I want to customize RFNOC blocks, like adding an FFT block in >> Gnuradio generate OOOOOOOOOOO? >> When I change the RFNOC image core in USRP from the below link, the FFT >> block does not work in Gnuradio, For the Gain block same problem... >> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 >> >> My environment is Ubuntu 20.04 ,Gnuradio 3.8.1, UHD 4.1.0.5, gr-ettus, >> (I build all Gnuadio, UHD, and.... from source, Original RFNOC block >> works but the custom block that I added does not work correctly? >> >> My question is when I rebuild and synthesize bitstream FPGA I should >> compile all Gnuradio, UHD, and ....from scratch? >> What work should I do? I study all links and videos but my problem still >> remains... >> >> I saw these links that they had my problem... >> https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11087.html >> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-11/msg00077.html >> >> I to describe the problem in this mail..... >> https://lists.ettus.com/empathy/thread/76SR2TPUUXQPBWUXIWVGVIIHHHWTFRJF >> >> I shared the RFNOC image core that I added FFT but it doesn't work... >> Can anyone guide me? Thanks in advance >> >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >> >

SPP means "Samples Per Packet". It's the size of the packets you request from the radio. I don't know how to set this from GNU Radio (that's not my area of expertise), but with the RFNoC API you can set the "spp" property on the radio to set the packet size. If using MultiUSRP, you can use set_rx_spp(). But I'm pretty sure the FFT block won't work unless the FFT size and spp are the same. Also, the FFT block doesn't support FFT size of 64k. It is limited by the maximum spp size and the maximum size supported by the IP, which is currently 1024. https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/ip/axi_fft/axi_fft.xci#L134 I suspect that the problem you have with the Gain block and the problem you have with the FFT block have different causes, even though they both result in overflow. Wade On Sun, May 29, 2022 at 11:10 PM sp h <stackprogramer@gmail.com> wrote: > Yes! Thanks very much. > > Did you also test that it still works without FFT block in the RFNoC graph >> while keeping everything else the same > > Yes, I did it, without FFT block, The GRC Gnuradio that includes a Radio > core, DDC, RX streamer, and GUI time sink work successfully. > I mention that I don't have problem with the default RFNOC block in > USRP...All my problems is in customizing RFNOC image core like adding FFT, > Gain, and so on... > > Did you configure the SPP setting to match the FFT size? This is a >> requirement of the FFT block. > > I work with RFNOC image core for x300(a yml file) and set the route or > connection between RFNOC blocks according to the link below... > https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 > > I did both of the methods: > 1:Example: Adding an FFT Block > 2:Example: Adding an FFT Block to the Receive Chain > > But both of them I faced with OOOOOOOOOOO. > > I can not understand SPP? Can you explain more? What's SPP? FFT size I > set to 64,128,256 and sample rate I test different values.... yet my > problem is not solved... You can screenshot of my GRC file... > [image: Screenshot from 2022-05-30 08-39-06.png] > > > On Sun, May 29, 2022 at 8:18 PM Wade Fife <wade.fife@ettus.com> wrote: > >> You do not need to recompile GNURadio and UHD from scratch each time you >> build an FPGA bitstream. >> >> 'O' means overflow (the data is coming in from the radio faster than you >> are streaming it to the host). Did you also test that it still works >> without FFT block in the RFNoC graph while keeping everything else the same >> (including using the same bitfile)? >> >> Did you configure the SPP setting to match the FFT size? This is a >> requirement of the FFT block. >> >> Wade >> >> On Sat, May 28, 2022 at 1:16 AM sp h <stackprogramer@gmail.com> wrote: >> >>> When I want to customize RFNOC blocks, like adding an FFT block in >>> Gnuradio generate OOOOOOOOOOO? >>> When I change the RFNOC image core in USRP from the below link, the FFT >>> block does not work in Gnuradio, For the Gain block same problem... >>> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 >>> >>> My environment is Ubuntu 20.04 ,Gnuradio 3.8.1, UHD 4.1.0.5, gr-ettus, >>> (I build all Gnuadio, UHD, and.... from source, Original RFNOC block >>> works but the custom block that I added does not work correctly? >>> >>> My question is when I rebuild and synthesize bitstream FPGA I should >>> compile all Gnuradio, UHD, and ....from scratch? >>> What work should I do? I study all links and videos but my problem still >>> remains... >>> >>> I saw these links that they had my problem... >>> https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11087.html >>> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-11/msg00077.html >>> >>> I to describe the problem in this mail..... >>> https://lists.ettus.com/empathy/thread/76SR2TPUUXQPBWUXIWVGVIIHHHWTFRJF >>> >>> I shared the RFNOC image core that I added FFT but it doesn't work... >>> Can anyone guide me? Thanks in advance >>> >>> _______________________________________________ >>> USRP-users mailing list -- usrp-users@lists.ettus.com >>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>> >>

Thank you for the clarification. Finally, I used the SPP parameter, Now my FFT block works successfully... [image: Screenshot from 2022-06-08 11-26-06.png] On Tue, May 31, 2022 at 8:32 PM Wade Fife <wade.fife@ettus.com> wrote: > SPP means "Samples Per Packet". It's the size of the packets you request > from the radio. I don't know how to set this from GNU Radio (that's not my > area of expertise), but with the RFNoC API you can set the "spp" property > on the radio to set the packet size. If using MultiUSRP, you can use > set_rx_spp(). But I'm pretty sure the FFT block won't work unless the FFT > size and spp are the same. > > Also, the FFT block doesn't support FFT size of 64k. It is limited by the > maximum spp size and the maximum size supported by the IP, which is > currently 1024. > > > https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/ip/axi_fft/axi_fft.xci#L134 > > I suspect that the problem you have with the Gain block and the problem > you have with the FFT block have different causes, even though they both > result in overflow. > > Wade > > On Sun, May 29, 2022 at 11:10 PM sp h <stackprogramer@gmail.com> wrote: > >> Yes! Thanks very much. >> >> Did you also test that it still works without FFT block in the RFNoC >>> graph while keeping everything else the same >> >> Yes, I did it, without FFT block, The GRC Gnuradio that includes a Radio >> core, DDC, RX streamer, and GUI time sink work successfully. >> I mention that I don't have problem with the default RFNOC block in >> USRP...All my problems is in customizing RFNOC image core like adding FFT, >> Gain, and so on... >> >> Did you configure the SPP setting to match the FFT size? This is a >>> requirement of the FFT block. >> >> I work with RFNOC image core for x300(a yml file) and set the route or >> connection between RFNOC blocks according to the link below... >> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 >> >> I did both of the methods: >> 1:Example: Adding an FFT Block >> 2:Example: Adding an FFT Block to the Receive Chain >> >> But both of them I faced with OOOOOOOOOOO. >> >> I can not understand SPP? Can you explain more? What's SPP? FFT size I >> set to 64,128,256 and sample rate I test different values.... yet my >> problem is not solved... You can screenshot of my GRC file... >> [image: Screenshot from 2022-05-30 08-39-06.png] >> >> >> On Sun, May 29, 2022 at 8:18 PM Wade Fife <wade.fife@ettus.com> wrote: >> >>> You do not need to recompile GNURadio and UHD from scratch each time you >>> build an FPGA bitstream. >>> >>> 'O' means overflow (the data is coming in from the radio faster than you >>> are streaming it to the host). Did you also test that it still works >>> without FFT block in the RFNoC graph while keeping everything else the same >>> (including using the same bitfile)? >>> >>> Did you configure the SPP setting to match the FFT size? This is a >>> requirement of the FFT block. >>> >>> Wade >>> >>> On Sat, May 28, 2022 at 1:16 AM sp h <stackprogramer@gmail.com> wrote: >>> >>>> When I want to customize RFNOC blocks, like adding an FFT block in >>>> Gnuradio generate OOOOOOOOOOO? >>>> When I change the RFNOC image core in USRP from the below link, the FFT >>>> block does not work in Gnuradio, For the Gain block same problem... >>>> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 >>>> >>>> My environment is Ubuntu 20.04 ,Gnuradio 3.8.1, UHD 4.1.0.5, gr-ettus, >>>> (I build all Gnuadio, UHD, and.... from source, Original RFNOC block >>>> works but the custom block that I added does not work correctly? >>>> >>>> My question is when I rebuild and synthesize bitstream FPGA I should >>>> compile all Gnuradio, UHD, and ....from scratch? >>>> What work should I do? I study all links and videos but my problem >>>> still remains... >>>> >>>> I saw these links that they had my problem... >>>> https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11087.html >>>> >>>> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-11/msg00077.html >>>> >>>> I to describe the problem in this mail..... >>>> https://lists.ettus.com/empathy/thread/76SR2TPUUXQPBWUXIWVGVIIHHHWTFRJF >>>> >>>> I shared the RFNOC image core that I added FFT but it doesn't work... >>>> Can anyone guide me? Thanks in advance >>>> >>>> _______________________________________________ >>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>> >>>

Hi, I designed the following flowgraph just to make sure I could receive, process and transmit but even a simple receive and transmit doesn't work. I get no graph error and the gui pops up as it would normally do. However, the x310 I use doesn't do the job and seems inactive (no rx tx led on). Daughterboards are basicRX and basicTX both plugged in the A slots right now but switching and crossing channels doesn't change anything. What am I missing? Cheers, Maxime

Just a final comment to Ettus regarding this dependency between SPP and the FFT size.... This restriction should be eliminated. Not only does it cause the problems indicated in this thread, but it also restricts the max size of the FFT to the packet size (assuming that you change the FFT IP core size to something larger). And, it is not a difficult modification to remove this dependency - simply wrapping the FFT block using "axi_rate_change" as is done in the DDC/DUC handles the packet length issues (and, there is likely a superior solution given that "axi_rate_change" also handles rate changes which don't occur in the FFT). On Wed, Jun 8, 2022 at 2:59 AM sp h <stackprogramer@gmail.com> wrote: > Thank you for the clarification. Finally, I used the SPP parameter, Now my > FFT block works successfully... > [image: Screenshot from 2022-06-08 11-26-06.png] > > On Tue, May 31, 2022 at 8:32 PM Wade Fife <wade.fife@ettus.com> wrote: > >> SPP means "Samples Per Packet". It's the size of the packets you request >> from the radio. I don't know how to set this from GNU Radio (that's not my >> area of expertise), but with the RFNoC API you can set the "spp" property >> on the radio to set the packet size. If using MultiUSRP, you can use >> set_rx_spp(). But I'm pretty sure the FFT block won't work unless the FFT >> size and spp are the same. >> >> Also, the FFT block doesn't support FFT size of 64k. It is limited by the >> maximum spp size and the maximum size supported by the IP, which is >> currently 1024. >> >> >> https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/ip/axi_fft/axi_fft.xci#L134 >> >> I suspect that the problem you have with the Gain block and the problem >> you have with the FFT block have different causes, even though they both >> result in overflow. >> >> Wade >> >> On Sun, May 29, 2022 at 11:10 PM sp h <stackprogramer@gmail.com> wrote: >> >>> Yes! Thanks very much. >>> >>> Did you also test that it still works without FFT block in the RFNoC >>>> graph while keeping everything else the same >>> >>> Yes, I did it, without FFT block, The GRC Gnuradio that includes a Radio >>> core, DDC, RX streamer, and GUI time sink work successfully. >>> I mention that I don't have problem with the default RFNOC block in >>> USRP...All my problems is in customizing RFNOC image core like adding FFT, >>> Gain, and so on... >>> >>> Did you configure the SPP setting to match the FFT size? This is a >>>> requirement of the FFT block. >>> >>> I work with RFNOC image core for x300(a yml file) and set the route or >>> connection between RFNOC blocks according to the link below... >>> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 >>> >>> I did both of the methods: >>> 1:Example: Adding an FFT Block >>> 2:Example: Adding an FFT Block to the Receive Chain >>> >>> But both of them I faced with OOOOOOOOOOO. >>> >>> I can not understand SPP? Can you explain more? What's SPP? FFT size I >>> set to 64,128,256 and sample rate I test different values.... yet my >>> problem is not solved... You can screenshot of my GRC file... >>> [image: Screenshot from 2022-05-30 08-39-06.png] >>> >>> >>> On Sun, May 29, 2022 at 8:18 PM Wade Fife <wade.fife@ettus.com> wrote: >>> >>>> You do not need to recompile GNURadio and UHD from scratch each time >>>> you build an FPGA bitstream. >>>> >>>> 'O' means overflow (the data is coming in from the radio faster than >>>> you are streaming it to the host). Did you also test that it still works >>>> without FFT block in the RFNoC graph while keeping everything else the same >>>> (including using the same bitfile)? >>>> >>>> Did you configure the SPP setting to match the FFT size? This is a >>>> requirement of the FFT block. >>>> >>>> Wade >>>> >>>> On Sat, May 28, 2022 at 1:16 AM sp h <stackprogramer@gmail.com> wrote: >>>> >>>>> When I want to customize RFNOC blocks, like adding an FFT block in >>>>> Gnuradio generate OOOOOOOOOOO? >>>>> When I change the RFNOC image core in USRP from the below link, >>>>> the FFT block does not work in Gnuradio, For the Gain block same problem... >>>>> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0 >>>>> >>>>> My environment is Ubuntu 20.04 ,Gnuradio 3.8.1, UHD 4.1.0.5, gr-ettus, >>>>> (I build all Gnuadio, UHD, and.... from source, Original RFNOC block >>>>> works but the custom block that I added does not work correctly? >>>>> >>>>> My question is when I rebuild and synthesize bitstream FPGA I should >>>>> compile all Gnuradio, UHD, and ....from scratch? >>>>> What work should I do? I study all links and videos but my problem >>>>> still remains... >>>>> >>>>> I saw these links that they had my problem... >>>>> https://www.mail-archive.com/usrp-users@lists.ettus.com/msg11087.html >>>>> >>>>> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-11/msg00077.html >>>>> >>>>> I to describe the problem in this mail..... >>>>> https://lists.ettus.com/empathy/thread/76SR2TPUUXQPBWUXIWVGVIIHHHWTFRJF >>>>> >>>>> I shared the RFNOC image core that I added FFT but it doesn't work... >>>>> Can anyone guide me? Thanks in advance >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >>>>> >>>> _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >