[USRP-users] Re: USRP B200 basic tone sampling in GNU radio

2023-02-23 Thread Marcus D. Leech

On 23/02/2023 16:39, Maxim Belotserkovsky wrote:
Hi. I'm doing initial verification of a B200. A sine wave at 100MHz is 
fed into front end. The receiver is configured to use its quadrature 
downconverter to bring the wave down to 100kHz, which is then sampled 
by a GR "USRP Source" component and displayed in a "Frequency Sink" 
GUI. I notice the following unexplained behavior: as long as I set the 
Sampling Rate parameter of the radio to anything > or equal to 200 kHz 
(i.e. more than twice the frequency of the analog tone I'm trying to 
sample) I see the tone in the FFT output where I expect it to be; 
however, any sampling frequency less than that, and I get no output at 
all. For example, with the 100kHz tone in my experiment, setting the 
sampling rate to 100kHz should result in a spectral line near DC, 
however, no output is observed. It is almost as if there is something 
going on behind the scenes that doesn't allow for aliasing to happen, 
either in the stock FPGA design or some other block external to the 
FPGA. Can anyone comment? I just want to conduct a very basic sanity 
check of the received down-conversion and sampling. Is there a 
functional description of the digital and analog processing chain that 
B200 comes from the factory with? Thanks



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Most of the signal processing in a B200 is done by the AD9361 RF 
front-end chip.    There is still a DDC in the FPGA, to handle
  cases where the AD9361 can't do all the job.    If you ask for 
100ksps (quite low for the B200), the job of delivering that
  bandwidth to the host will be shared between the AD9361 and the DDC 
in the FPGA.    The combined filter roll-off of those

  is going to be quite aggressive--this is pretty normal for SDRs.

The datasheets for the AD9361 are available freely, as is the source 
code for all of UHD and the firmware and FPGA for

  the B2xx series.


Here's the basic summary of what happens:

    The AD9361 chip arranges to deliver a complex-baseband (ZeroIF) 
sample stream to the FPGA at some sample-rate
    (that is often some multiple of the target sample rate).   The FPGA 
then uses its DDC implementation to bring the
    signal down to the lower sample rate, and PART OF THAT PROCESS 
inherently involves filtering.  That is then
    delivered to the host as a complex baseband signal.   UHD has code 
that knows how to configure the AD9361
    and FPGA elements to deliver what you asked for--including 
knowledge of what the minimum tuning granularity
    of the AD9361 is, so that it can tell the DDC to rotate the signal 
down to baseband first if necessary.


There are flourishes and nuances of course--there's analog gain blocks 
involved, quadrature I/Q balancing algorithms in
  the AD9361, etc.  The inside of the AD9361 is itself quite complex, 
and I think you'd need to get the "developer docs"
  to get all the information on how it works--but I think that's free 
and easy to get.


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


[USRP-users] USRP B200 basic tone sampling in GNU radio

