I would like to use the LMS7002M in MIMO mode but found that the phase relationship between channel A and channel B is unpredictable and can be either 0 degrees or 180 degrees (random during power up and can switch after resetting and reloading the register values) at the output of the Rx mixer stage. Does anyone know how to prevent this so the phase relationship is constant, or at least automatically check it without an external signal?
Are you using Lime Suite? If so, what version? If not, what stack are you using?
The function that tries to align channels can be found here:
Thank you for your reply. We are using custom hardware controlling the LMS7002M IC directly, so the code wouldn’t run directly on our system, however I would be interested to see what the functions ResetStreamBuffers(), StartStreaming() and StopStreaming() do, you know if these control the internal buffer in the IC or are related to a buffer in the FPGA?.
Hi,
Sorry for the late reply. None of these functions deal with LMS7002M directly. ResetStreamBuffers() is used to clear leftover data in communication channel between board and PC (e.g. in LimeSDR-USB it resets FX3 USB buffers). StartStreaming() and StopStreaming() sends commands to FPGA to start/stop IQ sample stream. In case of LimeSDR-USB it starts stops sample transfer between LMS7002M and FX3.
Ok, so how do I prevent the Rx mixer from inverting the vector phase of channel B wrt channel A at random every time I change the LO frequency, any ideas?
It seems that the problem has something to do with the RxPLL, as it also does it when the Rx PLL is switched off and on.
We have tried to generate loopback signals from the Tx to the Rx on channel A and B simultaneously and found that we cannot predict the phase ambiguity of the PLL as is seems to occur for both the Rx and the Tx. My question is:
a) Is there a way to avoid the phase ambiguity of the Rx mixer PLLs by setting a parameter on the PLLs?
b) if not, is there a way to detect the phase reversal (i.e. using BIT)?
c) Alternatively, is there a way to lock the PLL of channel A and channel B so that they are phase coherent, then it wouldn’t matter if there is a phase ambiguity as long as it occurs on both channel A and channel B so the relative phase is the same?
I’ve translated this code as best as possible in our embedded platform in C on our own board, ie not LimeSDR. When implemented we occasionally get the 180° flip @KMichaelides has talked about, and what appears to be totally random phase difference between A and B. In the end we rolled our own calibration where we trigger the cgen forward divider (0x0086[4]) and reset the logic registers (0x0020[9,11]) then check for channel alignment. Still, if we use the quadrature alignment routine from LimeSuite the 180° jump occurs when the frequency is changed because the c driver routine toggles 0x011C[0,1,4].
Did the steps you describe work or do you still get the 180 degree phase jump?
We still get the 180° jump randomly when the frequency is changes. Our current approach to solving the jump works but it appears to be frequency dependent, we’re working in a range from ~1 - 3Ghz. When the frequency is changes I sample the IQ data and calculate the average phase difference, if that phase difference is between 0 and -PI I add PI to align it back. it works more often than not, but occasionally at the lower frequencies it won’t. I have spent several days trying to find what could indicate the jump is happening but I’m coming up empty.
Are you using the c driver code?
We are using C code on a custom board. What we have found is that the phase reversal occurs in both the transmitter and the receiver, so using the RF loopback (to avoid having to provide an external test signal) there is no way of telling which one has flipped or if both have flipped, as in that case the loopback phase difference will appear correct.
However, I recently analysed the ‘streamer’ code shown above and found a function called ‘RstRxIQGen()’. Having tested it, it seems to successfully revert the I&Q phase of the receiver to a known state, at least at some LO frequencies as it hasn’t been fully tested yet. The function appears to reset the forward divide and the quadrature generator of the Rx PLL, which I have found is where the problem is. We still get phase flipping in the transmitter though, but this can now be detected and compensated using RF loopback.
So I just figured out how to compensate for the flipping, on our board we connect the tx to the rx for an “external” loop-back. When changing Rx frequency we read in the alignment value and subtract that offset from the input to bring the phase difference down to zero. This would cause alignment to sometimes cause calibration to unexpected values. Turns out the rx was getting saturated. The tx pad gain is a function of the frequency and the lna and pga gain is based on the tx pad gain. This is done to try and get a certain amplitude of the signal
We are also in the process of building our board and it seems like we will encounter this issue soon. We are building a multi-chip system and doing an external loop back will not be feasible for us.
Look forward to hearing about a software-only fix.