# Question about Limesuiteng-integration fork

**URL:** <https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008>\
**Category:** LimeSDR\
**Created:** [12 January 2026 05:25 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008 "2026-01-12T05:25:13Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [12 January 2026 05:25 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/1 "2026-01-12T05:25:13Z")

</div>

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](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](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:

 ![WhatsApp Image 2026-01-09 at 10.22.38 PM](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/0/09f6003555d26c7739ccb6faf51724ddea087f82.jpeg)

 ![WhatsApp Image 2026-01-09 at 10.22.18 PM](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/7/75b8011bfefc0d5d7051106fbd4711f877c292ce.jpeg)

 ![WhatsApp Image 2026-01-09 at 10.21.36 PM](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/4/4ae7761219570753f6dde1f9364c38cb2672c748.jpeg)

### \*\*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.

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [13 January 2026 19:21 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/2 "2026-01-13T19:21:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [16 January 2026 06:51 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/3 "2026-01-16T06:51:00Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![N0YKG](https://avatars.discourse-cdn.com/v4/letter/n/3bc359/32.png) [@N0YKG](https://discourse.myriadrf.org/u/N0YKG)\
**Post date:** [16 January 2026 13:06 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/4 "2026-01-16T13:06:24Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [16 January 2026 14:00 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/5 "2026-01-16T14:00:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [24 January 2026 08:53 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/6 "2026-01-24T08:53:21Z")

</div>

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:

 ![WhatsApp Image 2026-01-24 at 12.51.16 PM](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/2/28445fc77f28a151d42a1eb42db040704ae88e11.jpeg)  
 ![WhatsApp Image 2026-01-24 at 12.51.41 PM](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/d/d3ed58860afefa0911a25586822810b0e42bc317.jpeg)

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [26 January 2026 15:48 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/7 "2026-01-26T15:48:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [29 January 2026 04:59 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/8 "2026-01-29T04:59:35Z")

</div>

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.

 ![Screenshot from 2026-01-28 19-13-00](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/d/d1a0bc2b459ea38da9e180263f6eab89966f85c1.png)  
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.  
 ![Screenshot from 2026-01-28 19-14-26](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/3/3c4427784011bc6a114368646c0247b5d1969677.png)  
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:  
 ![Screenshot from 2026-01-29 10-12-22](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/5/5b59651691e026d52fcb2ab5867abed6b85ba2c5.png)  
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](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](https://drive.google.com/file/d/1eKkEa3LWMUVXsNiWvge28LWM-aLdaDzd/view?usp=sharing)

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [29 January 2026 07:11 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/9 "2026-01-29T07:11:39Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [2 February 2026 10:59 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/10 "2026-02-02T10:59:25Z")

</div>

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](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](https://docs.google.com/document/d/1uMfQJwMnGGf2s0jU5wxpD1HiDGcSFiNUpmg4rK3uVFU/edit?usp=sharing)**
>
> This is my gNB logs— dtri03@dtri03:~/Documents/openairinterface5g/cmake\_targets/ran\_build/build$ sudo ./nr-softmodem -O ~/Documents/openairinterface5g/targets/PROJECTS/GENERIC-NR-5GC/CONF/lmssdr\_51PRB.conf --rf-config-file...

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](https://drive.google.com/file/d/1eKkEa3LWMUVXsNiWvge28LWM-aLdaDzd/view?usp=sharing)

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [2 February 2026 11:44 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/11 "2026-02-02T11:44:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [2 February 2026 11:51 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/12 "2026-02-02T11:51:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [3 February 2026 08:16 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/13 "2026-02-03T08:16:35Z")

</div>

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](https://drive.google.com/file/d/10rMRZxyMld-EXRi-7YNaMIo-8AOZ9_Ma/view?usp=sharing)**
>
> Google Drive file.

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](https://drive.google.com/file/d/15lg9gP87mBVxgUnJs2ngybAqX48R6k5U/view?usp=sharing)**
>
> Google Drive file.

While in Lime, that is not the case:-

 ![WhatsApp Image 2026-02-03 at 10.18.05 AM](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/b/bfe63ba5167a80066a66bd6eac54c3279039e0eb.jpeg)

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](https://drive.google.com/file/d/1eKkEa3LWMUVXsNiWvge28LWM-aLdaDzd/view?usp=sharing)**
>
> Google Drive file.

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [3 February 2026 09:23 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/14 "2026-02-03T09:23:38Z")

</div>

> [@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.

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [4 February 2026 07:45 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/15 "2026-02-04T07:45:56Z")

</div>

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.

 ![WhatsApp Image 2026-02-03 at 10.18.05 AM](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/b/bfe63ba5167a80066a66bd6eac54c3279039e0eb.jpeg)

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.

 ![Screenshot from 2026-02-04 12-38-08](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/4/415d814a0c780674443ce59577fe1be67832fb05.jpeg)  
 ![Screenshot from 2026-02-04 12-38-57](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/e/e33e1de451cad45ea49420ab76619abb319cb84e.jpeg)

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!

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [4 February 2026 14:30 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/16 "2026-02-04T14:30:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [13 February 2026 05:39 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/17 "2026-02-13T05:39:12Z")

</div>

Hi Ricardas,

Apologies for the delayed follow-up.

I’ve been running some experiments integrating the OpenAirInterface gNB with LimeSuite and testing on LimeSDR Mini v2.4.

SETUP →

1. OAI → LimeSDR mini v2.4 (LimeSuite plugin) → RFcable → 40dB Attenuation → USRP → GNU Radio (Observed waveform).

 ![Screenshot from 2026-02-11 12-42-19](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/7/778e35eb2db1b5dee6dac0142feec60265d8c021.jpeg)  
 ![Screenshot from 2026-02-11 12-43-33](https://canada1.discourse-cdn.com/flex034/uploads/myriadrf/original/2X/b/be5fdc63a0847b4f2bcbe7c2a6fe15cbf584989f.jpeg)

1. OAI → LimeSDR mini v2.4 (LimeSuiteNG plugin) → RFcable → 40dB Attenuation → USRP → GNU Radio (No waveform)

Observations →

1. Waveform is observed with LimeSuite but UE connection fails.
2. Waveform not observed with LimeSuiteNG.

Could you please verify this behaviour on a LimeSDR Mini v2.4 and advise what the next steps should be?

One more question → what is the command that let the gNB run with the .ini file.Can it be possible to run the .cfg as well as the .ini file ?

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [17 February 2026 07:23 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/18 "2026-02-17T07:23:39Z")

</div>

Hi Ricardas,

I was analyzing why the OAI gNB ( **limesuiteng-integration branch** ) does not produce any RF output when using LimeSDR Mini v2.4.

From the logs I consistently see:

> [HW] Rx channel0: dev0 chip0 ch0 , LO: 3604.800 MHz SR: 15.360 MHz BW: 10.000 MHz | path: 0(‘NONE’)  
> [HW] Tx channel0: dev0 chip0 ch0 , LO: 3604.800 MHz SR: 15.360 MHz BW: 10.000 MHz | path: 0(‘None’)

After stopping the gNB and checking in LimeSuiteGUI:- **TX antenna → NONE**

In the RF config I explicitly set:

```
name= "limesuite";

port0= "dev0"; # OPTIONAL; will use first available device if not specified
dev0 = "";

port0_chipIndex= 0; # OPTIONAL; will use 0 not specified

dev0_rx_Path= "LNAH";
dev0_tx_Path= "BAND1";

tx_gain = 40.0;
dev0_ini = "/home/dtri03/Documents/openairinterface5g/radio/LMSSDR/test5Gnew.ini";            

port0_ch0_txPower_dBm= -10; # OPTIONAL; hint about absolute TX power in dBm; assuming a square signal of maximum amplitude
port0_ch1_txPower_dBm= -10; # OPTIONAL; hint about absolute TX power in dBm; assuming a square signal of maximum amplitude

port0_calibration= "none";
logLevel= 5; # OPTIONAL; enable printing of additional information= 0-critical; 1-error; (default)2-warning; 3-info; 4-verbose; 5-debug
port0_linkFormat= "I12"; # OPTIONAL; data format for transfering

resetBoard = 1;

```

However at runtime the driver still reports `path: NONE`, so the TX antenna selection appears to be ignored or overwritten.

I also tried loading an `.ini` file with the TX path configured, and the same behavior occurs — after the gNB initializes, the TX antenna shows **NONE**.

The gNB Logs →

> dtri03@dtri03:~/Documents/openairinterface5g/cmake\_targets/ran\_build/build$ sudo ./nr-softmodem -O ~/Documents/openairinterface5g/targets/PROJECTS/GENERIC-NR-5GC/CONF/lmssdr\_24PRB.conf --rf-config-file ~/Documents/openairinterface5g/radio/LMSSDR/Limesdr\_mini\_v2\_1.cfg  
> CMDLINE: “./nr-softmodem” “-O” “/home/dtri03/Documents/openairinterface5g/targets/PROJECTS/GENERIC-NR-5GC/CONF/lmssdr\_24PRB.conf” “–rf-config-file” “/home/dtri03/Documents/openairinterface5g/radio/LMSSDR/Limesdr\_mini\_v2\_1.cfg”  
> [CONFIG] function config\_libconfig\_init returned 0  
> [UTIL] running in SA mode (no --phy-test, --do-ra, --nsa option present)  
> [OPT] OPT disabled  
> [HW] Version: Branch: limesuiteng-integration Abrev. Hash: d948c2962f Date: Mon Jan 26 18:46:49 2026 +0200  
> [GNB\_APP] Initialized RAN Context: RC.nb\_nr\_inst = 1, RC.nb\_nr\_macrlc\_inst = 1, RC.nb\_nr\_L1\_inst = 1, RC.nb\_RU = 1, RC.nb\_nr\_CC[0] = 1  
> [NR\_PHY] Initializing gNB RAN context: RC.nb\_nr\_L1\_inst = 1  
> [NR\_PHY] Registered with MAC interface module (0x55a5a85e5b90)  
> [NR\_PHY] Initializing NR L1: RC.nb\_nr\_L1\_inst = 1  
> [NR\_PHY] L1\_RX\_THREAD\_CORE -1 (15)  
> [NR\_PHY] TX\_AMP = 519 (-36 dBFS)  
> [PHY] No prs\_config configuration found..!!  
> [GNB\_APP] pdsch\_AntennaPorts N1 1 N2 1 XP 1 pusch\_AntennaPorts 1  
> [GNB\_APP] minTXRXTIME 6  
> [GNB\_APP] CSI-RS 0, SRS 0, report type 0 (ssb\_rsrp), 256 QAM may be on, delta\_MCS off, maxMIMO\_Layers -1, HARQ feedback enabled, num DLHARQ:16, num ULHARQ:16  
> [GNB\_APP] No RedCap configuration found  
> [GNB\_APP] No PTRS configuration found  
> [GNB\_APP] sr\_ProhibitTimer 0, sr\_TransMax 64, sr\_ProhibitTimer\_v1700 0, t300 400, t301 400, t310 2000, n310 10, t311 3000, n311 1, t319 400  
> [NR\_MAC] Candidates per PDCCH aggregation level on UESS: L1: 0, L2: 2, L4: 0, L8: 0, L16: 0  
> [RRC] Read in ServingCellConfigCommon (PhysCellId 0, ABSFREQSSB 640320, DLBand 78, ABSFREQPOINTA 640032, DLBW 24,RACH\_TargetReceivedPower -96  
> [RRC] absoluteFrequencySSB 640320 corresponds to 3604800000 Hz  
> [NR\_MAC] TDD period index = 6, based on the sum of dl\_UL\_TransmissionPeriodicity from Pattern1 (5.000000 ms) and Pattern2 (0.000000 ms): Total = 5.000000 ms  
> [UTIL] threadCreate() for MAC\_STATS: creating thread with affinity ffffffff, priority 2  
> [NR\_MAC] PUSCH Target 150, PUCCH Target 200, PUCCH Failure 10, PUSCH Failure 10  
> [NR\_PHY] Copying 0 blacklisted PRB to L1 context  
> [NR\_MAC] Set TX antenna number to 1, Set RX antenna number to 1 (num ssb 1: 80000000,0)  
> [NR\_MAC] TDD period index = 6, based on the sum of dl\_UL\_TransmissionPeriodicity from Pattern1 (5.000000 ms) and Pattern2 (0.000000 ms): Total = 5.000000 ms  
> [NR\_MAC] Set TDD configuration period to: 8 DL slots, 3 UL slots, 10 slots per period (NR\_TDD\_UL\_DL\_Pattern is 7 DL slots, 2 UL slots, 6 DL symbols, 4 UL symbols)  
> [NR\_MAC] Configured 1 TDD patterns (total slots: pattern1 = 10, pattern2 = 0)  
> [NR\_PHY] Set TDD Period Configuration: 2 periods per frame, 20 slots to be configured (8 DL, 3 UL)  
> [NR\_PHY] TDD period configuration: slot 0 is DOWNLINK  
> [NR\_PHY] TDD period configuration: slot 1 is DOWNLINK  
> [NR\_PHY] TDD period configuration: slot 2 is DOWNLINK  
> [NR\_PHY] TDD period configuration: slot 3 is DOWNLINK  
> [NR\_PHY] TDD period configuration: slot 4 is DOWNLINK  
> [NR\_PHY] TDD period configuration: slot 5 is DOWNLINK  
> [NR\_PHY] TDD period configuration: slot 6 is DOWNLINK  
> [NR\_PHY] TDD period configuration: slot 7 is FLEXIBLE: DDDDDDFFFFUUUU  
> [NR\_PHY] TDD period configuration: slot 8 is UPLINK  
> [NR\_PHY] TDD period configuration: slot 9 is UPLINK  
> [NR\_MAC] Command line parameters for OAI UE: -C 3604800000 -r 24 --numerology 1 --band 78 --ssb 24  
> [NR\_PHY] dlfreq:3604800 ulfreq:3604800 deltaduplex:0 khz, uldl\_min\_offset:0 khz  
> [NR\_PHY] dlfreq:3604800 ulfreq:3604800 deltaduplex:0 khz, uldl\_min\_offset:0 khz  
> [NR\_PHY] dlfreq:3604800 ulfreq:3604800 deltaduplex:0 khz, uldl\_min\_offset:0 khz  
> [NR\_PHY] dlfreq:3604800 ulfreq:3604800 deltaduplex:0 khz, uldl\_min\_offset:0 khz  
> [NR\_PHY] dlfreq:3604800 ulfreq:3604800 deltaduplex:0 khz, uldl\_min\_offset:0 khz  
> [NR\_PHY] dlfreq:3604800 ulfreq:3604800 deltaduplex:0 khz, uldl\_min\_offset:0 khz  
> DL frequency 3604800000: band 78, UL frequency 3604800000  
> [PHY] DL frequency 3604800000 Hz, UL frequency 3604800000 Hz: band 78, uldl offset 0 Hz  
> [PHY] Initializing frame parms for mu 1, N\_RB 24, Ncp 0  
> [PHY] Init: N\_RB\_DL 24, first\_carrier\_offset 368, nb\_prefix\_samples 36,nb\_prefix\_samples0 44, ofdm\_symbol\_size 512  
> [NR\_MAC] TDA index 0: start 0 length 13 k2 6  
> [NR\_MAC] TDA index 1: start 10 length 3 k2 6  
> [NR\_RRC] SIB1 freq: offsetToPointA 4  
> [GNB\_APP] F1AP: gNB idx 0 gNB\_DU\_id 3584, gNB\_DU\_name gNB-OAI, TAC 1 MCC/MNC/length 1/1/2 cellID 12345678  
> [GNB\_APP] ngran\_DU: Configuring Cell 0 for TDD  
> [GNB\_APP] SDAP layer is disabled  
> [GNB\_APP] Data Radio Bearer count 1  
> [GNB\_APP] Parsed IPv4 address for NG AMF: 192.168.1.46  
> [UTIL] threadCreate() for TASK\_SCTP: creating thread with affinity ffffffff, priority 50  
> [X2AP] X2AP is disabled.  
> [UTIL] threadCreate() for TASK\_NGAP: creating thread with affinity ffffffff, priority 50  
> [NGAP] Starting NGAP layer  
> [UTIL] threadCreate() for TASK\_RRC\_GNB: creating thread with affinity ffffffff, priority 50  
> [NGAP] Registered new gNB[0] and macro gNB id 3584  
> [NGAP] [gNB 0] check the amf registration state  
> [GTPU] Configuring GTPu  
> [GTPU] SA mode  
> [GTPU] Configuring GTPu address : 192.168.1.46, port : 2152  
> [GTPU] Initializing UDP for local address 192.168.1.46 with port 2152  
> [GTPU] Created gtpu instance id: 90  
> [UTIL] threadCreate() for GTPrx\_90: creating thread with affinity ffffffff, priority 50  
> [NR\_RRC] Entering main loop of NR\_RRC message task  
> [UTIL] threadCreate() for TASK\_GNB\_APP: creating thread with affinity ffffffff, priority 50  
> [NR\_RRC] Accepting new CU-UP ID 3584 name gNB-OAI (assoc\_id -1)  
> [UTIL] threadCreate() for TASK\_GTPV1\_U: creating thread with affinity ffffffff, priority 50  
> [NR\_RRC] Received F1 Setup Request from gNB\_DU 3584 (gNB-OAI) on assoc\_id -1  
> [NR\_RRC] Accepting DU 3584 (gNB-OAI), sending F1 Setup Response  
> [NR\_RRC] DU uses RRC version 17.3.0  
> [MAC] received F1 Setup Response from CU (null)  
> [MAC] CU uses RRC version 17.3.0  
> [MAC] Clearing the DU’s UE states before, if any.  
> [NR\_RRC] cell PLMN 001.01 Cell ID 12345678 is in service  
> [MAC] received gNB-DU configuration update acknowledge  
> [UTIL] threadCreate() for time source realtime: creating thread with affinity ffffffff, priority 2  
> [UTIL] time manager configuration: [time source: reatime] [mode: standalone] [server IP: 127.0.0.1} [server port: 7374] (server IP/port not used)  
> [PHY] RU clock source set as internal  
> [PHY] number of L1 instances 1, number of RU 1, number of CPU cores 8  
> [PHY] Initialized RU proc 0 (,synch\_to\_ext\_device),  
> [PHY] RU thread-pool core string -1,-1 (size 2)  
> [UTIL] threadCreate() for Tpool0\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool1\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for ru\_thread: creating thread with affinity ffffffff, priority 97  
> [PHY] Starting RU 0 (,synch\_to\_ext\_device) on cpu 5  
> [PHY] Initializing frame parms for mu 1, N\_RB 24, Ncp 0  
> [PHY] Init: N\_RB\_DL 24, first\_carrier\_offset 368, nb\_prefix\_samples 36,nb\_prefix\_samples0 44, ofdm\_symbol\_size 512  
> [PHY] fp-\>scs=30000  
> [PHY] fp-\>ofdm\_symbol\_size=512  
> [PHY] fp-\>nb\_prefix\_samples0=44  
> [PHY] fp-\>nb\_prefix\_samples=36  
> [PHY] fp-\>slots\_per\_subframe=2  
> [PHY] fp-\>samples\_per\_subframe\_wCP=14336  
> [PHY] fp-\>samples\_per\_frame\_wCP=143360  
> [PHY] fp-\>samples\_per\_subframe=15360  
> [PHY] fp-\>samples\_per\_frame=153600  
> [PHY] fp-\>dl\_CarrierFreq=3604800000  
> [PHY] fp-\>ul\_CarrierFreq=3604800000  
> [PHY] fp-\>Nid\_cell=0  
> [PHY] fp-\>first\_carrier\_offset=368  
> [PHY] fp-\>ssb\_start\_subcarrier=0  
> [PHY] fp-\>Ncp=0  
> [PHY] fp-\>N\_RB\_DL=24  
> [PHY] fp-\>numerology\_index=1  
> [PHY] fp-\>nr\_band=78  
> [PHY] fp-\>ofdm\_offset\_divisor=8  
> [PHY] fp-\>threequarter\_fs=0  
> [PHY] fp-\>sl\_CarrierFreq=0  
> [PHY] fp-\>N\_RB\_SL=0  
> [NR\_PHY] nb\_tx\_streams 1, nb\_rx\_streams 1, num\_Beams\_period 1  
> [PHY] Setting RF config for N\_RB 24, NB\_RX 1, NB\_TX 1  
> [PHY] tune\_offset 0 Hz, sample\_rate 15360000 Hz  
> [PHY] Channel 0: setting tx\_gain offset 0, tx\_freq 3604800000 Hz  
> [PHY] Channel 0: setting rx\_gain offset 114, rx\_freq 3604800000 Hz  
> [HW] rf-config-file: /home/dtri03/Documents/openairinterface5g/radio/LMSSDR/Limesdr\_mini\_v2\_1.cfg  
> [HW] Available devices:  
> [HW] “dspR\_test, media=USB3.0, addr=0403:601f, serial=00000000000013”  
> [HW] Connected: dspR\_test, media=USB3.0, addr=0403:601f, serial=00000000000013  
> [HW] FPGA: StopStreaming  
> [HW] lms7002m\_set\_tx\_lpf: bandwidth(20000000): LAD=140, H=0
> 
> [HW] INT 57, FRAC 385875, DIV\_OUTCH\_CGEN 18  
> [HW] CGEN\_VCO 14720000 Hz, RefClk 40000000 Hz  
> [HW] Calibrating CG\_IAMP\_TBB:  
> [HW] CG\_IAMP\_TBB(1) RSSI:0x00002872 approx. -16.24 dBFS  
> [HW] CG\_IAMP\_TBB(2) RSSI:0x00002AF6 approx. -15.72 dBFS  
> [HW] CG\_IAMP\_TBB(3) RSSI:0x000036D5 approx. -13.60 dBFS  
> [HW] CG\_IAMP\_TBB(4) RSSI:0x00004319 approx. -11.85 dBFS  
> [HW] CG\_IAMP\_TBB(5) RSSI:0x00005283 approx. -10.05 dBFS  
> [HW] CG\_IAMP\_TBB(6) RSSI:0x00005DC8 approx. -8.94 dBFS  
> [HW] CG\_IAMP\_TBB(7) RSSI:0x00006E5F approx. -7.52 dBFS  
> [HW] CG\_IAMP\_TBB(8) RSSI:0x00007AAA approx. -6.61 dBFS  
> [HW] CG\_IAMP\_TBB(9) RSSI:0x00008BA5 approx. -5.48 dBFS  
> [HW] CG\_IAMP\_TBB(10) RSSI:0x0000975D approx. -4.78 dBFS  
> [HW] CG\_IAMP\_TBB(11) RSSI:0x0000A7C8 approx. -3.88 dBFS  
> [HW] CG\_IAMP\_TBB(12) RSSI:0x0000B502 approx. -3.23 dBFS  
> [HW] lms7002m\_set\_rx\_lpf: bandwidth(20000000): TIA\_C=242, TIA\_RCOMP=11, TIA\_CCOMP=2, RX\_L\_C=59, RX\_H\_C=255
> 
> [HW] Sampling rate set(20.000 MHz): CGEN:160.000 MHz, Decim: 2^1, Interp: 2^1  
> [HW] INT 63, FRAC 0, DIV\_OUTCH\_CGEN 7  
> [HW] CGEN\_VCO 0 Hz, RefClk 40000000 Hz  
> [HW] FPGA SetPllFrequency: PLL[0] input:40.000 MHz clockCount:4  
> [HW] CLK[3] Fout:40.000 MHz bypass:0 phase:139.06 findPhase: 1  
> [HW] CLK[3] Fout:40.000 MHz bypass:0 phase:139.06 findPhase: 1  
> [HW] CLK[3] Fout:40.000 MHz bypass:0 phase:139.06 findPhase: 1  
> [HW] CLK[3] Fout:40.000 MHz bypass:0 phase:139.06 findPhase: 1  
> [HW] FPGA PLL[0] M=32, N=1, Fvco=1280.000 MHz (Requested 1280.000 MHz)  
> [HW] FPGA SetPllFrequency: PLL[0] input:40.000 MHz clockCount:4  
> [HW] CLK[1] Fout:40.000 MHz bypass:0 phase:100.45 findPhase: 1  
> [HW] CLK[1] Fout:40.000 MHz bypass:0 phase:100.45 findPhase: 1  
> [HW] CLK[1] Fout:40.000 MHz bypass:0 phase:100.45 findPhase: 1  
> [HW] CLK[1] Fout:40.000 MHz bypass:0 phase:100.45 findPhase: 1  
> [HW] FPGA PLL[0] M=32, N=1, Fvco=1280.000 MHz (Requested 1280.000 MHz)  
> [HW] dev0 chip0 loaded with: /home/dtri03/Documents/openairinterface5g/radio/LMSSDR/test5Gnew.ini  
> [HW] Rx channel0: dev0 chip0 ch0 , LO: 3604.800 MHz SR: 15.360 MHz BW: 10.000 MHz | path: 0(‘NONE’)  
> [HW] Tx channel0: dev0 chip0 ch0 , LO: 3604.800 MHz SR: 15.360 MHz BW: 10.000 MHz | path: 0(‘None’)  
> [HW] dev0 configure.  
> [HW] Set Rx LO frequency (3604800000 Hz)  
> [HW] SX VCO:7209600000 Hz, RefClk:40000000 Hz, INT:86, FRAC:125829, DIV\_LOCH:0, EN\_DIV2\_DIVPROG:1  
> [HW] Tuning Rx VCOH (ICT\_VCO:192):  
> [HW] TuneVCO(SXR) - searching interval [0:128]  
> [HW] binary search:  
> [HW] csw=64 cmphl=0  
> [HW] csw=96 cmphl=0  
> [HW] csw=112 cmphl=0  
> [HW] csw=120 cmphl=0  
> [HW] csw=124 cmphl=0  
> [HW] csw=126 cmphl=0  
> [HW] csw=127 cmphl=0  
> [HW] adjust with linear search:  
> [HW] CSW interval failed to lock  
> [HW] TuneVCO(SXR) - searching interval [128:256]  
> [HW] binary search:  
> [HW] csw=192 cmphl=3  
> [HW] csw=160 cmphl=2  
> [HW] csw=176 cmphl=3  
> [HW] csw=168 cmphl=2  
> [HW] csw=172 cmphl=3  
> [HW] csw=170 cmphl=2  
> [HW] csw=171 cmphl=2  
> [HW] adjust with linear search:  
> [HW] csw=159 cmphl=2  
> [HW] csw=158 cmphl=2  
> [HW] csw=157 cmphl=2  
> [HW] csw=156 cmphl=2  
> [HW] csw=155 cmphl=2  
> [HW] csw=154 cmphl=2  
> [HW] csw=153 cmphl=2  
> [HW] csw=152 cmphl=2  
> [HW] csw=151 cmphl=2  
> [HW] csw=150 cmphl=2  
> [HW] csw=149 cmphl=0  
> [HW] CSW: lowest=150, highest=171, will use=160  
> [HW] choosing wider CSW locking range: low=150, high=171  
> [HW] TuneVCO(SXR) - confirmed lock with final csw=160, cmphl=2  
> [HW] VCOH : csw=160 tune ok  
> [HW] Selected: VCOH, CSW\_VCO: 160  
> [HW] Set Tx LO frequency (3604800000 Hz)  
> [HW] SX VCO:7209600000 Hz, RefClk:40000000 Hz, INT:86, FRAC:125829, DIV\_LOCH:0, EN\_DIV2\_DIVPROG:1  
> [HW] Tuning Tx VCOH (ICT\_VCO:192):  
> [HW] TuneVCO(SXT) - searching interval [0:128]  
> [HW] binary search:  
> [HW] csw=64 cmphl=0  
> [HW] csw=96 cmphl=0  
> [HW] csw=112 cmphl=0  
> [HW] csw=120 cmphl=0  
> [HW] csw=124 cmphl=0  
> [HW] csw=126 cmphl=0  
> [HW] csw=127 cmphl=0  
> [HW] adjust with linear search:  
> [HW] CSW interval failed to lock  
> [HW] TuneVCO(SXT) - searching interval [128:256]  
> [HW] binary search:  
> [HW] csw=192 cmphl=3  
> [HW] csw=160 cmphl=2  
> [HW] csw=176 cmphl=3  
> [HW] csw=168 cmphl=2  
> [HW] csw=172 cmphl=2  
> [HW] csw=174 cmphl=3  
> [HW] csw=173 cmphl=2  
> [HW] adjust with linear search:  
> [HW] csw=159 cmphl=2  
> [HW] csw=158 cmphl=2  
> [HW] csw=157 cmphl=2  
> [HW] csw=156 cmphl=2  
> [HW] csw=155 cmphl=2  
> [HW] csw=154 cmphl=2  
> [HW] csw=153 cmphl=2  
> [HW] csw=152 cmphl=0  
> [HW] CSW: lowest=153, highest=173, will use=163  
> [HW] choosing wider CSW locking range: low=153, high=173  
> [HW] TuneVCO(SXT) - confirmed lock with final csw=163, cmphl=2  
> [HW] VCOH : csw=163 tune ok  
> [HW] Selected: VCOH, CSW\_VCO: 163  
> [HW] lms7002m\_set\_rx\_lpf: modifying G\_PGA\_RBB 28 → 12  
> [HW] lms7002m\_set\_rx\_lpf: bandwidth(10000000): TIA\_C=494, TIA\_RCOMP=6, TIA\_CCOMP=4, RX\_L\_C=221, RX\_H\_C=255
> 
> [HW] lms7002m\_set\_tx\_lpf: bandwidth(10000000): LAD=46, H=0
> 
> [HW] Custom .ini configuration file is loaded, SetTxLPF will not calibrate CG\_IAMP\_TBB  
> [HW] lms7002m\_set\_rx\_lpf: RxLPF bypassed  
> [HW] lms7002m\_set\_tx\_lpf: TxLPF bypassed.  
> [HW] Custom .ini configuration file is loaded, SetTxLPF will not calibrate CG\_IAMP\_TBB  
> [HW] Sampling rate set(15.360 MHz): CGEN:491.520 MHz, Decim: 2^3, Interp: 2^3  
> [HW] INT 48, FRAC 159383, DIV\_OUTCH\_CGEN 1  
> [HW] CGEN\_VCO 6080000 Hz, RefClk 40000000 Hz  
> [HW] FPGA SetPllFrequency: PLL[0] input:15.360 MHz clockCount:4  
> [HW] CLK[3] Fout:15.360 MHz bypass:0 phase:108.506 findPhase: 1  
> [HW] CLK[3] Fout:15.360 MHz bypass:0 phase:108.506 findPhase: 1  
> [HW] CLK[3] Fout:15.360 MHz bypass:0 phase:108.506 findPhase: 1  
> [HW] CLK[3] Fout:15.360 MHz bypass:0 phase:108.506 findPhase: 1  
> [HW] FPGA PLL[0] M=83, N=1, Fvco=1274.880 MHz (Requested 1274.880 MHz)  
> [HW] FPGA SetPllFrequency: PLL[0] input:15.360 MHz clockCount:4  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] FPGA PLL[0] M=83, N=1, Fvco=1274.880 MHz (Requested 1274.880 MHz)  
> [HW] FPGA SetPllFrequency: PLL[0] input:15.360 MHz clockCount:4  
> [HW] Port[0] Stream samples format: I12 , link: I12  
> [HW] [RAU] has loaded LMSSDR device.  
> [PHY] RU 0 Setting N\_TA\_offset to 200 samples (UL Freq 3600480, N\_RB 24, mu 1)  
> [PHY] Signaling main thread that RU 0 is ready, sl\_ahead 6  
> [PHY] L1 configured without analog beamforming  
> [PHY] Attaching RU 0 antenna 0 to gNB antenna 0  
> [UTIL] threadCreate() for Tpool0\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool1\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool2\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool3\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool4\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool5\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool6\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool7\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for L1\_rx\_thread: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for L1\_tx\_thread: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for L1\_stats: creating thread with affinity ffffffff, priority 1  
> TYPE TO TERMINATE  
> [PHY] got sync (L1\_stats\_thread)  
> [PHY] got sync (ru\_thread)  
> [HW] FPGA: StartStreaming  
> [PHY] RU 0 rf device ready  
> [PHY] RU 0 RF started cpu\_meas\_enabled 0  
> [HW] Tx transmit loop start.  
> [HW] Rx receive loop start.  
> [PHY] Command line parameters for OAI UE: -C 3604800000 -r 24 --numerology 1 --ssb 24  
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:15357120 pkt:11293 o:0(+0) l:0(+0) dma:11293/11294(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.250 MB/s | TS:15398400 pkt:8397 u:0(+0) l:0(+0) dma:1794/1799(+5) tsAdvance:+1932/+2274/+2541us, f:0  
> [NR\_MAC] Frame.Slot 128.0
> 
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:30716960 pkt:22587 o:0(+0) l:0(+0) dma:22587/22588(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.368 MB/s | TS:30758400 pkt:16797 u:0(+0) l:0(+0) dma:3594/3599(+5) tsAdvance:+1984/+2274/+2541us, f:0  
> [NR\_MAC] Frame.Slot 256.0
> 
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:46075440 pkt:33880 o:0(+0) l:0(+0) dma:33880/33882(+2) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.388 MB/s | TS:46118400 pkt:25197 u:0(+0) l:0(+0) dma:5395/5399(+4) tsAdvance:+2015/+2273/+2541us, f:0  
> [NR\_MAC] Frame.Slot 384.0
> 
> [HW] USB ep:83 Rx0: 46.264 MB/s | TS:61438000 pkt:45176 o:0(+0) l:0(+0) dma:45176/45177(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.388 MB/s | TS:61486080 pkt:33602 u:0(+0) l:0(+0) dma:7196/7200(+4) tsAdvance:+1953/+2273/+2541us, f:0  
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:76797840 pkt:56470 o:0(+0) l:0(+0) dma:56470/56471(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.368 MB/s | TS:76846080 pkt:42002 u:0(+0) l:0(+0) dma:8996/9000(+4) tsAdvance:+1979/+2273/+2541us, f:0  
> [NR\_MAC] Frame.Slot 512.0HW] CLK[3] Fout:15.360 MHz bypass:0 phase:108.506 findPhase: 1  
> [HW] CLK[3] Fout:15.360 MHz bypass:0 phase:108.506 findPhase: 1  
> [HW] CLK[3] Fout:15.360 MHz bypass:0 phase:108.506 findPhase: 1  
> [HW] FPGA PLL[0] M=83, N=1, Fvco=1274.880 MHz (Requested 1274.880 MHz)  
> [HW] FPGA SetPllFrequency: PLL[0] input:15.360 MHz clockCount:4  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] CLK[1] Fout:15.360 MHz bypass:0 phase:93.7726 findPhase: 1  
> [HW] FPGA PLL[0] M=83, N=1, Fvco=1274.880 MHz (Requested 1274.880 MHz)  
> [HW] chip0 ch0 Rx gain set LNA:15, PGA:31  
> [HW] chip0 ch0 Tx gain set MAIN:30, LIN:30  
> [HW] FPGA: StopStreaming  
> [HW] FPGA: StopWaveformPlayback  
> [HW] FPGA: ResetPacketCounters  
> [HW] FPGA: ResetTimestamp  
> [HW] USB ep:83 Rx0 Setup: usePoll:1 rxSamplesInPkt:1360 rxPacketsInBatch:1, DMA\_ReadSize:4096, link:I12, batchSizeInTime:88.5417us FS:15360000.000000, FIFO=2823\*1360
> 
> [HW] RxSetup wait for Rx worker thread.  
> [HW] Rx worker thread ready.  
> [HW] Tx0 Setup: samplesInTxPkt:1360 maxTxPktInBatch:5, batchSizeInTime:442.708us  
> [HW] TxSetup wait for Tx worker.  
> [HW] Tx worker thread ready.  
> [HW] Port[0] Stream samples format: I12 , link: I12  
> [HW] [RAU] has loaded LMSSDR device.  
> [PHY] RU 0 Setting N\_TA\_offset to 200 samples (UL Freq 3600480, N\_RB 24, mu 1)  
> [PHY] Signaling main thread that RU 0 is ready, sl\_ahead 6  
> [PHY] L1 configured without analog beamforming  
> [PHY] Attaching RU 0 antenna 0 to gNB antenna 0  
> [UTIL] threadCreate() for Tpool0\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool1\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool2\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool3\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool4\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool5\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool6\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for Tpool7\_-1: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for L1\_rx\_thread: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for L1\_tx\_thread: creating thread with affinity ffffffff, priority 97  
> [UTIL] threadCreate() for L1\_stats: creating thread with affinity ffffffff, priority 1  
> TYPE TO TERMINATE  
> [PHY] got sync (L1\_stats\_thread)  
> [PHY] got sync (ru\_thread)  
> [HW] FPGA: StartStreaming  
> [PHY] RU 0 rf device ready  
> [PHY] RU 0 RF started cpu\_meas\_enabled 0  
> [HW] Tx transmit loop start.  
> [HW] Rx receive loop start.  
> [PHY] Command line parameters for OAI UE: -C 3604800000 -r 24 --numerology 1 --ssb 24  
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:15357120 pkt:11293 o:0(+0) l:0(+0) dma:11293/11294(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.250 MB/s | TS:15398400 pkt:8397 u:0(+0) l:0(+0) dma:1794/1799(+5) tsAdvance:+1932/+2274/+2541us, f:0  
> [NR\_MAC] Frame.Slot 128.0
> 
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:30716960 pkt:22587 o:0(+0) l:0(+0) dma:22587/22588(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.368 MB/s | TS:30758400 pkt:16797 u:0(+0) l:0(+0) dma:3594/3599(+5) tsAdvance:+1984/+2274/+2541us, f:0  
> [NR\_MAC] Frame.Slot 256.0
> 
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:46075440 pkt:33880 o:0(+0) l:0(+0) dma:33880/33882(+2) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.388 MB/s | TS:46118400 pkt:25197 u:0(+0) l:0(+0) dma:5395/5399(+4) tsAdvance:+2015/+2273/+2541us, f:0  
> [NR\_MAC] Frame.Slot 384.0
> 
> [HW] USB ep:83 Rx0: 46.264 MB/s | TS:61438000 pkt:45176 o:0(+0) l:0(+0) dma:45176/45177(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.388 MB/s | TS:61486080 pkt:33602 u:0(+0) l:0(+0) dma:7196/7200(+4) tsAdvance:+1953/+2273/+2541us, f:0  
> [HW] USB ep:83 Rx0: 46.260 MB/s | TS:76797840 pkt:56470 o:0(+0) l:0(+0) dma:56470/56471(+1) swFIFO:0  
> [HW] USB ep:03 Tx0: 34.368 MB/s | TS:76846080 pkt:42002 u:0(+0) l:0(+0) dma:8996/9000(+4) tsAdvance:+1979/+2273/+2541us, f:0  
> [NR\_MAC] Frame.Slot 512.0

**Question** :- Is it that because the TX path is not being selected so the transmission is not happening?

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [17 February 2026 07:55 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/19 "2026-02-17T07:55:34Z")

</div>

> [@Prajwal](#):
>
> ```auto
> dev0_rx_Path= "LNAH";
> dev0_tx_Path= "BAND1";
> 
> ```

The argument names are case sensitive, should be dev0\_rx\_path, dev0\_tx\_path

> [@Prajwal](#):
>
> One more question → what is the command that let the gNB run with the .ini file.Can it be possible to run the .cfg as well as the .ini file ?

The .ini file can be specified in the .cfg, dev0\_ini=“someFile.ini”  
It will be loaded as base, and then other SDR parameters will be configured on top of it. It’s intended for configuring non generic, chip specific parameters, all other generic settings will be overwritten by values from the stack’s configuration LO,LPF,gains,antennas…

---

<div class="post-metadata">

**Author:** ![Prajwal](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Prajwal](https://discourse.myriadrf.org/u/Prajwal)\
**Post date:** [17 February 2026 11:15 UTC](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008/20 "2026-02-17T11:15:47Z")

</div>

Thanks for pointing out the issue — that fixed it.  
Now the RF chain initializes properly and I can now see the spectrum on the analyzer.

[Next page](https://discourse.myriadrf.org/t/question-about-limesuiteng-integration-fork/13008.md?page=2)