Agree with Rob here. The purpose of the tune request to the graph is to avoid both steps 2 and 4 and replace it with something more familiar to people coming from the multi_usrp world.
Maybe a general comment on the RFNoC API is useful here: With RFNoC, you get a much more fine-grained control over all components in your system (and most importantly, you can choose those components yourself). However, the flip side is that you lose some of the convenience functions that you can offer if you're using the multi_usrp API. At the risk of sounding defensive, in your case, you have 5 components with configurable frequencies that you need to set: One radio (controlling the LO frequency), and 4 DUCs (with digital frequency shifters). That translates into exactly 5 API calls to set each frequency. Because you have a special type of application (four DUC outputs summed into one RF input), it is not something that the RFNoC API can auto-magically set up for you. Or to put it differently, if you want an API call that auto-sets all 5 frequencies at the same time, then you need to provide that logic yourself, the same way that UHD provides logic to convert a tune request into a digital (DUC/DDC) tune, and an analog tune (LO). But the RFNoC API provides exactly the APIs to set your 5 different frequencies to 5 different components in 5 API calls -- that seems reasonable to me. --M On Wed, May 21, 2025 at 10:08 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > I think that some of the convenience mechanisms that you might see in the > examples (such as passing a tune request through the streamer) are likely > only helpful in a "typical" graph. In your graph with 4 DUC ports connected > to 1 Radio port with AddSub blocks to add the 4 DUC ports together, it is > not a 1-to-1 relationship between DUC and Radio. > > It seems to me that your step 3 below is not needed or helpful. It seems > you could set the LO frequency via the Radio block. But, this will be > quantized and not necessarily at the exact frequency you request. Thus, if > it is important to get the right frequency, you will need to use the return > value from the radio->set_tx_frequency function to determine your > quantization error. Then, you can call duc->set_freq for your DUC ports > with a frequency argument that includes both your desired values of -10, > -5, 5, 10 MHz as well as the quantization error you determined setting the > LO. > Rob > > On Wed, May 21, 2025 at 10:45 AM <carmix...@gmail.com> wrote: > >> Yes Martin, for example I’m working on a X310+UBX160 with a multichannel >> DUC that has 4 inputs each one with a different frequency offset and then i >> sum the outputs with the addsub rfnoc block(I generated the FPGA firmware >> accordingly). >> >> Actually I managed to have it work correctly but I had to discover by >> myself some oddities, the correct steps in my configuration are in order: >> >> 1-configure the graph according to my needs (radio_control, duc, streamer) >> >> 2-set the RF output frequency on the radio control >> >> 3-make the tune request through the streamer >> >> 4-set the desired frequency offset on the DUC (for example: -10e6, -5e6, >> 5e6, 10e6) >> >> The last step is the more critical, in order to get the exact offset I >> had first to get the starting frequency offset of the DUC (which is not >> zero after the tune request, but just on the first channel of the DUC!!!) >> and then to sum up that residual frequency offset (which actually counts >> few kHz) to the desired frequency offset. >> >> If I miss this step it won’t have the exact offset needed. >> >> It seems to me a bit clumsy, is there a cleaner way to do it? >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
