Hi Maria, A few remarks: - If you wrote a custom block controller for your custom block, then the forwarding policy should already be correct (one-to-one) by default (unless your custom block controller specifically set the policy to DROP). On the other hand, if you did not write a custom block controller (thus relying on the UHD default block controller), then this explains the issue because in that case the default policy is "drop" (which will cause the issue you are seeing). Note that the default behavior of DROP for the default block controller has been changed to ONE_TO_ONE on the 'master' branch of UHD but has not yet been changed on branch UHD-4.1. - So, you don't need to implement "issue_stream_cmd". You just need to verify that your block's action & properties forwarding policies are ONE_TO_ONE (which as I mentioned should be automatic if you create your own custom controller). - You mentioned that you used rfnocmodtool to create your block controller. But, my concern is that this block controller is not really being used. If you run uhd_usrp_probe, does your block show up with a custom name (that you specified) or does it show up as "Block#0". If it shows with the generic name "Block#0" it means that UHD is not using your block controller and instead using the default block controller (which DROPs forwarding on UHD 4.1). So, if this is the case for you, that is the issue that needs to be solved. Unfortunately, I don't know the best way to solve this because I don't use rfnoc_mod_tool. Take a look at the gain block controller <https://github.com/EttusResearch/uhd/blob/UHD-4.1/host/examples/rfnoc-example/lib/gain_block_control.cpp> in the uhd/host/examples/rfnoc-example/ folder. Note that this example does very little (empty constructor). At the bottom is a string identifying the block which is the string that will be shown with uhd_usrp_probe if UHD is using your block controller.
Let me know if this is the issue. Once you get uhd_usrp_probe to "see" your block controller, your problem should be solved. If you can't get this to work, let me know. Rob On Mon, Feb 21, 2022 at 4:41 AM Maria Muñoz <[email protected]> wrote: > Hi Rob, > > Thanks for the answer. > > I have checked rfnoc_rx_streamer.cpp, ddc_block_control.cpp and my > custom block controller in uhd/host/lib folder, and I search for > "issue_stream_cmd" in them. > > In the rx_streamer one I see this function: > > void rfnoc_rx_streamer::issue_stream_cmd(const stream_cmd_t& stream_cmd) >> { >> if (get_num_channels() > 1 and stream_cmd.stream_now >> and stream_cmd.stream_mode != >> stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS) { >> throw uhd::runtime_error( >> "Invalid recv stream command - stream now on multiple >> channels in a " >> "single streamer will fail to time align."); >> } > > > auto cmd = stream_cmd_action_info::make(stream_cmd.stream_mode); >> cmd->stream_cmd = stream_cmd; > > > for (size_t i = 0; i < get_num_channels(); i++) { >> const res_source_info info(res_source_info::INPUT_EDGE, i); >> post_action(info, cmd); >> } >> } > > > While in the ddc I see this: > > void issue_stream_cmd(const uhd::stream_cmd_t& stream_cmd, const >> size_t port) >> { >> RFNOC_LOG_TRACE("issue_stream_cmd(stream_mode=" << >> char(stream_cmd.stream_mode) >> << ", port=" << >> port); >> res_source_info dst_edge{res_source_info::OUTPUT_EDGE, port}; >> auto new_action = >> stream_cmd_action_info::make(stream_cmd.stream_mode); >> new_action->stream_cmd = stream_cmd; >> issue_stream_cmd_action_handler(dst_edge, new_action); >> } > > > There's no "issue_stream_cmd" on my block controller, so maybe as you said > the block is not forwarding actions. I'm not very familiar with controller > files, so could you please tell me which changes I must do to have my block > forwarding actions or point me out to any example to take as a reference? I > created my block using rfnocmodtool and follow the gain example, so I guess > this example is not forwarding actions either. > > By the way, how can I stream from DDC in a GNURadiograph? If DDC is on the > FPGA side, I have to cross to the host domain through a streamer, don't I? > > Kind Regards, > > Maria > > > > El vie, 18 feb 2022 a las 15:14, Rob Kossler (<[email protected]>) escribió: > >> 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 <[email protected]> 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 <[email protected]> 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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>>
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
