[USRP-users] Messaging the DDC

[Jason Matusiak via USRP-users]

I have a block that outputs a message with a frequency.  I would love to be 
able to set the frequency adjustment in the RFNoC DDC, but I don't see a way to 
do it it automagically.
I am guessing that there is no way to do it even though it can be set from a 
variable slider easily. Is there an option I am missing?___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 DAC sample rate

[Marcus D. Leech via USRP-users]

On 09/26/2018 03:35 PM, Mega Samples via USRP-users wrote:

Hi USRP-users,

I am working on a project where I have an X300, and want to use the 
DAC at a sample rate of 800 MS/s, which is what is advertised on the 
X300 datasheet.  However, it appears the maximum sample rate is set by 
the FPGA at 200 MHz (see "Clocking and Sample Rates" section at 
http://kb.ettus.com/X300/X310). How is it possible to use the DAC with 
a sample rate higher than 200 MHz?


Thanks,
Mike

You can't get 800Msps over 10GiGe, so the only way to do this is with an 
implementation inside the FPGA.  Also, the AD9146 has a 2X or 4X 
interpolator
  internal to it, so samples that arrive at 200Msps are interpolated 
internally to 800Msps, which is where that figure comes from.







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

[USRP-users] X300 DAC sample rate

[Mega Samples via USRP-users]

Hi USRP-users,

I am working on a project where I have an X300, and want to use the DAC at
a sample rate of 800 MS/s, which is what is advertised on the X300
datasheet.  However, it appears the maximum sample rate is set by the FPGA
at 200 MHz (see "Clocking and Sample Rates" section at
http://kb.ettus.com/X300/X310).  How is it possible to use the DAC with a
sample rate higher than 200 MHz?

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

Re: [USRP-users] B205 External Reference issue

[Marcus D. Leech via USRP-users]

On 09/26/2018 02:24 PM, Arun kumar Verma wrote:

Hi Marcus

well I am connecting external ref of 10MHz on Ref Input SMA connector 
and once I connect this and set my clock source for external source 
then we are getting spurios, these spurs are low but for AM,FM audio 
demodulation even Hz suprs can create probelem and that is what we 
are facing. Right now what we using a VCXO of 50ppb satbility and 
what we noticed that with the internal clock there was a shift in 
frequency of about 5KHz at 3GHz input while with external Ref shift 
was around 300Hz. Is it possible to switch off supply manually for 
internal oscillator and board still works?


Regards,
Arun Verma



Could you please post an image of the situation, showing the spur levels?





*From:* Marcus D. Leech via USRP-users 
*To:* usrp-users@lists.ettus.com
*Sent:* Wednesday, 26 September 2018 9:15 PM
*Subject:* Re: [USRP-users] B205 External Reference issue

On 09/26/2018 02:42 AM, Arun kumar Verma via USRP-users wrote:

Hi

We are using B205i-mini and we found that when I am sleclecting 
external Ref using set_clock_source("ëxternal"); I am getting 
intermodulation components in Hz.
I think supply for the internal oscillator is still on and it is not 
compeletly shutting down. Is there any options to switch off the 
suppy of ineternal oscillator through some API.


Regards,
Arun Verma


There is only one clock on the B205 -- a 40MHz VCXO.   When you switch 
to "external", the FPGA implements a clock-steering

  "servo" that phase-locks that 40MHz clock to the external reference.

You're probably seeing very low-level clock spurs that appear as a 
result of the servo algorithm.




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



 
	I’m protected online with Avast Free Antivirus. Get it here — it’s 
free forever. 
 





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

Re: [USRP-users] B205 External Reference issue

[Arun kumar Verma via USRP-users]

Hi Marcus 
well I am connecting external ref of 10MHz on Ref Input SMA connector and once 
I connect this and set my clock source for external source then we are getting 
spurios, these spurs are low but for AM,FM audio demodulation even Hz suprs can 
create probelem and that is what we are facing. Right now what we using a VCXO 
of 50ppb satbility and what we noticed that with the internal clock there was a 
shift in frequency of about 5KHz at 3GHz input while with external Ref shift 
was around 300Hz. Is it possible to switch off supply manually for internal 
oscillator and board still works?
Regards,Arun Verma


  From: Marcus D. Leech via USRP-users 
 To: usrp-users@lists.ettus.com 
 Sent: Wednesday, 26 September 2018 9:15 PM
 Subject: Re: [USRP-users] B205 External Reference issue
   
 On 09/26/2018 02:42 AM, Arun kumar Verma via USRP-users wrote:
  
 Hi  
  We are using B205i-mini and we found that when I am sleclecting external Ref 
using set_clock_source("ëxternal"); I am getting  intermodulation components in 
Hz. I think supply for the internal oscillator is still on and it is not 
compeletly shutting down. Is there any options to switch off the suppy of 
ineternal oscillator through some API.  
  Regards, Arun Verma 
  
 
 There is only one clock on the B205 -- a 40MHz VCXO.   When you switch to 
"external", the FPGA implements a clock-steering
   "servo" that phase-locks that 40MHz clock to the external reference.
 
 You're probably seeing very low-level clock spurs that appear as a result of 
the servo algorithm.
 
 
 
 ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


   

|  | I’m protected online with Avast Free Antivirus. Get it here — it’s free 
forever.  |

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

Re: [USRP-users] Rssi reading on b205/b210

[Marcus D. Leech via USRP-users]

On 09/26/2018 12:28 PM, Chintan Patel via USRP-users wrote:

Thanks - two follow up questions:

1. Is RSSI exposed as a sensor for the B205mini?
2. Does the Python UHD API, allow reading this in python?

Thanks

Yes to both as far as I can tell.





On Fri, Sep 21, 2018 at 8:20 PM Julian Arnold > wrote:


Hey,

Since release 3.8.2 the RSSI is exposed as a frontend sensor.
You should be able to read it using the usual sensor read-back
mechanism
(look at get_rx_senor_names and get_rx_sensor())

Cheers,
Julian

> On 21. Sep 2018, at 17:04, Chintan Patel via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:
>
> Hi,
>
> Is there a function/script in the uhd driver to read the rssi
for the b205/b210?
>
> Thanks
> ___
> 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] Rssi reading on b205/b210

[Chintan Patel via USRP-users]

Thanks - two follow up questions:

1. Is RSSI exposed as a sensor for the B205mini?
2. Does the Python UHD API, allow reading this in python?

Thanks


On Fri, Sep 21, 2018 at 8:20 PM Julian Arnold 
wrote:

> Hey,
>
> Since release 3.8.2 the RSSI is exposed as a frontend sensor.
> You should be able to read it using the usual sensor read-back mechanism
> (look at get_rx_senor_names and get_rx_sensor())
>
> Cheers,
> Julian
>
> > On 21. Sep 2018, at 17:04, Chintan Patel via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> > Hi,
> >
> > Is there a function/script in the uhd driver to read the rssi for the
> b205/b210?
> >
> > Thanks
> > ___
> > 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] B205 External Reference issue