2023-02-23 Thread Maxim Belotserkovsky
Hi. I'm doing initial verification of a B200. A sine wave at 100MHz is fed
into front end. The receiver is configured to use its quadrature
downconverter to bring the wave down to 100kHz, which is then sampled by a
GR "USRP Source" component and displayed in a "Frequency Sink" GUI. I
notice the following unexplained behavior: as long as I set the Sampling
Rate parameter of the radio to anything > or equal to 200 kHz (i.e. more
than twice the frequency of the analog tone I'm trying to sample) I see the
tone in the FFT output where I expect it to be; however, any sampling
frequency less than that, and I get no output at all. For example, with the
100kHz tone in my experiment, setting the sampling rate to 100kHz should
result in a spectral line near DC, however, no output is observed. It is
almost as if there is something going on behind the scenes that doesn't
allow for aliasing to happen, either in the stock FPGA design or some other
block external to the FPGA. Can anyone comment? I just want to conduct a
very basic sanity check of the received down-conversion and sampling. Is
there a functional description of the digital and analog processing chain
that B200 comes from the factory with? Thanks
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Active GPS Antenna For USRPs

2023-02-23 Thread Marcus D. Leech

On 23/02/2023 15:06, Hamed Al-Zubi wrote:

Would it be possible to provide the link to the antenna that you use?
Sorry, wish I could.   I think Amazon, about 3-4 years ago.  But really, 
any random active GPS antenna should work.


I wonder if yours perhaps isn't actually *active*?  I noticed that a 
*passive* antenna on the X310 is quite

  "hit and miss".




On Thursday, February 23, 2023 at 02:00:34 PM CST, Marcus D. Leech 
 wrote:



On 23/02/2023 14:53, Hamed Al-Zubi via USRP-users wrote:
Hello,

I am just wondering why the 3V active GPS antenna for the USRP N210 is 
compatible with the USRP X300/X310?
I have 3-5V active antenna manufactured from china, but it does not 
work with USRP X300. However, it works perfectly fine with N210.
The 5G Active GPS antenna  for USRP X300/X310 manufactured by ettus is 
expensive.


Regards,
HA

___
USRP-users mailing list --usrp-users@lists.ettus.com  

To unsubscribe send an email tousrp-users-le...@lists.ettus.com  

I have absolutely used a cheaper active GPS antenna with the X310 and 
it works just fine.    I'm using one right now
  with an Octoclock-G (which I think uses the same GPS module as 
inside the X310) and it has been working flawlessly 24/7

  for months.


___
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: Active GPS Antenna For USRPs

2023-02-23 Thread Marcus D. Leech

On 23/02/2023 14:53, Hamed Al-Zubi via USRP-users wrote:

Hello,

I am just wondering why the 3V active GPS antenna for the USRP N210 is 
compatible with the USRP X300/X310?
I have 3-5V active antenna manufactured from china, but it does not 
work with USRP X300. However, it works perfectly fine with N210.
The 5G Active GPS antenna  for USRP X300/X310 manufactured by ettus is 
expensive.


Regards,
HA

___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
I have absolutely used a cheaper active GPS antenna with the X310 and it 
works just fine.    I'm using one right now
  with an Octoclock-G (which I think uses the same GPS module as inside 
the X310) and it has been working flawlessly 24/7

  for months.

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


[USRP-users] Active GPS Antenna For USRPs

2023-02-23 Thread Hamed Al-Zubi via USRP-users
Hello, 

I am just wondering why the 3V active GPS antenna for the USRP N210 is 
compatible with the USRP X300/X310?
I have 3-5V active antenna manufactured from china, but it does not work with 
USRP X300. However, it works perfectly fine with N210. 
The 5G Active GPS antenna  for USRP X300/X310 manufactured by ettus is 
expensive.

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


[USRP-users] Fwd: Re: E310 GnuRadio upgrade?

2023-02-23 Thread Philip Balister
For the person asking about upgrading GNURadio on the E312. My outline 
from last year.


Philip


 Forwarded Message 
Subject:[USRP-users] Re: E310 GnuRadio upgrade?
Date:   Fri, 4 Nov 2022 15:42:31 -0700
From:   Rich Gopstein 
To: Philip Balister 
CC: Marcus D. Leech , usrp-users@lists.ettus.com



Thanks.  I'll take a look, though I suspect that is beyond my abilities...

Rich


On Fri, Nov 4, 2022 at 8:49 AM Philip Balister > wrote:


Random git links that might help:

https://github.com/balister/sdr-build/tree/dunfell-ettus


This will build a file system based of a Yocto Project branch that is
still supported. It does a a gcc version that causes fftw failures
though. This hasn't been updated in a couple of years, so it does need
updating to collect bug and security fixes.

https://github.com/balister/meta-sdr/tree/dunfell-3.10


Contains work to get gnuradio-3.10 building against the YP Dunfell
branch. Still needs some cleanup. Also I need to break out a layer to
update the gcc version so fftw works. This actually happen, but is a
spare time task :)

All of the above likely need uhd recipe updates.

So, basically the pieces are available to put gnuradio-3.10 on the E3XX
series are known, they just need someone to do the work to make it
happen.

Philip

On 11/2/22 19:05, Marcus D. Leech wrote:
 > On 02/11/2022 16:39, Rich Gopstein wrote:
 >> I tried following the instructions in here:
 >>

https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source


 >> to cross compile GnuRadio on my Ubuntu box, but the cmake failed
 >> because the OE environment was from 2016 and had old library
versions.
 >>
 >> I could really use some suggestions on how to get a more modern
 >> GnuRadio (3.9+) on the E310.
 >>
 >> Thanks.
 >> Rich
 > Here's a direct link to the images:
 >
 > https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.3.0.0/

 >
 >
 > That image includes GR 3.8.3
 >
 >
 >>
 >> On Tue, Oct 25, 2022 at 2:32 PM Rich Gopstein
mailto:r...@ourowndomain.com>>
 >> wrote:
 >>
 >>     I'd like to run GR 3.9 or later on the E310.  Is there a
 >>     documented process to upgrade GR on the E310?
 >>
 >>     Thanks.
 >>     Rich
 >>
 >>
 >> ___
 >> USRP-users mailing list --usrp-users@lists.ettus.com

 >> To unsubscribe send an email tousrp-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 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 mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: RFNoC OOT Module w/ GNURadio 3.10.5

2023-02-23 Thread Marcus D. Leech

On 23/02/2023 13:17, Mattingly, Rylee wrote:
Is there currently a way to create custom OOT RFNoC blocks that work 
with GNURadio 3.10?


