Question about Limesuiteng-integration fork

[Prajwal]

Hi,

I have installed LimeSuiteNG v25.1.0 on my system and confirmed that:

• LimeSDR Mini v2.4 is detected correctly via USB

• LimeSuiteNG libraries are installed and linkable

I was following the discussion:
https://discourse.myriadrf.org/t/limenet-micro-2-0-de-expected-performance/12991

In that thread, it is mentioned that the limesuiteng-integration fork of OpenAirInterface5G is fully integrated and functional, tested on x86.

Based on this, I cloned the Lime-maintained OAI fork:

https://github.com/myriadrf/openairinterface5g/tree/limesuiteng-integration

and attempted to build the gNB using:

./build_oai -w LMSSDR --gNB -C

However, the build fails during compilation of

radio/LMSSDR/limesuiteng_lib.cpp, below are the terminal logs:

**Build error summary **

Build fails while compiling radio/LMSSDR/limesuiteng_lib.cpp
Error 1:
invalid initialization of reference of type ‘lime::StreamMeta&’ from expression of type ‘lime::StreamTxMeta’
Occurs in trx_lms7002m_write() when calling
LimePlugin_Write_complex12(…)
LimeSuiteNG header expects:
LimePlugin_Write_complex12(…, lime::StreamMeta&)

Error 2:
invalid initialization of reference of type ‘lime::StreamMeta&’ from expression of type ‘lime::StreamRxMeta’
Occurs in trx_lms7002m_read() when calling
LimePlugin_Read_complex12(…)
LimeSuiteNG header expects:
LimePlugin_Read_complex12(…, lime::StreamMeta&)

Error 3:
no match for operator= for std::vectorLimeRuntimeParameters::PortParams
Triggered by:
params.rf_ports = {{sample_rate, rxCount, txCount}};
Indicates rf_ports initializer-list assignment is incompatible with current LimeSuiteNG API
Build stops at target oai_lmssdrdevif
Using LimeSuiteNG v25.1.0 on Ubuntu 22.04 (GCC 11.4)

My Questions are:-

1. Which LimeSuiteNG version / commit is officially supported by the limesuiteng-integration branch of OpenAirInterface5G?, Is there a recommended LimeSuiteNG tag or commit that should be used when building OAI with Lime hardware?

2. When Inspected the limesuiteng_lib.cpp library file some functions was found not implemented [trx_lms7002m_set_gains,trx_lms7002m_set_freq] and some functions were the cause of the above errors.

3. I am using LimeSDR Mini v2.4:

• Have you tested the current OAI Lime integration with LimeSDR mini v2.4?

• Are the .ini files under openairinterface5g/radio/LMSSDR/ compatible with LimeSDR Mini v2.4?

System information

CPU: Intel Core i7 (x86_64)
OS: Ubuntu 22.04 LTS
Kernel: 5.15.0-163-lowlatency
LimeSuiteNG: v25.1.0
SDR: LimeSDR Mini v2.4

My goal is to implement the OpenAirInterface 5G stack using the LimeSDR Mini v2.4.

[ricardas]

Hi,

@Prajwal

Which LimeSuiteNG version / commit is officially supported by the limesuiteng-integration branch of OpenAirInterface5G?, Is there a recommended LimeSuiteNG tag or commit that should be used when building OAI with Lime hardware?

LimeSuiteNG ‘develop’ branch should be used.

@Prajwal

Are the .ini files under openairinterface5g/radio/LMSSDR/ compatible with LimeSDR Mini v2.4?

.ini files are not always compatible between boards, in any case .ini files are not required, they are only used for very fine tuning of non generic hardware parameters.

@Prajwal

Have you tested the current OAI Lime integration with LimeSDR mini v2.4?

Most of current testing is done with PCIe based boards, but I don’t see a reason why LimeSDR mini v2.4 would work any differently.

[Prajwal]

Hi Ricardas,

Thank you for your response. Regarding the points you mentioned, I would like to clarify that I am using the LimeSuiteNG develop branch. However, I am still encountering issues when building the limesuiteng-integration repository using the following command.

→ ./build_oai -w LMSSDR --gNB -C

