Or, another option could be to add a null sink block to your build and connect one of the two radio ports to it. The problem with this is that you would need to dynamically re-link your graph each time you wanted to switch radio ports (connecting the unwanted port to the null sink and the desired port to the SplitStream). This may not be practical if you need to switch ports frequently / quickly. Rob
On Mon, Apr 12, 2021 at 11:44 AM Rob Kossler <[email protected]> wrote: > Hi Luca, > I don't think that there is a way to change the RF front end associated > with a given Radio block port - I think this is fixed (maybe someone can > correct me if I'm wrong on this). So, I think your graph will need to > include two Radio ports and that you will need an RF multiplexer capability > between the Radio and the SplitStream. In UHD 4.0 (RFNoC 4.0), there is > such a block (SwitchBoard) but I don't think that there is a corresponding > block for UHD 3.13. You could develop such a stand-alone RFNoC block > (perhaps using the SwitchBoard block as an example) or perhaps you could > modify the SplitStream block to have 2 inputs and a multiplexer capability. > Rob > > On Mon, Apr 12, 2021 at 10:47 AM Luca Oliva <[email protected]> wrote: > >> Hi Rob, >> >> the question is exactly that! Is there a way to change the radio channel >> between two receive? >> Il 12/04/21 16:00, Rob Kossler ha scritto: >> >> Hi Luca, >> You mentioned that you need to capture alternately from the two radio >> channels. Can you share the graph you are implementing (the graph below >> shows only 1 radio channel)? >> Rob >> >> On Mon, Apr 12, 2021 at 4:23 AM Luca Oliva <[email protected]> wrote: >> >>> Unfortunately I haven't enough FPGA resources to insert a DDC block. >>> >>> I've tried to issue the STREAM_MODE_NUM_SAMPS_AND_DONE command directly >>> to the Radio block and It seems to work, after a hundred of command the FFT >>> is still aligned to time domain capture. >>> >>> The problem now is that I need to capture alternately from the two radio >>> channels. >>> >>> As first test I've tried to connect statically the second output of the >>> Radio block to the SplitStream but It doesn't work. Receive fails with >>> timeout error. >>> >>> Luca >>> Il 08/04/21 03:25, Rob Kossler ha scritto: >>> >>> Is it possible (enough FPGA resources) for you to insert the DDC block >>> after the Radio in your graph and before the SplitStream? And, is your FFT >>> size small enough that you can set the Radio SPP equal to the FFT length? >>> If both of these are true, I think this will solve your issue. The DDC >>> block will then provide output packets that are exactly the length of the >>> FFT and there will be no residual samples at the end. >>> >>> I think it "should" be possible to get the "reset" to work, but I am not >>> certain. My plan of attack would be to wait until after flush and then set >>> fft_reset=1 and then fft_reset=0 and then reconfigure the fft with all >>> needed settings. But, if this doesn't work, I suppose that it is possible >>> that there is a FIFO (at the input of the FFT block or at the output of the >>> Radio or SplitStream block where the residual samples are "stuck". >>> >>> Finally, regarding the "Late" command, perhaps you could try to >>> "issue_stream_cmd" directly to the radio rather than to the rx_streamer. >>> When you call this function from the rx_streamer, the command propagates >>> upstream on the graph until it gets to the radio. But since you have a >>> SplitStream in your graph, maybe there is some bug in the propagation. I >>> think you could call this same function directly on the Radio controller >>> and it may solve the Late issue. >>> >>> Rob >>> >>> On Wed, Apr 7, 2021 at 12:39 PM Luca Oliva <[email protected]> wrote: >>> >>>> Hi Rob, >>>> >>>> Some update: >>>> >>>> 1) The ERROR_CODE_LATE_COMMAND error using >>>> STREAM_MODE_NUM_SAMPS_AND_DONE happens only if I put stream_now=false (I >>>> set time_spec with a future value obviously). >>>> >>>> 2) I've tried to set fft_reset=1 before STREAM_MODE_STOP_CONTINUOUS >>>> command, after it or after buffer flush but the problem is still present. >>>> >>>> Luca >>>> Il 06/04/21 14:58, Rob Kossler ha scritto: >>>> >>>> Hi Luca, >>>> I don't know the overall solution, but I have some comments about using >>>> the FFT block. I have never had success with this block unless I ensure >>>> that the block never receives a "partial FFT" block of samples. >>>> >>>> One way to ensure this is to use the DDC block (Radio->DDC->FFT) and >>>> you set the radio SPP equal to the FFT length. The only purpose of the DDC >>>> in this case is that it only processes "full packets" and discards the >>>> final "partial packet". Thus, it will ensure that the FFT also receives >>>> only full packets. >>>> >>>> Another way to ensure this is to use the NUM_SAMPS_AND_DONE you >>>> mentioned. As long as this number is a multiple of the FFT size, it should >>>> be fine for the FFT block. I'm not sure why you were getting the Late >>>> error. >>>> >>>> When you use CONTINUOUS mode, you are basically ensuring that the FFT >>>> will work fine the first time but then partially fill with the trailing >>>> samples. The next time you start, the FFT block will complete the filling >>>> process, but your data will be misaligned. Perhaps you could use the >>>> "fft_reset" functionality to reset the block every time but this will >>>> likely mean that you need to re-configure the FFT length, scale, direction, >>>> etc. >>>> Rob >>>> >>>> On Tue, Apr 6, 2021 at 6:31 AM Luca Oliva <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I've an Ettus E310 with UHD 3.13.1.0 >>>>> >>>>> >>>>> I need to receive some samples both in time domain than frequency >>>>> domain. I’m trying to do that using this rfnoc graph: >>>>> >>>>> +---------+ +--------------+ >>>>> | | | |---------------------> RxStreamer >>>>> Ch 0 >>>>> | Radio |------->| SplitStream | +-------+ >>>>> | | | |------>| FFT |-----> RxStreamer >>>>> Ch 1 >>>>> +---------+ +--------------+ +-------+ >>>>> >>>>> >>>>> uhd::rfnoc::block_id_t radio_ctrl_id(0, "Radio", 0); >>>>> uhd::rfnoc::block_id_t split_ctrl_id(0, "SplitStream", 0); >>>>> uhd::rfnoc::block_id_t fft_ctrl_id(0, "FFT", 0); >>>>> >>>>> uhd::rfnoc::source_block_ctrl_base::sptr fft_blk_ctrl = >>>>> >>>>> m_Usrp->get_block_ctrl<uhd::rfnoc::source_block_ctrl_base>(fft_ctrl_id); >>>>> >>>>> m_RadioCtrl = m_Usrp->get_block_ctrl< uhd::rfnoc::radio_ctrl >>>>> >(radio_ctrl_id); >>>>> m_RadioCtrl->set_rate(16e6); >>>>> m_RadioCtrl->set_arg<int>("spp", 2048); >>>>> fft_blk_ctrl->set_arg<int>("spp", 2048); >>>>> >>>>> m_Usrp->clear(); >>>>> >>>>> m_Graph = m_Usrp->create_graph("rfnoc_rx"); >>>>> m_Graph->connect(radio_ctrl_id, 0, split_ctrl_id, 0); >>>>> m_Graph->connect(split_ctrl_id, 1, fft_ctrl_id, 0); >>>>> >>>>> uhd::device_addr_t streamer_args(""); >>>>> streamer_args["block_id0"] = split_ctrl_id.to_string(); >>>>> streamer_args["block_port0"] = str(boost::format("%d") % 0); >>>>> streamer_args["block_id1"] = fft_ctrl_id.to_string(); >>>>> streamer_args["block_port1"] = str(boost::format("%d") % 0); >>>>> >>>>> uhd::stream_args_t stream_args_fc32("sc16", "sc16"); >>>>> stream_args_fc32.channels = { 0, 1 }; >>>>> stream_args_fc32.args = streamer_args; >>>>> stream_args_fc32.args["spp"] = boost::lexical_cast<std::string>(2048); >>>>> m_RxStreamerFc32 = m_Usrp->get_rx_stream(stream_args_fc32); >>>>> >>>>> I need to receive a burst in a precise moment, elaborate it and >>>>> restart >>>>> on a different frequency (I need also to change radio channel because >>>>> I've two different antennas). >>>>> >>>>> I've tried >>>>> >>>>> uhd::stream_cmd_t >>>>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); >>>>> stream_cmd.num_samps = size_t(nBurstLen*MAX_DIM_SAMPLES_FRAME_FOR_RSA); >>>>> stream_cmd.stream_now = false; >>>>> stream_cmd.time_spec = m_RadioCtrl->get_time_now()+1.0; >>>>> m_RxStreamerFc32->issue_stream_cmd(stream_cmd); >>>>> >>>>> but the receive fails with ERROR_CODE_LATE_COMMAND. >>>>> >>>>> I've tried issuing the STREAM_MODE_START_CONTINUOUS command and it >>>>> seems >>>>> to work correctly until I don't send a STREAM_MODE_STOP_CONTINUOUS >>>>> command. >>>>> >>>>> After a STREAM_MODE_STOP_CONTINUOUS command I flush the buffer with a >>>>> receive loop: >>>>> >>>>> while(m_RxStreamerFc32->recv(buff, 2048, uselessMd, 0.010, false)); >>>>> >>>>> The problem I'm observing is that since second start the FFT samples >>>>> lost alignment with the time samples and after some stop and start the >>>>> receive fails often with Overflow errors and than stops definitely to >>>>> work with Timeout errors >>>>> >>>>> Someone else have this problem? >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Luca >>>>> >>>>> >>>>> LEGAL DISCLAIMER: >>>>> The contents of this email and any transmitted files are confidential >>>>> and intended solely for the use of the individual or entity to whom they >>>>> are addressed. We hereby exclude any warranty and any liability as to the >>>>> quality or accuracy of the contents of this email and any attached >>>>> transmitted files. If you are not the intended recipient, be advised that >>>>> you have received this email in error and that any use, dissemination, >>>>> forwarding, printing or copying of this email is strictly prohibited. If >>>>> you have received this email in error please contact the sender and delete >>>>> the material from any computer. >>>>> _______________________________________________ >>>>> USRP-users mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> -- >>>> *ing. Luca Oliva* >>>> Senior Developer Engineer >>>> >>>> [image: Intecs Solutions S.p.A.] >>>> >>>> *Intecs Solutions S.p.A.* >>>> Via Ferrante Imparato 198 >>>> Isola F - 80146 Napoli - Italy >>>> Phone: +39 081 19718400 >>>> email: [email protected] >>>> >>>> LEGAL DISCLAIMER: The contents of this email and any transmitted files >>>> are confidential and intended solely for the use of the individual or >>>> entity to whom they are addressed. We hereby exclude any warranty and any >>>> liability as to the quality or accuracy of the contents of this email and >>>> any attached transmitted files. If you are not the intended recipient, be >>>> advised that you have received this email in error and that any use, >>>> dissemination, forwarding, printing or copying of this email is strictly >>>> prohibited. If you have received this email in error please contact the >>>> sender and delete the material from any computer. >>>> >>> -- >>> *ing. Luca Oliva* >>> Senior Developer Engineer >>> >>> [image: Intecs Solutions S.p.A.] >>> >>> *Intecs Solutions S.p.A.* >>> Via Ferrante Imparato 198 >>> Isola F - 80146 Napoli - Italy >>> Phone: +39 081 19718400 >>> email: [email protected] >>> >>> LEGAL DISCLAIMER: The contents of this email and any transmitted files >>> are confidential and intended solely for the use of the individual or >>> entity to whom they are addressed. We hereby exclude any warranty and any >>> liability as to the quality or accuracy of the contents of this email and >>> any attached transmitted files. If you are not the intended recipient, be >>> advised that you have received this email in error and that any use, >>> dissemination, forwarding, printing or copying of this email is strictly >>> prohibited. If you have received this email in error please contact the >>> sender and delete the material from any computer. >>> >> -- >> *ing. Luca Oliva* >> Senior Developer Engineer >> >> [image: Intecs Solutions S.p.A.] >> >> *Intecs Solutions S.p.A.* >> Via Ferrante Imparato 198 >> Isola F - 80146 Napoli - Italy >> Phone: +39 081 19718400 >> email: [email protected] >> >> LEGAL DISCLAIMER: The contents of this email and any transmitted files >> are confidential and intended solely for the use of the individual or >> entity to whom they are addressed. We hereby exclude any warranty and any >> liability as to the quality or accuracy of the contents of this email and >> any attached transmitted files. If you are not the intended recipient, be >> advised that you have received this email in error and that any use, >> dissemination, forwarding, printing or copying of this email is strictly >> prohibited. If you have received this email in error please contact the >> sender and delete the material from any computer. >> >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
