usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: [USRP-users] [Discuss-gnuradio] Phase measurement with Ettus Research N210
Hello Daniele,
I've included the USRP users mailing list [1], since this is not related
to GNU Radio but to the USRP.
The N210 has a fixed master clock rate of 100MHz, generated from the
10MHz reference by using PLL controlled clock multipliers.
The ADC always samples at 100MHz complex, then passes this 100MS/s
signal to the FPGA, which then shifts it (if you use an RF frequency
that cannot be synthesized by the daughterboard in use exactly)
digitally by multiplying it with a complex sine, lowpasses it to fulfill
nyquist for your desired sampling rate, and then decimates it. The
sample stream at your desired rate is then passed on via gigabit ethernet.
First of all, let's get a relative error estimate: 9.32e-3/10e6 is about
1ppb error, which is fantastically low from my point of view; this might
as well be caused by numerical accuracy in the FPGA, e.g. when shifting
the signal or decimating it; this is all fixed point arithmetic!
Then, your 200kHz sampling rate is an odd fraction of 100MHz; try
250kHz, to get nicer low pass filtering (I always thought 250kHz was the
minimum usable sampling rate).
Also, how long did you observe your phase drift? To estimate a relative
error of 1e-9 reliably, you'll need a lot of samples (remember: you
always have quantization noise in digital systems, so even given perfect
analog signals and analog components at 0K temperature, you don't get
infinite SNR).
Hope that was a little helpful!
Greetings,
Marcus Müller
[1] subscribe via
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 17.06.2014 21:37, Daniele Nicolodi wrote:
Hello,
I'm using an Ettus Research N210 with a LFRX daughter-board to do data
measure the phase of a signals referred to a 10 MHz clock.
To start I want to characterize the phase noise of the device, therefore
I send to both the RX channel and to the frequency reference input the
same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
carrier frequency of 10 MHz.
When I look at the data I obtain, I see a constant phase drift
corresponding to a 9.32 mHz frequency different between the signal I
send to the RX channel and the frequency at which the N210 does the
demodulation.
Given that the signal and the clock are derived from the same oscillator
(in this simple case are the exact same signal), where does this
difference come from? How can I get rid of it?
I imagine it comes from the fact that the ADC sampling frequency is not
an exact multiple of the signal frequency, but I haven't found details
on how the ADC sampling frequency is generated, thus I have no idea
about how to make it an exact multiple of the signal frequency.
Thanks. Cheers,
Daniele
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hello Marcus,
thank for your detailed response. Some comments and further questions:
On 17/06/2014 22:04, Marcus Müller wrote:
The N210 has a fixed master clock rate of 100MHz, generated from the
10MHz reference by using PLL controlled clock multipliers.
The ADC always samples at 100MHz complex,
What do you mean by complex in this context? ADCs saple voltages, which
are a real quantity...
then passes this 100MS/s
signal to the FPGA, which then shifts it (if you use an RF frequency
that cannot be synthesized by the daughterboard in use exactly)
digitally by multiplying it with a complex sine, lowpasses it to fulfill
nyquist for your desired sampling rate, and then decimates it. The
sample stream at your desired rate is then passed on via gigabit ethernet.
Ok, I think that in the case of the LFRX daughter board the signal is
acquired as-it-is and the demodulation is done completely in the FPGA.
First of all, let's get a relative error estimate: 9.32e-3/10e6 is about
1ppb error, which is fantastically low from my point of view; this might
as well be caused by numerical accuracy in the FPGA, e.g. when shifting
the signal or decimating it; this is all fixed point arithmetic!
Uhm, this is not a phase accuracy error (which I could maybe agree can
be explained by numerical issues) but a frequency accuracy error: the
phase error adds systematically.
Then, your 200kHz sampling rate is an odd fraction of 100MHz; try
250kHz, to get nicer low pass filtering (I always thought 250kHz was the
minimum usable sampling rate).
I'll try to see if this makes a difference. The minimum sampling rate I
can program is ~193 kHz (it is a strange fraction that I cannot check
right now).
Also, how long did you observe your phase drift? To estimate a relative
error of 1e-9 reliably, you'll need a lot of samples (remember: you
always have quantization noise in digital systems, so even given perfect
analog signals and analog components at 0K temperature, you don't get
infinite SNR).
1e-9 is the relative frequency error: the phase drift is ~58 mrad/s
which is 0.58 rad in 10 seconds and this is very easily accessible.
Hope that was a little helpful!
It is helpful, thanks. However, I believe that the source of the problem
cannot be finite numerical accuracy.
Given your explanation I believe that the issue may come from finite
accuracy in the generation of the 100 MHz sampling rate: how is the 100
MHz clock generated exactly? If the 100 MHz clock is divided with a DDS
to be compared to the 10 MHz clock to derive the error signal for the
PLL, the finite precision of the DDS control register may explain the
small frequency error (a 32 bit DDS would introduce the right order of
magnitude effect, but I haven't check the exact number).
Cheers,
Daniele