Marcus, There is a potential ambiguity of one clock cycle (of the reference clock used to sample the PPS) if the PPS is generated from a different clock root as the phase of PPS w.r.t the REF_CLK slowly shifts. This is due to the possibility of a setup/hold violation at one or both of the sampling registers and the resultant potential for a meta-stable state. The same situation is actually possible if they are generated from the same clock root, but in that case the phase of PPS is fixed w.r.t the reference and should the timing relationship of the active PPS and REF_CLK edges fall within the setup/hold violation window, then inversion of the active edge of the clock should provide a wide window of stability. The X310 samples PPS with the rising edge of the REF CLK.
-Ian > On Jun 18, 2018, at 9:32 AM, Marcus D. Leech via USRP-users > <usrp-users@lists.ettus.com> wrote: > > On 06/18/2018 12:07 PM, Daniel Jepson wrote: >> Dmitry, >> >> The PPS and 10MHz should (at the very least) be generated using the same >> base clock so they don't drift with respect to one another. Since you are >> using multiple X310 devices, it is also important that the PPS arrives at >> each device on the exact same cycle of the 10MHz clock--otherwise you may >> see your timekeepers in each X310 offset with respect to one another. There >> are no setup or hold specs for the X310 for PPS relative to 10MHz, but if >> you use equal length cables for both signals you should achieve a decent >> level of consistency. >> >> -Daniel > Daniel: > > Not sure this is true? > > The 1PPS signal is used as a "one shot", and as such, I don't think it is > required that it be synchronous to the 10MHz signal. > > As long as both devices are "seeing" the 10Mhz and 1PPS with controlled phase > and delay for the individual signals (cable lengths, etc), it shouldn't > matter, unless the FPGA requires that the PPS edge be synchronous with the > 10MHz edge, and I don't think it does. > > >> >> On Mon, Jun 18, 2018 at 10:17 AM, Marcus D. Leech via USRP-users >> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >> On 06/18/2018 10:57 AM, Дмитрий Михайличенко via USRP-users wrote: >>> Is it important to have PPS signal aligned with reference 10 MHz signal. In >>> my case they come from different sources. >>> >>> thanks, >>> Dmitry? >> That shouldn't matter >> >> >> >>> >>> пн, 18 июн. 2018 г. в 17:37, Marcus D. Leech via USRP-users >>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>: >>> On 06/18/2018 10:28 AM, Дмитрий Михайличенко via USRP-users wrote: >>>> The frequency is around 600 MHz. I also tried higher frequencies. The >>>> offset is visible on picture attached. >>>> >>>> thanks, >>>> Dmitry >>> If you look here: >>> >>> https://kb.ettus.com/UBX <https://kb.ettus.com/UBX> >>> >>> You can see that for frequencies below 1GHz, you have to use a 20MHz >>> daughterboard clock for UBX to achieve synchronization. >>> I don't know if SBX will work correctly with a 20MHz daughterboard clock, >>> so you can't have "mixed" UBX + SBX on the same >>> X310. >>> >>> Also, integer-N tuning can help maintain better phase synchronization >>> characteristics: >>> >>> https://files.ettus.com/manual/structuhd_1_1tune__request__t.html >>> <https://files.ettus.com/manual/structuhd_1_1tune__request__t.html> >>> >>>> >>>> пн, 18 июн. 2018 г. в 14:50, Дмитрий Михайличенко <mdm...@gmail.com >>>> <mailto:mdm...@gmail.com>>: >>>> Hi, >>>> >>>> I have a couple of X310 each of them has UBX+SBX cards. The devices are >>>> synchronized by external 10MHz + PPS signal. But in my test I see random >>>> phase delay between all channels that varies between test runs. The test >>>> creates multi usrp device, sets up time and tunes to the same frequency >>>> using timed command, then it captures some buffers. The same external >>>> signal is supplied to all antenna ports. Is it expected to have random >>>> delay between channels? Is there any way to have constant phase delay from >>>> run to run? >>>> >>>> thanks, >>>> Dmitry >>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >> >> >> >> >> -- >> Daniel Jepson <> >> Digital Hardware Engineer >> >> National Instruments >> >> >> O: +1.512.683.6163 >> >> daniel.jep...@ni.com <mailto:daniel.jep...@ni.com> > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
