How to correct for the drift in an (FMCW) Rx signal?

GNU Radio
1

Hi,

Given a set of synced (i.e., using external GPS REF/PPS),
time-commanded
and calibrated *(i.e., through compensating for the phase/mag offset
between digital Tx chirp prior to transmission and ADC’ed Rx signals)
*N200
devices with LFTX/LFRX daughterboards, that work with coherent LFMCW
chirps, I am still seeing a tiny drift (both in the magnitude and
frequency) of the calibrated back-scatter Rx chirp received at time t1
when compared to an Rx chirp received at an earlier time t0.

The more the N200 device runs (e.g., 5 hours), the greater the drift is.
Obviously, this drift is pertinent to both the DAC and ADCs and the GPS
referenced clocks of the N200 devices.

My questions are:

1- Why I still see such drift although my devices are synced with an
external GPS? and how do I correct for it?

2- Can the *PLL Carrier Tracking *block in GRC be used to track and
correct
for such a drift? If so, how do I set the max/min freq inputs for this
block?

3- Can AGC2 or *AGC3 *block be useful in this regard? If so, are there
any examples to explain how the input parameters of these blocks can be
set
up?

Thanks.

Best regards,
Khalid

2

What is the magnitude of the frequency drift?

What is the magnitude of the gain drift?

What are you measuring backscatter from?

On 2014-11-28 10:14, khalid.el-darymli via USRP-users wrote:

2- Can the PLL CARRIER TRACKING block in GRC be used to track and correct for
such a drift? If so, how do I set the max/min freq inputs for this block?
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]

Links:

3

Hi Marcus,

Thanks for your response.

What is the magnitude of the frequency drift?
What is the magnitude of the gain drift?
Please see description below (and Figures e-1 and e-2).

What are you measuring backscatter from?
Sorry, I meant to say from loop-backing the Tx to Rx (without any
antennas
involved).

Description of the test:

1- The test I did takes the Rx signal from direct loopback of the Tx
(LFMCW) chirp.

2- Phase and magnitude offsets of the Rx signal relevant to the Tx chirp
are calibrated out from a prerecorded training signal.

3- The calibrated Rx signal is mixed (i.e., dechirped) through
complex-conjugate multiplication with the digital Tx chirp.

4- The mixed signal is decimated to 625 Hz.

5- The decimated signal is resolved to individual sweeps.

6- This test was run for around three hours. Hence, in total, I have
10838
sweeps with 490 samples in each sweep.

7- The LFMCW chirp parameters are: upsweep, 0.98 peak, 100 KHz, 0.784 s
sweep time.

8- Attached are the following figures:
a- Magnitude of successive sweeps (superimposed).
b- Instantaneous phase of successive sweeps (superimposed).
c- A plot for the mag and phase of a complex-valued sweep divided by
itself:
i.e., a_r * exp (j phi_r) = a_s exp (j phi_s)/ a_s exp (j phi_s)

Ideally, this should give magnitude a_r = 1 and phi_r =0.
However, as shown in the attachment, phi_r is not perfectly zero due to
the
floating-point precision (which is fine!).

d- Similar to ‘c’ (i.e., relative mag and phase) but for two neighboring
sweeps (three superimposed cases are depicted).

e- Similar to ‘c’ (i.e., relative magnitude and phase) between the last
sweep (i.e., sweep 10838) and the 10th sweep. The first 9 sweeps are
skipped just to allows the N200 to settle down.

For cases (d) and (e), ideally, one would expect to see the relative mag
and phase in the vicinity of ©. However, this is not the case as
shown.
Also, the tiny drifts in both magnitude and phase are increasing with
time
as shown in (e).

Back to my original question, what should I do to correct for this?

Thanks in advance.

Best,
Khalid

4

Hi Marcus,

Is there a temperature sensor on-board the N200 unit? If not, does it
support installing any such sensor?

Thanks.

Best regards,
Khalid

5

On 11/28/2014 03:41 PM, khalid.el-darymli wrote:

Back to my original question, what should I do to correct for this?

Thanks in advance.

Best,
Khalid

Khalid:

