I'm trying with a custom Mux block.
+---------+ +-----+ +--------------+
| |------->| | | |--------------------->
RxStreamer Ch 0
| Radio | | Mux |------->| SplitStream | +-------+
| |------->| | | |------>| FFT |----->
RxStreamer Ch 1
+---------+ +-----+ +--------------+ +-------+
If I configure the Mux to use the first channel, it works correctly.
If I configure the second channel the issue comand on radio_ctrl fails
for "radio_ctrl_impl::issue_stream_cmd() called on inactive". I've fixed
this with "RadioCtrl->set_rx_streamer(true, 1);", but after some minutes
the receive stops to work with error "EnvironmentError: IOError: Block
ctrl (CE_00_Port_10) packet parse error - EnvironmentError: IOError:
Expected SID: 02:10>00:00 Received SID: 02:11>ff:ff"
In Mux code I've put a noc_shell with 2 input_ports and an axi_wrapper.
I've muxed the link bteween noc_shell and axi_wrapper in this way:
assign sel_str_sink_tdata = channel ? str_sink_tdata[127:64] :
str_sink_tdata[63:0];
assign sel_str_sink_tlast = channel ? str_sink_tlast[1] :
str_sink_tlast[0];
assign sel_str_sink_tvalid = channel ? str_sink_tvalid[1] :
str_sink_tvalid[0];
assign str_sink_tready[0] = ( channel == 0 ) ? sel_str_sink_tready : 1;
assign str_sink_tready[1] = ( channel == 1 ) ? sel_str_sink_tready : 1;
On the other side of axi_wrapper I've loop backed data in this way:
assign m_axis_data_tready = s_axis_data_tready;
assign s_axis_data_tvalid = m_axis_data_tvalid;
assign s_axis_data_tlast = m_axis_data_tlast;
assign s_axis_data_tdata = m_axis_data_tdata;
Luca
Il 12/04/21 23:02, EJ Kreinar ha scritto:
I've fought similar problems before. Rfnoc < UHD 4.0 has trouble
arbitrarily propagating downstream connections ports back to the radio
in some edge cases.
I think the use case I had was trying to attach either channel (0 or
1) to a single channel ddc... A few years back I put out a "hack" PR
that swaps the radio channel behind the scenes, while keeping the
output port the same: https://github.com/EttusResearch/uhd/pull/164
<https://github.com/EttusResearch/uhd/pull/164>
You may be able to work around it with a custom router block as Rob
suggested... Attach both ports back to the radio, then provide a hook
inside the user code to mux in the channel you want to use? That might
actually avoid the edge case I hacked around, because you would have
both radio channels attached at the time you issue the stream command,
so both channels would start streaming then. Sounds possible but may
need to test it and inspect the UHD source to see for sure.
EJ
On Mon, Apr 12, 2021, 11:50 AM Rob Kossler <[email protected]
<mailto:[email protected]>> wrote:
Or, another option could be to add a null sink block to your build
and connect one of the two radio ports to it. The problem with
this is that you would need to dynamically re-link your graph each
time you wanted to switch radio ports (connecting the unwanted
port to the null sink and the desired port to the SplitStream).
This may not be practical if you need to switch ports frequently /
quickly.
Rob
On Mon, Apr 12, 2021 at 11:44 AM Rob Kossler <[email protected]
<mailto:[email protected]>> wrote:
Hi Luca,
I don't think that there is a way to change the RF front end
associated with a given Radio block port - I think this is
fixed (maybe someone can correct me if I'm wrong on this). So,
I think your graph will need to include two Radio ports and
that you will need an RF multiplexer capability between the
Radio and the SplitStream. In UHD 4.0 (RFNoC 4.0), there is
such a block (SwitchBoard) but I don't think that there is a
corresponding block for UHD 3.13. You could develop such a
stand-alone RFNoC block (perhaps using the SwitchBoard block
as an example) or perhaps you could modify the SplitStream
block to have 2 inputs and a multiplexer capability.
Rob
On Mon, Apr 12, 2021 at 10:47 AM Luca Oliva
<[email protected] <mailto:[email protected]>> wrote:
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]
<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]
