Hi,
“RestructureLimeSuite” branch had some changes that address channel offset problem. It is good to know that you were also able to see improvement. Recently, some more changes were made to “RestructureLimeSuite” branch. We think that it should improve things further (maybe get rid of that double peak), however it would be good if more people could test and confirm that the changes actually reduce channel offset variation.
Hi,
It seems that the channel offset fix is moving forward, but I would like to turn the attention a bit to the channel phase coherence issue. My company is currently waiting to see if this issue is solvable so we can acquire 11 limeSDR. Any possible lead on whether the phase incoherence problem is solvable? @Zack @andrewback @ricardas
Kind regards
Here waiting for phase news too… but my 2 x LimeSDRs are already purchased 
Never the less, we stopped possible avionics traffic advisory development project
because it is not sure we can gain diversity and adaptive arrays based on LimeSDR hw
BRG
Djani
Hi,
What I currently observe is that the phase/time offset between two channels is constant during a single run but it may vary between runs.
We are trying to eliminate (or at least reduce) phase/time offset variation between runs or power cycles.
1 Like
Hi @IgnasJ
If the variation between runs were eliminated, it would be extremelly desirable.
But only part of the problem would be solved. In fact the most important problem is that the phase offset is dependent on frequency. In the previous messages it is explained.
Anyway, if you fix the difference among execution, it would be great.
regards
So RestructureLimeSuite branch is up for testing? If so I will try recompile everything and try it out.
I have found that the ongoing phase-coherence issues seem to have something to do with gr-osmosdr. If I use an external program (see above for ‘limerec.py’) then feed the results to a simple gr-osmosdr flow-graph, then the results are coherent.
But if I use gr-osmosdr to use Soapy/LimeSDR ‘directly’ the results aren’t coherent. I have looked at the gr-osmosdr/soapy/limesuite “stack”, and I cannot fathom why this is happening.
I’ve tried your limerec.py code. With high sample rates like 50MS/s (and high corresponding bandwidth), python crashes quite fast, after 50 iterations or less, while with lower sample rates like 5MS/s, it reaches 1 or 2000 iterations, then crashes.
Does python also crashes on your computer or you can go on forever? I’m on Windows, I don’t know if it could be linked.
Is gr-osmosdr a gnuradio block? In our case phase incoherence appears both with LMS and SoapySDR API in C/C++.
The limerec.py script uses SoapySDR Python bindings, which is more direct than going via gr-osmosdr, which will add another layer of abstraction. In any case, interesting to hear that gr-osmosdr may be the culprit.
Yes, it is.
I disagree, as I could also see it when using USRP Source and Sink, not osmocom ones (talking about LimeSuite “master” branch, “RestructureLimeSuite” branch gave much better results, as already shown above).
Could you give a numbers on what phase difference you get and what do you need, please.
It works fine for me on my Linux machine at 6Msps, and runs at least overnight (longest test period so far).
There are two different (but possibly related) issues at play here.
The first of which is inconsistent channel-to-channel phase-offset across “session” re-starts. For my own
purposes, I don’t care about that, but others do.
The more-serious (IMHO) issue is that channel-to-channel phase alignment is not usefully coherent, with
large-magnitude mutual phase-noise occurring over short time intervals, rendering things like phased-arrays
and interferometry completely useless.
When I tried an approach that just used the Python SoapySDR bindings (limerec.py), feeding into a GR flow-graph via FIFOs (still via gr-osmosdr, using the “file” driver type), I found the streams to be coherent.
This is very puzzling, since based on my “shallow dive” into the code, there’s no difference in the way things get set-up in the hardware between the two approaches.
Hi @Zack ,
in the previous posts in this topic, there is a detailed description of the problem.
Anyway, it can be resumed with the following points, as stated @mleech:
a) at each “session restart”, the phase difference offset seems to be “quite random”. I say “quite” because it is not uniformly distributed. There is an amount of limited phase difference offsets that are repeated. (For example, 47 degrees or -110º, if we work with a signal freq close to central frequency).
A real MIMO system requires this offset is 0. Anyway, in case it is not zero but constant among sessions, it would be OK.
b) the phase difference offset is linearly dependent on frequency.
For example, if in the same “session” we use first a test tone close to central frequency, then a tone in another frequency, we observe different phase offset values.
In particular, the phase offsets difference is linearly proportional with the test signal frequency.
Also the slope of this linear proportionality changes among different “sessions”, so be careful with teh tests: it is needed to test always in the same session to observe correctly this secondo effect!
A real MIMO system would require a 0 (or close to 0) slope.
We observe all this things by using both LMS and SoapySDR API in C/C++.
If you need more infos, here we are.
cheers
Hi @nemo,
Regarding (a): did you test it after Ignas update?
Hi @Zack
not yet. We plan to test it today.
@Ignas, @Zack, I have tested updated “RestructureLimeSuite” branch today at frequency of 2.4 GHz. I am seeing a lot of “Reset Tx/Rx IQ Generator” messages, which were not present before, so I guess I was testing the right code 
Unfortunately, things look much worse. Here is a list of problems I have seen:
- RX0 vs. RX1 phase difference depends on frequency,
- RX0 vs. RX1 phase difference histogram no longer consists of one or two dominant values, instead it is much wider and contains a lot of different values (which makes sense when you take into account the problem mentioned above),
- RX0 vs. RX1 phase difference histogram is focused at different center value with every program run (i.e. RX0 vs. RX1 phase difference is not consistent during different program runs)
- In about 80%-90% of cases I got “SoapyLMS7::setupStream() failed” and “popping from TX, samples popped 0/1020” error and warning messages during initialization, and I cannot run the flowgraph then
- Even in remaining 10-20% of cases when I am actually able to run the flowgraph, it exits after several seconds at most, without any error message.
Here are some screenshots I was able to take before flowgraph exited:
To sum up, for me current version of “RestructureLimeSuite” seems to work even worse than “master” branch 
As others (@mleech, @nemo) have said, I agree that the same value of phase difference with different program runs would be “nice to have” feature, but this is not the main problem here - problem of frequency dependence is much more troublesome.
Repeated today the tests with Ignas’s update.
Our SW using LMS API works sensibly better.
Our SW based on Soapy doesn’t work correctly.
We decided to focus on LMS API. Later we’ll do tests based on Soapy.
These are the results.
a) The phase difference seems to be fixed to a stable value among different runs. (for example 47º)
Sometimes once every 5 repetitions of SW stop an restart) it could be observed that the phase difference jumps of 180º (in our case to -133º).
It’s like if one of the two signals changes its sign. Is it possible?
From the output messages, I imagine that, after launching, a process of initialization is repeated until a given condition is obtained. Could be a bug in this condition check the cause of this bug?
b) the phase dfference keeps depending on frequency. We’l do more tests before giving numbers.
cheers!