# How to correct for the drift in an (FMCW) Rx signal? **URL:** \ **Category:** GNU Radio\ **Created:** [November 28, 2014, 4:15pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261 "2014-11-28T16:15:27Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [November 28, 2014, 4:15pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/1 "2014-11-28T16:15:27Z")
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 ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [November 28, 2014, 4:40pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/2 "2014-11-28T16:40:20Z")
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? > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [http://lists.ettus.com/mailman/listinfo/usrp-users\_lists.ettus.com](http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com) [1] Links: ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [November 28, 2014, 9:43pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/3 "2014-11-28T21:43:04Z")
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 (c). 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 ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [December 2, 2014, 4:08pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/4 "2014-12-02T16:08:13Z")
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 ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [November 28, 2014, 10:16pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/5 "2014-11-28T22:16:28Z")
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. ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [December 2, 2014, 4:12pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/6 "2014-12-02T16:12:31Z")
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. ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [December 2, 2014, 4:38pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/7 "2014-12-02T16:38:14Z")
Ok, three things: 1. there are daughterboards with temperature sensors; search for temperature in [USRP Hardware Driver and USRP Manual: Daughterboards](http://files.ettus.com/manual/page_dboards.html) (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 ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [December 2, 2014, 5:13pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/8 "2014-12-02T17:13:11Z")
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 Device Manual: Daughterboards](http://files.ettus.com/manual/page_dboards.html) > (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… ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [December 3, 2014, 1:52pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/9 "2014-12-03T13:52:44Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [December 3, 2014, 8:08am UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/10 "2014-12-03T08:08:15Z")
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:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Marcus D. Leech via USRP-users Sent: Tuesday, December 2, 2014 4:11 PM To: khalid.el-darymli Cc: removed\_email\_address@domain.invalid; removed\_email\_address@domain.invalid 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 \ 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, \ 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 removed\_email\_address@domain.invalid [mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://lists.ettus.com/mailman/listinfo/usrp-users\_lists.ettus.com](http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com) – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. ---
**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\ **Post date:** [December 3, 2014, 3:34pm UTC](https://www.ruby-forum.com/t/how-to-correct-for-the-drift-in-an-fmcw-rx-signal/233261/11 "2014-12-03T15:34:20Z")
-----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 Device Manual: GPIO API](http://files.ettus.com/manual/page_gpio_api.html) 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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUfx8hAAoJEAFxB7BbsDrLWnUH/3sBlb+RSjnsUlgW5GASYbOw d2un2ueRY5GddfVopqnHFlj6e8bIKaOq/Ct5VcnX3133pskTnGPVyIsB5kgLLty+ Dws33Smo2FaA0YiqxrqZF4/O+35ZvYzIlkDtCeXIHr6TXw9eUQFZOEiOfglaHuTj 2WlJd8sRTx+gIqoWmuWROAz7qESsYIydz9rIHJuvn2HHn7LGfsWJBYLWRYEDx9Ds vatFqNEu8ZUICnfUep2m1Bo5cIAYpISB1JmXTDGEDob26sJTWfe5mBxxF6XnDNBN gHiMI9e2fT2mtQseIKkZ8FNL62+U1CY8bo5V0k8J0pVfXZcKkHEHYc2ZlJFA43Y= =eEXe -----END PGP SIGNATURE-----