Application for using the 2 RX channels simultaneously

We have LTE base station software running MIMO with LimeSDR, plus customers running their own stacks MIMO, so it should be possible to solve it. I believe another higher priority task caused this to be de-scheduled for a little while, but that attention has now turned back to it.

MIMO communications algorithms are designed to work in multipath environment. That is why they work. They don’t need aligned receivers. So it’s not any proof. In any other MIMO applications time alignment is crucial. Is there ANY working example of working beamforming, interfereometer, direction finding that will prove alignment?

That’s right, the problem raised here is MIMO channels alignment issue, not just the possibility to transmit/receive MIMO signals (this is possible and was indeed already tested by many users).

Hi guys,

just to help the community (or @zack, @andrewback and the guys that are working to solve the problem), I would like to share some observations about the problem.

By injecting a sine at frequency f0 + D_f in both input channels (f0 is RX central frequency), the expected phase difference between the 2 channels is zero (or a small value).

But what the observed phase difference can be modeled as follows:


D_ph_0 is a fixed offset, constant during a program execution, but it changes among different executions.
This offset seems to assume some fixed values, for example 47º or -110º.

The second part shows a component linearly dependent with frequency, in fact:
D_f is the frequency separation between the test signal and the RX central frequency
A is the slope of the line. It is constant during the same program execution, but it changes among different executions. In particular A seems to assume also fixed values. Furthermore A values seem to be multiple of a fixed values.
It’s something like:
A=nX with n integer

For example, in our tests we observed
A=12 degrees per MHz, 24 degrees per MHz

I don’t know if it could be useful for anyone, but I imagine it’s a godd starting point.



I observed exactly thhe same thing. It all looks like time/sampling misalignment.

I was able to achieve apparent phase-coherence using code from Dave Lonard’s interferometer experiments, feeding a pair of FIFOs going in to my Gnu Radio application.

However, “direct” using the gr-osmosdr Soapy interface yields nothing useful in terms of coherence.
This is perhaps part of the puzzle, but not sure why.

I have crafted simple GNU Radio Companion app in order to check both RX channels mutual phase offset. My idea is to transmit some known QPSK signal via TX 0 channel and plot constellations of signals received via both RX 0 and RX 1 channels. By comparing rotation angle of those constellations, RX channels mutual phase offset may be determined.

For such scenario there is always constant phase offset between both RX channels (in general, different for every program run). So it seems like phase coherent receiving should be possible.

Not so fast. Phase shift is linearly dependant with frequency(dfi/df=const). It is possible to correct that but its not so simple. Either FIR filtering or phase correction after FFT for each bin individually. Anyway lots of processing power goes to the wind. Unless it is fixed on lms7002 level there is no point in using limesdr for applications requiring phase coherency.

That’s the key - I can’t observe this linear dependence of RX channels phase offset vs. frequency. Can you explain what operations did you perform on received streams in order to plot that line?

What I observed is that phase relationships between the two channels were apparently-random over small measurement intervals (a few seconds at a time).

When I moved to using an external “reader” application, that problem appeared to be corrected. This leads me to conclude that gr-osmosdr is setting up the device in a way that causes apparent small-time-scale and significant magnitude phase-noise between the two channels.

HI mleech,

what is an external reader?
Are you usign Soapy or LimeSDR drivers from a C application?
We didn’t use gr-osmosdr but observed the problem.


Hi ccsh,

I will explain how to do the test.
The simplest way is the following:
a) if possible, use a well known, indipendent source (for example we’re using a USRP B210) to emit the test signal. If you can’t, try to use the LimeSDR( but it could be difficult to emit and read 2 channels at the same time).
Use a splitter and calbe of the same length to distribute the signal at the input of LimeSDR RX channels.
b) previously generate a IQ file with a chirp signal: a complex sine wave whose frequency increases at a linear rate with time (for example, a freq swap from -1MHz to +1MHz)
c) Prepare LimeSDR-based code or a model that:

  • read two channels a window of data
  • calculate the phase of both signals
  • calculate phase difference
  • visualize the result (for example as histogram)
    d) start the reading without external signal (in order to allow a correct calibration)
    e) start emitting
    f) observe te result

