Application for using the 2 RX channels simultaneously

[ccsh]

I am testing it with GNURadio, i.e. using SoapySDR, and maybe that’s why I did’t see any improvement (actually it was more like opposite). But I suppose that correct SoapySDR support should be very high on a priority list, since this is the only way to use LimeSDR in applications not written especially for it with LMS7 API…

[nemo]

Hi ccsh.

If you stop and relaunch the test, does the mean value of the “uniform” phase difference distribution change?

bye

[nemo]

[Divaldo]

Hi all, i started to use the LimeSDR PCIe right now and i am using the self_test.in with loopback RF at two channels. I am running the FPGA onetone signal, but the phase between two received channel are floating ± 5 degrees. The variation occur during the period of the signal. Does someone have any idea about what could be happen?

[shincky]

hi Divaldo
can you tell us after several restarts the misalignment is fixed or not

[Divaldo]

Hi Shincky.
No, continue misaligned, but in my tests the misalignment occurs between the samples without restart the board.

[Cornie]

I can think of 3 possible causes:

1. non-linearity in the TX - RX amplifiers. Reducing the output level should give some improvement.
2. spurious signals of the IQ modulator -demodulator. If so, using a filter in the TX-RX loop should improve things.
3. IQ Amplitude Calibration Errors

A FFT of the received signal could show unexpected spurious signals

[nemo]

Hi @Zack

Any update about the 180º jump??
Did you observe it?

I’m waiting the bug is solved to buy some devices.
cheers

[ccsh]

I have just tested the most recent version of LimeSuite via GNURadio Companion with UHD blocks and it still keeps exiting after several seconds at most with not a single warning or error message being displayed at all. So unfortunately I gotta feeling that I won’t be able to help testing following low-level (i.e. LMS7 API-based) fixes, since with recent version of LimeSuite my LimeSDR cannot be used in GNURadio in a reliable way.

[IgnasJ]

Hi,
Could you clarify if it no longer works with master branch or RestructureLimeSuite branch or both?

[ccsh]

Both.

[Aridane]

@nemo

Any update about the 180º jump??

UP!

[IgnasJ]

@nemo

Any update about the 180º jump??

We have made some additional changes to address channel alignment issues including 180º jump. The most recent changes that attempt to correct this issue are now in ‘PhaseAlignment’ branch. Please, try that and report your results.

Anyone, who is still experiencing phase alignment issues after testing ‘PhaseAlignment’ branch, please share your setup information and/or test code or other information that might help to replicate the issue.

[Aridane]

Hi @IgnasJ. We have performed some tests and it looks really promising . The initial phase offset seems static for each Fc. We will perform more thorough testing tomorrow and report back.

[ccsh]

Wow, I can confirm that indeed things look much better now. I am still able to run my chirp measurement flowgraph only once in a while, because in many cases it keeps printing the following UHD error and warnings:

Generating: '/home/sdr/Pulpit/grc/top_block.py'

Executing: /usr/bin/python2 -u /home/sdr/Pulpit/grc/top_block.py

linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.003.000-0-g423b4c19

-- Make connection: 'LimeSDR-USB [USB 3.0] 9062000C4220F'
-- Reference clock 30,72 MHz
-- Device name: LimeSDR-USB
-- Reference: 3,072e+07 MHz
-- LMS7002M calibration values caching Disable

UHD Error:
    Stream cannot be set up while streaming is running
thread[thread-per-block[13]: <block gr uhd usrp source (1)>]: SoapyLMS7::setupStream() failed: 

UHD Warning:
    popping from TX, samples popped 0/1020

UHD Warning:
    popping from TX, samples popped 0/1020

UHD Warning:
    popping from TX, samples popped 0/1020

UHD Warning:
    popping from TX, samples popped 0/1020

However, when it actually starts, I can see the same and very stable phase difference, repeatable in different program runs, as in below pictures:

Everytime I could see single peak occuring at the same value in phase difference histogram.

During my test, I have noticed that some frequencies cannot be set both in GNURadio and custom SoapySDR-based C++ app, for example 1.457 GHz, as I end up with following errors:

UHD Error:
    SetFrequencySXR(1457 MHz) - cannot deliver frequency

UHD Error:
    SetFrequencySXR(1457 MHz) - cannot deliver frequency

UHD Error:
    MCU working too long 98

As for this strange flowgraph-initialization issue, I will try to track down the reason as it seems like it may be something wrong with my chirp-based flowgraph or some particular block is causing this, because for now I cannot replicate that in other simpler flowgraphs. Will let you know when I’ll gather more information about that.

Anyway, good job about this phase alignment!

[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 am using GNURadio Companion 3.7.11.1, UHD 003.010.003, both built from source on Xubuntu 16.04 OS.

I believe tagging @IgnasJ and @joshblum would be best here.

[mleech]

I’m still seeing random-phase-errors using gr-osmosdr, built against the PhaseAlignment branch of LimeSuite, and updated SoapySDR and gr-osmosdr.

What is the advantage of the “pretend to be a USRP”?? Interface? Since it requires that patches be
applied to the UHD codebase, it seems, well, “icky”.

[ccsh]

I can confirm that when using gr-osmocom blocks instead USRP ones, the issue is still there:

That being said, personally I think gr-osmocom blocks are kind of useless anyway, since when using them you cannot for example provide different DSP frequency offsets for both channels in order to transmit/receive at different frequencies (e.g. use FDD mode).

@mleech

Since it requires that patches be applied to the UHD codebase, it seems, well, “icky”.

I don’t think that’s true. As I see it, phase alignment fix is applied in low-level LMS7 driver, and UHD is just a way to access it through SoapySDR (there is SoapyUHD plugin which allows you to access UHD-controlled devices via SoapySDR and vice-versa).

[mleech]

If you have a GR-based application that is quite hardware agnostic (as my radio astronomy apps are), then I cannot fathom why one would characterize gr-osmosdr as “kind of useless” simply because they don’t expose the entirety of an underlying API.

I cannot get the “agnostic” feature-set from just using Soapy yet–that may change in the future, but until that time, I must rely on gr-osmosdr to make my applications reasonably hardware-independent.

[ccsh]

Oh, sorry, maybe I put it wrong way - I meant that these blocks are useless for me, as USRP ones give me all I need

Just curious, why can’t you install UHD and also try to use USRP błocks? Is there some function of osmosom błocks which you need and it is not available on USRP błocks? If not, then I believe switching into USRP błocks is a matter of quite minor flowgraph modification.