enjoy-digital
commented
1 year ago The issue is probably related to a calibration of the FPGA <-> LMS7002M delays that would need to be done after setting up the CGEN (or a pre-defined table that would need to be generated/configured based on CGEN).
The FPGA has the possibility to adjust TX/RX delays (similarly to what you are doing with the clock inversion) and this has been tested from Python scripts with: https://github.com/enjoy-digital/xtrx_julia/blob/master/test/test_lms7002m_digital_interface.py
IIRC I set default values that were working correctly with the CGEN I tested, but the behavior is maybe different in your case.
In the short term, this could be useful to had the possibility to adjust these delays in your software and see if you find values that work correctly for the CGEN freqs you are currently using.
In the long term, it would be useful to implement a proper calibration:
- Setting CGEN on the LMS.
- Enabling the attern generator and checker on the FPGA.
- Do a software scan of the delays and set delay at the middle of the sampling window.
This could be similar to AD9361's AN-1441: https://www.analog.com/media/en/technical-documentation/app-notes/an-1441.pdf
maleadt
When capturing signals using the TBB loopback, we found that there is a regular spiking pattern that tends to happen near signal zero-crossings. In this figure, the blue line represents what was transmitted, and the orange/green lines represent what is received:
Note the regular pattern of the spikes, and how the spikes follow the curvature of the signal, almost like the signal is being bitshifted. I hypothesized that this might be a clocking issue, and so embarked on a combinatorial exploration of the various clocking options within the LMS, finding that if we inverted the RX LMLA and RX LMLB clocks (e.g. set
CDSN_RXALMLandCDSN_RXBLML) the spikes went away. Here's a zoomed out view, where we're transmitting a modulated sinusoid, showing timing behavior (don't worry that the transmitted signal ends, we're only plotting a single period of it):This is a reasonable workaround, but I'm pretty sure it's just adding a little extra stability on top of an unsteady foundation. If we start to push other parameters of the system, we see similar issues appear elsewhere. If we increase CGEN frequency up to 400MHz (necessary for high-bandwidth (40MHz) captures), we get a host of bad behaviors, including spiking, and leakage from the real part to the imaginary part:
Even if we don't pass through the baseband, the digital loopback itself starts to break down at such a high CGEN frequency:
My main guess as to what's going on wrong here is that our estimate of our reference clock is off by a few percentage points, and when we feed this through the PLL, we get something that is wildly off of what we expect, and that screws up some clock propagation somewhere. However, this isn't really my domain of expertise, so I think we're going to need to call in an expert to truly get to the bottom of this.