We have a system with 4 AD9361 chips and an FPGA. One of them, the master, sends its Rx DATA_CLK to the FPGA, which clocks our logic. The 3 other chips are slave and their DATA_CLK are not used. All four FB_CLK are generated from the same Rx clock sent by the master chip. The sampling clocks/bbpll of the slaves, however, are all aligned using the MCS function provided with ADI's Reference Design.
The problem we are running into right now is performing the digital tuning procedure. The interface between the FPGA and our AD9361 chips is 6 lanes LVDS.
To configure the sampling frequency, we use the AD9361 Filter Design Wizard. We load the coefficients using functions ad9361_set_rx_fir_config() and ad9361_set_tx_fir_config(). With the FIR coefficients generated with the predefined configurations LTE5, LTE10, LTE15 and LTE20 of the wizard, the digital tuning procedure generally converges well and suceeds for all 4 AD9361.
However, I also generated other FTR files for sampling frequencies of 40 mhz, 50 mhz and 61.44 mhz. To do this, I simply entered the frequency in the Data field of the wizard and clicked Design Filter. With those ftr files, the digital tuning procedure almost never converges, especially for the slave boards. We use a modified version of the ad9361_conv.c file that was picked on ADI's github in may 2015. We are aware that the tuning algorithm was updated by ADI and that a new version of the algorithm was committed on june 2015, now featuring control of the IDELAY and ODELAY elements in the FPGA. We don't feel this would solve our issue here because our LVDS lanes are well matched together (within a maximum of 0.1 ns). Also, when I "manually" set the sampling frequency of the chip using function ad9361_set_rx_sampling_freq(), the digital tuning procedure converges much more often, in fact almost 100% of time at 40 mhz, whereas when I use the corresponding FTR file, it never converges.
What's strange is that when the tuning algorithm fails (using my FTR files), it looks like absolutely no combination of clock delay (all 16 of them) and data delay (all 16 of them) is valid. We made a modification to the algorithm so that the dig_tune function would try systematically all combinations to test this.
So basically, why can't the digital interface calibration algorithm succeed when using my FTR files above 30.72 mhz? Why does it work if I call the ad9361_set_rx_sampling_freq() function instead of using my FTR files?
Thank you very much!