[Marcus D. Leech via USRP-users]

On 09/26/2018 02:42 AM, Arun kumar Verma via USRP-users wrote:

Hi

We are using B205i-mini and we found that when I am sleclecting 
external Ref using set_clock_source("ëxternal"); I am getting 
intermodulation components in Hz.
I think supply for the internal oscillator is still on and it is not 
compeletly shutting down. Is there any options to switch off the suppy 
of ineternal oscillator through some API.


Regards,
Arun Verma


There is only one clock on the B205 -- a 40MHz VCXO.   When you switch 
to "external", the FPGA implements a clock-steering

  "servo" that phase-locks that 40MHz clock to the external reference.

You're probably seeing very low-level clock spurs that appear as a 
result of the servo algorithm.




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

Re: [USRP-users] RFNoC loopback

[Daniel Rauschen via USRP-users]

Hi,

sure, find the cpp attached.

Thanks and best regards,
Daniel

On 26.09.2018 16:56, Brian Padalino wrote:
On Wed, Sep 26, 2018 at 10:36 AM Daniel Rauschen via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi all,

I have a question regarding a RFNoC loopback in plain UHD.

I am familiar with [1] and I have a working solution with gr-ettus
and
python. The problem is, I can not figure out how to connect the
blocks
in plain UHD. Does anyone have a working example in UHD for a RFNoC
loopback?

Connecting in UHD/c++ fails with following error: "Error:
RuntimeError:
On node 0/Radio_0, output port 0 is already connected."...

Any help is highly appreciated :)


You didn't show us how you tried to connect them?  Can you attach your 
source file?


Brian


//
// Copyright 2014 Ettus Research LLC
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program.  If not, see .
//

// This is a simple example for RFNoC apps written in UHD.
// It connects a null source block to any other block on the
// crossbar (provided it has stream-through capabilities)
// and then streams the result to the host, writing it into a file.

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define FFT_SIZE 1024
#define CENTER_FREQ 2.45e9
#define RX_GAIN 0
#define TX_GAIN 0

namespace po = boost::program_options;

