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:patchvonbr...@gmail.com]
*Sent:* Tuesday, July 21, 2020 9:56 PM
*To:* Prasad; usrp-users@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-boun...@lists.ettus.com] *On
Behalf Of *Marcus D. Leech via USRP-users
*Sent:* Tuesday, July 21, 2020 9:49 PM
*To:* usrp-users@lists.ettus.com <mailto:usrp-users@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:kp...@trilcomm.com]
*Sent:* Monday, July 20, 2020 7:58 PM
*To:* 'usrp-users@lists.ettus.com <mailto:usrp-users@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@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
