Hi Philipp, One more comment. It would be possible for you to block the stream command propagation from the rx_streamer to the radio in your original graph since you have the custom pulse counter block. The custom block controller could just discard rather than propagate this command to the radio. Perhaps not the best solution, but wanted to mention. Rob
On Wed, Oct 18, 2023 at 8:31 AM Philipp Niedermayer <p.niederma...@gsi.de> wrote: > 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 > > [image: grafik] > ------------------------------ > *From:* Rob Kossler [mailto:rkoss...@nd.edu <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.yml > > > > > 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). >> >> 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 >> <patchvonbr...@gmail.com>] >> *Date:* Monday, October 16, 2023 at 23:41 UTC+2 >> *Subject:* [USRP-users] Re: RFNoC Loopback with stream from host >> >> On 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 >> >>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
