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.

[Prajwal]

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

2. 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 ?

[Prajwal]

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?

[ricardas]

@Prajwal

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…

[Prajwal]

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.