I am currently using UHD 4.4.0.0 and GNURadio 3.10.5.1 and I am 
looking for an alternative to build RFNoC blocks that function with 
GNURadio. I have been using gr-ettus to build OOT blocks for GNURadio 
3.8 but it has been made clear in issues #60 
 and #66 
 that gr-ettus will 
not be upgraded for GR 3.10 and all of that functionality will be 
ported to gr-uhd.


I have noticed that there is no rfnocmodtool replacement in UHD and 
the example RFNoC  project in UHD does not support GNURadio.  So has 
the GNURadio functionality for OOT blocks already been ported over or 
is that still in the works?


Thank you,

Rylee Mattingly
Graduate Research Assistant
School of Electrical and Computer Engineering
The University of Oklahoma



I think the last time someone asked this question, the answer was "Real 
Soon Now(tm)".



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


[USRP-users] RFNoC OOT Module w/ GNURadio 3.10.5

2023-02-23 Thread Mattingly, Rylee
Is there currently a way to create custom OOT RFNoC blocks that work with 
GNURadio 3.10?

I am currently using UHD 4.4.0.0 and GNURadio 3.10.5.1 and I am looking for an 
alternative to build RFNoC blocks that function with GNURadio. I have been 
using gr-ettus to build OOT blocks for GNURadio 3.8 but it has been made clear 
in issues #60 and 
#66 that gr-ettus will not 
be upgraded for GR 3.10 and all of that functionality will be ported to gr-uhd.

I have noticed that there is no rfnocmodtool replacement in UHD and the example 
RFNoC  project in UHD does not support GNURadio.  So has the GNURadio 
functionality for OOT blocks already been ported over or is that still in the 
works?

Thank you,

Rylee Mattingly
Graduate Research Assistant
School of Electrical and Computer Engineering
The University of Oklahoma

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


[USRP-users] Re: libuhd - read IQ samples without discontinuities

2023-02-23 Thread Marcus D. Leech

On 23/02/2023 04:27, Peter Featherstone (XENINT) wrote:


Hi,

I’m trying to read samples from my B210 as fast as possible without 
gaps in the IQ.


I’m using a sample rate of 1e6 Hz and read 5s of IQ.

As an experiment, I read 16K samples at a time in a loop.

At each iteration I sleep for 5 seconds.

I was expecting to see loads of ERROR_CODE_OVERFLOW error codes, but I 
don’t.


Is it the case that that error is only “thrown” when you can’t write 
to a buffer quick enough, but not necessarily if you’re waiting too 
long between successive reads in a continuous RX stream?


Many thanks,

*Peter*


___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
If you want to capture samples discontinuously, this is not the way to 
do it.


Use "NUM_SAMPS_AND_MORE"  in creating your stream:

https://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html

This particular stream mode tells the device to send you the number of 
samples requested and to expect a future

  stream command to fetch more samples.

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


[USRP-users] Re: libuhd - read IQ samples without discontinuities

2023-02-23 Thread Rob Kossler
On Thu, Feb 23, 2023 at 4:28 AM Peter Featherstone (XENINT)
 wrote:
> I’m trying to read samples from my B210 as fast as possible without gaps in 
> the IQ.
> I’m using a sample rate of 1e6 Hz and read 5s of IQ.
> As an experiment, I read 16K samples at a time in a loop.
> At each iteration I sleep for 5 seconds.
> I was expecting to see loads of ERROR_CODE_OVERFLOW error codes, but I don’t.
> Is it the case that that error is only “thrown” when you can’t write to a 
> buffer quick enough, but not necessarily if you’re waiting too long between 
> successive reads in a continuous RX stream?
>
> Many thanks,
> Peter

I don't know why you aren't seeing the error, but I think you will
need to change your method to "read and discard samples" during your
sleep or else send the "stop streaming" command to the device during
your sleep.  I'm not sure you will have success by just "ignoring
errors" during your sleep.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Wrong Measurement Results

2023-02-23 Thread Rob Kossler
Is it possible that you are using a CW signal with no offset such that the
CW signal is right on top of the LO leakage?  Perhaps the LO leakage
"interference" is causing problems.  You could try this experiment with an
LO offset.
Rob
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] libuhd - read IQ samples without discontinuities

2023-02-23 Thread Peter Featherstone (XENINT)
Hi,

I'm trying to read samples from my B210 as fast as possible without gaps in the 
IQ.
I'm using a sample rate of 1e6 Hz and read 5s of IQ.
As an experiment, I read 16K samples at a time in a loop.
At each iteration I sleep for 5 seconds.
I was expecting to see loads of ERROR_CODE_OVERFLOW error codes, but I don't.
Is it the case that that error is only "thrown" when you can't write to a 
buffer quick enough, but not necessarily if you're waiting too long between 
successive reads in a continuous RX stream?
Many thanks,

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