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]
