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