Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/23/2020 12:26 PM, Prasad wrote:


I understand it is within the time spec. But the delay goes 
incremented linearly, it means if we wait for 30mins we are getting 
expected signal after 0.5milliseconds from the desire time boundary


So do we need to use rx streamer command to adjust it?.

Since none of us here (likely) are intimately familiar with your 5G 
implementation details, it's hard to say which "button to push" to make

  your implementation correctly deal with inevitable clock-slip.

You'll need a strategy, that's about as much as I can offer, since I'm 
not myself a 5G implementation expert.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 9:41 PM
To: Prasad; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/23/2020 11:47 AM, Prasad wrote:

 

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 9:16 PM
To: Prasad; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/23/2020 08:28 AM, Prasad wrote:

Dear Marcus,

 

Verified the code couple of time even tested bypassing USRP and it works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

 

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an apparent "time 
slip"?
30.72e6.

Nearly 40ms one-four sample delay.




 

You're seeing a one to four-sample slip over a period of 40ms, unless I 
misunderstand what you're saying.

At 30.72e6 SPS, that amounts to between 0.8 and 2.4PPM, which is within spec 
for the B210 without an external clock.

The clock quality necessarily determines not only frequency accuracy of the RF 
components, but also of everything else in the system
  including sampling.

I understand it is within the time spec. But the delay goes incremented 
linearly, it means if we wait for 30mins we are getting expected signal after 
0.5milliseconds from the desire time boundary 

So do we need to use rx streamer command to adjust it?.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/23/2020 11:47 AM, Prasad wrote:


*From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
*Sent:* Sunday, August 23, 2020 9:16 PM
*To:* Prasad; usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP B210: getting RX samples with 
gradually increase delay


On 08/23/2020 08:28 AM, Prasad wrote:

Dear Marcus,

Verified the code couple of time even tested bypassing USRP and it
works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an 
apparent "time slip"?

30.72e6.

Nearly 40ms one-four sample delay.


You're seeing a one to four-sample slip over a period of 40ms, unless I 
misunderstand what you're saying.


At 30.72e6 SPS, that amounts to between 0.8 and 2.4PPM, which is within 
spec for the B210 without an external clock.


The clock quality necessarily determines not only frequency accuracy of 
the RF components, but also of everything else in the system

  including sampling.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

 

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 9:16 PM
To: Prasad; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/23/2020 08:28 AM, Prasad wrote:

Dear Marcus,

 

Verified the code couple of time even tested bypassing USRP and it works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

 

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an apparent "time 
slip"?
30.72e6.

Nearly 40ms one-four sample delay.



From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 6:56 AM
To: kp...@trilcomm.com; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/22/2020 09:08 PM, kp...@trilcomm.com wrote:

Yes relative delay between samples in buffer.

While detecting SYNC signal of 5G periodically, it  detects gradually increased 
delay from its expected position.

It means expected to receive at  2280 position of buffer but its keep detecting 
away from expected position, 2281,2282,2284, and so on.

 

Thanks,

Prasad.

 

My guess is that you have an off-by-one error in your buffer-harvesting code.  
This has nothing to do with the device.




 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/23/2020 08:28 AM, Prasad wrote:


Dear Marcus,

Verified the code couple of time even tested bypassing USRP and it 
works fine.


So, suspecting any time_spec either in RX or TX missing in the code?

Regards,

Prasad.

What is your sample rate?  Over what time scales do you see an apparent 
"time slip"?




*From:*Marcus D. Leech [mailto:patchvonbr...@gmail.com]
*Sent:* Sunday, August 23, 2020 6:56 AM
*To:* kp...@trilcomm.com; usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] USRP B210: getting RX samples with 
gradually increase delay


On 08/22/2020 09:08 PM, kp...@trilcomm.com <mailto:kp...@trilcomm.com> 
wrote:


Yes relative delay between samples in buffer.

While detecting SYNC signal of 5G periodically, it  detects
gradually increased delay from its expected position.

It means expected to receive at  2280 position of buffer but its
keep detecting away from expected position,
2281,2282,2284, and so on.

Thanks,

Prasad.

My guess is that you have an off-by-one error in your 
buffer-harvesting code.  This has nothing to do with the device.




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

Dear Marcus,

 

Verified the code couple of time even tested bypassing USRP and it works fine.

So, suspecting any time_spec either in RX or TX missing in the code?

 

Regards,

Prasad.

 

From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, August 23, 2020 6:56 AM
To: kp...@trilcomm.com; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP B210: getting RX samples with gradually increase 
delay

 

On 08/22/2020 09:08 PM, kp...@trilcomm.com wrote:

Yes relative delay between samples in buffer.

While detecting SYNC signal of 5G periodically, it  detects gradually increased 
delay from its expected position.

It means expected to receive at  2280 position of buffer but its keep detecting 
away from expected position, 2281,2282,2284, and so on.

 

Thanks,

Prasad.

 

My guess is that you have an off-by-one error in your buffer-harvesting code.  
This has nothing to do with the device.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/22/2020 09:08 PM, kp...@trilcomm.com wrote:

Yes relative delay between samples in buffer.
While detecting SYNC signal of 5G periodically, it  detects gradually 
increased delay from its expected position.
It means expected to receive at  2280 position of buffer but its keep 
detecting away from expected position, 2281,2282,2284, and so on.


Thanks,
Prasad.

My guess is that you have an off-by-one error in your buffer-harvesting 
code.  This has nothing to do with the device.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Marcus D. Leech via USRP-users]

On 08/22/2020 11:27 AM, Prasad via USRP-users wrote:

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.
Delay *as measured where?*  Relative delay between samples in the same 
buffer?  Please be more specific...




-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, 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 
*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
'
 *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 

Re: [USRP-users] USRP B210: getting RX samples with gradually increase delay

[Prasad via USRP-users]

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, 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 
>> *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
>> '
>>     *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