LMS7002M 180 degree phase jump

We have a long standing issue with phase alignment of channel A and channel B. It seems that this is a known issue as I found a discussion on this topic “Application for using the 2 RX channels simultaneously”, but it is not clear if a solution has been found for the 180 degree ‘random’ phase reversal between channel A and B, particularly as if we are using a custom board so the method is important to us.

I have partially resolved the issue of phase alignment by generating a CW signal using the Lime and activating the baseband loopback. Small differences in the phase alignment can be found and corrected, as the loopback signal seems to have very similar phase offset with the externally generated signal using a signal generator and 0 degree splitter to feed channel A and B simultaneously, except that the random 180 phase reversal (on power up or changing LO frequency, etc.) cannot be detected by baseband loopback as it seems to occur further down the chain (i.e. in the RF mixer).

The obvious solution to this is to activate the RF loopback, which also experiences the same 180 degree phase reversal. Unfortunately so does the transmitted signal, so this is not a reliable method of detecting it in order to compensate. Does anyone have a more reliable solution?

I am having the same issue trying to use the LimeSDR Mini as a VNA (among other things), and I’m trying to find a solution as well. I was trying to use the Python library to do this. They have a branch called PhaseAlignment on the LimeSuite git, one which I think was merged into the master (but I’m not sure about that), which they hoped would solve this problem; have you worked with this yet?

Can you clarify when you observe this phase change?

By the way - the PhaseAlignment branch mostly comes down to a function called AlignQuadrature in src/protocols/Streamer.cpp, which is a little subroutine that fiddles with the gains and the loopback and some other configuration stuff, and then it … tries initializing the stream 100 times and checks if it’s aligned. Some side effect of running RstRxIQGen() seems to cause the phase flipping, and if you invoked that function when you needed to reset the receive, you could probably just use it to align your channels properly. It looks like it’s turning on RF loopback, checking if the channel is aligned, and returning if it is; otherwise not. This SEEMS to be aligning the two receiver channels to each other (all but about one in every 2^100 times), so does the loopback connect the transmitter to both receivers, or just one? It seems like it must go to both receivers, if this is working.

It’ll certainly need some modifications, since it also invokes the FPGA, but the basic idea should work.

Okay, on studying the top level design, each Tx stage can be routed to either or both outputs, and the loopback switches can be turned on for both, so using both switches should give you a phase reference you can compare no matter how they’re misaligned.

And then studying it some more, this is not true at all. If the transmitters suffer from phase alignment issues, I don’t see why this solution would work. Otherwise, they somehow solved this, possibly by enabling the daisy chain LO buffer for the transmitters? I don’t know how they accomplished this, honestly.

I have found that one of the main problems with the 180 degree phase jump is that it occurs on both the transmitter and the receiver, so by enabling the RF loopback on channel A and B, there is no way of telling which one has reversed phase. In the AlignQuadrature function, they seem to get around this by enabling channel A transmitter only and detect the loopback signal on channel A normally, but rely on leakage to detect the same signal on channel B (the gain on loopback receive path B is at maximum). Once the phase reversal has been detected, it is corrected by resetting the IQ generator and repeating the measurement until the phase difference is in the correct quadrant, but this is not very efficient as several measurements might be needed, so I find it is quicker and just as effective to just compensate for the 180 degree phase difference.

Yes, I would say for sure that just correcting for the phase difference is suitable, but on average you’re only going to initialize it twice; in a real-time OS type of environment you may not be able to tolerate the faults and compensating for the phase flip is easier, but otherwise it should be fine.

Ah, thanks for helping me understand what they’re doing there. I was going through the registers and commenting what they were doing so I could try to understand it, but I wasn’t confident they were using leakage to sync in this way.

Do you think their leakage approach is reliable enough and stable enough to synchronize the receive channels for you?

I’m still trying to determine which of the steps in the VNA procedure actually causes the issue. I also don’t fully understand their VNA setup, since they’re detecting phase, but the receive mixer is still on; I would have expected them to detect the phase without mixing. Running it with the frequency value staying constant over a whole run doesn’t trigger the phase flipping, so whatever setFREQ is doing might cause it but only conditionally when the frequency actually changes, so it seems likely it’s to do with the LO initialization?

This is only a hobby project for me, so I haven’t had as much time to spend on it as I’d like.

What I found is that the phase reversal can occur even when the LO is changed and retuned. providing the Tx and Rx parameters are set correctly (may need to be adjusted depending on your hardware) then the method seems to be pretty reliable. Please note however that there is also an issue with phase alignment on the Lime, where a random delay occurs in the IF stage between channel A and B. This is also dealt with in their code, but this does not seem to be affected by retuning the LO so the function need to be run only at initialisation

I was able to modify pyLMS7002M’s VNA example to turn on the shunt and make another phase measurement; when I corrected based on that measurement, the phase measurements were coherent and within a fraction of a degree of each other for two runs on the same setup. I’ve posted these modifications to GitHub and I’m writing the three-standard calibration routine that makes use of short, open, and load calibrations, in case anyone has a set of calibration standards and a directional coupler laying around, but they just don’t happen to have a VNA on hand …

@therealmarauder,

Where is that github post with the mentioned modification ?