[USRP-users] Different gain traces at RX interfaces

[Arash Jafari via USRP-users]

Hello All,

My instrument (USRP X310) has 2 equivalent UBX-160 daughter boards.




*|   |   |   RX Dboard: A|   |   |   ID: UBX-160 v2 (0x007e)|   |   |
Serial: 31D5AC*



* RX Dboard: B|   |   |   ID: UBX-160 v2 (0x007e)|   |   |   Serial:
31D5B02*

I applied an equivalent external stimulus at both RX interfaces.
but the same stimulus signal at RX1 and RX2 interfaces  results in an 18 dB
difference in relative gain trace!!
In attachment please find the relative gain trace.
Does anybody know what is wrong with the board?
Thank you in advance!


-- 
Dipl.-Ing. Arash Jafari

Phone: +43 650 844 3617
E-mail: arash.jafari.tele...@gmail.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Planning to buy USRP

[Kumari, Surabhi via USRP-users]

Hi,

I was working with LimeSDR with OpenAirInterface, We are not getting the 
desired result. We are planning to buy USRP. Please suggest which USRP shall we 
buy which should be compatible with openairinterface as well as free5GC.
Please let me know what are the other hardware requirements to work with USRP.

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

[USRP-users] Which ports to secure with RF terminators and how to setup loopback testing.

[Pavlos Basaras via USRP-users]

Hello,

i am a newbie to this so i would appreciate all help and pointers for
reading/understanding what i should (please excuse possibly newbie
questions, thanks!).

I have configured 2 usrp n310 devices, following the instructions from:
https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide
I am connected to both over all available ports eth0/sfp0/sfp1, and both
"usrp_find_devices" and "uhd_usrp_probe" seem to be working properly.

I would like to proceed with some real testing (
https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio
).

Q1: which TX ports should be secured with RF terminators? Assuming that we
use e.g., only RF 0, all TX ports in the remaining RF1-3 should be
terminated, correct? As we are not currently using any other port from the
front panel (e.g., gps, ref in, trig out, pps ), should these also be
terminated?  What about the daughterboard ports?

Q2:  the loopback configuration refers to using one usrp to test TX/RX,
correct?. So the setup for this testing is a single usrp, and focusing on
e.g., only on RF 0, by using sma-m to sma-m cable with 30dB attenuator to
start testing?

all the best,
Pavlos.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] 10us+ sample delay between daughterboards

[Johannes Demel via USRP-users]

Hi all,

I have an issue with multiple USRP streams. If they are on separate 
daughterboards, but on the same motherboard aka USRP, those streams are 
not time aligned. They show a time offset of more than 10us. I use one 
USRP source block in GNU Radio and configure it with multiple streams.


At first, I observed this behavior with N310s but now I see it on an 
X310 as well. I use a GNU Radio flowgraph where I set the clock to "PC 
clock". I'd expect all streams to be in sync because they are handled by 
the same object. At least that's what I hope.
On an X310 I have 2 RX streams that observe a signal from across the 
room. On an N310, I tried different configurations and I could observe 
this delay between daughterboards. They are in sync for one daughterboard.


My flowgraph handles frequency offsets etc. But constant time offsets 
between RX streams are problematic. And I suppose they should not be there.


I'd like to use GPSDOs at some point but I don't have a GPS signal in 
the lab. And I don't have an octoclock or smth similar. But all of this 
shouldn't matter since I only use on USRP for RX. Or am I missing smth?


USRP: N310/X310(with 2x UBX160)
UHD: 3.15LTS
OS: Ubuntu 20.04
GNU Radio 3.9 (aka master)

Cheers
Johannes

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

Re: [USRP-users] 1 Ts delay in USRP B210

[Prasad via USRP-users]

Thanks! a lot Marcus M and Marcus D for your valuable information.

Thanks,

-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 has been detected
>>
>>     Init PSS detected wit

[USRP-users] C++ thread Priority.

[David Carsenat via USRP-users]

