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]
<mailto:[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]
<mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
--
*ing. Luca Oliva*
Senior Developer Engineer
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] <mailto:[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]
