Dear all,thank you for the explanations. I don't think it is possible to mix USRP with RFNoC radio sources, but it seams that the RFNoC RX Radio Block can be triggered to issue a start-stream command via it's message port (I cannot find any documentation about this, but the source code suggest it [1]). However, the RFNoC Rx Streamer Block will always issuing a start-stream command independently, since it is hardcoded.
I went ahead and wired the time_spec parameter from the RX-Streamer implementation though to GNU Radio GUI. The first test looks promising, with a time_spec of 1s the RFNoC stream is started 1s delayed and that seams to indeed reduce the loopback latency and also keep it reproducible with the flow graph below. I also added an option to disable the start stream command altogether, so I can test starting the stream via the message port of the RX Radio instead.
I have opened a PR for the changes, see https://github.com/gnuradio/gnuradio/pull/6922
Best regards and thank you very much for your help Philipp[1] https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/lib/rfnoc_rx_radio_impl.cc#L164
grafik ------------------------------------------------------------------------ *From:* Rob Kossler [mailto:rkoss...@nd.edu] *Date:* Tuesday, October 17, 2023 at 18:36 UTC+2 *Subject:* [USRP-users] Re: RFNoC Loopback with stream from host
On Tue, Oct 17, 2023 at 9:20 AM Philipp Niedermayer <p.niederma...@gsi.de> wrote:Dear Marcus and Rob,The multi_usrp UHD "sink" in Gnu Radio has a "start time" parameter. But I'm not sure how this works when you're using RFNoC from within Gnu Radio.@Marcus: I think for RFNoC it is the RX-Streamer that issues the start command. The C++ implementation [1] has a method to set the start time, but it is neither exposed via the Python bindings [2], nor to GNU Radio [3]. Would it be possible to update the bindings?Delaying the Rx Radio start time should be relatively easy to do. While I don't know how to do this from gnuradio, I do it all the time using UHD from C++. Perhaps you will have to modify the GRC generated python to do it rather than do it from GRC - not really sure.@Rob: What methods are you using to delay the start time? The same as the RX-Streamer [1] uses internally? I tried calling the RX-streamers "start" and "stop" methods, since these are accessible from python. Stopping works, but when re-starting it gives me OOOOOOOO (see below).Yes, I use the issue_stream_cmd() function. I am not sure why your start and stop produce the behavior you described, but I want to mention a few things about how this works in UHD under-the-hood. 1) There is an issue_stream_cmd() available not only on rx_streamer but on the radio block as well. The radio block is derived from usrp_source in gnuradio I think (see here <https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html>) 2) The way it normally works in UHD is you call issue_stream_cmd on the rx_streamer. Then the block controller propagates this cmd to the next upstream block controller in the graph. This might normally be the DDC. The DDC block then might use this information (such as the timestamp) internally and then it propagates this cmd to the next upstream block controller. Finally, it reaches the radio block controller which then controls the radio to start streaming at the desired time. In this way, all of the blocks in the chain are aware of the impending streaming. But, that said, it is also possible to call issue_stream_cmd directly on the radio block controller and it will start streaming. The only difference is that the other blocks in the chain will be unaware of the impending streaming. The fact that you are getting streaming at all is a good indication that your custom block controllers are appropriately propagating the issue_stream_cmd. 3) If your graph was just a "repeater path" and did not include the rx_streamer, you would have to call issue_stream_cmd using the radio block 4) When you stop and restart your graph and you get overflows, is it possible that the overflow is occurring because the data path is blocked at the multiply - perhaps the tx_streamer data is not flowing for some reason? If so, this would cause the Overflows.[2] https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/python/uhd/bindings/rfnoc_rx_streamer_python.cc [3] https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/grc/uhd_rfnoc_rx_streamer.block.ymlOn Tue, Oct 17, 2023 at 9:20 AM Philipp Niedermayer <p.niederma...@gsi.de> wrote:Dear Marcus and Rob,The multi_usrp UHD "sink" in Gnu Radio has a "start time" parameter. But I'm not sure how this works when you're usingRFNoC from within Gnu Radio.@Marcus: I think for RFNoC it is the RX-Streamer that issues the start command. The C++ implementation [1] has a method to set the start time, but it is neither exposed via the Python bindings [2], nor to GNU Radio [3]. Would it be possible to update the bindings?Delaying the Rx Radio start time should be relatively easy to do. While I don't know how to do this from gnuradio, I do it all the time using UHD from C++. Perhaps you will have to modify the GRC generated python to do it rather than do it from GRC - not really sure.@Rob: What methods are you using to delay the start time? The same as the RX-Streamer [1] uses internally? I tried calling the RX-streamers "start" and "stop" methods, since these are accessible from python. Stopping works, but when re-starting it gives me OOOOOOOO (see below). Best Philipp [1] https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/lib/rfnoc_rx_streamer_impl.cc#L83-L93 [2] https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/python/uhd/bindings/rfnoc_rx_streamer_python.cc [3] https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/grc/uhd_rfnoc_rx_streamer.block.yml ******* MESSAGE DEBUG PRINT ******** ((rate_now . 1.99964e+06) (rate_avg . 1.99964e+06)) ************************************ Stopping stream rfnoc_rx_streamer :debug: UHD recv() call timed out. ******* MESSAGE DEBUG PRINT ******** ((rate_now . 666323) (rate_avg . 1.79964e+06)) ************************************ rfnoc_rx_streamer :debug: UHD recv() call timed out. rfnoc_rx_streamer :debug: UHD recv() call timed out. Starting stream rfnoc_rx_streamer :debug: Sending start stream command... OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO >>> Done ------------------------------------------------------------------------ *From:* Marcus D. Leech [mailto:patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>] *Date:* Monday, October 16, 2023 at 23:41 UTC+2 *Subject:* [USRP-users] Re: RFNoC Loopback with stream from hostOn 16/10/2023 17:31, Rob Kossler via USRP-users wrote:Hi Philipp, 1. Delaying the Rx Radio start time should be relatively easy to do. While I don't know how to do this from gnuradio, I do it all the time using UHD from C++. Perhaps you will have to modify the GRC generated python to do it rather than do it from GRC - not really sure.The multi_usrp UHD "sink" in Gnu Radio has a "start time" parameter. But I'm not sure how this works when you're using RFNoC from within Gnu Radio. _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
