Chintan, When you refer to lab trial’s with B210…I’m assuming you were using multiple B210’s rather than demonstrating coherence of the 2 channels on a singe B210? How were you verifying that the sample clocks were aligned? Can you share your rough configuration? If you are using a common PPS to sync time on multiple REF locked B210’s then the FPGA’s will be operating coherently with the caveat that they are clocked with the divided BBPLL clock (a.k.a master_clock_rate). If you are running master_clock_rate at a relatively high value and doing significant decimation to the ultimate sample_rate on B210, then a residual phase ambiguity on the BBPLL might start to be hard to observe just looking at output samples. -Ian
> On Jun 26, 2018, at 2:42 AM, Chintan Patel <cpa...@vt.edu> wrote: > > Hi Ian, Robin, Marcus > > Thanks a lot for your help so far. Three more questions/clarifications: > > 1. For the B205 Multi-chip sync (MCS), we are trying to achieve, we are > actually providing an external stable 40MHz clock common to both B205s. i.e. > we have re-worked the boards so that the DPLL is not being used at all to > drive the CLK_40MHz_FPGA to the FPGA input - instead a shared very-stable > 40MHz clock input it. > > 2. Sounds like along with this, the sync_in pin into the AD9364/9361 needs to > be driven correctly to both B2xx radios. I see that for the B205mini this pin > is grounded, while the B210 it goes to the FPGA - which would explain the MCS > capability of the B210. What confuses me, is that the stock FPGA image for > B210 drives the sync_in input to 0. So, I don't understand why we see phase > aligned sample clocks on the B210 in our lab trials. I think the FPGA > changes Ian refers to that he needed to make MCS work for B210 must be > related to driving this sync_in pin - but we are just using the stock FPGA > image, so scratching my head on that one. > > 3. Lastly, seems like there is a software routine to be called too, for the > AD936 MCS. ( ad9361_multichip_sync.c > <https://github.com/analogdevicesinc/libad9361-iio/blob/master/ad9361_multichip_sync.c#L108> > per > https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5-ebz/multi-chip-sync > > <https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5-ebz/multi-chip-sync>). > Theoretically, if one is able to rework the B205mini so that the sync_in pin > goes to the FPGA (not practical I know), I assume there will be a similar > routine needed for ad9364_multichip_sync. > > Thanks again for your continued guidance. > > Chintan > > > > On Tue, Jun 26, 2018 at 12:31 AM, Ian Buckley via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > Robin, > that ADI support thread is not applicable to B2x0, it’s for AD9361 external > LO mode which isn’t used by Ettus products. > > In internal LO mode there is always a phase ambiguity in the RF synthesizers > that requires higher level S/W to calibrate and correct for. > The baseband synthesizer can be made phase coherent between multiple AD936x’s > if you use the MCS mechanism, however that’s not included in the factory FPGA > image, (though I have used it in custom images) so you also see some phase > ambiguity here too between REF locked USRP's > -Ian > > >> On Jun 25, 2018, at 9:15 PM, Robin Coxe via USRP-users >> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >> >> Marcus is correct and the schematics do in fact provide the answer. >> >> Please refer to p.1 of the B210 schematic. It contains an ADF4002 analog >> PLL. >> The B200mini clocking circuitry is on p. 4 of the schematic. The PLL is >> digital and implemented inside the FPGA. >> >> There is a divide-by-2 for the external LO input in the AD9361/AD9364 RFIC >> that can result in a 180 degree phase ambiguity. More details here >> provided by my former colleague at ADI also named Robin: >> https://ez.analog.com/thread/73543?commentID=225150#comment-225150 >> <https://ez.analog.com/thread/73543?commentID=225150#comment-225150> >> >> >> -Robin >> >> >> On Mon, Jun 25, 2018 at 9:07 PM, Marcus D. Leech via USRP-users >> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >> On 06/25/2018 11:57 PM, Dan CaJacob wrote: >>> Without looking at the schematic, I'd guess that the difference is in the >>> implementation of the PLLs for tracking. >>> >>> On Mon, Jun 25, 2018 at 11:21 AM Chintan Patel via USRP-users >>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >>> Hi Marcus, >>> >>> Two follow-up questions related to B205/B210 synchronization. >>> >>> 1. What is the fundamental reason why B210 supports phase coherent sync >>> across multiple devices and B205 does not. The reference manuals on the >>> AD9364/AD9361 does not point to any clues, and neither does the schematic. >> Because on B210, the reference PLL is a hardware, analog PLL, whereas on the >> B205mini, it's a DPLL that simply cannot maintain low mutual >> phase noise because of the way the servo works. >> >>> >>> 2. If we feed identical 40 MHz to multiple B205 from the reference input >>> to the output of the DPLL (remove X1 and run a wire from R35-1 to X1-3) and >>> identical 1PPS to a GPIO pin, is there a way to phase and frequency align >>> the rx sample (CAT-DCLK) signals. >> Yes, if you basically provide a shared 40MHz clock, and ignore whatever the >> DPLL is doing, and perhaps re-jig the FPGA code to take 1PPS >> from a GPIO pin, this should, in theory, work. But no guarantees. >> Modified hardware. Modified FPGA code. >> >> >> >>> >>> Thanks >>> >>> Chintan >>> >>> On Sat, Jun 23, 2018 at 11:26 AM, Marcus D. Leech <mle...@ripnet.com >>> <mailto:mle...@ripnet.com>> wrote: >>> On 06/23/2018 09:06 AM, Chintan Patel wrote: >>>> Hi Marcus, >>>> >>>> Thanks for the response. I came to a similar conclusion reading the Ettus >>>> app note on MIMO synchronization. >>>> >>>> Do you know if the DPLL code (or any other way) can be modified to achieve >>>> phase coherence across multiple B205 minis. >>> My understanding is that it is likely a very challenging exercise with the >>> existing hardware, otherwise, it would already be in place. >>> But the code, like all the other Ettus FPGA and host-side UHD code is >>> freely available. >>> >>> >>> >>> >>>> >>>> Thanks >>>> Chintan >>>> >>>> On Sat, Jun 23, 2018 at 1:07 AM, Marcus D. Leech via USRP-users >>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >>>> On 06/23/2018 12:25 AM, Chintan Patel via USRP-users wrote: >>>> Hello, >>>> >>>> I am an Ettus newbie. We have an application that requires us to >>>> synchronize multiple B205 mini radios (RX side) using the PPS in signal. >>>> In the FPGA, the pps_in is reclocked into the radio clock domain. What we >>>> notice is that when we monitor this PPS signal (reclocked in radio clock >>>> domain) from two different radios on a scope, there is a time variation >>>> between the alignment of these two PPS signals across different trials. In >>>> other words, after each reset the time skew between the two signals >>>> varies. Since the PPS_in for both radios is the same, I think this >>>> variation across different reboot iterations means that the radio clock is >>>> not guaranteed to be phase aligned/locked to the PPS for the B205 radio. >>>> >>>> Curiously, when we repeat the same experiment using the B210, we do not >>>> see this time alignment variation across reboots. Which only makes sense >>>> if somehow for the B210 the radio clock is phase locked to the PPS in. >>>> >>>> Any thoughts from folks who might have tried similar applications and/or >>>> who understand the B205 mini/B210 radios. >>>> >>>> Thanks >>>> Chintan >>>> >>>> The 1PPS/10MHz DPLL on the B205mini series is not designed to provide >>>> close phase coherence across multiple devices. It is designed to >>>> synchronize the clock on the board to an external reference. >>>> >>>> The DPLL servo code in the B205mini drives the control voltage on the >>>> VCTCXO that provides all clocking signals on the board. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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> >>> -- >>> Very Respectfully, >>> >>> Dan CaJacob >> >> >> _______________________________________________ >> 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 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
