Hi Jorge,
I don't immediately see what the problem is. I can tell you that it is
certainly possible to do what you are doing. You can do so with as few as
one rfnoc block or you can use a chain. I have done this often.
Typically, after I verify my custom rfnoc block with a testbench, I will
build the new FPGA image and then test my block alone in a very similar
test case to the testbench such that the flow is host -> my_block -> host.
One thing you might try is to enable additional UHD logging so that you can
see DEBUG and TRACE logging messages. Perhaps that will provide a better
indication regarding your "No upstream blocks" log message. It would be
nice to know which block is missing a connection.
Rob
On Tue, Nov 10, 2020 at 4:44 AM Jorge Arroyo Giganto <jarr...@gradiant.org>
wrote:
> Hi Rob,
>
> Thank you for your quick response. I'm sorry if I didn't specifically
> mention that. I did connect the blocks calling the connect() function like
> so:
>
> uhd::rfnoc::graph::sptr txrx_graph = usrp3->create_graph("txrx");
> usrp3->clear();
> txrx_graph->connect(dmafifo_blockid, 0, gain_blockid, 0);
>
> Where "dmafifo_blockid" and "gain_blockid" come from:
>
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
> uhd::device3::sptr usrp3 = usrp->get_device3();
> uhd::rfnoc::dma_fifo_block_ctrl::sptr dmafifo_block_ctrl =
> usrp3->get_block_ctrl<uhd::rfnoc::dma_fifo_block_ctrl>(uhd::rfnoc::block_id_t(0,
> "DmaFIFO"));
> uhd::rfnoc::block_ctrl_base::sptr gain_block_ctrl =
> usrp3->get_block_ctrl(uhd::rfnoc::block_id_t(0, "gain"));
> std::string dmafifo_blockid = dmafifo_block_ctrl->get_block_id();
> std::string gain_blockid = gain_block_ctrl->get_block_id();
>
> I also tried connecting a FIFO after the gain block (
> txrx_graph->connect(gain_blockid, 0, fifo_blockid, 0);) and telling the
> rx_streamer to use that block, but the result looked the same.
>
> Thanks again,
>
> Jorge
>
> El lun., 9 nov. 2020 a las 20:33, Rob Kossler (<rkoss...@nd.edu>)
> escribió:
>
>> Hi Jorge,
>> I don't see any indication that you are calling the Connect() function to
>> connect the RFNoC blocks in the FPGA.
>> Rob
>>
>> On Mon, Nov 9, 2020 at 1:35 PM Jorge Arroyo Giganto via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> After testing a loopback in GNU Radio with a custom block (the gain
>>> example from the Getting Started with RFNoC guide), I managed to get the
>>> samples going from the host to the "RFNoC domain" and back to the host,
>>> without involving the radio cores at all. My flowgraph was Signal Source
>>> (Host) -> RFNoC: DmaFIFO -> RFNoC: gain -> QT GUI Freq Sink (Host), and
>>> everything worked fine, so I know that what I'm trying to do is possible.
>>>
>>> I have also made examples in UHD with C++ transmitting (Host -> TX
>>> Radio) and receiving (RX Radio -> Host) using the custom RFNoC block in the
>>> graph, by modifying the tx_waveforms and rfnoc_rx_to_file examples, and
>>> everything worked fine as well, I checked that all of the examples had a
>>> resulting signal that looked like it was expected.
>>>
>>> Now, I would like to replicate in UHD with C++ something similar to what
>>> I have in GNU Radio, a loopback using the RFNoC custom block but without
>>> involving the radio cores, basically: Host -> RFNoC -> Host. Right now my
>>> approach is to have a graph looking like Host TX -> DmaFIFO -> Gain Custom
>>> -> Host RX, I am configuring the tx and rx streamers this way:
>>>
>>> uhd::device_addr_t tx_streamer_args;
>>> uhd::stream_args_t tx_stream_args("fc32", "sc16");
>>> tx_streamer_args["block_id"] = dmafifo_blockid;
>>> tx_streamer_args["block_port"] = "0";
>>> tx_stream_args.args = tx_streamer_args;
>>> tx_stream_args.args["spp"] = boost::lexical_cast<std::string>(spp);
>>> //spp=364
>>> uhd::tx_streamer::sptr tx_stream = usrp3->get_tx_stream(tx_stream_args);
>>>
>>> ----
>>>
>>> uhd::device_addr_t rx_streamer_args;
>>> uhd::stream_args_t rx_stream_args("fc32", "sc16");
>>> rx_streamer_args["block_id"] = gain_blockid;
>>> rx_streamer_args["block_port"] = "0";
>>> rx_stream_args.args["spp"] = boost::lexical_cast<std::string>(spp);
>>> rx_stream_args.args = rx_streamer_args;
>>> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(rx_stream_args);
>>>
>>> I'm creating a thread that continuously sends (send()) samples to the
>>> DmaFIFO, and then I try to do the recv() until I get something, but I
>>> always get a timeout. It's like if the samples aren't flowing through the
>>> blocks, or like if I'm not doing the recv() right. Also, I'm getting a
>>> strange warning ([INFO] [RFNOC] No upstream blocks.) that I don't
>>> understand quite well in this context, does it have anything to do with the
>>> fact that I'm not using the radio cores? I have also tried to put a FIFO
>>> after the Gain block but I get pretty much the same result.
>>>
>>> I would appreciate any help or recommendations on how to achieve in C++
>>> this idea of Host TX -> RFNoC -> Host RX, is there something I am missing
>>> or should consider?
>>>
>>> I am using UHD-3.15.LTS on a X310, and GNU Radio 3.7. Everything is
>>> running on Ubuntu 16.04.
>>>
>>> Thanks in advance,
>>>
>>> Jorge
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>
> --
>
> <http://www.gradiant.org>
>
> Jorge Arroyo Giganto
>
> Becario | Área de Comunicaciones Avanzadas
>
> Intern | Advanced Communications Department
>
>
>
> jarr...@gradiant.org | <http://www.gradiant.org/>www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
> <https://es-es.facebook.com/GradiantCT/> [image: Iconos Redes Sociales
> GRD Firma email-02] <https://twitter.com/Gradiant> [image: Iconos Redes
> Sociales GRD Firma email-03] <https://www.linkedin.com/company/gradiant/>
> [image: Iconos Redes Sociales GRD Firma email-04]
> <https://www.youtube.com/gradiantct>
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
