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