It is saying build has failed and the cause of it is openairinterface5g/radio/LMSSDR/limesuiteng_lib.cpp

This is the summary of the errors given:-

1. The build fails while compiling radio/LMSSDR/limesuiteng_lib.cpp for target oai_lmssdrdevif.

2. Primary error: invalid initialization of reference lime::StreamMeta& from lime::StreamTxMeta.

3. This occurs in trx_lms7002m_write() when calling LimePlugin_Write_complex12().

4. A symmetric error occurs in trx_lms7002m_read() with lime::StreamRxMeta.

5. The LimeSuite API expects lime::StreamMeta&, but TX/RX-specific meta types are passed.

6. This indicates an API incompatibility or breaking change in LimeSuite headers.

7. Additional error in device_init(): no matching operator= for std::vector"LimeRuntimeParameters::PortParams"

8. A brace-enclosed initializer list is assigned to a vector, which is not type-compatible.

9. This suggests a struct or container definition change in LimeSuite runtime parameters.

10. Overall failure is due to version mismatch between OpenAirInterface code and installed LimeSuite.

I have attached screenshots of the build errors in the previous message. I would appreciate it if you would review them and let me know whether there is anything incorrect in the build command I am using.

Additionally, could you please share the recommended or up-to-date build instructions for the limesuiteng-integration fork? I want to ensure that my build environment and procedure are aligned with the expected setup.

[N0YKG]

What version of C++ are you using? C++11, C++17, C++21? Some of what you describe sounds like an older C++ version being used (e.g. the vector not being able to be initialized from a brace enclosed list of initializers).

[ricardas]

Hmm, not sure how the meta changes got there, partial rebuild was fine, only clean rebuild failed.
Anyway, I’ve pushed a fix to the OAI repo.

[Prajwal]

Hi Ricardas,
After Cloning the Lime-maintained OAI fork on Ubuntu 22.04 and when rebuilding observed that build fails . The error occurs in radio/LMSSDR/limesuiteng_lib.cpp, where
LimeRuntimeParameters::PortParams is initialized using a brace-enclosed initializer list ({sample_rate, rxCount, txCount}), but the current LimeSuiteNG PortParams struct only provides a default and copy/move constructors, not a parameterized one. As a result, the compiler reports “no matching function for call to PortParams(…)”. This appears to be an API mismatch between the OAI LMSSDR integration code and the installed LimeSuiteNG headers.
below are the terminal logs:

[ricardas]

The initializer list problem seems to be due to compiler version. I’ve removed the use of initalizer list, and updated OAi to the latest version. Update your LimeSuiteNG and OAi sources, now they should build without errors.

[Prajwal]

Hi Ricardas,
After updating LimeSuiteNG and OAI, I built the gNB with Lime support, and the build completed successfully.
Then When I ran the lmssdr.conf file located at
targets/PROJECTS/GENERIC-NR-5GC/CONF/, it asked for an --rf-config file. This was unexpected, as I had not encountered this requirement before.

Upon further analysis, I noticed several .cfg files under radio/LMSSDR/. I selected a file and configurated specific to LimeSDR Mini v2.4, renamed it to Limesdr_mini_v2.cfg , and reran the configuration file. The gNB started running, however, I observed packet loss logs.

The packet loss appears to be due to the default lmssdr.conf being configured for 106 PRBs, which requires a sampling rate of 61 Msps, whereas the LimeSDR Mini v2.4 supports only 30.72 Msps. To address this, I modified lmssdr.conf to use 24 PRBs with 30 kHz SCS and 10 MHz bandwidth, resulting in a sampling rate of 15.36 Msps in OAI.
However, after making these changes, I am now encountering errors when attempting to run the configuration file, as shown below:

When the same configuration ran in the OAI stack , there is no errors .
Then what I observed is that when a known working configuration file that i have tested to work in OAI stack (USRP conf file 24PRB) and replaced the parameters in the lmssdr.conf file and then tried running , but still i am getting the same errors.

