[USRP-users] How to correct for the drift in an (FMCW) Rx signal?

Marcus D. Leech mleech at ripnet.com
Tue Dec 2 10:23:34 EST 2014


On 12/02/2014 10:21 AM, khalid.el-darymli wrote:
> Thanks for the prompt reply. I need to monitor the*internal 
> temperature *(i.e., not the ambient temperature) of the N200 USRP 
> board/ chip/etc., to compensate for the temperature-based variations 
> in the Rx FMCW chirp.
>
> How the USB based sensor can do that?
>
> Khalid
>
Plenty of room inside the enclosure, you'd have to use some mechanical 
creativity.


>
> On Tue, Dec 2, 2014 at 11:41 AM, Marcus D. Leech <mleech at ripnet.com 
> <mailto:mleech at ripnet.com>> wrote:
>
>     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
>>     <mleech at ripnet.com <mailto:mleech at ripnet.com>> 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, <mleech at ripnet.com
>>>         <mailto:mleech at ripnet.com>> 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
>>>>             USRP-users at lists.ettus.com  <mailto:USRP-users at lists.ettus.com>
>>>>             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>
>>
>>         -- 
>>         Marcus Leech
>>         Principal Investigator
>>         Shirleys Bay Radio Astronomy Consortium
>>         http://www.sbrac.org
>>
>>
>>
>
>
>     -- 
>     Marcus Leech
>     Principal Investigator
>     Shirleys Bay Radio Astronomy Consortium
>     http://www.sbrac.org
>
>
>
>
> -- 


-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141202/3e74b215/attachment-0002.html>


More information about the USRP-users mailing list