Hello, I have made a c++ code which sends samples in the main function and
receives samples in a thread launched in this main function.
I have read that we can set the real time priority with the
set_thread_priority function.
I have tried to call this function (with parameters (1,true) inside the
main function but it doesn't seem to change the priority of the executable.
When I launch another application, I have lots of U and O.

Do you have an idea how to achieve what I want ? i.e. allocate almost all
computer resources to my uhd program ? What is the best way ?
I have already tuned my ubuntu with advice given on Ettus site.( cpu-freq
set etc...)

Many thanks

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

Re: [USRP-users] 10us+ sample delay between daughterboards

[Marcus D. Leech via USRP-users]

On 07/22/2020 12:39 PM, Johannes Demel via USRP-users wrote:

Hi all,

I have an issue with multiple USRP streams. If they are on separate 
daughterboards, but on the same motherboard aka USRP, those streams 
are not time aligned. They show a time offset of more than 10us. I use 
one USRP source block in GNU Radio and configure it with multiple 
streams.


At first, I observed this behavior with N310s but now I see it on an 
X310 as well. I use a GNU Radio flowgraph where I set the clock to "PC 
clock". I'd expect all streams to be in sync because they are handled 
by the same object. At least that's what I hope.
On an X310 I have 2 RX streams that observe a signal from across the 
room. On an N310, I tried different configurations and I could observe 
this delay between daughterboards. They are in sync for one 
daughterboard.


My flowgraph handles frequency offsets etc. But constant time offsets 
between RX streams are problematic. And I suppose they should not be 
there.


I'd like to use GPSDOs at some point but I don't have a GPS signal in 
the lab. And I don't have an octoclock or smth similar. But all of 
this shouldn't matter since I only use on USRP for RX. Or am I missing 
smth?


USRP: N310/X310(with 2x UBX160)
UHD: 3.15LTS
OS: Ubuntu 20.04
GNU Radio 3.9 (aka master)

Cheers
Johannes

Here's something you need to know about the time-keeping architecture in 
both X310 and N310.  There are, effectively TWO time-keeping

  registers.

When you use "Sync to PC", those registers each get updated as a 
*separate* operation across the wire, so there can be (as you observe) a

  several-microsecond inconsistency between them.

The whole thing about the 1PPS pulse when doing time-setting is that no 
matter how many timekeeper registers there are, they all get

  set at the same instant, due to the 1PPS pulse processing.



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

Re: [USRP-users] Which ports to secure with RF terminators and how to setup loopback testing.

[Marcus D. Leech via USRP-users]

On 07/22/2020 05:12 AM, Pavlos Basaras via USRP-users wrote:

Hello,

i am a newbie to this so i would appreciate all help and pointers for 
reading/understanding what i should (please excuse possibly newbie 
questions, thanks!).


I have configured 2 usrp n310 devices, following the instructions 
from: https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide
I am connected to both over all available ports eth0/sfp0/sfp1, and 
both "usrp_find_devices" and "uhd_usrp_probe" seem to be working properly.


I would like to proceed with some real testing 
(https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio).


Q1: which TX ports should be secured with RF terminators? Assuming 
that we use e.g., only RF 0, all TX ports in the remaining RF1-3 
should be terminated, correct? As we are not currently using any other 
port from the
front panel (e.g., gps, ref in, trig out, pps ), should these also be 
terminated?  What about the daughterboard ports?


Q2:  the loopback configuration refers to using one usrp to test 
TX/RX, correct?. So the setup for this testing is a single usrp, and 
focusing on e.g., only on RF 0, by using sma-m to sma-m cable with 
30dB attenuator to start testing?


all the best,
Pavlos.

Putting terminators on unused ports is good laboratory "hygiene" but not 
strictly necessary.


Placing 30-40dB "inline" in a loopback connection (direct connect 
between RX and TX) is mandatory, to prevent possible damage to the receiver.




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

Re: [USRP-users] Planning to buy USRP

[Marcus D. Leech via USRP-users]

On 07/22/2020 04:45 AM, Kumari, Surabhi via USRP-users wrote:


Hi,

I was working with LimeSDR with OpenAirInterface, We are not getting 
the desired result. We are planning to buy USRP. Please suggest which 
USRP shall we buy which should be compatible with openairinterface as 
well as free5GC.


Please let me know what are the other hardware requirements to work 
with USRP.


Regards,

Surabhi


You may want to augment whatever USRP you buy with a GPSDO module, since 
I think most of these "stacks" are sensitive to timing quality.


Without knowing exactly what problems you encountered with the LimeSDR, 
it's hard to make recommendations.  I hate to do this on a technical

  list, but sa...@ni.com might be your best bet.


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

Re: [USRP-users] Different gain traces at RX interfaces

[Marcus D. Leech via USRP-users]

On 07/22/2020 04:37 AM, Arash Jafari via USRP-users wrote:

Hello All,

My instrument (USRP X310) has 2 equivalent UBX-160 daughter boards.


*|   |   |   RX Dboard: A
|   |   |   ID: UBX-160 v2 (0x007e)
|   |   |   Serial: 31D5AC*
*
*
* RX Dboard: B
|   |   |   ID: UBX-160 v2 (0x007e)
|   |   |   Serial: 31D5B02*
*
*
I applied an equivalent external stimulus at both RX interfaces.
but the same stimulus signal at RX1 and RX2 interfaces  results in an 
18 dB difference in relative gain trace!!

In attachment please find the relative gain trace.
Does anybody know what is wrong with the board?
Thank you in advance!
*
*
*
*
--
Dipl.-Ing. Arash Jafari

Phone: +43 650 844 3617
E-mail: arash.jafari.tele...@gmail.com 



How are these interfaces being driven?  Hard-wired?  Antenna?   What is 
the magnitude of the stimulus signal?


Are you sure you are plugged in to the right connectors on the front 
panel?   Is the gain being set to the same thing on both interfaces?



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

Re: [USRP-users] C++ thread Priority.

[Marcus D. Leech via USRP-users]

On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
Hello, I have made a c++ code which sends samples in the main function 
and receives samples in a thread launched in this main function.
I have read that we can set the real time priority with the 
set_thread_priority function.
I have tried to call this function (with parameters (1,true) inside 
the main function but it doesn't seem to change the priority of the 
executable. When I launch another application, I have lots of U and O.


Do you have an idea how to achieve what I want ? i.e. allocate almost 
all computer resources to my uhd program ? What is the best way ?
I have already tuned my ubuntu with advice given on Ettus site.( 
cpu-freq set etc...)


Many thanks

David

In general, applications have only very-rough control over the behavior 
of the scheduler.  This is true in most general-purpose operating system

  environments, whether it's Windows, Linux, *BSD, MacOS, etc.

If you've played with priorities, and starting up other programs causes 
OU to happen, you should probably consider:


(A) Optimizing your code -- find out where the hot-spots are, and see if 
they can be improved

(B) Choosing a faster CPU

The CPU usage of a DSP flow is roughly proportional to:

inherent-per-sample-complexity X sample-rate

Can you lower the sample rate and still achieve what you need to 
achieve?  Can you improve the main-path per-sample complexity?




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

Re: [USRP-users] C++ thread Priority.

[David Carsenat via USRP-users]

Ok thanks. The code is really simple and i don't think it can be optimized.
Is there other linux OS i can try ?
Thanks again.

Le mer. 22 juil. 2020 à 19:12, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> a écrit :

> On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
> > Hello, I have made a c++ code which sends samples in the main function
> > and receives samples in a thread launched in this main function.
> > I have read that we can set the real time priority with the
> > set_thread_priority function.
> > I have tried to call this function (with parameters (1,true) inside
> > the main function but it doesn't seem to change the priority of the
> > executable. When I launch another application, I have lots of U and O.
> >
> > Do you have an idea how to achieve what I want ? i.e. allocate almost
> > all computer resources to my uhd program ? What is the best way ?
> > I have already tuned my ubuntu with advice given on Ettus site.(
> > cpu-freq set etc...)
> >
> > Many thanks
> >
> > David
> >
> In general, applications have only very-rough control over the behavior
> of the scheduler.  This is true in most general-purpose operating system
>environments, whether it's Windows, Linux, *BSD, MacOS, etc.
>
> If you've played with priorities, and starting up other programs causes
> OU to happen, you should probably consider:
>
> (A) Optimizing your code -- find out where the hot-spots are, and see if
> they can be improved
> (B) Choosing a faster CPU
>
> The CPU usage of a DSP flow is roughly proportional to:
>
> inherent-per-sample-complexity X sample-rate
>
> Can you lower the sample rate and still achieve what you need to
> achieve?  Can you improve the main-path per-sample complexity?
>
>
>
> ___
> 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

Re: [USRP-users] C++ thread Priority.

[Marcus D. Leech via USRP-users]

On 07/22/2020 01:22 PM, David Carsenat wrote:
Ok thanks. The code is really simple and i don't think it can be 
optimized.

Is there other linux OS i can try ?
Thanks again.

If it's really simple, what is the sample-rate?  Is it trying to write 
data to the filesystem at high rates?  No amount of code optimization 
can get
  around the fact that the disk subsystem is very slow compared to 
other parts of the computer, like memory, CPU, etc.



Le mer. 22 juil. 2020 à 19:12, Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> a écrit :


On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
> Hello, I have made a c++ code which sends samples in the main
function
> and receives samples in a thread launched in this main function.
> I have read that we can set the real time priority with the
> set_thread_priority function.
> I have tried to call this function (with parameters (1,true) inside
> the main function but it doesn't seem to change the priority of the
> executable. When I launch another application, I have lots of U
and O.
>
> Do you have an idea how to achieve what I want ? i.e. allocate
almost
> all computer resources to my uhd program ? What is the best way ?
> I have already tuned my ubuntu with advice given on Ettus site.(
> cpu-freq set etc...)
>
> Many thanks
>
> David
>
In general, applications have only very-rough control over the
behavior
of the scheduler.  This is true in most general-purpose operating
system
   environments, whether it's Windows, Linux, *BSD, MacOS, etc.

If you've played with priorities, and starting up other programs
causes
OU to happen, you should probably consider:

(A) Optimizing your code -- find out where the hot-spots are, and
see if
they can be improved
(B) Choosing a faster CPU

The CPU usage of a DSP flow is roughly proportional to:

inherent-per-sample-complexity X sample-rate

Can you lower the sample rate and still achieve what you need to
achieve?  Can you improve the main-path per-sample complexity?



___
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

Re: [USRP-users] C++ thread Priority.

[David Carsenat via USRP-users]

It just put received samples in a circular buffer and  transmit this
buffer. A delay line.
But the SR is 50 Msps... 8 bits.
 Do you have ideas about OS ?
Thanks.

Le mer. 22 juil. 2020 à 19:33, Marcus D. Leech  a
écrit :

> On 07/22/2020 01:22 PM, David Carsenat wrote:
>
> Ok thanks. The code is really simple and i don't think it can be
> optimized.
> Is there other linux OS i can try ?
> Thanks again.
>
> If it's really simple, what is the sample-rate?  Is it trying to write
> data to the filesystem at high rates?  No amount of code optimization can
> get
>   around the fact that the disk subsystem is very slow compared to other
> parts of the computer, like memory, CPU, etc.
>
>
> Le mer. 22 juil. 2020 à 19:12, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> a écrit :
>
>> On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
>> > Hello, I have made a c++ code which sends samples in the main function
>> > and receives samples in a thread launched in this main function.
>> > I have read that we can set the real time priority with the
>> > set_thread_priority function.
>> > I have tried to call this function (with parameters (1,true) inside
>> > the main function but it doesn't seem to change the priority of the
>> > executable. When I launch another application, I have lots of U and O.
>> >
>> > Do you have an idea how to achieve what I want ? i.e. allocate almost
>> > all computer resources to my uhd program ? What is the best way ?
>> > I have already tuned my ubuntu with advice given on Ettus site.(
>> > cpu-freq set etc...)
>> >
>> > Many thanks
>> >
>> > David
>> >
>> In general, applications have only very-rough control over the behavior
>> of the scheduler.  This is true in most general-purpose operating system
>>environments, whether it's Windows, Linux, *BSD, MacOS, etc.
>>
>> If you've played with priorities, and starting up other programs causes
>> OU to happen, you should probably consider:
>>
>> (A) Optimizing your code -- find out where the hot-spots are, and see if
>> they can be improved
>> (B) Choosing a faster CPU
>>
>> The CPU usage of a DSP flow is roughly proportional to:
>>
>> inherent-per-sample-complexity X sample-rate
>>
>> Can you lower the sample rate and still achieve what you need to
>> achieve?  Can you improve the main-path per-sample complexity?
>>
>>
>>
>> ___
>> 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

Re: [USRP-users] C++ thread Priority.

[Marcus D. Leech via USRP-users]

On 07/22/2020 01:40 PM, David Carsenat wrote:
It just put received samples in a circular buffer and  transmit this 
buffer. A delay line.

But the SR is 50 Msps... 8 bits.
 Do you have ideas about OS ?
Thanks.

There are commercial real-time low-latency OS "out there" that aren't 
free, and UHD has not been ported to them as far as I know.



Le mer. 22 juil. 2020 à 19:33, Marcus D. Leech 
mailto:patchvonbr...@gmail.com>> a écrit :


On 07/22/2020 01:22 PM, David Carsenat wrote:

Ok thanks. The code is really simple and i don't think it can be
optimized.
Is there other linux OS i can try ?
Thanks again.


If it's really simple, what is the sample-rate?  Is it trying to
write data to the filesystem at high rates?  No amount of code
optimization can get
  around the fact that the disk subsystem is very slow compared to
other parts of the computer, like memory, CPU, etc.



Le mer. 22 juil. 2020 à 19:12, Marcus D. Leech via USRP-users
mailto:usrp-users@lists.ettus.com>>
a écrit :

On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
> Hello, I have made a c++ code which sends samples in the
main function
> and receives samples in a thread launched in this main
function.
> I have read that we can set the real time priority with the
> set_thread_priority function.
> I have tried to call this function (with parameters
(1,true) inside
> the main function but it doesn't seem to change the
priority of the
> executable. When I launch another application, I have lots
of U and O.
>
> Do you have an idea how to achieve what I want ? i.e.
allocate almost
> all computer resources to my uhd program ? What is the best
way ?
> I have already tuned my ubuntu with advice given on Ettus
site.(
> cpu-freq set etc...)
>
> Many thanks
>
> David
>
In general, applications have only very-rough control over
the behavior
of the scheduler.  This is true in most general-purpose
operating system
   environments, whether it's Windows, Linux, *BSD, MacOS, etc.

If you've played with priorities, and starting up other
programs causes
OU to happen, you should probably consider:

(A) Optimizing your code -- find out where the hot-spots are,
and see if
they can be improved
(B) Choosing a faster CPU

The CPU usage of a DSP flow is roughly proportional to:

inherent-per-sample-complexity X sample-rate

Can you lower the sample rate and still achieve what you need to
achieve?  Can you improve the main-path per-sample complexity?



___
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

Re: [USRP-users] Signal transmission on a USRP X310

[Jerrid Plymale via USRP-users]

Hello Marcus,

The tool I have been using for initial signal quality checking has been the QT 
Waterfall sink in GNU Radio Companion to see if the signals are looking 
correct. Upon seeing that it looked like I was loosing data when I set the USRP 
sink's center frequency above 1.3 GHz, I connected the output of the USRP to a 
spectrum analyzer to get some more accurate measurements of the signal. After 
running some tests, I found that at a center frequency less than 1.3 GHz, the 
strength of the signal was somewhere around -70 dBm. When I would increase the 
frequency to a value above 1.3 GHz, and no changes to anything else (e.g., 
channel gain, sample rate), the strength dropped to somewhere around -90 dBm. 
This was measured by tracking the peak power from an FFT of the signal input to 
the spectrum analyzer. Would it help to see the flowgraph?

Best Regards,

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

Re: [USRP-users] Signal transmission on a USRP X310

[Marcus D. Leech via USRP-users]

On 07/22/2020 02:15 PM, Jerrid Plymale via USRP-users wrote:


Hello Marcus,

The tool I have been using for initial signal quality checking has 
been the QT Waterfall sink in GNU Radio Companion to see if the 
signals are looking correct. Upon seeing that it looked like I was 
loosing data when I set the USRP sink’s center frequency above 1.3 
GHz, I connected the output of the USRP to a spectrum analyzer to get 
some more accurate measurements of the signal. After running some 
tests, I found that at a center frequency less than 1.3 GHz, the 
strength of the signal was somewhere around -70 dBm. When I would 
increase the frequency to a value above 1.3 GHz, and no changes to 
anything else (e.g., channel gain, sample rate), the strength dropped 
to somewhere around -90 dBm. This was measured by tracking the peak 
power from an FFT of the signal input to the spectrum analyzer. Would 
it help to see the flowgraph?


Best Regards,

Jerrid Plymale



Yes, it would help to see the flow-graph, and to see what settings 
you're using in the TX path.  The output power from the UBX is not 
likely to be
  completely consistent across the entire tuneable range, but 20dB is 
way more than I would expect.




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

Re: [USRP-users] X310 with DPDK

[Rob Kossler via USRP-users]

I have used DPDK with the X310.  I don't recall specifically, but I'm
pretty sure you either...
a) don't specify mgmt_addr, or
b) specify it the same as addr


On Tue, Jul 21, 2020 at 12:12 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 07/21/2020 10:53 AM, Carmichael, Ryan via USRP-users wrote:
>
> On the DPDK page (https://files.ettus.com/manual/page_dpdk.html) the
> following statement is made:
>
>
>
> “Device discovery via DPDK is not currently implemented, so the device
> args mgmt_addr, addr, and second_addr (if applicable) must all be
> specified at runtime. There is no mechanism for MPM's TCP/IP control
> traffic to flow over a link that is occupied by DPDK, so mgmt_addr must
> point to a link that is not used for CHDR, such as N310's RJ45 port.”
>
>
>
> I’ve been using the X310 without DPDK with dual 10Gb SPI/SFP+ connections
> (192.168.30.2, 192.168.40.2). Once I start DPDK, ifconfig no longer shows
> the NICs at all, which I assume is what it is supposed to be doing. My
> question is, what is the ‘mgmt_addr’ ? I’ve never used it before when using
> the X310. And how do I make sure the mgmt_addr isn’t using a CHDR link? The
> X310 only has two RJ45s, right – and they’re both being used by DPDK.
>
>
>
> Thanks,
>
> -  Ryan
>
>
>
>
>
>
>
>
>
>
>
>
> *Ignore my last. Yes, the X310 has only the two ports.   I was suffering
> from cognitive pollution between the N310 and X310. So, this is an
> excellent point.   I don't use DPDK myself, since my hosts don't have the
> right NICs, and it's really only justified for very high   sample rates.
> Also, X310 is not an MPM device, so the comments about MPM traffic aren't
> relevant to X310 as far as I know. *
> ___
> 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

Re: [USRP-users] C++ thread Priority.

[Rob Kossler via USRP-users]

If you are using X310 or N310, you might try DPDK. Even though it is a
pain, it would be a whole lot easier than trying a new OS, I believe.
Using DPDK enabled my application (which was storing Rx samples to SSD) to
run a bunch faster than without DPDK.

On Wed, Jul 22, 2020 at 1:47 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 07/22/2020 01:40 PM, David Carsenat wrote:
>
> It just put received samples in a circular buffer and  transmit this
> buffer. A delay line.
> But the SR is 50 Msps... 8 bits.
>  Do you have ideas about OS ?
> Thanks.
>
> There are commercial real-time low-latency OS "out there" that aren't
> free, and UHD has not been ported to them as far as I know.
>
>
> Le mer. 22 juil. 2020 à 19:33, Marcus D. Leech 
> a écrit :
>
>> On 07/22/2020 01:22 PM, David Carsenat wrote:
>>
>> Ok thanks. The code is really simple and i don't think it can be
>> optimized.
>> Is there other linux OS i can try ?
>> Thanks again.
>>
>> If it's really simple, what is the sample-rate?  Is it trying to write
>> data to the filesystem at high rates?  No amount of code optimization can
>> get
>>   around the fact that the disk subsystem is very slow compared to other
>> parts of the computer, like memory, CPU, etc.
>>
>>
>> Le mer. 22 juil. 2020 à 19:12, Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> a écrit :
>>
>>> On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
>>> > Hello, I have made a c++ code which sends samples in the main function
>>> > and receives samples in a thread launched in this main function.
>>> > I have read that we can set the real time priority with the
>>> > set_thread_priority function.
>>> > I have tried to call this function (with parameters (1,true) inside
>>> > the main function but it doesn't seem to change the priority of the
>>> > executable. When I launch another application, I have lots of U and O.
>>> >
>>> > Do you have an idea how to achieve what I want ? i.e. allocate almost
>>> > all computer resources to my uhd program ? What is the best way ?
>>> > I have already tuned my ubuntu with advice given on Ettus site.(
>>> > cpu-freq set etc...)
>>> >
>>> > Many thanks
>>> >
>>> > David
>>> >
>>> In general, applications have only very-rough control over the behavior
>>> of the scheduler.  This is true in most general-purpose operating system
>>>environments, whether it's Windows, Linux, *BSD, MacOS, etc.
>>>
>>> If you've played with priorities, and starting up other programs causes
>>> OU to happen, you should probably consider:
>>>
>>> (A) Optimizing your code -- find out where the hot-spots are, and see if
>>> they can be improved
>>> (B) Choosing a faster CPU
>>>
>>> The CPU usage of a DSP flow is roughly proportional to:
>>>
>>> inherent-per-sample-complexity X sample-rate
>>>
>>> Can you lower the sample rate and still achieve what you need to
>>> achieve?  Can you improve the main-path per-sample complexity?
>>>
>>>
>>>
>>> ___
>>> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] C++ thread Priority.

[Marcus D. Leech via USRP-users]

On 07/22/2020 03:18 PM, Rob Kossler wrote:
If you are using X310 or N310, you might try DPDK. Even though it is a 
pain, it would be a whole lot easier than trying a new OS, I believe.  
Using DPDK enabled my application (which was storing Rx samples to 
SSD) to run a bunch faster than without DPDK.
Thanks, Rob.  DPDK does facilitate lower-cost higher data transfer into 
the application.  That may, or may not, be the issue here.





On Wed, Jul 22, 2020 at 1:47 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 07/22/2020 01:40 PM, David Carsenat wrote:

It just put received samples in a circular buffer and  transmit
this buffer. A delay line.
But the SR is 50 Msps... 8 bits.
 Do you have ideas about OS ?
Thanks.


There are commercial real-time low-latency OS "out there" that
aren't free, and UHD has not been ported to them as far as I know.



Le mer. 22 juil. 2020 à 19:33, Marcus D. Leech
mailto:patchvonbr...@gmail.com>> a écrit :

On 07/22/2020 01:22 PM, David Carsenat wrote:

Ok thanks. The code is really simple and i don't think it
can be optimized.
Is there other linux OS i can try ?
Thanks again.


If it's really simple, what is the sample-rate?  Is it trying
to write data to the filesystem at high rates?  No amount of
code optimization can get
  around the fact that the disk subsystem is very slow
compared to other parts of the computer, like memory, CPU, etc.



Le mer. 22 juil. 2020 à 19:12, Marcus D. Leech via
USRP-users mailto:usrp-users@lists.ettus.com>> a écrit :

On 07/22/2020 12:56 PM, David Carsenat via USRP-users wrote:
> Hello, I have made a c++ code which sends samples in
the main function
> and receives samples in a thread launched in this main
function.
> I have read that we can set the real time priority
with the
> set_thread_priority function.
> I have tried to call this function (with parameters
(1,true) inside
> the main function but it doesn't seem to change the
priority of the
> executable. When I launch another application, I have
lots of U and O.
>
> Do you have an idea how to achieve what I want ? i.e.
allocate almost
> all computer resources to my uhd program ? What is the
best way ?
> I have already tuned my ubuntu with advice given on
Ettus site.(
> cpu-freq set etc...)
>
> Many thanks
>
> David
>
In general, applications have only very-rough control
over the behavior
of the scheduler.  This is true in most general-purpose
operating system
   environments, whether it's Windows, Linux, *BSD,
MacOS, etc.

If you've played with priorities, and starting up other
programs causes
OU to happen, you should probably consider:

(A) Optimizing your code -- find out where the hot-spots
are, and see if
they can be improved
(B) Choosing a faster CPU

The CPU usage of a DSP flow is roughly proportional to:

inherent-per-sample-complexity X sample-rate

Can you lower the sample rate and still achieve what you
need to
achieve?  Can you improve the main-path per-sample
complexity?



___
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



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

Re: [USRP-users] gnuradio-companion can not find RFNOC blocks

[Hodges, Jeff via USRP-users]

Cherif,


Did you install gr-ettus? Unless you are using UHD on master branch (4.0), you 
need gr-ettus. I installed UHD3.15LTS on Ubuntu 18.04 without PYBOMBS and it 
works fine.


Jeff


From: USRP-users  on behalf of Marcus 
Müller via USRP-users 
Sent: Tuesday, July 21, 2020 2:39:46 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] gnuradio-companion can not find RFNOC blocks

Hi Cherif,

this is typically an issue encountered if you didn't install the blocks
into a directory GNU Radio companion looks into.

Make sure that you've used `-DCMAKE_INSTALL_PREFIX=` with a prefix that
contains a path that GNU Radio looks into; GRC prints the paths into the
console when it's started!

Best regards,
Marcus

On 24.06.20 20:03, cherif chibane via USRP-users wrote:
> Hello,
>
> I have just installed RFNOC using the app note:
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
> I used the manual way because I was having some weird problems using
> Pybombs and I am using X300 under Ubuntu 18.4. I can successfully use  all
> the UHD commands, load FPGA with new images etc.I can also successfully use
> the Gnuradio-comapnion gnuradio blocks.
>
> But when I use gnuradio-comapnion graphs with  RFNOC blocks, it can not
> find them.
> Here is the error:
> Loading: "/home/rfnocdev/rfnoc/gr-ettus/examples/rfnoc/rfnoc_ddc.grc"
> Block key "variable_uhd_device3" not found
> Block key "uhd_rfnoc_streamer_ddc" not found
> Block key "uhd_rfnoc_streamer_fifo" not found
> Block key "uhd_rfnoc_streamer_radio" not found
>
>
> Any ideas What I am missing here.
>
> Thanks,
> Cherif
>
>
> ___
> 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
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 RFNoC Basic Transmit Signal Source Flowgraph Not Working

[Hodges, Jeff via USRP-users]

I get a set_tx_gain error running a basic signal generator through RFNoC Radio:

Signal Source -> DMA FIFO -> DUC -> Radio  (See image below)


This is equivalent to:

Signal Source --> USRP Sink(Works fine)


https://kb.ettus.com/File:dma_fifo_v02.png




Traceback (most recent call last):
  File "/home/nvd/Documents/top_block.py", line 169, in 
main()
  File "/home/nvd/Documents/top_block.py", line 157, in main
tb = top_block_cls()
  File "/home/nvd/Documents/top_block.py", line 84, in __init__
self.uhd_rfnoc_streamer_radio_0.set_tx_gain(0, 0)
  File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line 3235, 
in set_tx_gain
return _ettus_swig.rfnoc_radio_sptr_set_tx_gain(self, gain, chan)
RuntimeError: _Map_base::at



I am using 3.15.LTS.


Any ideas?

Thanks,


Jeff

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

Re: [USRP-users] How to suppress the overflow indicator "O"

[Mikio Fukushima via USRP-users]

Hi Xavier,
Thank you for your advice.
I will try it next Monday and let you know.

Regards,
Mikio

2020年7月22日(水) 15:51 Xavier Arteaga :

> Hi Mikio,
> You can disable the fastpath logging in runtime by setting the environment
> variable UHD_LOG_FASTPATH_DISABLE to 1:
>
> Example in C:
>   setenv("UHD_LOG_FASTPATH_DISABLE", "1", 0);
>
> Regards,
> Xavier
>
> On Wed, 22 Jul 2020 at 05:38, Mikio Fukushima via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>> UHD device driver prints the indicator "O" while overflow to stdout.
>> How to supress this printing of the indicator?
>>
>> Mikio Fukushima
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 

===
 福島 幹雄 (Mikio Fukushima)
 株式会社ドルフィンシステム (Dolphin System Co.,Ltd)

〒171-0014 東京都豊島区池袋２－４５－１
アークシティ池袋 ６０１

Mail: mi...@dolphinsystem.jp
URL : http://www.dolphinsystem.jp/
TEL/FAX : 03-6658-4949
===
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com