I have attached the lmssdr.conf file and the Limesdr_mini_v2.cfg file that I am using.
lmssdr.conf - https://drive.google.com/file/d/1AXGpL3hwESNW8GVf9PqG728IJtwOzgVz/view?usp=sharing
Limesdr_mini_v2.cfg - https://drive.google.com/file/d/1eKkEa3LWMUVXsNiWvge28LWM-aLdaDzd/view?usp=sharing

[ricardas]

The Limesdr_mini_v2.cfg looks ok.
As for lmssdr.conf, everything in there is OAI specific stack configuration settings, I have no idea what they do, or what that error message means. There’s no need for you to modify and use that lmssdr.conf, simply use OAI configuration file that is working for you with the other SDRs.

[Prajwal]

Hi Ricardas,
I modified the configuration and then to verify , I ran both the gNB and UE with USRP in Openairinterface stack. In this setup, the UE successfully detected the gNB and established connection.
However, when I repeated the same experiment using LimeSDR Mini v2.4 in Limesuiteng-integration fork of Openairinterface ,the gNB runs without any errors, but the UE is unable to detect the gNB at all.
I verified the gain settings on the gNB side using LimeSuite:

->TX gain: 70 dB
->RX gain: 70 dB

I also tested mixed setups:

->gNB with LimeSDR and UE with USRP
->gNB with USRP and UE with LimeSDR
->gNB and UE Lime wired connection with 40dB Attenuation.

In all cases, the UE still failed to detect the gNB.

I even checked in Openairinterface stack , building with limesuiteng_lib.cpp , the build was successful.when I ran the gNB with the same configuration file, there were no errors, but the UE was unable to detect my gNB.

This is the conf file that i am using-> https://drive.google.com/file/d/19lx9__Iz6mOv03fJ13gLxtOkQ4C2ebkl/view?usp=sharing

This is my gNB logs when ran with Limesuiteng-integration fork->

gNB_lime_logs

This is my rf-config file that i am using to drive the limesdr-> https://drive.google.com/file/d/1eKkEa3LWMUVXsNiWvge28LWM-aLdaDzd/view?usp=sharing

[ricardas]

Hi, we’re currently investigating the UE functionality, it acts a bit different then gNB. gNB is configured once at the startup and just streams data, while the UE is attempting to change some parameters dynamically during runtime.

@Prajwal

I also tested mixed setups:

->gNB with LimeSDR and UE with USRP
->gNB with USRP and UE with LimeSDR
->gNB and UE Lime wired connection with 40dB Attenuation.

In all cases, the UE still failed to detect the gNB.

Is your LimeSDR Mini LO calibrated? Using spectrum analyzer check the output of the Tx LO, if it is actually at the desired frequency, it could have a small kHz offset, that would make the 5G communications channels misaligned.

[ricardas]

The LO offset can be adjusted using limeGUI, connect to device, and in Modules->BoardControls you’ll find VCTCXO DAC(runtime) value, adjust it so that the Tx LO would be at exactly/close to desired frequency.

[Prajwal]

Hi Ricardas,
I checked the TX output of both the SDRs (USRP and Lime) running with the same configuration file in GNU Radio.
The Configuration file-

gnb.sa.band78.fr1.24PRB.usrpb210.conf

What I observed is that in case of USRP there is a wideband that can be noticed in the frequency domain:-

12-1-26_usrpb210.webm

While in Lime, that is not the case:-

The Tx LO is being calibrated. I verified it by running the gNB and stopped it when it showed in the logs that packets are being generated, Then connected to LimeSuite GUI and checked , there the Tx was being set to the correct frequency as shown in the logs of gNB.

Regarding the Offset-
In UE , I run this command->
sudo ./nr-uesoftmodem -O ~/openairinterface5g/targets/PROJECTS/GENERIC-NR-5GC/CONF/ue.conf --band 78 -C 3609180000 -r 51 --numerology 1 --ssb 40 --ue-fo-compensation

The ue-fo-compensation handles the kHz drift.

You also mentioned that we can adjust the TX LO, but we are not loading the .ini file , so even if we set it to the desired frequency and then run the gNB, the gNB overrides the values set .
So how can I include that change in my rf-config file so that it takes the correct frequency value.
This is my rf-conf file that is being used->

Limesdr_mini_v2.cfg

[ricardas]

@Prajwal

