Hello Dragoslav, What you are seeing is expected and correct. With the multi_usrp interface the set_tx_freq function does a series of actions for you.
1) Calculate a target RF frequency, taking into account any LO offset requested 2) Call a function to set the RF frequency to this target and then read back the actual frequency 3) Call a function on the DDC to account for the difference between the user requested frequency and the actual RF frequency The important thing to note is that the DDC frequency shift will be the combination of the LO offset and the frequency error of the RF tuning. This frequency error can occur for a number of reasons usually based on limitations in the frequency synthesizer and sometimes because of decisions built into the code to improve system performance. When using the RFNoC workflow you'll have to replicate the above three steps because you have manual control over the Radio and DDC blocks. Tune the Radio block first then use the results of that to compensate using the DDC. Regards, Derek On Thu, Nov 2, 2017 at 3:17 PM, Dragoslav Stojadinovic via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > I have been trying to set LO offset while using an RFNoC device, and I > have encountered 2 separate problems with it. > > Specifically, I create a standard uhd::usrp::multi_usrp object, and then > get device3::sptr from it. I set the TX graph in the following way: DUC -> > radio_ctrl, and the RX graph is radio_ctrl->DDC->custom_block. > > The first problem is setting the LO offset. The only way I know of doing > this is by calling set_tx_freq with a uhd::tune_request_t(freq, lo_offset) > as an argument. However, this did not work in my case. It works perfectly > when using clean UHD, but with RFNoC I don't get consistent behavior, and > it seems most of the time I will just get no LO offset and central > frequency set to freq + lo_ffset. Is this a known problem? Is there a way > to set the LO offset with RFNoC? Is there a specific RFNoC block that I > would need to use to set this? > > The second problem is the actual central frequency, when setting it simply > as set_tx_freq(freq) - where freq is a double, or set_tx_frequency (a > method of device3 instead of multi_usrp). These both work in exactly the > same fashion, which is fine, however - with some frequencies simply not > being set very precisely. Here, the results I get are very consistent, > always the same, and the precision of the frequency I get depends on the > frequency I request. For example, when I request 1 GHz, I get exactly 1 > GHz. When I request 992.5 MHz, I get ~ 992.498 which is approximately 2 kHz > below the frequency I requested. Depending on the frequency I request, the > actual frequency will be up to 5 kHz below (or above). This happened across > multiple different RFNoC bitstreams, both the ones provided by Ettus and > custom ones, and both with using integer and fractional dividers, the > values I get were always exactly the same and it only happens with RFNoC - > with standard UHD I consistently always get the exact frequency I requested > (maybe up to a couple of Hz off, but that is really negligible). Is this a > known issue, am I doing something wrong? Is there something I can do to get > a more precise actual frequency with RFNoC? > > Thank you in advance! > > Regards, > Dragoslav Stojadinovic > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
