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