The Tx LO is being calibrated. I verified it by running the gNB and stopped it when it showed in the logs that packets are being generated, Then connected to LimeSuite GUI and checked , there the Tx was being set to the correct frequency as shown in the logs of gNB.

The frequency number in the settings will always be correct. I’m talking about the analog part calibration.
If the software expects reference clock of 30.72MHz, and configure LO to 800MHz, the GUI will show 800MHz.
But if the actual reference clock is not that exact, and has an offset let’s say 30.72MHz ± couple kHz, then the LO frequency would also result 800MHz ± that offset multiplied, but software is not aware of that and would still show exact 800MHz.
Therefore clock inaccuracies need to be compensated, by adjusting VCTCXO DAC value, it is then stored in device non volatile memory, so the calibration would not need to be repeated.

I suggest you to first get the LimeSDR running as gNB, before even attempting to run as UE. UE has to many variables where it can go wrong.

@Prajwal

You also mentioned that we can adjust the TX LO, but we are not loading the .ini file , so even if we set it to the desired frequency and then run the gNB, the gNB overrides the values set .

The LO analog adjustment value is stored on device memory and is not being modified by applications. You write it yourself manually.

[Prajwal]

Hi Ricardas,
Thank you for your quick response.

As per your suggestion, I will surely do the VCTCXO calibration through DAC, but this may take a few days as our spectrum analyzer is out for calibration. So right now using USRP+GNU radio for spectrum analysis.

Before investigating the frequency offset which might result in failure to connect to UE.I first wanted to confirm if the gNB is even able to stream the initial RF signals responsible to establish the connection with UE through the LimeSDR mini 2.4.
To verify this, I conducted 2 Experiments:-

Experiment 1:- gNB PC → limesdr mini → RF cable → 40dB attenuation → USRP → GNU Radio (Frequency sink)

I ran the gNB on the LimeSDR mini 2.4 and connected its TX port to a USRP through an RF cable with 40 dB attenuation. The USRP was connected to a separate PC running GNU Radio, where I monitored the spectrum at a sampling rate of 15.36 Msps. Since the gNB is configured for 24 PRB (30 kHz SCS, 10 MHz bandwidth), the LimeSDR TX gain was set to 65dB. In GNU Radio, the USRP center frequency (Fc) was set to 3.60432 GHz with a 20 MHz bandwidth, and I monitored the downconverted baseband spectrum in the frequency sink. However, across the entire 15.36 MHz span, I observed only noise with no visible indication of any transmitted signal.

Experiment 2:- gNB PC → USRP → RF cable → 40dB attenuation → USRP → GNU Radio (Frequency sink)

When running the same gNB configuration (the same 24 PRB basic file) with a USRP, I can clearly observe the transmitted spectrum in GNU Radio.

My concern is that the limesuiteng-integration fork may not be streaming samples at all. Even with a frequency offset of a few kHz, I would still expect to observe a spectral signature in the baseband plot—similar to what is seen with the USRP—only shifted by the corresponding offset.

I believe first we should get the spectrum at RF level and then focus on exact frequency tuning.

Could you please check this on your setup with LimeSDR mini 2.4 and let me know if any RF Signature is actually being transmitted.

Thanks!

[ricardas]

From software perspective the OAI gNB, should work, we are currently using it with other PCIe based boards. USB has more latency, but should not pose problems with 10MHz bandwidth, otherwise you would get log messages about dropped Tx data.

@Prajwal

I ran the gNB on the LimeSDR mini 2.4 and connected its TX port to a USRP through an RF cable with 40 dB attenuation. The USRP was connected to a separate PC running GNU Radio, where I monitored the spectrum at a sampling rate of 15.36 Msps. Since the gNB is configured for 24 PRB (30 kHz SCS, 10 MHz bandwidth), the LimeSDR TX gain was set to 65dB. In GNU Radio, the USRP center frequency (Fc) was set to 3.60432 GHz with a 20 MHz bandwidth

Analog part is outside of my expertise, and I’m not familiar with USRP hardware, but 3.6GHz LO, is within LimeSDR Mini range, but it’s RF matching network is not optimized for that frequency, so not sure what the Tx output performance results would be.