DDC frequency resolution/programming accuracy?

[jmfriedt]

The DDC of the X310 is not programmed with the right frequency/DDC DDS resolution?

A X310 fitted with two BasicRX (no frequency conversion before sampling and FPGA DDC) is externally clocked by an Octoclock fed by the output of a microstepper generating a 10 MHz and 1-PPS output. This same 10 MHz reference feeds a Rohde & Schwarz SMA100A synthesizer and HP 53131A frequency counter. The synthesizer is programmed to output a 70 MHz continuous wave, validated with the frequency counter:

The X310 is set to a sampling rate of 200/40=5 MS/s and the LO frequency of the DDC set to 70 MHz. The spectrum of the signal recorded for 5 seconds (0.2 Hz resolution) is as follows:

An obvious offset of 5 Hz is seen. It is unclear whether this offset is within the DDC DDS resolution which seems to be 200 MHz/2^24=12 Hz but sounds a poor resolution (see discussion on chat.gnuradio.org): could this resolution be confirmed?

Repeating the measurement at 143.05 MHz and using the second Nyquist zone, so setting the DDC frequency to 56.95 MHz and feeding the X310 with a synthesized signal

leads to

The reason for the Issue is that this behaviour is observed with 4.5.0.0 but not with 4.1.0: with the latter, the 70 MHz signal is measured with sub-Hz error, so a behaviour changed in between.

Setup Details

The flowchart is as attached

with external time and frequency selected on the X310, only one of the two channels used in this experiment, stored in file and post-processed with GNU Octave running

fs=5E6;
x=read_cshort_binary('fichier.bin',50e6);
x1=x(1:2:end)/32767;
x2=x(2:2:end)/32767;
freq=linspace(-fs/2,fs/2-fs/length(x2),length(x2));
plot(freq,abs(fftshift(fft(x2))));

[mbr0wn]

Sorry for the late response. We haven't yet gone into the weeds here (something is definitely off), but I can confirm the DDS resolution is 24 bits.

[mbr0wn]

I'm sorry, I was a bit hasty. We use 24-bit multipliers to calculate the e^{j2\pi f t} term, but the phase increment is 32-bit.

[mbr0wn]

OK, @jmfriedt, I repeated your setup and got the same results. This is a legit bug and there's a fix incoming. A couple of comments:

• The approx. 5Hz offset you were seeing was us rounding to the next integer multiple of 256 phase increments. With a resolution of approx. 12 Hz, you get an error up to approx. 6 Hz.
• The result of set_rx_freq() in the MultiUSRP API actually tells you the remaining frequency offset; so for any multi_usrp API users reading this, you can read out the tune_result object returned by set_rx_freq() and in this case it would have told you approx. 4.7 Hz error.
• The fix brings back the full 32-bit range of tuning (as it should). The tune function also now reports the correct frequency.

This issue will be fixed with the next UHD release. Thanks again for reporting.

[mbr0wn]

(Note: When we merge the fix, this will be closed, but the public master branch will be updated a few days later).

[jmfriedt]

Thank you Martin for spending the time to correct the issue. I am not sure the digital communication crowd will benefit with their inaccurate local oscillators, but the time and frequency community will be forever grateful for a high accuracy numerically controlled local oscillator. Thank you.

[mbr0wn]

@jmfriedt You're very welcome, and we do have plenty of applications that require accurate NCOs. But in this case, my personal pride (and annoyance over this bug) would have been enough for me to fix it. Thanks again for the excellent report.

[joergho]

Fixed with 635ad362a.