[USRP-users] Re: Wrong Measurement Results

[henry . powell . xx]

Hi Rob,

I need complex signal. But I tried with a constant, too. I set what you said. 
But the result has not changed. I changed variables. I tried different setups 
in the context of what you wrote like lo_offset to 1MHz, 5MHz, bandwidth to 
5MHz, 10MHz, master_clock_rate to 20MHz all this combinations but still hasn’t 
changed.

Thank you for helping.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] request for x310

[STEFANI, Maurizio (External) via USRP-users]

HI,
I am using an x310 SDR,
I am able to ping it 192.168.10.2, but if I try to issue: uhd_find-devices 
-args addr=192.168.10.2, it return:
Linux, GNU C++ version 10.2.1 20201207; Boost_107400; UHD_3.15.0.0-4build1
No UHD Devices Found

Is there someone can help me?
Thank you in advance

maurizio
The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: request for x310

[Yasir Özçalık]

Hi Stefani,
Your USRP's IP address is "192.168.10.2" and its netmask is
"255.255.255.0". Therefore; you need to make your host IP address
192.168.10.X where X can be any number between 1 and 255 except 2. You can
test it by making your Host IP Address "192.168.10.1" with netmask
"255.255.255.0".

Kind Regards,
Yasir.

STEFANI, Maurizio (External) via USRP-users , 3
Mar 2023 Cum, 13:06 tarihinde şunu yazdı:

> HI,
>
> I am using an x310 SDR,
>
> I am able to ping it 192.168.10.2, but if I try to issue: uhd_find-devices
> –args addr=192.168.10.2, it return:
>
> Linux, GNU C++ version 10.2.1 20201207; Boost_107400; UHD_3.15.0.0-4build1
>
> No UHD Devices Found
>
>
>
> Is there someone can help me?
>
> Thank you in advance
>
>
>
> maurizio
> The information in this e-mail is confidential. The contents may not be
> disclosed or used by anyone other than the addressee. Access to this e-mail
> by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately
> and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness
> of this e-mail as it has been sent over public networks. If you have any
> concerns over the content of this message or its Accuracy or Integrity,
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated virus
> scanning software but you should take whatever measures you deem to be
> appropriate to ensure that this message and any attachments are virus free.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: request for x310

[Jonathon Pendlum]

Hello Maurizio,

Try going through these recovery steps:
https://kb.ettus.com/X300/X310_Device_Recovery

Jonathon

On Fri, Mar 3, 2023 at 7:07 PM STEFANI, Maurizio (External) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> HI,
>
> I am using an x310 SDR,
>
> I am able to ping it 192.168.10.2, but if I try to issue: uhd_find-devices
> –args addr=192.168.10.2, it return:
>
> Linux, GNU C++ version 10.2.1 20201207; Boost_107400; UHD_3.15.0.0-4build1
>
> No UHD Devices Found
>
>
>
> Is there someone can help me?
>
> Thank you in advance
>
>
>
> maurizio
> The information in this e-mail is confidential. The contents may not be
> disclosed or used by anyone other than the addressee. Access to this e-mail
> by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately
> and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness
> of this e-mail as it has been sent over public networks. If you have any
> concerns over the content of this message or its Accuracy or Integrity,
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated virus
> scanning software but you should take whatever measures you deem to be
> appropriate to ensure that this message and any attachments are virus free.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
-- 

Jonathon


*DISCLAIMER: Any attached Code is provided As Is. It has not been tested or
validated as a product, for use in a deployed application or system, or for
use in hazardous environments. You assume all risks for use of the Code.
Use of the Code is subject to terms of the licenses to the UHD or RFNoC
code with which the Code is used. Standard licenses to UHD and RFNoC can be
found at https://www.ettus.com/sdr-software/licenses/
.*

*NI will only perform services based on its understanding and condition
that the goods or services (i) are not for the use in the production or
development of any item produced, purchased, or ordered by any entity with
a footnote 1 designation in the license requirement column of Supplement
No. 4 to Part 744, U.S. Export Administration Regulations and (ii) such a
company is not a party to the transaction.  If our understanding is
incorrect, please notify us immediately because a specific authorization
may be required from the U.S. Commerce Department before the transaction
may proceed further.*
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: [EXTERNAL]Re: What do I need to do to make uhd_usrp_probe see my custom RFNOC module?

[Kevin Williams]

Hi Guys,

 

Answering my own question also.

 

I had a mismatch in the NOC_ID between the driver code and my firmware block.

 

After fixing that I could get uhd_usrp_probe and others, like gnuradio, to 
recognize my block.

 

It did still require an LD_PRELOAD after the “sudo make install” but that is ok 
for now.

 

Regards, Kevin

 

From: Brian Padalino  
Sent: Wednesday, 01 March 2023 16:20
To: Gwenhael Goavec-Merou 
Cc: Vermeulen, Bas (Consultant) ; 
usrp-users@lists.ettus.com
Subject: [EXTERNAL][USRP-users] Re: What do I need to do to make uhd_usrp_probe 
see my custom RFNOC module?

 

