Application for using the 2 RX channels simultaneously

[mleech]

I don’t like having to use a non-standard instance of UHD to get LimeSDR support, and my software, as I said, is hardware-agnostic. It also has different modes. Granted, for interferometer mode, the only currently available hardware that will likely work is USRP, with some hope that LimeSDR can be made to work as well.

But in the non-interferometric modes, my software supports RTLSDR, AirSpy, USRP, LimeSDR, BladeRF, HackRF, and any others that are supported by gr-osmosdr and have “reasonable” specs. I cannot achieve that through UHD/USRP support alone, and, as I said, having to ask my users to install a non-standard version of UHD is unpleasant.

[mleech]

OK, so, after a little bit of digging, there are SoapySDR plug-ins for most major SDRs now. Now I have to ponder what my strategy going forward will be.

[mleech]

Nope. Even Josh now recommends using gr-osmosdr wrapper with SoapySDR instead of his “GR native” Soapy wrappers for GR.

So, back to square one. The gr-osmosdr interface for LimeSDR appears to break coherence. It’s a myster as to why.

[mleech]

A subtlety that I missed is that SoapyUHD allows any supported-by-SoapySDR device to “appear” as a UHD device. I will experiment with that instead of gr-osmosdr.

[ccsh]

That’s exactly what I mean, all of devices that you mentioned are supported by SoapySDR by corresponding plugins, and thanks to SoapyUHD it should be possibile to control all of them with UHD blocks. Of course, fixing gr-osmocom blocks would be ideal solution, but for now at least you got some promising workaround

[mleech]

Certainly, gr-osmosdr needs to be fixed in this case. I did a little bit of a dive into the code last week, but couldn’t find any reason for it.

[mleech]

I built SoapyUHD and a bunch of drivers to go with it.

UHD can no see the LimeSDR no problem. That’s kinda neat.

HOWEVER. I still see no useful channel-to-channel coherence. My head is of the scratching.

[mleech]

I’m now getting coherent results even with gr-osmosdr with the PhaseAlignment branch. Well done!

[ccsh]

That’s interesting as there was no another recent update in that branch So probably something else helped. Can you describe what exactly did you do?

[mleech]

I rebuilt everything with the latest pulls (gr-osmosdr, and friends, LimeSuite from PhaseAlignment branch, SoapySDR, SoapyUHD, SoapyRTLSDR, SoapyAirSpy, SoapyHackRF, SoapyBladeRF).

I then unplugged the radio, plugged it back in, and used my spectro_radiometer application in interferometer mode, using:

soapy=0,device=limesdr,nchan=2

For the device field in gr-osmosdr.

Waited for Cass. A to go through the beam, and I was getting strong fringes.

I run another instance of the App on another machine, and it gets a copy of the antenna signals, but uses a USRP B210–this has worked well for years.

Tomorrow’s task is to see if I can build this environment on Arch for Odroid XU4.

[nemo]

Hi @IgnasJ and @Zack

First of all, my feedback.
The new branch allows us to obtain a fixed phase offset among different execution: well done.
Great job, thank you.

Now, only a little step is needed to reach a really useful phase alignment.
It is needed to solve the phase offset dependence on frequency.

Here some data about what we observed.
Data at:
sampling freq= 22 Msps
central freq= 1575 MHz
LPFilter= 21 MHz

A linear dependence is observed like this:
-9 MHz, 41º
-6 MHz, 44º
-3 MHZ, 45º
0 MHZ, 47º
+3 MHZ, 49º
+6 MHZ, 50º
+9 MHZ, 52º

Among different executions, we observe two things:
a) @ 0 MHZ, the phase offset is always 47º (that’s what you just fixed, GREAT!!!)
b) the slope is not constant.
The interesting part is that somethimes we observed a “more sloped” dependence, like this:
-9 MHz, 37º
0 MHZ, 47º
+9 MHZ, 56º

but also an interesting “less sloped” dependence, like this:
-9 MHz, 46º
0 MHZ, 47º
+9 MHZ, 48º

This last condition is a almost real phase alignment because minimizes the frequency dependence and make the system practically MIMO. My feeling is that we are very close. All the comunity spent time in testing it and trying to give a precise feedback about phase alignment.
Only a little last effort is needed. If you could fix it, it would be the best news for us!

If anyone in the community (for example @modimo) could confirm what we observed, it would be great.

cheers

[IgnasJ]

@ccsh

