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]
<mailto:[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]
<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.
--
*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]
