But you know what I observed and what is weird? When I ask for an external
source and I intentionally turn off the external generator providing a 10
MHz signal, USRP behaves as if it was still seeing a 10 MHz reference
signal at its input. Doesn't matter if the generator is switched on or off
- USRP behaves the same way. Because of that I am  not sure if USRP is
being clocked from an internal or external clock source. Is it the bug in
the GNU radio or UHD or am I doing something wrong? How can I get the
feedback from the USRP hardware that it was locked to the external clock?
Is it even possible?



śr., 11 maj 2022 o 16:14 Marcus D. Leech <[email protected]>
napisał(a):

> On 2022-05-11 09:51, Marcin Puchlik wrote:
>
> Will it be enough to clock USRP from the external 10 MHz signal generator?
> When I run the flowgraph I cannot see the information that is using the
> external clock. Here is the output from GNU Radio:
> [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
> UHD_3.15.0.HEAD-0-gaea0e2de
> [INFO] [B200] Detected Device: B200
> [INFO] [B200] Operating over USB 2.
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Setting master clock rate selection to 'automatic'.
> [INFO] [B200] Asking for clock rate 16.000000 MHz...
> [INFO] [B200] Actually got clock rate 16.000000 MHz.
> [INFO] [B200] Asking for clock rate 51.200000 MHz...
> [INFO] [B200] Actually got clock rate 51.200000 MHz.
> [INFO] [MULTI_USRP]     1) catch time transition at pps edge
> [INFO] [MULTI_USRP]     2) set times next pps (synchronously)
> [INFO] [B200] Asking for clock rate 51.200000 MHz...
> [INFO] [B200] OK
> [INFO] [B200] Asking for clock rate 51.200000 MHz...
> [INFO] [B200] OK
> [WARNING] [AD936X] Selected Tx sample rate (0.2 MHz) is less than
> analog frontend filter bandwidth (0.2 MHz).
>
>
> [image: image.png]
>
> Yeah, I don't think it puts out an "i'm locked to the external reference"
> message.
>
> But you've asked for "external" clock source, so you should be good to go,
> assuming your external generator meets the requirements.
>
>
> śr., 11 maj 2022 o 15:24 Marcus D. Leech <[email protected]>
> napisał(a):
>
>> On 2022-05-11 09:18, Marcin Puchlik wrote:
>>
>> Marcus,
>> Thank you very much for the answer. Does it mean that 1 PPS signal is
>> optional? Can I only provide an external 10 MHz clock without 1 PPS?
>> *Z poważaniem *
>> *Marcin Puchlik*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Yes, absolutely.  If timestamp synchronization is not important to you,
>> then you can just provide a 10MHz reference when you want better
>> frequency accuracy and drift characteristics than are offered by the
>> on-board clock and/or you want some type of phase-synchronization   but
>> don't care much about mutual phase offsets.... *
>>
>>
>>
>> śr., 11 maj 2022 o 14:24 Marcus D. Leech <[email protected]>
>> napisał(a):
>>
>>> On 2022-05-11 06:17, Marcin Puchlik wrote:
>>>
>>> Hello Community,
>>> Like in the topic, I know that a stable 10 MHz source is needed as a
>>> clock signal but why do we need 1 PPS signal? How is it used by the USRP
>>> hardware? Can someone explain that to me?
>>> Thanks
>>> Marcin
>>>
>>> _______________________________________________
>>> USRP-users mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>>
>>> 1PPS is used to provide timestamp-clock synchronization across multiple
>>> devices, typically.  This is important when your application requires this,
>>> such as in MIMO or
>>>   multi-receiver TDOA schemes, etc.
>>>
>>> Basically, when you have multiple devices you use set_time_unknown_pps()
>>> or set_time_next_pps() to signal to all devices in your multi_usrp object
>>> that at the next
>>>   1PPS, to set the timestamp clock to the value given in the the API
>>> call.
>>>
>>> This turns out to be useful even in single devices that are "bicameral",
>>> such as B210 and X310, where there are (for historic and architectural
>>> reasons)
>>>   TWO timestamp clocks.  Use the 1PPS synchronization primitives causes
>>> the internal timestamp clocks to become synchronized.
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>>
>>
>>
>
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to