Thanks very much for the very-extensive data. My main concern, as one
of the Ettus support team, was that there was something wrong with
the hardware, but the magnitude of both the apparent phase and
magnitude drift is entirely consistent with analog-hardware temperature
effects, unrelated to clock stability, etc.

Coax cables, for example, will change their loss characteristics and
effective length with temperature, so with precise hardware like
USRPs, it’s
easy to see these effects.

FMCW radar isn’t my area of expertise, so hopefully others can comment
on RX-processing strategies to deal with this, as it must also be a
problem
with non-SDR FMCW radar implementations.

6

On 12/02/2014 10:06 AM, khalid.el-darymli wrote:

Hi Marcus,

Is there a temperature sensor on-board the N200 unit? If not, does it
support installing any such sensor?

Thanks.
No, and no.

But there are a tonne of USB-based temperature sensors out there.
Google is your friend, etc.

7

Ok, three things:

  1. there are daughterboards with temperature sensors; search for
    temperature in
    USRP Hardware Driver and USRP Manual: Daughterboards
    (I think it’s tvrx2)

  2. there are auxiliary ADCs. If you use a daughterboard that exposes
    these pins, you can use them with a PTC or something equivalent.

  3. If your daughterboard exposes that (there are quite some that do),
    you can bit-band GPIO lines to talk to I2C temperature sensors.

Greetings,
Marcus

8

On 12/02/2014 10:36 AM, Marcus M. wrote:

Ok, three things:

  1. there are daughterboards with temperature sensors; search for
    temperature in
    USRP Hardware Driver and USRP Manual: Daughterboards
    (I think it’s tvrx2)
    I had forgotten that the TVRX2 had an on-board temperature sensor. It’s
    the only one that does.

  1. there are auxiliary ADCs. If you use a daughterboard that exposes
    these pins, you can use them with a PTC or something equivalent.

  2. If your daughterboard exposes that (there are quite some that do),
    you can bit-band GPIO lines to talk to I2C temperature sensors.

Greetings,
Marcus

It’s probably less-painful to just integrate a USB-based temp sensor
into an application, to be honest…

9

Thank you Ralph and Marcus for this information. That is so helpful. One
final question on this, rather than having a standalone USB connection
to
the computer, is there anyway to piggyback the temperature data from the
temp sensor onto the digital interface to the FPGA board of the N200?

Thank you.

Best regards,
Khalid

On Wed, Dec 3, 2014 at 3:36 AM, Ralph A. Schmid, dk5ras
[email protected]

10

In my job we have learned that lesson and fitted on all our DSP systems
(you could call them direct digitizing SDRs, although we do not radio
stuff) a cheap I2C temperature sensor. No big thing by means of
software, costs and PCB space, but already proved being very useful.
Could be considered for future products…

Ralph.

From: USRP-users [mailto:[email protected]] On Behalf
Of Marcus D. Leech via USRP-users
Sent: Tuesday, December 2, 2014 4:11 PM
To: khalid.el-darymli
Cc: [email protected]; [email protected]
Subject: Re: [USRP-users] How to correct for the drift in an (FMCW) Rx
signal?

On 12/02/2014 10:06 AM, khalid.el-darymli wrote:

Hi Marcus,

Is there a temperature sensor on-board the N200 unit? If not, does it
support installing any such sensor?

Thanks.

No, and no.

But there are a tonne of USB-based temperature sensors out there.
Google is your friend, etc.

Best regards,
Khalid

On Fri, Nov 28, 2014 at 5:44 PM, Marcus D. Leech <[email protected]
mailto:[email protected] > wrote:

On 11/28/2014 03:41 PM, khalid.el-darymli wrote:

Back to my original question, what should I do to correct for this?

Thanks in advance.

Best,
Khalid

Khalid:

Thanks very much for the very-extensive data. My main concern, as one
of the Ettus support team, was that there was something wrong with
the hardware, but the magnitude of both the apparent phase and
magnitude drift is entirely consistent with analog-hardware temperature
effects, unrelated to clock stability, etc.

Coax cables, for example, will change their loss characteristics and
effective length with temperature, so with precise hardware like
USRPs, it’s
easy to see these effects.