// ***
void pretty_print_flow_graph(std::vector blocks) {
	std::string sep_str = "==>";
	std::cout << std::endl;
	// Line 1
	for (size_t n = 0; n < blocks.size(); n++) {
		const std::string name = blocks[n];
		std::cout << "+";
		for (size_t i = 0; i < name.size() + 2; i++) {
			std::cout << "-";
		}
		std::cout << "+";
		if (n == blocks.size() - 1) {
			break;
		}
		for (size_t i = 0; i < sep_str.size(); i++) {
			std::cout << " ";
		}
	}
	std::cout << std::endl;
	// Line 2
	for (size_t n = 0; n < blocks.size(); n++) {
		const std::string name = blocks[n];
		std::cout << "| " << name << " |";
		if (n == blocks.size() - 1) {
			break;
		}
		std::cout << sep_str;
	}
	std::cout << std::endl;
	// Line 3
	for (size_t n = 0; n < blocks.size(); n++) {
		const std::string name = blocks[n];
		std::cout << "+";
		for (size_t i = 0; i < name.size() + 2; i++) {
			std::cout << "-";
		}
		std::cout << "+";
		if (n == blocks.size() - 1) {
			break;
		}
		for (size_t i = 0; i < sep_str.size(); i++) {
			std::cout << " ";
		}
	}
	std::cout << std::endl << std::endl;
}

// ***
int UHD_SAFE_MAIN(int argc, char *argv[]){
	uhd::set_thread_priority_safe();

	//variables to be set by po
	std::string args, file, format;
	size_t total_num_samps, spb, spp;
	double rate, total_time, setup_time, block_rate;

	//setup the program options
	po::options_description desc("Allowed options");
	desc.add_options()("help", "help message")("args", po::value()->default_value("type=x300, master_clock_rate=120e6, num_recv_frames=1024"), "multi uhd device address args")
#if (JGEN == true)
	("file", po::value()->default_value("sig_resp_fpga.dat"), "name of the file to write binary samples to, set to stdout to print")
#else
	("file", po::value()->default_value("sig.dat"), "name of the file to write binary samples to, set to stdout to print")
#endif
	("null", "run without writing to file")("nsamps", po::value(_num_samps)->default_value(FFT_SIZE * 234375), "total number of samples to receive")("time", po::value(_time)->default_value(0), "total number of seconds to receive")("spb",
			po::value()->default_value(1024 * 10), "samples per buffer")("spp", po::value()->default_value(FFT_SIZE), "samples per packet (on FPGA and wire)")("block_rate", po::value(_rate)->default_value(120e6), "The clock rate of the processing block.")(
			"rate", po::value()->default_value(120e6), "rate at which samples are produced in the radio source")("setup", po::value(_time)->default_value(1.0), "seconds of setup time")("format", po::value()->default_value("sc16"),
			"File sample type: sc16, fc32, or fc64")("progress", "periodically display short-term bandwidth")("stats", "show average bandwidth on exit")("continue", "don't abort on a bad packet");
	

Re: [USRP-users] RFNoC loopback

[Brian Padalino via USRP-users]

On Wed, Sep 26, 2018 at 10:36 AM Daniel Rauschen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have a question regarding a RFNoC loopback in plain UHD.
>
> I am familiar with [1] and I have a working solution with gr-ettus and
> python. The problem is, I can not figure out how to connect the blocks
> in plain UHD. Does anyone have a working example in UHD for a RFNoC
> loopback?
>
> Connecting in UHD/c++ fails with following error: "Error: RuntimeError:
> On node 0/Radio_0, output port 0 is already connected."...
>
> Any help is highly appreciated :)
>

You didn't show us how you tried to connect them?  Can you attach your
source file?

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

[USRP-users] RFNoC loopback

[Daniel Rauschen via USRP-users]

Hi all,

I have a question regarding a RFNoC loopback in plain UHD.

I am familiar with [1] and I have a working solution with gr-ettus and 
python. The problem is, I can not figure out how to connect the blocks 
in plain UHD. Does anyone have a working example in UHD for a RFNoC 
loopback?


Connecting in UHD/c++ fails with following error: "Error: RuntimeError: 
On node 0/Radio_0, output port 0 is already connected."...


Any help is highly appreciated :)

Daniel


Software used:
gr-ettus @ commit 51e88285
uhd @ commit eec24d7b
fpga-src @ commit 1b40696a


[1] https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/

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

[USRP-users] UHD occupying 100% CPU

[Vladica Sark via USRP-users]

Hi folks,

