Don't know your receiver and your Implementation in detail, but isn't that PBCH a little strong? you're probably "screaming" at your receiver so loudly that it drastically distorts the receive signal. Try with lower gain.
On 29.07.20 17:17, Prasad wrote: > Hi Muller, > > Just a quick question. > During our 5G-NR integration with USRP B210, we observe very high noise > power at receiver. > Is it expected behavior ? > PBCH rsrp: -13.775554 dBm, SNR: -12.942591 dB, NOISE_POWER: -0.832963 dBm, > rssi: 1.643662dBm. > > Applied gain in USRP: > Tx Gain: 45 > Rx Gain: 45 > Transmit power:- 0dBm. > > Regards, > Prasad. > > -----Original Message----- > From: Prasad [mailto:[email protected]] > Sent: Wednesday, July 22, 2020 10:21 PM > To: 'Marcus Müller'; '[email protected]' > Subject: RE: [USRP-users] 1 Ts delay in USRP B210 > > Thanks! a lot Marcus M and Marcus D for your valuable information. > > Thanks, > > -----Original Message----- > From: Marcus Müller [mailto:[email protected]] > Sent: Tuesday, July 21, 2020 11:07 PM > To: [email protected]; Prasad > Subject: Re: [USRP-users] 1 Ts delay in USRP B210 > > Hello Prasad, > > I second everything Marcus L said, and will add: > > In your first email you said this is about the UE. > > UE (user equipment) are normally things like phones. These don't have > any great clocks of their own. They derive their clocks from that of the > network. > > Sure, for prototyping, reducing the frequency error makes sense, but > even if both your basestation (gNodeB in 5G jargon) and your UE have > atomic clocks, they will be unsynchronized if either moves. Doppler! > > So, in the end, if you're not in the business of evaluating > synchronization algorithms, you're probably requesting the wrong thing: > Make your UE implementation extract frequency information from the > received downlink signal (there's plenty of implicit and explicit info > in LTE/5G for exactly that), and live with the oscillator you have - it > only needs to be stable for short times. I'm almost certain that any > smartphone will have a worse oscillator than your B210 has. > > Best regards, > Marcus M > > On 21.07.20 18:38, Marcus D. Leech via USRP-users wrote: >> On 07/21/2020 12:31 PM, Prasad wrote: >>> Then how we can handle this drift in our 5G-NR stack by using >>> /uhd_rx_streamer_issue_stream_cmd/? >>> >>> Or we should go with GPSDO/external clock? >>> >>> Thanks, >>> >> Well, since most users on here aren't experts on 5G stacks, me included, >> I can't tell you what to do to your stack to handle >> clock drift. But I WILL say that clock drift is an inevitable issue, >> and as you get better clocks, the scale of that issue becomes >> smaller as you spend more money on better clocks. >> >> A built-in GPSDO would not be a bad investment if clock drift at a scale >> of 0.8PPM is an issue for your implementation. >> >> Many digital demodulators implement algorithms for dealing with >> clock-drift and imprecision on the rx side using PLLs and the like. >> But for 5G I have no idea how that would play out. >> >> >>> *From:*Marcus D. Leech [mailto:[email protected]] >>> *Sent:* Tuesday, July 21, 2020 9:56 PM >>> *To:* Prasad; [email protected] >>> *Subject:* Re: [USRP-users] 1 Ts delay in USRP B210 >>> >>> On 07/21/2020 12:25 PM, Prasad wrote: >>> >>> We are using internal clock, don’t use any GPSDO or external clock. >>> >>> So for internal clock is this expected? >>> >>> Thanks, >>> >>> The internal clock is specced to +/- 2PPM. You're seeing much less >>> than that, so it's within spec. >>> >>> >>> >>> *From:*USRP-users [mailto:[email protected]] *On >>> Behalf Of *Marcus D. Leech via USRP-users >>> *Sent:* Tuesday, July 21, 2020 9:49 PM >>> *To:* [email protected] <mailto:[email protected]> >>> *Subject:* Re: [USRP-users] 1 Ts delay in USRP B210 >>> >>> On 07/21/2020 12:13 PM, Prasad via USRP-users wrote: >>> >>> Soft reminder! >>> >>> Thanks, >>> >>> *From:*Prasad [mailto:[email protected]] >>> *Sent:* Monday, July 20, 2020 7:58 PM >>> *To:* '[email protected] >>> <mailto:[email protected]>' >>> *Cc:* 'Rao Yenamandra' >>> *Subject:* 1 Ts delay in USRP B210 >>> >>> Dear Team. >>> >>> Hope you are doing well and safe. >>> >>> We are bringing up our NR-5G UE stack with USRP B210. >>> >>> If time permits, would you pls. reply to below concern with your >>> valuable information. >>> >>> During the synchronization procedure, we observe atleast /±/1 >>> /Ts/ (Sampling Time) drift in rx streamer in every ~40ms time >>> period. >>> >>> Are we missing any time_spec during /uhd_rx_streamer_recv/ api or >>> in /uhd_tx_streamer_send/ ? >>> >>> Master clock rate: 30.72e6 >>> >>> Sampling rate: 30.72e6 >>> >>> Carrier frequency: 3.8e9 >>> >>> We use one B210 to transmit time domain samples back to back and >>> others to receive. >>> >>> Log snippet: >>> >>> Init PSS detected with lag: /4469/ (/PSS detection offset from the >>> slot boundary/ ) >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4469 >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4469 >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4469 >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4470 à1 Ts drift >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4470 >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4470 >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4471 à1 Ts drift. >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4472à1 Ts drift >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4472 >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4472 >>> >>> sss has been detected >>> >>> Init PSS detected with lag: 4484 à12 Ts drift >>> >>> sss has been detected >>> >>> Thanks! in advance. >>> >>> Regards, >>> >>> Prasad. >>> >>> Are you just using the on-board reference clock, or using something >>> like a GPS module? >>> >>> The drift you show is roughly 0.8PPM (if I've done my math correctly), >>> which is well within spec for this board without a better reference >>> clock. >>> >>> >>> >> >> >> _______________________________________________ >> USRP-users mailing list >> [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