FMCW radar isn’t my area of expertise, so hopefully others can comment
on RX-processing strategies to deal with this, as it must also be a
problem
with non-SDR FMCW radar implementations.

On Fri, Nov 28, 2014 at 12:08 PM, <[email protected]
mailto:[email protected] > wrote:

What is the magnitude of the frequency drift?

What is the magnitude of the gain drift?

What are you measuring backscatter from?

On 2014-11-28 10:14, khalid.el-darymli via USRP-users wrote:

Hi,

Given a set of synced (i.e., using external GPS REF/PPS), time-commanded
and calibrated (i.e., through compensating for the phase/mag offset
between digital Tx chirp prior to transmission and ADC’ed Rx signals)
N200 devices with LFTX/LFRX daughterboards, that work with coherent
LFMCW chirps, I am still seeing a tiny drift (both in the magnitude and
frequency) of the calibrated back-scatter Rx chirp received at time t1
when compared to an Rx chirp received at an earlier time t0.

The more the N200 device runs (e.g., 5 hours), the greater the drift is.
Obviously, this drift is pertinent to both the DAC and ADCs and the GPS
referenced clocks of the N200 devices.

My questions are:

1- Why I still see such drift although my devices are synced with an
external GPS? and how do I correct for it?

2- Can the PLL Carrier Tracking block in GRC be used to track and
correct for such a drift? If so, how do I set the max/min freq inputs
for this block?

3- Can AGC2 or AGC3 block be useful in this regard? If so, are there any
examples to explain how the input parameters of these blocks can be set
up?

Thanks.

Best regards,

Khalid

USRP-users mailing list
[email protected] mailto:[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Khalid,

rather than having a standalone USB connection to the computer, is
there anyway to piggyback the temperature data from the temp sensor
onto the digital interface to the FPGA board of the N200?

That’s what you would do if you attached a sensor to the FPGA’s debug
header, modified the FPGA image and the host driver and got your data
out of that.
Definitely possible, definitely a huge effort for a few bytes of data.

I’d either go with the GPIO interface[1], or use the fact that the
N2x0 works on standard Gigabit Ethernet / IP, and you can simply
attach any networked hardware to a Gigabit Ethernet switch. Raspberry
Pi comes to mind, if you want something rather capable and running a
stock linux, for which many kernel drivers already allow you to talk
to hardware attached to things like I2C or SPI.

Currently I’m playing around with a stamp-sized openWRT-running board
that would potentially even fit inside the casing of the N200, but I
don’t think that would be a good idea (it being a least cost, and
definitely not EMI-tested, one-man project).

Greetings,
Marcus

[1] which many daughterboards expose; what daughterboard are you using?
The information about the X3x0’s front panel GPIO applies to the N2x0
GPIO, too, mostly: USRP Hardware Driver and USRP Manual: GPIO API

On 12/03/2014 01:51 PM, khalid.el-darymli wrote:

Best regards, Khalid

Coax cables, for example, will change their loss characteristics

Given a set of synced (i.e., using external GPS REF/PPS),
ADCs and the GPS referenced clocks of the N200 devices.
freq inputs for this block?

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUfx8hAAoJEAFxB7BbsDrLWnUH/3sBlb+RSjnsUlgW5GASYbOw
d2un2ueRY5GddfVopqnHFlj6e8bIKaOq/Ct5VcnX3133pskTnGPVyIsB5kgLLty+
Dws33Smo2FaA0YiqxrqZF4/O+35ZvYzIlkDtCeXIHr6TXw9eUQFZOEiOfglaHuTj
2WlJd8sRTx+gIqoWmuWROAz7qESsYIydz9rIHJuvn2HHn7LGfsWJBYLWRYEDx9Ds
vatFqNEu8ZUICnfUep2m1Bo5cIAYpISB1JmXTDGEDob26sJTWfe5mBxxF6XnDNBN
gHiMI9e2fT2mtQseIKkZ8FNL62+U1CY8bo5V0k8J0pVfXZcKkHEHYc2ZlJFA43Y=
=eEXe
-----END PGP SIGNATURE-----