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

Marcus D. Leech mleech at ripnet.com
Tue Dec 2 11:37:31 EST 2014


On 12/02/2014 11:31 AM, khalid.el-darymli wrote:
> I see. Thanks for the information. It seems the temp sensor 
> incorporated in the QR210 is also for the 'ambient temperature', 
> similar to your suggestion, right?
> http://www.ettus.com/kb/detail/qr210-architecture-and-overview
>
> Khalid
>
>
Yes.

>
> On Tue, Dec 2, 2014 at 12:43 PM, Marcus D. Leech <mleech at ripnet.com 
> <mailto:mleech at ripnet.com>> wrote:
>
>     On 12/02/2014 11:02 AM, khalid.el-darymli wrote:
>>     I am not sure if we are talking about the same thing. Since I
>>     need to track the internal electronic circuit variation in
>>     temperature, which pins on the USRP board/daughterboard are
>>     suitable for extracting information that correlates with the
>>     temperature variation?
>>
>>     Thanks,
>>     Khalid
>>
>     With the exception of the TVRRX2, there are no internal
>     temperature sensors in USRP hardware.  That's why I suggested a
>     separate device, placed
>       inside the N210 cabinet to be used as a proxy. There are very
>     few electronic components that provide an "internal temperature"
>     output as
>       a kind of monitoring thing.  Particularly in the analog RF
>     space.  Some computer motherboards have this, but it's not an
>     inherent property of
>       electronics to provide a temperature output as a side effect or
>     anything.
>
>
>
>>
>>     On Tue, Dec 2, 2014 at 11:53 AM, Marcus D. Leech
>>     <mleech at ripnet.com <mailto:mleech at ripnet.com>> wrote:
>>
>>         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
>>
>>
>
>
>     -- 
>     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/6a6afcef/attachment-0002.html>


More information about the USRP-users mailing list