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. >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
