Hi Marcus, This delay is gradually increased and sometimes it goes beyond 0.5 milliseconds. I think it is not like frequency error but the delay in receiving packet. So are we missing anything during the UHD API ?
Thanks, Prasad. -----Original Message----- From: Marcus Müller [mailto:marcus.muel...@ettus.com] Sent: Tuesday, July 21, 2020 11:07 PM To: usrp-users@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: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, dont 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 > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
