[USRP-users] [USRP B210] Very High Noise power at receiver

Marcus D. Leech patchvonbraun at gmail.com
Thu Jul 30 13:06:01 EDT 2020


On 07/30/2020 11:56 AM, Prasad via USRP-users wrote:
> Soft reminder!.
>
> Thanks!
>
> -----Original Message-----
> From: Prasad [mailto:kpras at trilcomm.com]
> Sent: Wednesday, July 29, 2020 8:48 PM
> To: 'Prasad'; 'Marcus Müller'; 'usrp-users at lists.ettus.com'
> Subject: RE: [USRP-users] 1 Ts delay in USRP B210
>
> 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.
There's no way with a B210 with a TX gain of 45, you're getting 0dBm out 
the antenna.  The device can produce a maximum of about 10dBm, and
   with the TX gain range topping out at something like 80dB, your 35dB 
below the 10dBm point.   Similarly, the RX gain range is almost 80dB, so
   you've got the gain set for about 30dB of attenuation in the RX 
path.  You're using antennae or a direct connection?


>
> Regards,
> Prasad.
>
> -----Original Message-----
> From: Prasad [mailto:kpras at trilcomm.com]
> Sent: Wednesday, July 22, 2020 10:21 PM
> To: 'Marcus Müller'; 'usrp-users at lists.ettus.com'
> 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:marcus.mueller at ettus.com]
> Sent: Tuesday, July 21, 2020 11:07 PM
> To: usrp-users at lists.ettus.com; 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:patchvonbraun at gmail.com]
>>> *Sent:* Tuesday, July 21, 2020 9:56 PM
>>> *To:* Prasad; usrp-users at lists.ettus.com
>>> *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:usrp-users-bounces at lists.ettus.com] *On
>>> Behalf Of *Marcus D. Leech via USRP-users
>>> *Sent:* Tuesday, July 21, 2020 9:49 PM
>>> *To:* usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>
>>> *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:kpras at trilcomm.com]
>>>      *Sent:* Monday, July 20, 2020 7:58 PM
>>>      *To:* 'usrp-users at lists.ettus.com
>>> <mailto:usrp-users at lists.ettus.com>'
>>>      *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
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




More information about the USRP-users mailing list