Overflow problems when running

[koupsop]

Dear developers,

First of all, thank you for designing such a useful tool.

While running ./nrscope, I meet overflow problems and terminate called without an active exception.
Here is the result

Active RF plugins: libsrsran_rf_uhd.so
Inactive RF plugins: 
Reading configs.
USRP Device: 0
    rf_args: clock=internal,type=x300,sampling_rate=11520000
    device_name: 
    srsran_srate_hz: 23.04 MHz
    srate_hz: 23.04 MHz
    rx_gain: 30
    AGC min_rx_gain: 0
    AGC max_rx_gain: 80
    nof_carriers: 1
    nof_antennas: 1
    freq_offset: 0
    scs: 0
Opening 1 channels in RF device= with args=clock=internal,type=x300,sampling_rate=11520000
Supported RF device list: UHD file
Trying to open RF device 'UHD'
2024-12-21T09:06:26.138779 [RF     ] [I] Configuring physical DL channel 0 with band-pass filter (0.0, 0.0)
2024-12-21T09:06:26.138781 [RF     ] [I] Configuring physical UL channel 0 with band-pass filter (0.0, 0.0)
[INFO] [UHD] linux; GNU C++ version 13.2.0; Boost_108300; UHD_4.7.0.0-0ubuntu1~noble1
Opening USRP channels=1, args: type=x300,master_clock_rate=184.32e6
[INFO] [LOGGING] Fastpath logging disabled at runtime.
[INFO] [UHD RF] RF UHD Generic instance constructed
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
[INFO] [X300] Radio 1x clock: 184.32 MHz
[WARNING] [RFNOC::GRAPH] One or more blocks timed out during flush!
RF device 'UHD' successfully opened

Warning: TX gain was not set. Using open-loop power control (not working properly)

usrp srate_hz: 2.304e+07
resample_needed: 0
2024-12-21T09:06:31.497106 [RF     ] [I] Mapping RF channel 0 (device=0, channel=0) to logical carrier 0 on f_rx=622.8 MHz
slot_sz: 23040
pre_resampling_slot_sz: 23040
Starting workers...
New worker 0 is going to start... 
New worker 1 is going to start... 
New worker 2 is going to start... 
New worker 3 is going to start... 
Workers started...
Task scheduler started...
2024-12-21T09:06:32.759657 [PHY    ] [I] [    0] Cell search: Setting SSB configuration srate=23.04 MHz; c-freq=622.850 MHz; ss-freq=622.850 MHz; scs=15kHz; pattern=A; duplex=fdd;
2024-12-21T09:06:33.309631 [RF     ] [I] Mapping RF channel 0 (device=0, channel=0) to logical carrier 0 on f_rx=622.9 MHz
2024-12-21T09:06:33.411277 [RF     ] [I] Overflow
2024-12-21T09:06:36.360637 [RF     ] [I] Overflow
terminate called without an active exception

The config I used:

nof_usrp_dev: 1
usrp_setting_0:
  ssb_freq: 622850000 # Set to the ssb frequency of the cell, could be obtained with the cell scan function
  # rf_args: "clock=external,type=b200" # For B210
  # rf_args: "clock=external,type=x300,serial=32B0F2F,master_clock_rate=200000000,sampling_rate=25000000" ## For TwinRX daughterboard
  rf_args: "clock=internal,type=x300,sampling_rate=23040000" ## For CBX daughterboard
  rx_gain: 30 # for x310 CBX, max rx gain is 31.5, for b210, it's around 80, for x310 TwinRX, max rx gain is 90
  min_rx_gain: 0
  max_rx_gain: 80
  srate_hz: 23040000 # the sampling rate of USRP, integer division of 200MHz for TwinRX, and 5G sampling rate for CBX: 11520000 or 23040000
  srsran_srate_hz: 23040000 # the sampling for real signal processing, should be in 5G sampling rate, multiple of 1.92 MHz. 
  nof_carriers: 1 # srsRAN rf setting, always set to be 1 for now. 
  nof_antennas: 1 # srsRAN rf setting, always set to be 1 for now.
  scs_index: 0 #(0: 15kHz, 1: 30kHz, ..., the u in standard)
  rf_log_level: "debug"
  nof_rnti_worker_groups: 4 # number of of threads for DCI decoding, each will divide the UEs into small groups
  nof_bwps: 1 # number of BWP of the cell
  nof_workers: 4 # using worker pool to asynchronously process the slot data
  cpu_affinity: false # pin the worker's thread into CPU or not.

  log_name: "a.csv"
  google_dataset_id: "ngscope5g_dci_log_wanhr"

I use a UBX daughter board instead of CBX with USRP X310, does it matter?
Please tell me if there are any issues with the hardware configuration or if there is any code that needs to be modified.

Thank you!

[XuyangCaoPrinceton]

Hi,

What is the SSB frequency of the cell you are trying to monitor? Looks like you are using the default ssb_freq: 622850000. Maybe you need to update that correspondingly. Please also change max_rx_gain: 80 to max_rx_gain: 30 for your case.

[koupsop]

Hi,

I set ssb_freq: 3.40896e+9 and max_rx_gain:30. The frequency is got from cellular-pro as ./nrscan didn't give feedback. But I met a new bug that NR-Scope/nrscope/hdr/nrscope_def.h:81: Assertion Failure: Invalid band. This really confused me, why it occurred?

[WanHaoRan]

Hi, this is because the 3408.96MHz cell is in n77 or n78 and the default SCS is 30kHz. So you should set the scs_index to 1, as scs_index: 1.

[koupsop]

Hi,
When I tried to use NR-Scope to receive commercial station signals, I encountered the following problems after the RACH decoder. However, my nof-bwps is 1 as required.

The log and config are below. How can I make the program output the final DCI?
config

nof_usrp_dev: 1
usrp_setting_0:
  ssb_freq: 3.40896e+9 # Set to the ssb frequency of the cell, could be obtained with the cell scan function
  # rf_args: "clock=external,type=b200" # For B210
  # rf_args: "clock=external,type=x300,serial=32B0F2F,master_clock_rate=200000000,sampling_rate=25000000" ## For TwinRX daughterboard
  rf_args: "clock=gpsdo,type=x300,sampling_rate=11520000" ## For CBX daughterboard
  rx_gain: 30 # for x310 CBX, max rx gain is 31.5, for b210, it's around 80, for x310 TwinRX, max rx gain is 90
  min_rx_gain: 0
  max_rx_gain: 30
  srate_hz: 11520000 # the sampling rate of USRP, integer division of 200MHz for TwinRX, and 5G sampling rate for CBX: 11520000 or 23040000
  srsran_srate_hz: 11520000 # the sampling for real signal processing, should be in 5G sampling rate, multiple of 1.92 MHz. 
  nof_carriers: 1 # srsRAN rf setting, always set to be 1 for now. 
  nof_antennas: 1 # srsRAN rf setting, always set to be 1 for now.
  scs_index: 1 #(0: 15kHz, 1: 30kHz, ..., the u in standard)
  rf_log_level: "debug"
  nof_rnti_worker_groups: 4 # number of of threads for DCI decoding, each will divide the UEs into small groups
  nof_bwps: 1 # number of BWP of the cell
  nof_workers: 16 # using worker pool to asynchronously process the slot data
  cpu_affinity: false # pin the worker's thread into CPU or not.

  log_name: "a.csv"
  google_dataset_id: "ngscope5g_dci_log_wanhr"

2025-01-13_20:06:48.txt

Thank you!

[WanHaoRan]

Hi,
Thanks for the update, the configuration of this cell is new and not seen by us. There is no initialDownlinkBWP in the RRCSetup, thus the dci_decoder.cc doesn't configure the active bwp correctly. There is no firstActiveDownlinkBWP-Id as well, which means we should use the initialDownlinkBWP configuration in the SIB 1.

I think we will have to convert the common type initialDownlinkBWP from SIB1 to dedicated type in dci_decoder.cc or keep it as it is.

Are you using other tool to decode the RRCSetup messages, such as cellularPro app on the phone? If so, could you share with us so we could verify our decoded RRCSetup is correct?

Any thought @XuyangCaoPrinceton ? I think this scenario is quite rare as the spec states "Network always configures the UE with a value for this field (initialDownlinkBWP in RRCSetup) if no other BWPs are configured. If the dedicated part of initial UL/DL BWP configuration is absent, the initial BWP can be used but with some limitations. For example, changing to another BWP requires RRCReconfiguration since DCI format 1_0 doesn't support DCI-based switching."

[koupsop]

Hi,
Sorry for late reply. Unfortunately, there's no accessible root phone around me now, so cellular pro can't feed me back the RRC. I wonder if the wrong gps synchronization can cause the wrong RRC decoder？That may be the reason as my RRC lack many information, not only initialDownlinkBWP.
After I get RRC information of 5G, I will share with you as soon as possible!

[XuyangCaoPrinceton]

Just saw the message; sorry for late reply.

Yep I guess this is legit, so in such a case your UE will temporarily use the common dl config from SIB1 while use the initial ul bwp configured by RRC_setup. Yeah @WanHaoRan let's discuss and we could add a small patch.

"I wonder if the wrong gps synchronization can cause the wrong RRC decoder？"
I think the RRC_setup message should be good and valid.

Yeah @koupsop really appreciate if you could share all the RRC-level messages (e.g., from cellular pro). Curious what kind of cell it is (and what's its purpose of doing so 😀).

[koupsop]

Hi,
I finally got the RRC-level messages from the same station. Hope it helps.
2025-01-18_20_03_53_signal_ms2.CSV

[WanHaoRan]

Hi, sorry for the late reply, we have been kept busy recently. From your file there is a RRCReconfiguration and you may use the known information to set the cell's information directly. You may check this branch (https://github.com/PrincetonUniversity/NR-Scope/tree/hidden_bwp_40mhz) or the pull request (#11) for how to set it up. We will be back and look into your issue in the next month.

[XuyangCaoPrinceton]

Hi,

issue_20_fix branch is the amend. The encrypted bwp configurations for the cell https://github.com/PrincetonUniversity/NR-Scope/blob/issue_20_fix/nrscope/hidden_bwp_db/826.txt are manually loaded and monitored. Please have a try. Please also install the json parser, mentioned in README.

Thank you.

[diespondency]

I'm currently facing a similar issue, with a lot of overflows and no apparent way of getting logs from NRscope/NRscan. I already lowered the number of workers to 1 and reduced my gain. I don't see how I could debug this further, did anyone find a way to achieve this?

[WanHaoRan]

Hello, thanks for trying our tool. The overflows would happen during the cell search phase for nrscope, which is normal. For the nrscan, it will try every possible frequency for a cell to operate, thus will create even more overflow message and take more time to finish. If you can figure out the cell's frequency through other methods, you can set the frequency in the config.yaml directly and skip the nrscan. An successful operation would be like the figure below:

There will be Overflows in the cell search phase even we have the correct frequency set. If you are sure about the cell's frequency, maybe find a location with better signal strength or see if there is a more suitable antenna?

There will be errors during the DCI decoding, some come from the cell's DCI information (allocating 0 resource elements), and the other is caused by MAC/PHY HARQ (using MCS higher than 28, we can't decode the TBS, you can match the DCI with the previous DCI that has the same harq_id and ndi to figure out the original TBS). Both you can safely ignore, but when you find a too large discrepancy between the TBS and the data rate (captured by the tcpdump), please feel free to reach out to us and we can take a look and discuss.

Feel free to ask if you have other questions.