> > In the rfnoc_rx_to_file program, > > streaming is started by the function rx_stream->issue_stream_cmd(). Note > > that this is a command to the streamer which then must be forwarded to the > > gain controller and then the ddc controller and then the radio controller > > which will then turn on the radio. > > I have a question regarding that statement. > Since the gain block and the radio+ddc are on different EP, > wouldn't the rx_streamer able to transfer that command to the radio > without forwarding it to the gain block? > I do not know the type of issue_stream_cmd. > From the RFNoC Specification, it is stated that it is an "Action", > "calling into API provided by the graph". > It is also stated that it "propagates". But it does not specify > in which case it does or not and how it does it.
I don't think it matters about the different EP. Once the "graph" is constructed, the propagation goes from node to node. But, I don't really understand it well, so I can't comment on it. > > So, one question I have is: does the command make it to the radio? I think > > that you can tell by looking at the LED - does it turn on? > > > > - If so, then I am on the wrong path. > > - If not, then > > - Maybe there is some setting in the gain block controller that is > > not forwarding the command. > > - Or, more likely, maybe the gain block controller is not being used > > at all because of the block finding issue "block#0" vs "gain#0". In > > this > > case, perhaps building the gain block controller in-tree would help > > You are right! > The LED does not turn on when putting the gain block > (Radio -> DDC -> Gain -> rx_streamer). > So it seems that the stream_cmd is not forwarded... But why? > > You said that I could try to build the controller in-tree. > I would like to avoid that. > Could I issue_stream_cmd on the radio_ctrl instead of rx_streamer? > How would it work with multiple radios (like in the X310)? I think you could issue the stream command on either the DDCs or the Radios and it should work. I would suggest the DDCs which will then forward the commands to the radio. It should work fine with multiple radios. If you need them to start synchronously, then it will still work so long as you have a common start time for all radios which will each hold off the start of streaming until the specified time. Also, regarding building in-tree, are you opposed to building in-tree as even a temporary test case? It's not too difficult to do. I am not talking about the FPGA code - just the block controller HPP / CPP. > On a side note: > Are we forced to implement a custom controller for each RFNoC block? > I was expecting that I could just write the verilog part > and use the basic noc_block_base controller to manage my blocks in C++, > using regs()->peek32/poke32 to set my registers etc. > But from above, it seems that it does not forward the issue_stream_cmd > by default? Is that correct? As far as I understand, we presently need a custom controller for each RFNoC block. But, I'm not positive. This has been one area where the rollout for RFNoC 4.0 has not been smooth. You should be able to do just as you intended, but I'm not sure that UHD 4.0 is ready for that such that in the meantime, you might be better off building custom controllers. That said, I don't think that the command forwarding is disabled by default. Honestly, I don't know what is the issue and I am just guessing. But, I didn't need to do anything special with my blocks and I am not seeing the issue. On the other hand, I did build a custom block controller for each and so maybe that is related to the problem.... > > > Also, it might help if you turn on "debug" logging (export > > UHD_LOG_LEVEL=debug; export UHD_LOG_CONSOLE_LEVEL=debug) and run the > > rfnoc_rx_to_file example. First try with a working block such as FFT and > > then with the gain block and see if there are any clues. > > Rob > > I attached 3 logs: > - normal.log is (Radio -> DDC -> rx_streamer) > - fft.log is (Radio -> DDC -> fft -> rx_streamer) > - gain.log is (Radio -> DDC -> gain -> rx_streamer) > > I just had to specify "--spp 256" to match the default FFT size > (otherwise I get overrun). I looked at the log files but nothing there. It is possible that we would need "trace" level logging to see anything useful. But, that may require a re-build of UHD with the appropriate command to enable trace debugging. _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
