usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsX310 transmit multi streams on single radio channel
Hi, I’m developing a solution on X310+UBX160 SDR, the solution is the one depicted in the picture:
I have 4 streams at 2MHz bandwidth each, but they are spaced each other of 35 MHz around F0 so that the total frequency span is around 140MHz. Now I have to transmit these signals on a single X310 channel and 140MHz is well inside the 160MHz bandwidth. However I would like to save network bandwidth and computing power and transmit to the radio just the four streams @ 2MHz, for a total bandwidth of 8MHz. What is the best solution according to you? I’m thinking of using RFNoC, using for example 4 SEP and merging/shifting the signals inside the Radio, is it the correct path? Can I combine existing RFNoCs to obtain such a result or should I have to develop it on my own?
Thank you in advance for your support,
John
Hi John,
I think you will need to build your own RFNoC image, but you could probably
do it with stock blocks such that you don't need to develop a new block.
If you built a 4-channel DUC with each input tied to an SEP (as you
suggested) and each output tied to inputs of AddSub blocks. You would need
3 such addsub blocks - two to handle the 4 outputs of the DUC and then one
additional to add the 2 AddSub blocks and send the result to the radio.
The AddSub blocks would automatically synchronize the streams.
Just as a caution, in my experience when combining multiple streams (as
done with the AddSub block), the graph can get blocked if the streams don't
always have the same number of samples. For example, let's say you start
transmitting on all four streams but then you later stop them sequentially
such that the total trailing number of samples on each stream is unequal.
Then, these samples will be left in the queue waiting at the AddSub for the
next transmit and thus cause the subsequent transmit to be misaligned.
Rob
On Wed, Mar 12, 2025 at 3:33 AM carmixdev@gmail.com wrote:
Hi, I’m developing a solution on X310+UBX160 SDR, the solution is the one
depicted in the picture:
I have 4 streams at 2MHz bandwidth each, but they are spaced each other of
35 MHz around F0 so that the total frequency span is around 140MHz. Now I
have to transmit these signals on a single X310 channel and 140MHz is well
inside the 160MHz bandwidth. However I would like to save network bandwidth
and computing power and transmit to the radio just the four streams @ 2MHz,
for a total bandwidth of 8MHz. What is the best solution according to you?
I’m thinking of using RFNoC, using for example 4 SEP and merging/shifting
the signals inside the Radio, is it the correct path? Can I combine
existing RFNoCs to obtain such a result or should I have to develop it on
my own?
Thank you in advance for your support,
John
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Thank you for your answer,
I’m following your directions and I’m creating the yaml file with the relevant elements in it, however since it is the first time that I create such a file I’m facing some difficulties:
-The 4 port DUC will need 4 new endpoints right?
-all the addsub blocks that are internal do not need an endpoint, so I imagine that i can connect them statically in the connections section (or it would be better to have them dinamically connected?)
-The diff ports of addsub block will not be connected, i think i should connect them to a Null Source Sink Block, right?
-I noticed that on old tutorials there was a python tool that helped in the creation of yaml files, why it isn’t available anymore?
-I’m using GNUradio to design a sample system, however I noticed that when I use RFNoC blocks I can only generate python and not C++, is it normal? that means that if I go on with the project, since I use C++ I will have to migrate to UHD and dismiss GNUradio?
Thank you for you kind support
On Fri, Mar 14, 2025 at 5:57 AM carmixdev@gmail.com wrote:
Thank you for your answer,
I’m following your directions and I’m creating the yaml file with the
relevant elements in it, however since it is the first time that I create
such a file I’m facing some difficulties:
-The 4 port DUC will need 4 new endpoints right?
Yes. But, the I later realized that the typical X310 yaml files already
include 4 DUC ports (2 ports in each of 2 DUC blocks), so you could just
use those as shown in the example
"rfnoc-gain/icores/x310_rfnoc_image_core.yaml" without having to add a
4-port DUC.
-all the addsub blocks that are internal do not need an endpoint, so I
imagine that i can connect them statically in the connections section (or
it would be better to have them dinamically connected?)
Either way is fine. Dynamic connections require more SEP, but allow you
more flexibility (e.g., if you wanted to only have 2 streaming sources
combined, you could reconfigure the graph to only have 1 addsub block at
the DUC outputs, whereas if you statically connect, I think you will always
need 4 streaming sources)
-The diff ports of addsub block will not be connected, i think i should
connect them to a Null Source Sink Block, right?
This seems correct, but I don't have any experience using the Null Source
Sink.
-I noticed that on old tutorials there was a python tool that helped in
the creation of yaml files, why it isn’t available anymore?
Not sure. But, if you start with the example x310 icore yaml mentioned
above, it is not too hard to modify it to add three "addsub" blocks and
make the connections.
-I’m using GNUradio to design a sample system, however I noticed that when
I use RFNoC blocks I can only generate python and not C++, is it normal?
that means that if I go on with the project, since I use C++ I will have to
migrate to UHD and dismiss GNUradio?
I don't know gnuradio well. I didn't even know that gnuradio could
generate C++. I thought that gnuradio was always Python (for the flow graph
portion). But, I would check with the gnuradio list for this question. I
will mention that if you want to use C++ directly with UHD for your
specific scenario, it would not be too difficult. But, if you need to
later add things like signal processing that are available in gnuradio, you
might want to stick with gnuradio.
One more thing. I would start as small as possible. Just add one addsub
block and one null src sink and see if you can get it working with 2 tx
streams.
On Fri, Mar 14, 2025 at 10:06 AM Rob Kossler rkossler@nd.edu wrote:
On Fri, Mar 14, 2025 at 5:57 AM carmixdev@gmail.com wrote:
Thank you for your answer,
I’m following your directions and I’m creating the yaml file with the
relevant elements in it, however since it is the first time that I create
such a file I’m facing some difficulties:
-The 4 port DUC will need 4 new endpoints right?
Yes. But, the I later realized that the typical X310 yaml files already
include 4 DUC ports (2 ports in each of 2 DUC blocks), so you could just
use those as shown in the example
"rfnoc-gain/icores/x310_rfnoc_image_core.yaml" without having to add a
4-port DUC.
-all the addsub blocks that are internal do not need an endpoint, so I
imagine that i can connect them statically in the connections section (or
it would be better to have them dinamically connected?)
Either way is fine. Dynamic connections require more SEP, but allow you
more flexibility (e.g., if you wanted to only have 2 streaming sources
combined, you could reconfigure the graph to only have 1 addsub block at
the DUC outputs, whereas if you statically connect, I think you will always
need 4 streaming sources)
-The diff ports of addsub block will not be connected, i think i should
connect them to a Null Source Sink Block, right?
This seems correct, but I don't have any experience using the Null Source
Sink.
-I noticed that on old tutorials there was a python tool that helped in
the creation of yaml files, why it isn’t available anymore?
Not sure. But, if you start with the example x310 icore yaml mentioned
above, it is not too hard to modify it to add three "addsub" blocks and
make the connections.
-I’m using GNUradio to design a sample system, however I noticed that
when I use RFNoC blocks I can only generate python and not C++, is it
normal? that means that if I go on with the project, since I use C++ I will
have to migrate to UHD and dismiss GNUradio?
I don't know gnuradio well. I didn't even know that gnuradio could
generate C++. I thought that gnuradio was always Python (for the flow graph
portion). But, I would check with the gnuradio list for this question. I
will mention that if you want to use C++ directly with UHD for your
specific scenario, it would not be too difficult. But, if you need to
later add things like signal processing that are available in gnuradio, you
might want to stick with gnuradio.
On Fri, Mar 14, 2025 at 10:57 AM carmixdev@gmail.com wrote:
Thank you for your answer,
I’m following your directions and I’m creating the yaml file with the
relevant elements in it, however since it is the first time that I create
such a file I’m facing some difficulties:
-The diff ports of addsub block will not be connected, i think i should
connect them to a Null Source Sink Block, right?
Yes. We could build an AddSub block that has an optional diff-port, but
it's meant to be an easy example so we won't burden it with features like
that. In your case, it would be more optimal to have a single four-port
adder block, but we don't have that in stock UHD. So your approach is
probably fine.
-I noticed that on old tutorials there was a python tool that helped in
the creation of yaml files, why it isn’t available anymore?
That was for UHD 3. For UHD 4 (and the now-current version of RFNoC), the
complexity of the YAML files went way up, so the graphical tool from UHD 3
was no longer feasible. However, we're enabling building bitfiles from GNU
Radio, that will become the replacement for this feature.
-I’m using GNUradio to design a sample system, however I noticed that when
I use RFNoC blocks I can only generate python and not C++, is it normal?
that means that if I go on with the project, since I use C++ I will have to
migrate to UHD and dismiss GNUradio?
Sadly, yes. If we get requests for adding C++ support for code gen from
GRC, we will prioritize it. For now we're focusing on a smaller feature set
that works well, so we're leaving out the "less popular" things. That said,
we have to make a guess what they are so comments like this are valuable
input.
--M
Thank you for your hints. Actually I implemented such configuration and it seems to work too :D, the signal is sum up and then transmitted.
I have some issues that I would like to understand how to fix:
-The input signal to every streamer is int16, now since the samples coming from the 4 streamers of each channel are sum up, do you think that I have to divide the IQ signal value by 4 in order to avoid clipping, or is there any auto scaling inside?
-I don’t know how to fine tuning the RF frequency. Normally I would send a tune request with txstreamer->post_output_action() method, but in this case I get an error which is telling me that “cannot forward action tune_request from TxSteramer#0:OUTPUT_EDGE:0, no neighbour found!”
Could you help me with that?