By the way, if your custom FPGA block was truly the problem (blocking streaming), the Rx LED should be on and you should be getting lots of Overflow. Since this is not happening, it is a good indication that the Rx Radio is never starting.
On Fri, Feb 18, 2022 at 9:10 AM Rob Kossler <rkoss...@nd.edu> wrote: > Hi Maria, > The issue is likely related to "action forwarding" of the streaming > command. When your application asks to start streaming, it typically does > so by calling rx_streamer->issue_stream_cmd(). This "action" will then be > forwarded to the next upstream block controller (typically DDC block > controller) which will see the command and forward it to the next upstream > block controller (typically the Rx radio controller). The Rx radio block > controller will then start the streaming. As an example, let's say your > rx_streamer requested a fixed number of samples (say 1000) and assume that > your DDC decimation is 4. With this architecture, the DDC block controller > can intercept the action and change the requested number of samples from > 1000 to 4000 so that when the radio block controller receives the command, > it will stream for exactly 4000 samples (which will provide 1000 samples > out of the DDC). Note that all of this "action" propagation occurs in UHD > land (not on the FPGA). So, if your custom block controller is not > forwarding actions, the Radio controller never gets the action and thus > never starts the streaming. One way you can verify this is if you are able > to call issue_stream_cmd() from the DDC controller rather than the > rx_streamer. This should cause your streaming to start. > Rob > > On Fri, Feb 18, 2022 at 8:13 AM Maria Muñoz <mamuk...@gmail.com> wrote: > >> Hi all, >> >> I'm using a USRP E320 with UHD 4.0 and GNURadio 3.8 for receiving >> samples through an RX RFNoC Radio block and performing some processing in a >> custom RFNoC block. >> I have created my block using rfnocmodtool, modifying the Verilog and yml >> files for my custom block. I left the cpp and hpp files as default, but I >> copied them to the UHD install path to see the name of my block with >> uhd_usrp_probe. >> I have tested satisfactorily my custom block with a gnuradio graph like >> this: >> >> Host block => rfnoc tx streamer => custom RFNoC block => rfnoc rx >> streamer => Host block >> >> I have also tested it for transmission through the rfnoc tx radio, and >> works fine: >> >> Host block => rfnoc tx streamer => custom RFNoC block => RFNoC DUC=> >> RFNoC TX Radio >> >> But when I try to receive from the radio with the following graph, rx led >> does not light up and gnuradio give time out: >> RFNoC RX Radio => RFNoC DDC => custom RFNoC block => rfnoc rx >> streamer =>Host block >> >> If I remove my custom block from the last graph, I can receive samples >> and the led is on. >> >> It seems like the custom block is blocking somehow the samples. I tried >> with different sampling rates and spp values for the radio but nothing >> works. >> >> Any help on this will be appreciated. >> >> Kind Regards, >> >> Maria >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
