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=D_ph_0+A*D_f
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.
cheers!!
2 Likes
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.
cheers
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?
thanks
1 Like
Iâm using the SoapySDR API through Python.
mleech,
could you share your external reader code, please?
In this way we could repeat tests with your code.
Thanks
The code is here:
http://www.ccera.ca/files/limerec.py
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 
1 Like
HI ccsh!!
wow!! good post!! 
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.
cheers
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 
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! 