Okay, I was able to create simple flowgraph which should allow us to replicate the initialization issue: https://ufile.io/1dwv4

Basically, it feeds test cosine signal into single TX channel via “USRP Sink” and then receive it with two RX channels via “USRP Source” block. Also, received IQ signals are plotted in time domain via “QT GUI Time Sink” blocks. The gains and center frequency were chosen so that received signals should be nicely visible when using LimeSDR’s stock antennas.

While testing this, make sure to run it many times in a row - the issue does not occur every time.

I have tried running your flowgraph.
There seems to be a race condition in flowgraph initialization. E.g. UHD sink starts streaming before UHD source configures Rx streams and that results in “Stream cannot be set up while streaming is running” error. Using 2 channels for Tx (sending ‘0’ to second) helps to avoid this error. However, UHD source still doesn’t like something when streaming is started before finishing configuring all streams and produces “gr uhd usrp source0 - USRP Source Block caught rx error code: 2”. I will see if some workaround can be implemented for situation where we don’t have control of initialization order.

[Aridane]

We have observed exactly the same thing using the LMS API in C.

[ccsh]

@Ignas, thank you for looking into this. Hope that this workaround will be possible, as it will simplify testing a lot

As for now, here are my observations from further testing:

Sometimes I also observe following UHD error:

UHD Error:
    MCU working too long 98

But for now I don’t see any particular problems coming from it.

Also, my flowgraph sometimes exits with no error message, but I was able to reduce it by removing not used blocks.

Also, I just checked that actually there are three “holes” in frequency coverage. I cannot set any TX/RX frequency from their ranges:
[690;800) MHz, (first hole)
[1380-1600) MHz. (second hole, aka. first hole x 2)
[2760-3200) MHz (third hole, aka. first hole x 4)

Also, for some frequencies the phase difference depends on frequency in a more visible way that for other frequencies. Here are some examples:
0.3 GHz

1.6 GHz

2.4 GHz

Especially for higher frequencies, phase difference histograms are getting wider and more often consist two dominant peaks:
3.5 GHz

3.8 GHz

[booth]

Wow,
I didn’t know that I can use the USRP Sink-Sources for LIMESDR until I saw your flowgraph.
Thanks for that.
However, I cannot use the second RX channel. I’m getting:
RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of range for configured RX frontends and can’t get the second channel.Any Ideas?

[CoraDias]

Hi…as per my knowledge phase compensation is a good suggestion, and it might solve someone’s issues for their particular application. MIMO also works fine, no denying that. Sadly, the problem I am having, and I think some of the above commenters are also having, is a lack of phase coherence, not a lack of MIMO.

pcb assembly company

[mleech]

MIMO applications require ongoing phase-coherence. But they typically expect some amount of phase-offset on “system startup”, and calibrate it out.

Without ongoing phase-coherence, then MIMO cannot be made to work.

What exactly do I mean by phase coherence? Consider a signal (let’s say a pure tone) that is provided to both channels. The inter-channel phase measurement of that signal should be more-or-less constant over time. There will always be some small amount of mutual phase noise, but applications, in general expect that.

Now, what I was seeing prior to the “PhaseAlignment” branch was that in some circumstances, notably when used via gr-osmosdr, the channel-to-channel phase was apparently random.

Now, it isn’t. It is coherent (modulo my earlier comment about small amounts of mutual phase-noise).

[shincky]

@CoraDias

phase coherence

yes, looking for it as well.

[astancombe]

Hi @IgnasJ - Thanks so much for looking into these issues!

I’m not sure if what you’ve been working on has been attempting to address the specific issues I’m having, but I thought I’d test out the PhaseAlignment branch anyway and report my results.

It appears as though the phase difference between RX1 and RX2 is still variable between separate runs of the LimeSDR - though it is always 180 degrees off for me. Is this something that you expected the PhaseAlignment branch to have fixed?

I tested this using SoapySDR, sweeping up from 1 - 2 GHz in steps of 10MHz (so retuning to a different centre frequency every 10MHz) and saving the phase data for each RX channel. My measurement setup can be seen below, and was just a matched load on a coupler, using the reflected and coupled ports for RX1 and RX2. I would expect the results from this to be a linear phase change over frequency, and that’s almost what I get, except for the 180 degree jumps that can be seen in the second image.

[booth]

Actually I would prefer a 180 degrees between RX1 and RX2. Why? The device would act as an Interleaved ADC and we could get 2x the sampling rate.That would make the LimeSDR a broadband receiver…