Ian, It turns out the B210s were not phase aligned (contrary to my earlier report)- we had not done our measurements correctly. So, need to get the MCS proof-of-concept working on two B210s i.e. just prove on the scope that the baseband RX sample clocks are indeed aligned. Currently we call a uhd FFT function to initialize/tune the AD9361 and check the RX sample clocks coming to the FPGA on the scope (obviously any UHD function that configures the AD9361 to recv samples will suffice for our setup).
Coming to the MCS changes, I understand the FPGA piece of it (driving the sync_in to the AD9361), but needed some hand-holding on finding the minimum and easiest path for the MCS software/firmware. Conceptually I understand the change needed - need to add the ad9361_multipchip_sync function provided in the IIO Library (libad9361-iio), but not sure how to go about it. (I have not rebuilt UHD source code before). I am specifically looking for details on which source files will I need to change and which files will I have to rebuild if I want to make sure that when the UHD FFT or UHD stream samples type function is sent from the host, the MCS function is called underneath. Once again, I am trying to keep the software footprint of this effort to bare minimum. Any pointers will be much appreciated. Thanks Chintan On Wed, Jun 27, 2018 at 10:28 AM, Chintan Patel <cpa...@vt.edu> wrote: > Ian, > > We are using multiple B210 radios. We are monitoring two PPS signal (one > per radio) reclocked in the radio/sample clk domain on the scope. So > essentially, we are indirectly monitoring the radio clk/sample clk from two > different B210s, which always seem phase aligned over multiple reboots. > > But given everything I now know about MCS, I am beginning to doubt the > measurements and will repeat. > > Thanks > Chintan > > > On Tue, Jun 26, 2018 at 2:09 PM, Ian Buckley <i...@ionconcepts.com> wrote: > >> 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). 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> 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> 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 >>> >>> >>> -Robin >>> >>> >>> On Mon, Jun 25, 2018 at 9:07 PM, Marcus D. Leech via USRP-users < >>> 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> 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> >>>>> 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> 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 >>>>>>> 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 >>>>> >>>> -- >>>> Very Respectfully, >>>> >>>> Dan CaJacob >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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