On Wed, Mar 1, 2023 at 8:59 AM Gwenhael Goavec-Merou mailto:gw...@trabucayre.com> > wrote:

On Wed, 1 Mar 2023 07:20:22 -0500
Brian Padalino mailto:bpadal...@gmail.com> > wrote:

> On Wed, Mar 1, 2023 at 5:40 AM Vermeulen, Bas (Consultant) via USRP-users <
> usrp-users@lists.ettus.com  > wrote:
> 
> > Just to answer my own question:
> >
> > Run uhd_usrp_probe with LD_PRELOAD=/usr/lib/librfnoc-module.so
> > uhd_usrp_probe and it will be able to find the RFNOC modules.
> > The same for any test programs you use, those need the LD_PRELOAD as well.
> >  
> 
> While this is a way to do it, I believe the preferred method is using the
> UHD_MODULE_PATH environment variable.
> 
> Set that to a location which contains all the .so files for any RFNoC
> modules, and UHD will load them automatically.  Note that if any non-.so
> files are in that path, you will get a warning about not being able to load
> the library.
> 
> Brian

/usr/lib is a default path for libraries.
Maybe using (as root) ldconfig to rebuild/refresh the cache used by the runtime
linker?

 

No - this doesn't make sense.  Use UHD_MODULE_PATH.

 

You can put your modules in ~/mymodules and point your UHD_MODULE_PATH to 
~/mymodules and things will work fine.

 

There is no need to play with LD_PRELOAD or worry about being root or install 
to default library paths.

 

Use UHD_MODULE_PATH.

 

Brian



smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: [EXTERNAL]Re: What do I need to do to make uhd_usrp_probe see my custom RFNOC module?

[Brian Padalino]

On Fri, Mar 3, 2023 at 10:14 AM Kevin Williams 
wrote:

> Hi Guys,
>
>
>
> Answering my own question also.
>
>
>
> I had a mismatch in the NOC_ID between the driver code and my firmware
> block.
>
>
>
> After fixing that I could get uhd_usrp_probe and others, like gnuradio, to
> recognize my block.
>
>
>
> It did still require an LD_PRELOAD after the “sudo make install” but that
> is ok for now.
>

I just want to reiterate that there is no need for LD_PRELOAD and you
should be using UHD_MODULE_PATH.

Brian
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: [EXTERNAL]Re: What do I need to do to make uhd_usrp_probe see my custom RFNOC module?

[Kevin Williams]

Thanks Brian, yes, this is true. I just checked it.

 

From: Brian Padalino  
Sent: Friday, 03 March 2023 17:46
To: Kevin Williams 
Cc: gw...@trabucayre.com; bas.vermeu...@molex.com; usrp-users@lists.ettus.com
Subject: Re: [EXTERNAL][USRP-users] Re: What do I need to do to make 
uhd_usrp_probe see my custom RFNOC module?

 

On Fri, Mar 3, 2023 at 10:14 AM Kevin Williams mailto:kevin.willi...@vastech.co.za> > wrote:

Hi Guys,

 

Answering my own question also.

 

I had a mismatch in the NOC_ID between the driver code and my firmware block.

 

After fixing that I could get uhd_usrp_probe and others, like gnuradio, to 
recognize my block.

 

It did still require an LD_PRELOAD after the “sudo make install” but that is ok 
for now.

 

I just want to reiterate that there is no need for LD_PRELOAD and you should be 
using UHD_MODULE_PATH.

 

Brian



smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Underflows every 33s at 200 Msps

[Eugene Grayver]

Hi Marcus,


Yes, it is a loopback through computer.  I have 3 threads (in addition to the 
DPDK threads):

Thread1 : Read from UHD into a circular buffer A

Thread2: Read from circular buffer A, minimal processing, write to circular 
buffer B

Thread3: Read from circular buffer B, write to UHD


The circular buffer uses standard synchronization (mutex/condvar).  My next 
plan is to try a lock-free buffer.  The fact that the system works at 100 Msps 
but fails extremely infrequently (in terms of samples processed) makes me think 
that something in the kernel is taking control of the CPU(s) even though they 
are isolated.


Eugene.



Responding to Marcus... for some reason his response did not show up in my 
email.

-

This is a "loopback through the computer stack" type application?
Basically a receiver and a transmitter, in separate threads, but
  sharing a buffer between them?

These can be tricky, and plenty of others have "stumbled" with this type
of app, particularly at high sample rates.   I've never done one of
  these myself, but I suspect that some kind of elastic FIFO mechanism
will be required.

I"m happy to have others chime in, but this class of application,
despite its appearance of simplicity can reveal the limitations of
  ordinary general-purpose operating systems, and their schedulers, and
buffer-management systems.





Eugene Grayver, Ph.D.
Aerospace Corp., Principal Engineer
Tel: 310.336.1274

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com