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 <rkoss...@nd.edu> wrote: > > On Fri, Mar 14, 2025 at 5:57 AM <carmix...@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. > >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