After playing a bit with all the parameters (like the number of points, the emitted power, the RX gain, etc), when the test is correctly prapared, you should see a uniformly distributed histogram.

At each repetition of the test, you will observe two things:
a) the center of the uniformly distributed histogram changes (offset)
b) the limits (that is the width of the histogram) change

the b) parameter is proportional to the slope of the linear dependence. We found that the slope is not constant among test repetitions.

If you repeat the test, for example, by changing the frequency swap (for example from -2MHz to 2MHz) you will see that the histogram is wider.

You can also do another thing, that maybe it’s easier but gives you the same result.
a) emit a complex sine.
b) observe the mean value of the gaussian you obtain as result
c) emit a complex sine at difference frequency
d) observe the mean value of the gaussian

If you have an external source, you can change the frequency without stopping the reading process. This is important because each restart in the reading process sadly produces an alteration of the result.

You’ll observe that the “distance” of the mean values of the gaussinas change proportionally to the frequency distance of the test signals.

I don’t know if I was clear in my explaination.

Please, could you try to do this test, and share the result?

1 Like

I’m using the SoapySDR API through Python.

could you share your external reader code, please?

In this way we could repeat tests with your code.

The code is here:

It sets up, then records the channels in their own FIFO files

Here is set of fringes from earlier today:

Note that in my application, I don’t care about random phase offsets on startup. I only care about ongoing coherence, which I wasn’t seeing with a “direct” gr-osmosdr connection.

1 Like

@nemo, thank you for detailed description of the test procedure. Thanks to it I was finally able to reproduce the issue. I couldn’t see it at first, because I was transmitting at 2.4 GHz, where this effect for some reason does not occur. But at 1.9 GHz I could see it almost every time. I was using BAND2 port on TX side and LNAH ports on RX side and stock antennas (yeah, I know that wired connection via splitter and cables of equal length would be better for this purpose, but as non-zero phase difference is expected anyway I think keeping RX antennas close in stable position and using high gains should be good enough).

For “master” branch of LimeSuite at conditions described above, typical effect is as follows:

So it matches all of your observations. However, “RestructureLimeSuite” branch seems to help a little, as typical results are like below:

Note much smaller phase variations and interesting two peak points on histogram. Though it is far better than in “master” branch, it is still not perfect, so I hope @zack will be able to improve that even more :slight_smile:

1 Like

HI ccsh!!

wow!! good post!! :wink:
and very interesting results!!

The cables and splitter are useful to guarantee, for example, that the power is stable, that there’s no multipath and you have more controlled conditions. But also with antennas only it works, as you showed!

We’ll check the RestructureLimeSuite.

In our tests, we also observe the “double peak”.
I imagine it could be caused by DC offset (that you can observe , for example, in channel 0 time course), and by the IQ imbalance.
If you execute a RX calibration, the DC offset would desappear, and probably also the double peak.


That’s all true, but to be honest when using LimeSDR with high gains and stock antennas in a small room where nothing is moving, these effects are neglible :wink:

DC offset correction won’t help, it’s the matter of IQ imbalance. With manual IQ magnitude/phase adjustment I was able to convert histogram to single peak every time in few seconds. The question is why sometimes automatic IQ imbalance calibration in LimeSDR works well and other time not. I saw also “CalibrationUpdate” branch, which sounds promising. @ricardas, can you tell what is its status (it has not been updated for over two weeks now)?

I was on vacation, the CalibrationUpdate is pretty much done, just need to add adjustable timing between RSSI measurements and test it. Will probably be done next week, unless more bugs appear.

1 Like

Great news, thanks for sharing that info! :slight_smile: