Hi Vishwanath, The LLLLL sequence means that your Tx samples are reaching the device too late. So, anything that affects processing latency on your host could be the culprit.
Since you are now running at 184.32 Msps, your required throughput is much higher than before. Are you resampling on the host? If so, that could be costing you. --M On Thu, Feb 19, 2026 at 2:09 PM P S Vishwanath Koushik < [email protected]> wrote: > Hi Martin, > Thank you very much for precisely pointing out the solution for operating > at 122.88Msps. Can you please suggest on how can i resolve this issue of > "LLLLLLL" sequence? Is there any OS level tuning/configuration required? > > Regards, > Vishwanath > > On Thu, 19 Feb 2026 at 17:43, Martin Braun <[email protected]> wrote: > >> 122.88 Msps is not supported on X310 out of the box. The N310 and N320 >> series can do this, and of course the X410. >> >> It is possible to create a 1.5x resampler as an RFNoC block, but such a >> block is not available as a turnkey solution, so you would have to do FPGA >> development to enable that. If you had such a block, you could run at >> 184.32 MHz master clock rate and decimate by 1.5 giving you your desired >> rate. >> >> --M >> >> On Thu, Feb 19, 2026 at 11:32 AM P S Vishwanath Koushik < >> [email protected]> wrote: >> >>> Dear USRP Community, >>> >>> I am currently working with OpenAirInterface (OAI) 2026.w06 and using a >>> NI/Ettus USRP-2952R (X310 class device, XG FPGA image, reported type as >>> x300) for 5G NR gNB experiments. >>> >>> I am attempting to configure a 100 MHz NR carrier (273 PRB, 30 kHz SCS, >>> band 77). Based on 3GPP numerology, the expected sampling rate is 122.88 >>> MSps. However, when configuring the device, UHD reports: >>> >>> "[WARNING] [MULTI_USRP] Could not set RX rate to 122.880 MHz. Actual >>> rate is 184.320 MHz" >>> "[WARNING] [MULTI_USRP] Could not set TX rate to 122.880 MHz. Actual >>> rate is 184.320 MHz" >>> >>> The device is therefore running at 184.32 MSps instead of the requested >>> 122.88 MSps. >>> >>> System Details: >>> >>> • SDR: USRP-2952R (X310 class, XG FPGA image) >>> • Master clock observed: 184.32 MHz >>> • UHD version: 4.8.0 >>> • OAI version: 2026.w06 >>> • Host CPU: Intel i7-7700 (4 cores / 8 threads) >>> • CPU governor: performance (all cores locked to max frequency) >>> • NIC: Single 10G interface >>> • MTU of 10G Interface : 9000 >>> • Network buffers configured as: >>> >>> net.core.wmem_max=33554432 >>> net.core.rmem_max=33554432 >>> net.core.wmem_default=33554432 >>> net.core.rmem_default=33554432 >>> >>> • Using single 10G link >>> >>> Observed behavior: >>> >>> When operating at 273 PRB (100 MHz), I see continuous sequences of: >>> >>> *LLLLLLLLLLLL* >>> >>> along with: >>> >>> *L[HW]* *Buffer overflow, count_write = 10, start = 4 end = 4, >>> resetting write package.* >>> >>> It appears that because 122.88 MSps does not satisfy the integer >>> MCR/decimation requirement (184.32 / 122.88 = 1.5), UHD forces the sampling >>> rate to 184.32 MSps (decimation = 1). This significantly increases host >>> data throughput and processing load, possibly contributing to the buffer >>> overflows and late processing. >>> >>> I would appreciate clarification on the following: >>> >>> 1. >>> >>> Is 122.88 MSps fundamentally unsupported with MCR = 184.32 MHz on >>> the X310 architecture? >>> 2. >>> >>> Is there a recommended master clock configuration for stable 100 MHz >>> NR operation? >>> >>> OAI gNB Logs are attached for your reference. >>> >>> Thank you for your guidance. >>> >>> Regards, >>> Vishwanath >>> >>> _______________________________________________ >>> USRP-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
