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

Dragoslav Stojadinovic stojadin at winlab.rutgers.edu
Thu Nov 2 11:17:50 EDT 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171102/6cf20f53/attachment-0002.html>


More information about the USRP-users mailing list