[USRP-users] Setting LO offset and exact central frequency with RFNoC

Derek Kozel derek.kozel at ettus.com
Fri Nov 3 12:46:11 EDT 2017


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 at 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 at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171103/4cc99805/attachment-0002.html>


More information about the USRP-users mailing list