I have a C/C++ code that transmits frames in a given time slots from 2x 
X310. All 4 AFEs are used (2 on each X310). The duty cycle is relatively 
low, 1 frame in each 10 ms. Frame duration is a few hundred 
microseconds. The processing is not CPU intensive. The problem is that 
all 4 cores on my laptop have 100% utilization during transmission. This 
happens with all UHD 3.10 and 3.11 releases but not with 3.9. With 3.9 
the CPU utilization is less than 10%.


I had this problem in the past but I was not using a release, but a 
version under development. I switched to a release, as it was suggested 
here, since the release should have less bugs. Unfortunately, these bugs 
were not corrected in the coming 3.10 and 3.11 releases.


BR,
Vladica

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

Re: [USRP-users] IOError: x300 fw poke32 - reply timed out

[Stefan van der Linden via USRP-users]

Hi Marcus,

We have built the library from source. I will make sure to update the 
library (and dependencies) and report back. Fingers crossed!


Kind regards,

Stefan

On 24/09/2018 22:38, Marcus Müller wrote:

Hi Stefan,

so I've talked to our main software sustainance hero, and we rather
quickly came to the conclusion that it's pretty likely you should move
on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are you
building from source, or are you using binary packages?

Best regards,
Marcus

On Mon, 2018-09-24 at 20:04 +0200, Marcus Müller wrote:

Hi Stefan,

I know it's not of great comfort when an engineer finds a problem to
be
/interesting/, but yours certainly is.
So, first things first: if the computational power and memory of the
host that your USRP is connected to allows, it might be good to have
a
packet capture in some kind of a ring buffer, so that you can infer a
bit on the state at the point where things go wrong:

tcpdump -n # no DNS lookups
-i 
-s 0 # don't stop after a finite amount of packets
-C 400 # 400 million bytes per capture file
-W 2 # rotate through three files of capturs
-w /tmp/rotate.pcap # make sure that you're using a file that's on an
RAM filesystem; if in doubt, make one with `mount -t tmpfs tmpfs
/path`

So, yes, using an MTU of 8000 would be the first thing that the Ettus
hivemind would recommend, too, but if you say things still go wrong,
we
might need to dig deeper.

I do know that we've improved the bus clocking, and that had impact
on
the X300 firmware. Is trying the last 3.10 release an option for you?

Best regards,
Marcus

On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via USRP-
users
wrote:

Hi,

We are in the process of prototyping a setup using an X300 with two
UBX-40 daughterboards to be used in the validation of an externally
provided signal source. The daughterboards are each dedicated to
one
of two tasks: transmitting a pre-recorded reference signal in a
loop
at 50 MSps, and capturing that same signal again after passing
through a chain of devices under test at 25MSps. This is to run
continuously up to 24 hours.

The X300 is connected to the (dedicated) host computer via a 10Gbps
connection to an Intel X520-DA2 NAC over SFP+. On the host, we are
currently using the kitchen_sink utility included with UHD to run
the
system in multi-channel mode. We are using UHD 3.11.0.1.

The system works flawlessly when performing short measurements
(say,
up to an hour or so). However, having recently started setting up
the
system for long 24 hour tests, we are seeing timeouts from which
UHD
is unable to recover. These timeouts occur randomly: sometimes they
occur after ~1 hours, other times they occur after ~18 hours and
everywhere in between. Naturally, this random behaviour makes it
difficult to debug.

The error message retrieved from UHD is as follows:

As previous messages on this list have mentioned varying the MTU
settings (for example:


http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html

), this was the first thing we tried. Unfortunately, these timeouts
occur more often at lower MTU values.

Hopefully someone is able to point us in the right direction.
Perhaps
we are dealing with hardware issues here, but I'd I hope we are
able
to solve this through software.

Thanks,
Stefan van der Linden
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




--
S.P. (Stefan) van der Linden MSc
System Engineer

S[&]T - Science and Technology corporation
Olof Palmestraat 14, 2616 LR Delft, The Netherlands
PO Box 608, 2600 AP Delft, The Netherlands
M: +31 (0)6 502 08 173
T: +31 (0)15 262 98 89
Skype: spvdlinden
I: www.stcorp.nl


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

[USRP-users] B205 External Reference issue

[Arun kumar Verma via USRP-users]

Hi 
We are using B205i-mini and we found that when I am sleclecting external Ref 
using set_clock_source("ëxternal"); I am getting intermodulation components in 
Hz.I think supply for the internal oscillator is still on and it is not 
compeletly shutting down. Is there any options to switch off the suppy of 
ineternal oscillator through some API. 
Regards,Arun Verma
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com