Re: [USRP-users] X310 with dual TwinRX set up

[Marcus D. Leech via USRP-users]

On 03/10/2021 06:15 PM, Rob Kossler via USRP-users wrote:

Hi Oliver,
I don't have any example code to provide (and I don't use gnuradio), 
but I can address a couple of things:
- the first step is to get all four channels recognized (as you 
indicated); perhaps using subdev spec "A:0 A:1 B:0 B:1"
- synchronizing in time is definitely possible. From gnuradio, I 
thought that it was the default for multi-channel operation.  You 
might have to lookup a set_start_time or similar command. check the 
uhd gnuradio documentation for usrp source 
.
- four channels at 100 MS/s is also achievable.  To use dual 10Gbe, 
you need to specify the "second_addr" device arg as indicated here 
.

Rob

Indeed, sample-level time synchronization among channels happens 
automatically for multi_usrp streams.


The suggested sub-dev string should work just fine as well.

In the uhd-usrp source in the "RF Options" you can set the tuned 
frequency for each channel.


Specify a "Num Channels" of 4 and a "num_mboards" of 1.


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

Re: [USRP-users] X300/X310: how to control an external TX/RX switch for 60GHz mm-wave transceiver?

[Marcus D Leech via USRP-users]

You’ll need to familiarize yourself with this

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

You should be able to tie a GPIO pin to the ATR state machine in the FPGA to 
drive a GPIO output signal. 



Sent from my iPhone

> On Mar 10, 2021, at 2:23 PM, SungWon Chung via USRP-users 
>  wrote:
> 
> 
> Hello,
> 
> I'm working to use X300/X310 as a front-end of a custom built 60GHz mm-wave 
> transceiver, which needs a digital signal for its TX/RX switch to share a 
> horn antenna.
> 
> What do you think is the best solution?  
> 
> Any methods are welcome as long as it's a robust solution. Your thoughts will 
> be much appreciated.
> 
> Thanks,
> sungwon
> ___
> 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] x300 latency over 10GigE

[Marcus D Leech via USRP-users]

Hah. Yes. Sorry for the confusion. 



Sent from my iPhone

> On Mar 9, 2021, at 10:36 PM, Doug Blackburn  wrote:
> 
> 
> Marcus,
> 
> Thanks for your response; I believe I am.  The math is spread over two lines:
> 
> uhd::time_spec_t expectedTime = startTime + (double) ( num_tx_samps  )
>   / (double)usrp->get_tx_rate();
> 
> Best,
> Doug
> 
> 
>> On Tue, Mar 9, 2021 at 10:20 PM Marcus D Leech  
>> wrote:
>> Shouldn’t you be scaling your num_tx_samples by the time per sample when 
>> calculating the expectedTime?
>> 
>> Sent from my iPhone
>> 
 On Mar 9, 2021, at 10:03 PM, Doug Blackburn via USRP-users 
  wrote:
 
>>> 
>>> Hello --
>>> 
>>> I've got some questions re: latency with the x300 over the 10GigE 
>>> interface.  
>>> 
>>> If I use the latency_test example operating at a rate of 50 MSPS, I have no 
>>> issues with a latency of 1ms.  The latency test receives data, examines the 
>>> time stamp, and transmits a single packet. 
>>> 
>>> I have an application where I'd like to run the transmitter continuously, 
>>> and I got curious about the latency involved in that operation.  My 
>>> application is similar to the benchmark_rate example.  I added the 
>>> following lines to the benchmark_rate example at line 256 after the line.
>>> 
>>> md.has_time_spec = false; 
>>> 
>>> 
>>> if ( (num_tx_samps % 5000) < 4*max_samps_per_packet )
>>> {
>>> uhd::time_spec_t expectedTime = startTime + (double) ( num_tx_samps  )
>>>   / (double)usrp->get_tx_rate();
>>> uhd::time_spec_t timeAtLog = usrp->get_time_now();
>>> timeAtLog = usrp->get_time_now();
>>> std::cerr << " Actual time " << std::endl;
>>> std::cerr << " " << timeAtLog.get_full_secs() << " / "
>>>   << timeAtLog.get_frac_secs() << std::endl;
>>> std::cerr << " Expected time " << std::endl;
>>> std::cerr << " " << expectedTime.get_full_secs() << " / "
>>>   << expectedTime.get_frac_secs() << std::endl;
>>> }
>>> 
>>> 
>>> The intent of this insertion is to log the time at which we return from 
>>> tx_stream->send() and the time at which the first sample of that sent data 
>>> should be transmitted -- at approximately once per second when running at 
>>> 50 MSPS.
>>> 
>>> After the first second, I consistently saw the following results:
>>> 
>>>  Actual time 
>>>  1 / 0.10517
>>>  Expected time 
>>>  1 / 0.27253
>>> 
>>>  Actual time 
>>>  1 / 0.105419
>>>  Expected time 
>>>  1 / 0.27255
>>> 
>>> Which indicates to me that there is a latency of approximately 167ms when 
>>> transmitting data.  That is, the send() function is returning 167ms earlier 
>>> than I expect the data to actually be transmitted.   If I halve the sample 
>>> rate to 25 MSPS, the latency doubles.
>>> 
>>> What is the source of the latency when running in a continuous mode?  
>>> Initially, I had thought that this might be related to the 
>>> send_buffer_size, but making changes to send_buffer_size seem to not have 
>>> an effect.   FWIW, 167ms at 50 MSPS is suspiciously close to the value for 
>>> wmem_max (33554432) suggested in the x300 system configuration ... but 
>>> neither changing that value or send_buffer_size seems to make a difference.
>>> 
>>> Is this latency tunable?  
>>> 
>>> Thank you for your help!
>>> 
>>> Best Regards,
>>> Doug Blackburn
>>> 
>>> ___
>>> 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] x300 latency over 10GigE

[Marcus D Leech via USRP-users]

Shouldn’t you be scaling your num_tx_samples by the time per sample when 
calculating the expectedTime?

Sent from my iPhone

> On Mar 9, 2021, at 10:03 PM, Doug Blackburn via USRP-users 
>  wrote:
> 
> 
> Hello --
> 
> I've got some questions re: latency with the x300 over the 10GigE interface.  
> 
> If I use the latency_test example operating at a rate of 50 MSPS, I have no 
> issues with a latency of 1ms.  The latency test receives data, examines the 
> time stamp, and transmits a single packet. 
> 
> I have an application where I'd like to run the transmitter continuously, and 
> I got curious about the latency involved in that operation.  My application 
> is similar to the benchmark_rate example.  I added the following lines to the 
> benchmark_rate example at line 256 after the line.
> 
> md.has_time_spec = false; 
> 
> 
> if ( (num_tx_samps % 5000) < 4*max_samps_per_packet )
> {
> uhd::time_spec_t expectedTime = startTime + (double) ( num_tx_samps  )
>   / (double)usrp->get_tx_rate();
> uhd::time_spec_t timeAtLog = usrp->get_time_now();
> timeAtLog = usrp->get_time_now();
> std::cerr << " Actual time " << std::endl;
> std::cerr << " " << timeAtLog.get_full_secs() << " / "
>   << timeAtLog.get_frac_secs() << std::endl;
> std::cerr << " Expected time " << std::endl;
> std::cerr << " " << expectedTime.get_full_secs() << " / "
>   << expectedTime.get_frac_secs() << std::endl;
> }
> 
> 
> The intent of this insertion is to log the time at which we return from 
> tx_stream->send() and the time at which the first sample of that sent data 
> should be transmitted -- at approximately once per second when running at 50 
> MSPS.
> 
> After the first second, I consistently saw the following results:
> 
>  Actual time 
>  1 / 0.10517
>  Expected time 
>  1 / 0.27253
> 
>  Actual time 
>  1 / 0.105419
>  Expected time 
>  1 / 0.27255
> 
> Which indicates to me that there is a latency of approximately 167ms when 
> transmitting data.  That is, the send() function is returning 167ms earlier 
> than I expect the data to actually be transmitted.   If I halve the sample 
> rate to 25 MSPS, the latency doubles.
> 
> What is the source of the latency when running in a continuous mode?  
> Initially, I had thought that this might be related to the send_buffer_size, 
> but making changes to send_buffer_size seem to not have an effect.   FWIW, 
> 167ms at 50 MSPS is suspiciously close to the value for wmem_max (33554432) 
> suggested in the x300 system configuration ... but neither changing that 
> value or send_buffer_size seems to make a difference.
> 
> Is this latency tunable?  
> 
> Thank you for your help!
> 
> Best Regards,
> Doug Blackburn
> 
> ___
> 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] x310 two UBX daughterboard receiver

[Marcus D. Leech via USRP-users]

On 03/08/2021 01:22 PM, Xiang Ma wrote:
I have tried to first use GNURadio to write a program in GRC. And 
implement my code referring to the generated top_block.py

The following code works

```
from gnuradio import uhd

  def u_source(self):
self.source = uhd.usrp_source(
device_addr=self.usrp_address_source,
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.source.set_samp_rate(self.adc_rate)
self.source.set_center_freq(self.freq, 0)
self.source.set_gain(self.rx_gain, 0)
self.source.set_antenna("RX2", 0)
self.source.set_auto_dc_offset(False, 0) # Uncomment this line for 
SBX daughterboard


self.source.set_center_freq(self.freq, 1)
self.source.set_gain(self.rx_gain, 1)
self.source.set_antenna("RX2", 1)
self.source.set_auto_dc_offset(False, 1)
```

And when I change the channels=range(2),
Add a new line as the file sink of channel 2, it doesn't work. It 
doesn't crash, just stuck.

self.connect((self.source, 1), self.file_sink_source)

I don't understand. I thought the two channels might be independent 
since they work on two daughterboards.


I try to use gdb to debug the code. But the information is hard to 
understand. It shows multiple threads.


The fact that you feel the need to *edit* the *generated* code from GRC 
means that you have an insufficient understanding of
  GRC, and making random, unguided-by-deep-knowledge changes to the 
*generated* code is almost never called for unless you're
  doing something "special" and you have the expertise to make those 
changes.


Go back to GRC, simply create a usrp_source object with two channels, a 
single motherboard, and a subdev spec of "A:0 B:0", with
  RX2 for the antenna selector, and you'll have two streams that you 
can deal with independently.  One can go to a file sink, the

  other can go to a different file sink, or other bits of DSP chain.

I'll note that on balance, this is more of a discuss-gnuradio question 
than a usrp-users question, I'd recommend cross-posting any

  further missives in this thread.

Doing this "two channels from the same device" thing is not that exotic 
or unusual, so I suspect that your approach of post-editing
  the generated code from GRC is where your problems are, and I'd avoid 
it.  The GRC file should be considered the "source code", and
  you make all your edits to that, using the GRC tooling.  Just as in 
compiled languages, there's very few legitimate reasons for

  "editing the object code".



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

Re: [USRP-users] Phase synchronization after hopping

[Marcus D. Leech via USRP-users]

On 03/06/2021 11:31 AM, Snehasish Kar via USRP-users wrote:


Hello everyone

I am trying to achieve frequency hopping in GSM using twinrx with usrp 
x310. Here I am using timed command for tuning a single port across a 
given frequency list. During hopping it stays in each frequency for 
4msecs and till the time frequency hopping continues, I am able to 
identify FCCH using phase difference. But as soon as the hopping is 
over and it tunes back to the actual frequency containing the 
broadcast channel, I am not getting phase difference greater than 0 
and thus not able to demodulate the GSM burst. Can anyone please help 
where I am going wrong below is the snippet of the code, responsible 
for  hopping.


Function handling hopping:

uhd::tune_request_t tune_request(rf_freq);

tune_request.rf_freq_policy = uhd::tune_request_t::POLICY_MANUAL;

tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;

tune_request.rf_freq = rf_freq;

tune_request.dsp_freq = dsp_freq;

uhd_src->set_rx_freq(tune_request, chan_num);

  {

If(verbose_lvl==3){

char msg[100]={0x00};

sprintf(msg,"info: DSP freq: changed to channel %d: %fMHz offset 
%fMHz", chan_num, uhd_src->get_rx_freq(chan_num)/1e6, dsp_freq);


vipl_printf(msg,error_lvl, __FILE__, __LINE__);

}

  }

//uhd_src->clear_command_time();

usleep(11); // allow LOs to lock

Module for setting back to original frequency with broadcast:

uhd_src->clear_command_time();

uhd::tune_request_t tune_request(rf_freq, 0x00); //considering 
LO-Offset to be zero


tune_request.rf_freq_policy = uhd::tune_request_t::POLICY_AUTO;

tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_AUTO;

tune_request.rf_freq = rf_freq;

//tune_request.dsp_freq = -dsp_freq;

uhd_src->set_rx_freq(tune_request, channel);

  {

char msg[100]={0x00};

sprintf(msg,"info: freq: set to channel %d: %fMHz requested freq 
%fMHz", channel, uhd_src->get_rx_freq(channel)/1e6, rf_freq/1e6);


vipl_printf(msg,error_lvl, __FILE__, __LINE__);

  }

usleep(11);

My UHD version is 3.14.0.0

USRP: X310

Daughter board: 2 sets of Twinrx

OS: Debian 10

Interface: 10gig sfp+ ethernet

Thanks!!

Regards

Snehasish Kar



By "phase synchronization" you're describing the demodulator phase?

You're hoping that the LO phase would be the same as if you had not 
hopped away from the original frequency?  I don't think that's
  even possible, but your description is not very precise, so perhaps 
that's not what you meant?



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

Re: [USRP-users] very low TX power for burst transmission with B210

[Marcus D Leech via USRP-users]

My guess is that the startup transient time
On the B210 is slightly longer and you’ll need to compensate for that. 

On average the B210 output power will be perhaps 3-4dB lower than N310. But 
that should not make much difference at close range. 

Sent from my iPhone

> On Mar 4, 2021, at 5:18 AM, Johannes Demel via USRP-users 
>  wrote:
> 
> Hi all,
> 
> I see some very odd behavior with a B210. I have this simple sine flowgraph 
> attached. My RX and TX antennae are approximately 1m apart. I just send a 
> sine and receive it with an acceptable power level.
> 
> Though, my application uses burst transmission. Here, things start to fail. 
> For some reason, TX bursts have very low output power. I make sure, all 
> bursts are scaled to match the output level in my `sine_test.grc` flowgraph.
> 
> With 2 N310s, I can observe very reliable communication. If I swap one of 
> those for a B210, I'm barely able to receive a B210s own bursts. I set TX 
> gain to 90 and I could observe an improvement. Though, this is still far from 
> what I'd expect after my sine test.
> 
> Is there an issue with burst transmission and B210s? Do I need to take any 
> special precautions?
> 
> Cheers
> Johannes
> 
> 
> 
> -- 
> Johannes Demel M.Sc.
> Research Engineer
> 
> University of Bremen
> Department of Communications Engineering
> Faculty 1 - Physics / Electrical Engineering
> NW1, N2400
> Otto-Hahn-Allee NW1
> 28359 Bremen
> 
> Phone +49 421 218-62393
> de...@ant.uni-bremen.de
> 
> Secretariat
> Tel. +49 421 218-62390
> pre...@ant.uni-bremen.de
> 
> www.uni-bremen.de/en
> 
> University of Bremen - Established 1971
> 
> ___
> 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] B205mini continously transmitting a carrier tone even though UHD crashed

[Marcus D Leech via USRP-users]

Well assuming it doesn’t crash you can turn down the RF gain and tune it to an 
out of band frequency. 

Sent from my iPhone

> On Mar 3, 2021, at 9:32 AM, Kelvin Lok  wrote:
> 
> 
> Thanks Marcus, I realised it might just have been the lo offset. Is there a 
> way to "turn off" the lo linkage to the front-end output whenever I'm done 
> with the usrp? Ideally, I would like to avoid power cycling the radio 
> whenever I'm done.
> 
>> On Wed, 3 Mar 2021, 10:18 pm Marcus D Leech,  wrote:
>> That’s likely just the TX Lo leakage. 
>> 
>> I’m guessing it a a lot weaker than when you’re actually transmitting?
>> 
>> Sent from my iPhone
>> 
>> > On Mar 3, 2021, at 3:42 AM, Kelvin Lok via USRP-users 
>> >  wrote:
>> > 
>> > 
>> > Hi everyone, I am facing an unexpected problem where my B205mini USRP is 
>> > continuously transmitting a tone (that I set initialised as the tx freq), 
>> > even when my parent program has crashed. My parent program is a C++ 
>> > program that calls uhd, but when the main program catches an exception and 
>> > terminates, the B205mini is still transmitting a tone. I observed this 
>> > behaviour by monitoring the TX output with a spectrum analyser.
>> > 
>> > Does anyone have any ideas what could be the problem? Do I need to call a 
>> > UHD usrp destructor? I noticed that the example UHD programs don't need to 
>> > release or delete the uhd object. Hence I am stumped.
>> > 
>> > 
>> > ___
>> > 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] B205mini continously transmitting a carrier tone even though UHD crashed

[Marcus D Leech via USRP-users]

That’s likely just the TX Lo leakage. 

I’m guessing it a a lot weaker than when you’re actually transmitting?

Sent from my iPhone

> On Mar 3, 2021, at 3:42 AM, Kelvin Lok via USRP-users 
>  wrote:
> 
> 
> Hi everyone, I am facing an unexpected problem where my B205mini USRP is 
> continuously transmitting a tone (that I set initialised as the tx freq), 
> even when my parent program has crashed. My parent program is a C++ program 
> that calls uhd, but when the main program catches an exception and 
> terminates, the B205mini is still transmitting a tone. I observed this 
> behaviour by monitoring the TX output with a spectrum analyser.
> 
> Does anyone have any ideas what could be the problem? Do I need to call a UHD 
> usrp destructor? I noticed that the example UHD programs don't need to 
> release or delete the uhd object. Hence I am stumped.
> 
> 
> ___
> 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] MIMO for X3x0 (AN-881 Table 4 may need some edit)

[Marcus D Leech via USRP-users]

Two X310 plus 4 UBX delivers 4x4 MIMO with an external 1PPS and 10Mhz 
clock—octoclock or something else.  

The X310 does have a ref clock output, but I think it is not recommended for 
use in coherent applications just because of unknown clock skew. 



Sent from my iPhone

> On Feb 27, 2021, at 2:50 PM, Marcus Müller via USRP-users 
>  wrote:
> 
> You're right. The whole point of the TwinRX boards is to give you coherent 
> channels, and
> you can build a coherent 4-channel *receiver*.
> 
> However, TwinRX can't transmit, so for 4×4 MIMO, you'll need something else. 
> Since there's
> no dual-transmit-channel daughterboards, you'll need to coordinate the phases 
> of four
> different TX-capable daughterboards. Therefore, you'll need a clock 
> distributor like the
> octoclock.
> 
> Haven't tried it in a while, but the clk and pps out of the X3x0 series 
> should solve that
> issue, however: you could link two USRP X3x0 that are equipped with e.g. two 
> UBX-160 each
> through that to get 4 coherent TX channels, and use a single USRP X3x0 with 
> two TwinRX as
> receiver with 4 coherent RX channels.
> 
> Best regards,
> Marcus
> 
> 
>> On 27.02.21 15:50, Ali G. Dezfuli via USRP-users wrote:
>> Hi all,
>> When USRP X3x0 is used with TwinRX daughterboards, we can have up to 4 rx 
>> channels.
>> (ref:AN-244, Direction Finding with the USRP™ X-Series and TwinRX™)
>> But in AN-881 (Selecting a USRP Device) in Table 4, it says that USRP X3x0 
>> needs
>> OctoClock for 4x4 MIMO !!!
>> I wonder when X3x0 can receive 4 channels with TwinRX, why it can NOT be 
>> used in 4x4
>> MIMO w/o OctoClock.
>> 
>> regards,
>> AGD
>> 
>> ___
>> 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] USRP N300 - Set RX bandwidth

[Marcus D. Leech via USRP-users]

On 02/25/2021 11:30 AM, Puertas Blanco, Roberto via USRP-users wrote:


Hello,

I noticed that RX bandwidth is fixed to 100MHz, although the AD9371 
datasheet specifies an adjustable range of 8 to 100MHz. Why is this 
parameter fixed?


double magnesium_radio_control_impl::set_rx_bandwidth(

const double bandwidth, const size_t chan)

{

std::lock_guard l(_set_lock);

_ad9371->set_bandwidth(bandwidth, chan, RX_DIRECTION);

// FIXME: setting analog bandwidth on AD9371 take no effect.

// Remove this warning when ADI can confirm that it works.

RFNOC_LOG_WARNING("set_rx_bandwidth take no effect on AD9371. "

 "Default analog bandwidth is 100MHz");

return AD9371_RX_MAX_BANDWIDTH;

}

Best regards,

Roberto


Because despite what the *datasheet* for the AD9371 says, the published 
interface to change the analog RX bandwidth has no effect.



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

Re: [USRP-users] Overhead Time for Tuning USRP LO and Acquiring Signal for Swept Spectrum Analysis

[Marcus D Leech via USRP-users]

It’s likely better to use continuous steaming, and use the tags inserted in the 
steam to determine applicable frequency. 

Tune time on the UBX is probably a few milliseconds.  But I must emphasize that 
none of this hardware was optimized for fast frequency hopping. 



Sent from my iPhone

> On Feb 23, 2021, at 11:19 AM, Cox, Jonathan Albert via USRP-users 
>  wrote:
> 
> 
> Hello USRP Users,
>  
> I’d like to understand the practicality of using a USRP with UBX board as a 
> swept spectrum analyzer to sweep a broad bandwidth, like sampling 10 MHz to 6 
> GHz fairly quickly. I don’t require extremely precise amplitude calibration 
> across that bandwidth, but the sweep speed (LO tuning and data acquisition 
> initialization) should be relatively quick.
>  
> How long does it take to command the USRP to tune to a particular LO center 
> frequency, initiate a data acquisition, and then return the result (excluding 
> the time required to perform the actual sampling)? For example, the Tektronix 
> RSA306B claims a sweep speed of 500 ms for 9 kHz to 6 GHz.
>  
> Roughly speaking, to cover 6 GHz with ~160 MHz bandwidth, you would need to 
> tune the LO probably 45 to 100 times (depending on overlap, filtering, etc.) 
> . Therefore, if you want to keep the overhead under 200 ms, each 
> tune/initiate acquisition/download step should take no more than 2 or 4 ms.
>  
> Is it reasonable to tune and acquire with the UBX board in an X300 in 2 to 4 
> ms?
>  
> Regards,
> Jonathan
> ___
> 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] Read a register

[Marcus D. Leech via USRP-users]

On 02/23/2021 03:45 AM, COURANT Frederique - Contractor wrote:


I’m working in python.

*De :*COURANT Frederique - Contractor
*Envoyé :* mardi 23 février 2021 09:13
*À :* 'Marcus D Leech' 
*Objet :* RE: [USRP-users] Read a register

My USRP platform is the X310.

I would like to read an internal control register at the address 133. 
I had ever allocated in the xml file with the name status.



From the fact that you've mentioned XML, I'm going to *guess* that 
you're working with RFNOC, and thus the "radio3" API.


I'm pretty sure that in the regular multi_usrp API, the python interface 
doesn't expose low-level register I/O, but the story may be
  different in RFNOC--so at this point I'm hoping an RFNOC person can 
jump in, but a lot more context will be needed.



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

Re: [USRP-users] Read a register

[Marcus D Leech via USRP-users]

Context here is really important. 

What USrP platform? Are you talking about a user register or an internal 
control register in the FPGA implementation?

Sent from my iPhone

> On Feb 22, 2021, at 10:15 AM, COURANT Frederique - Contractor via USRP-users 
>  wrote:
> 
> 
> Hello,
>  
> Could you give me some examples of how can I read a value at the register 134 
> please ?
> This register is only a readable data.
>  
> Best regards.
>  
> ___
> 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] Problem with tx_waveform reference lock

[Marcus D. Leech via USRP-users]

On 02/21/2021 07:00 PM, Guillermo Gancio via USRP-users wrote:

Dear Marcus,

Thank you very much for your answer,
the reference that I use comes from a 10MHz GPSDSO, that I also use
with other ettus boards without any problem as receivers.
I did some tests using the Python APIs and the reference sensor shows
a locked state, then I add a 5 seconds delay on the tx_waveform.cpp
right after setting the reference value, and the reference now appears
locked..

Code:
if (vm.count("ref")) {
 usrp->set_clock_source(ref);
 }
  usleep(100*5);

And the result is...:
Setting device timestamp to 0...
Checking TX: LO: locked ...
Checking TX: Ref: locked ...
Press Ctrl + C to stop streaming...

without the 5 second delay , I got:

Setting device timestamp to 0...
Checking TX: LO: locked ...
Checking TX: Ref: unlocked ...
Error: AssertionError: ref_locked.to_bool()
   in int _main(int, char**)
   at /home/user/uhd/host/examples/tx_waveforms.cpp:286


Thanks again !!

All the best.
Ah, so this is just the tx_waveforms code being a bit too hasty to check 
for ref_locked after setting the reference.  I'm guessing that a few

  hundred milliseconds would be entirely adequate in all cases...



El vie, 19 feb 2021 a las 17:58, Marcus D. Leech via USRP-users
() escribió:

On 02/19/2021 12:31 PM, Guillermo Gancio via USRP-users wrote:

Dear all,

I'm using a B205 as a CW signal generator with the example
tx_waveform, in general it works ok, but if I try to use a 10MHz
external reference (option --ref external) I got the error, same issue
if I replace the 10MHz with a PPS, (--pps external), power levels are
ok.


Checking TX: Ref: unlocked ...
Error: AssertionError: ref_locked.to_bool()
in int _main(int, char**)
at /home/ggancio/uhd/host/examples/tx_waveforms.cpp:285

This is with a fresh install
[INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501;
UHD_4.0.0.0-93-g3b9ced8f

Any idea on this? Thank you very much!

Cheers.



You should probably check the quality of your 10MHz signal going into
the B210. I've used all kinds of external 10MHz references for B210
and it has never complained.   10MHz OCXO with a TTL buffer. Rubidium
clock with a TTL buffer.Octoclock-G.  Never had a problem.

Check what your 10MHz signal looks like into a 50Ohm termination on a
good quality oscilloscope.  Does it look reasonably pure, or are there
unwanted ringing artifacts?

If you're driving the reference input "too hard", you may be creating
unwanted spurs that confuse the reference PLL.  Make sure the level
is not too "loud".



___
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] GPSDO fails to lock

[Marcus D Leech via USRP-users]

Every GPS implementation is different. 

It may be the case that higher SNR is required for timing receivers compared to 
position receivers. 

Sent from my iPhone

> On Feb 21, 2021, at 10:13 AM, Johannes Demel  wrote:
> 
> Sure. Generally I wouldn't expect GPS to work in a building. Though, since 
> we have at least 3 different systems (phone, RPi /w GPS-shield, LTE eNodeB) 
> that work there, I assumed that the GPSDO would do so as well.
> 
>> On 21.02.21 14:23, Marcus D. Leech wrote:
>>> On 02/21/2021 07:15 AM, Johannes Demel wrote:
>>> Thanks for your hints. The antennae and devices are indoors. Is there a 
>>> difference if the device receives a signal and locking onto that signal? 
>>> e.g. the devices determines the signal too distorted to lock?
>> https://itstillworks.com/doesnt-gps-work-inside-building-18659.html
>>> 
>>> On 19.02.21 16:32, Marcus D. Leech wrote:
>>>> On 02/19/2021 09:48 AM, Rob Kossler wrote:
>>>>> When I first started using UHD 4.0 with the N310 (this past summer), I
>>>>> noticed what I thought was a degradation in the device's ability to
>>>>> lock. I was comparing one N310 running UHD 3.15 to another running UHD
>>>>> 4.0.  Both systems were located a few feet apart from each other with
>>>>> the same model antenna so they should have produced similar results,
>>>>> but it seemed that the 3.15 system achieved lock more easily. In any
>>>>> case, I never spent the time to "prove the case" and then got
>>>>> distracted on another issue and never returned to it. Not sure if this
>>>>> is relevant in this discussion, but I thought I would mention it.
>>>>> Rob
>>>> The N310 uses one of these modules:
>>>> 
>>>> http://www.jackson-labs.com/index.php/products/lte_lite
>>>> 
>>>> Pretty sure that UHD4.0/UHD3.15 wouldn't affect the operation of that 
>>>> module, but, you never know.
>>>> 
>>>> 
>>>>> 
>>>>> On Fri, Feb 19, 2021 at 9:12 AM Marcus D Leech via USRP-users
>>>>>  wrote:
>>>>>> Are the antennae situated outdoors?
>>>>>> 
>>>>>> It can take almost an hour to achieve lock from a cold start.
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On Feb 19, 2021, at 4:14 AM, Johannes Demel  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Each USRP has its own GPS antenna. One of those you buy at ettus.com 
>>>>>>> as a recommended accessory.
>>>>>>> 
>>>>>>>> On 18.02.21 15:05, Marcus D Leech wrote:
>>>>>>>> How are you delivering the GPS antenna signal to the USRPs?  Via a 
>>>>>>>> splitter? Does that splitter provide DC pass-through?
>>>>>>>> Sent from my iPhone
>>>>>>>>>> On Feb 18, 2021, at 7:07 AM, Johannes Demel via USRP-users 
>>>>>>>>>>  wrote:
>>>>>>>>> Just a quick follow-up. The B210 finally got a GPS lock. (I had to 
>>>>>>>>> wait for ~2h). Though, all N310s still don't.
>>>>>>>>> 
>>>>>>>>>> On 18.02.21 10:12, Johannes Demel via USRP-users wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>> I have some N310s and a B210 that I try to sync with a GPSDO. All of 
>>>>>>>>>> them recognize their GPSDOs but fail to lock.
>>>>>>>>>> My phone can see ~7 Satellites. We have a RPi with a GPS module that 
>>>>>>>>>> locks to GPS in the same hall. We switched antennas but still, we 
>>>>>>>>>> can't sync any of the USRPs to GPS.
>>>>>>>>>> I tried:
>>>>>>>>>> ```
>>>>>>>>>> lib/uhd/utils/query_gpsdo_sensors
>>>>>>>>>> ```
>>>>>>>>>> and
>>>>>>>>>> ```
>>>>>>>>>> lib/uhd/examples/sync_to_gps
>>>>>>>>>> ```
>>>>>>>>>> but even after a day, they always return "GPS does not have lock" 
>>>>>>>>>> and "WARNING:  GPS not locked - time will not be accurate until 
>>>>>>>>>> locked".
>>>>>>>>>> `gpsmon` on the N310s reports 0 Satellites. But it has a list of 
>>>>>>>>>> satellites.
>>>>>>>>>> Since we have several devices in that room that are able to acquire 
>>>>>>>>>> a lock but none of our USRPs with their GPSDOs, I wonder what is 
>>>>>>>>>> going on. Do they need a very strong signal?
>>>>>>>>>> Cheers
>>>>>>>>>> Johannes
>>>>>>>>> ___
>>>>>>>>> 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] GPSDO fails to lock

[Marcus D. Leech via USRP-users]

On 02/21/2021 07:15 AM, Johannes Demel wrote:
Thanks for your hints. The antennae and devices are indoors. Is there 
a difference if the device receives a signal and locking onto that 
signal? e.g. the devices determines the signal too distorted to lock?

https://itstillworks.com/doesnt-gps-work-inside-building-18659.html



On 19.02.21 16:32, Marcus D. Leech wrote:

On 02/19/2021 09:48 AM, Rob Kossler wrote:

When I first started using UHD 4.0 with the N310 (this past summer), I
noticed what I thought was a degradation in the device's ability to
lock. I was comparing one N310 running UHD 3.15 to another running UHD
4.0.  Both systems were located a few feet apart from each other with
the same model antenna so they should have produced similar results,
but it seemed that the 3.15 system achieved lock more easily. In any
case, I never spent the time to "prove the case" and then got
distracted on another issue and never returned to it. Not sure if this
is relevant in this discussion, but I thought I would mention it.
Rob

The N310 uses one of these modules:

http://www.jackson-labs.com/index.php/products/lte_lite

Pretty sure that UHD4.0/UHD3.15 wouldn't affect the operation of that 
module, but, you never know.





On Fri, Feb 19, 2021 at 9:12 AM Marcus D Leech via USRP-users
 wrote:

Are the antennae situated outdoors?

It can take almost an hour to achieve lock from a cold start.

Sent from my iPhone

On Feb 19, 2021, at 4:14 AM, Johannes Demel 
 wrote:


Each USRP has its own GPS antenna. One of those you buy at 
ettus.com as a recommended accessory.



On 18.02.21 15:05, Marcus D Leech wrote:
How are you delivering the GPS antenna signal to the USRPs?  Via 
a splitter? Does that splitter provide DC pass-through?

Sent from my iPhone
On Feb 18, 2021, at 7:07 AM, Johannes Demel via USRP-users 
 wrote:
Just a quick follow-up. The B210 finally got a GPS lock. (I had 
to wait for ~2h). Though, all N310s still don't.



On 18.02.21 10:12, Johannes Demel via USRP-users wrote:
Hi all,
I have some N310s and a B210 that I try to sync with a GPSDO. 
All of them recognize their GPSDOs but fail to lock.
My phone can see ~7 Satellites. We have a RPi with a GPS module 
that locks to GPS in the same hall. We switched antennas but 
still, we can't sync any of the USRPs to GPS.

I tried:
```
lib/uhd/utils/query_gpsdo_sensors
```
and
```
lib/uhd/examples/sync_to_gps
```
but even after a day, they always return "GPS does not have 
lock" and "WARNING:  GPS not locked - time will not be accurate 
until locked".
`gpsmon` on the N310s reports 0 Satellites. But it has a list 
of satellites.
Since we have several devices in that room that are able to 
acquire a lock but none of our USRPs with their GPSDOs, I 
wonder what is going on. Do they need a very strong signal?

Cheers
Johannes

___
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] Problem with tx_waveform reference lock

[Marcus D. Leech via USRP-users]

On 02/19/2021 12:31 PM, Guillermo Gancio via USRP-users wrote:

Dear all,

I'm using a B205 as a CW signal generator with the example
tx_waveform, in general it works ok, but if I try to use a 10MHz
external reference (option --ref external) I got the error, same issue
if I replace the 10MHz with a PPS, (--pps external), power levels are
ok.


Checking TX: Ref: unlocked ...
Error: AssertionError: ref_locked.to_bool()
   in int _main(int, char**)
   at /home/ggancio/uhd/host/examples/tx_waveforms.cpp:285

This is with a fresh install
[INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501;
UHD_4.0.0.0-93-g3b9ced8f

Any idea on this? Thank you very much!

Cheers.


You should probably check the quality of your 10MHz signal going into 
the B210. I've used all kinds of external 10MHz references for B210
  and it has never complained.   10MHz OCXO with a TTL buffer. Rubidium 
clock with a TTL buffer.Octoclock-G.  Never had a problem.


Check what your 10MHz signal looks like into a 50Ohm termination on a 
good quality oscilloscope.  Does it look reasonably pure, or are there

  unwanted ringing artifacts?

If you're driving the reference input "too hard", you may be creating 
unwanted spurs that confuse the reference PLL.  Make sure the level

  is not too "loud".



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

Re: [USRP-users] microSD Size Limit

[Marcus D Leech via USRP-users]

I’ve used 32G without any issues. 

Sent from my iPhone

> On Feb 19, 2021, at 11:27 AM, Dennis Trask via USRP-users 
>  wrote:
> 
> What is the largest microSD card supported by the E310? I want to get larger 
> cards for development purposes, but don't want to buy a size that isn't 
> supported.
> 
> Thanks,
> Dennis
> 
> ___
> 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] GPSDO fails to lock

[Marcus D. Leech via USRP-users]

On 02/19/2021 09:48 AM, Rob Kossler wrote:

When I first started using UHD 4.0 with the N310 (this past summer), I
noticed what I thought was a degradation in the device's ability to
lock. I was comparing one N310 running UHD 3.15 to another running UHD
4.0.  Both systems were located a few feet apart from each other with
the same model antenna so they should have produced similar results,
but it seemed that the 3.15 system achieved lock more easily.  In any
case, I never spent the time to "prove the case" and then got
distracted on another issue and never returned to it. Not sure if this
is relevant in this discussion, but I thought I would mention it.
Rob

The N310 uses one of these modules:

http://www.jackson-labs.com/index.php/products/lte_lite

Pretty sure that UHD4.0/UHD3.15 wouldn't affect the operation of that 
module, but, you never know.





On Fri, Feb 19, 2021 at 9:12 AM Marcus D Leech via USRP-users
 wrote:

Are the antennae situated outdoors?

It can take almost an hour to achieve lock from a cold start.

Sent from my iPhone


On Feb 19, 2021, at 4:14 AM, Johannes Demel  wrote:

Each USRP has its own GPS antenna. One of those you buy at ettus.com as a 
recommended accessory.


On 18.02.21 15:05, Marcus D Leech wrote:
How are you delivering the GPS antenna signal to the USRPs?  Via a splitter? 
Does that splitter provide DC pass-through?
Sent from my iPhone

On Feb 18, 2021, at 7:07 AM, Johannes Demel via USRP-users 
 wrote:

Just a quick follow-up. The B210 finally got a GPS lock. (I had to wait for 
~2h). Though, all N310s still don't.


On 18.02.21 10:12, Johannes Demel via USRP-users wrote:
Hi all,
I have some N310s and a B210 that I try to sync with a GPSDO. All of them 
recognize their GPSDOs but fail to lock.
My phone can see ~7 Satellites. We have a RPi with a GPS module that locks to 
GPS in the same hall. We switched antennas but still, we can't sync any of the 
USRPs to GPS.
I tried:
```
lib/uhd/utils/query_gpsdo_sensors
```
and
```
lib/uhd/examples/sync_to_gps
```
but even after a day, they always return "GPS does not have lock" and "WARNING:  GPS 
not locked - time will not be accurate until locked".
`gpsmon` on the N310s reports 0 Satellites. But it has a list of satellites.
Since we have several devices in that room that are able to acquire a lock but 
none of our USRPs with their GPSDOs, I wonder what is going on. Do they need a 
very strong signal?
Cheers
Johannes

___
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] GPSDO fails to lock

[Marcus D Leech via USRP-users]

Are the antennae situated outdoors?

It can take almost an hour to achieve lock from a cold start. 

Sent from my iPhone

> On Feb 19, 2021, at 4:14 AM, Johannes Demel  wrote:
> 
> Each USRP has its own GPS antenna. One of those you buy at ettus.com as a 
> recommended accessory.
> 
>> On 18.02.21 15:05, Marcus D Leech wrote:
>> How are you delivering the GPS antenna signal to the USRPs?  Via a splitter? 
>> Does that splitter provide DC pass-through?
>> Sent from my iPhone
 On Feb 18, 2021, at 7:07 AM, Johannes Demel via USRP-users 
  wrote:
>>> 
>>> Just a quick follow-up. The B210 finally got a GPS lock. (I had to wait 
>>> for ~2h). Though, all N310s still don't.
>>> 
 On 18.02.21 10:12, Johannes Demel via USRP-users wrote:
 Hi all,
 I have some N310s and a B210 that I try to sync with a GPSDO. All of them 
 recognize their GPSDOs but fail to lock.
 My phone can see ~7 Satellites. We have a RPi with a GPS module that locks 
 to GPS in the same hall. We switched antennas but still, we can't sync any 
 of the USRPs to GPS.
 I tried:
 ```
 lib/uhd/utils/query_gpsdo_sensors
 ```
 and
 ```
 lib/uhd/examples/sync_to_gps
 ```
 but even after a day, they always return "GPS does not have lock" and 
 "WARNING:  GPS not locked - time will not be accurate until locked".
 `gpsmon` on the N310s reports 0 Satellites. But it has a list of 
 satellites.
 Since we have several devices in that room that are able to acquire a lock 
 but none of our USRPs with their GPSDOs, I wonder what is going on. Do 
 they need a very strong signal?
 Cheers
 Johannes
>>> 
>>> ___
>>> 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] x310 two UBX daughterboard receiver

[Marcus D. Leech via USRP-users]

On 02/18/2021 11:47 PM, Xiang Ma wrote:
If I want to use slot A as transmitter, slot B as receiver, can I do 
like this:

self.source.set_antenna("RX2", 1)
self.sink.set_antenna("TX/RX", 0)

You'd need to set the antenna for the receive side in both slots to "RX2":

self.source.set_antenna("RX2", 0)
self.source.set_antenna("RX2", 1)

The default (and only, really) antenna for TX for the UBX is already 
"TX/RX".



The Python API isn't that well documented at this point, so there's a 
lot of "infer from the C++ API".


But, to be honest, a lot of this "mucking about" can be more easily 
accomplished using Gnu Radio as your experimental
  environment (at least initially), rather than just using the UHD 
API.  Things like "how do I create a multi-channel streamer and

  manage the data from it", are already handled in Gnu Radio.




In this page, it said /The default subdev spec is "A:0 B:0", which 
means slot A is mapped to channel 0, and slot B is mapped to channel 1./

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-June/056965.html

On Thu, Feb 18, 2021 at 9:18 PM Marcus D. Leech 
mailto:patchvonbr...@gmail.com>> wrote:


On 02/18/2021 10:16 PM, Xiang Ma wrote:

Are there any python code for this? I am using the python interface.

You'll have to kind of infer what to do from the C++
example--there is no Python version of that example.




On Thu, Feb 18, 2021 at 7:44 PM Marcus D Leech
mailto:patchvonbr...@gmail.com>> wrote:

Well there’s the rx_multi_samples example that is part of the
UHD source tree.

Sent from my iPhone


On Feb 18, 2021, at 9:32 PM, Xiang Ma mailto:marxwo...@gmail.com>> wrote:


  Do you have any example code? I am still confused.

Thank you.

On Thu, Feb 18, 2021 at 5:50 PM Marcus D Leech
mailto:patchvonbr...@gmail.com>>
wrote:

Just create a 2-channel USRP source and specify a subdev
of “A:0 B:0”.



Sent from my iPhone


On Feb 18, 2021, at 7:38 PM, Xiang Ma via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:


Hi,

I am using a x310 USRP with two UBX daughterboards.
Now I can transmit and receive the signal in RF A
daughterboard with command
  self.source.set_antenna("RX2", 0)
self.sink.set_antenna("TX/RX", 0).

Now, I want to transmit the signal in RF A, and
receive the signal in both RF A and RF B. It is
actually 1 transmitter and 2 receivers. How can I
implement this? I checked the set_subdev_subdev("B",
1), but it doesn't work.

Thank you,




-- 
/*Xiang Ma, */Ph.D. Student

College of Engineering
Utah State University
E-mail:marxwo...@gmail.com 
___
USRP-users mailing list
USRP-users@lists.ettus.com

http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




-- 
/*Xiang Ma, */Ph.D. Student

College of Engineering
Utah State University
E-mail:marxwo...@gmail.com 




-- 
/*Xiang Ma, */Ph.D. Student

College of Engineering
Utah State University
E-mail:marxwo...@gmail.com 




--
/*Xiang Ma, */Ph.D. Student
College of Engineering
Utah State University
E-mail:marxwo...@gmail.com 


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

Re: [USRP-users] x310 two UBX daughterboard receiver

[Marcus D. Leech via USRP-users]

On 02/18/2021 10:16 PM, Xiang Ma wrote:

Are there any python code for this? I am using the python interface.
You'll have to kind of infer what to do from the C++ example--there is 
no Python version of that example.





On Thu, Feb 18, 2021 at 7:44 PM Marcus D Leech 
mailto:patchvonbr...@gmail.com>> wrote:


Well there’s the rx_multi_samples example that is part of the UHD
source tree.

Sent from my iPhone


On Feb 18, 2021, at 9:32 PM, Xiang Ma mailto:marxwo...@gmail.com>> wrote:


  Do you have any example code? I am still confused.

Thank you.

On Thu, Feb 18, 2021 at 5:50 PM Marcus D Leech
mailto:patchvonbr...@gmail.com>> wrote:

Just create a 2-channel USRP source and specify a subdev of
“A:0 B:0”.



Sent from my iPhone


On Feb 18, 2021, at 7:38 PM, Xiang Ma via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:


Hi,

I am using a x310 USRP with two UBX daughterboards. Now
I can transmit and receive the signal in RF A daughterboard
with command
self.source.set_antenna("RX2", 0)
self.sink.set_antenna("TX/RX", 0).

Now, I want to transmit the signal in RF A, and receive
the signal in both RF A and RF B. It is actually 1
transmitter and 2 receivers. How can I implement this? I
checked the set_subdev_subdev("B", 1), but it doesn't work.

Thank you,




-- 
/*Xiang Ma, */Ph.D. Student

College of Engineering
Utah State University
E-mail:marxwo...@gmail.com 
___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




-- 
/*Xiang Ma, */Ph.D. Student

College of Engineering
Utah State University
E-mail:marxwo...@gmail.com 




--
/*Xiang Ma, */Ph.D. Student
College of Engineering
Utah State University
E-mail:marxwo...@gmail.com 


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

Re: [USRP-users] x310 two UBX daughterboard receiver

[Marcus D Leech via USRP-users]

Well there’s the rx_multi_samples example that is part of the UHD source tree. 

Sent from my iPhone

> On Feb 18, 2021, at 9:32 PM, Xiang Ma  wrote:
> 
> 
>   Do you have any example code? I am still confused.
> 
> Thank you.
> 
>> On Thu, Feb 18, 2021 at 5:50 PM Marcus D Leech  
>> wrote:
>> Just create a 2-channel USRP source and specify a subdev of “A:0 B:0”. 
>> 
>> 
>> 
>> Sent from my iPhone
>> 
 On Feb 18, 2021, at 7:38 PM, Xiang Ma via USRP-users 
  wrote:
 
>>> 
>>> Hi,
>>> 
>>> I am using a x310 USRP with two UBX daughterboards. Now I can transmit 
>>> and receive the signal in RF A daughterboard with command
>>> self.source.set_antenna("RX2", 0)
>>> self.sink.set_antenna("TX/RX", 0).
>>> 
>>> Now, I want to transmit the signal in RF A, and receive the signal in 
>>> both RF A and RF B. It is actually 1 transmitter and 2 receivers. How can I 
>>> implement this? I checked the set_subdev_subdev("B", 1), but it doesn't 
>>> work.
>>> 
>>> Thank you,
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Xiang Ma, Ph.D. Student
>>> College of Engineering
>>> Utah State University
>>> E-mail:marxwo...@gmail.com
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> -- 
> Xiang Ma, Ph.D. Student
> College of Engineering
> Utah State University
> E-mail:marxwo...@gmail.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] x310 two UBX daughterboard receiver

[Marcus D Leech via USRP-users]

Just create a 2-channel USRP source and specify a subdev of “A:0 B:0”. 



Sent from my iPhone

> On Feb 18, 2021, at 7:38 PM, Xiang Ma via USRP-users 
>  wrote:
> 
> 
> Hi,
> 
> I am using a x310 USRP with two UBX daughterboards. Now I can transmit 
> and receive the signal in RF A daughterboard with command
> self.source.set_antenna("RX2", 0)
> self.sink.set_antenna("TX/RX", 0).
> 
> Now, I want to transmit the signal in RF A, and receive the signal in 
> both RF A and RF B. It is actually 1 transmitter and 2 receivers. How can I 
> implement this? I checked the set_subdev_subdev("B", 1), but it doesn't work.
> 
> Thank you,
> 
> 
> 
> 
> -- 
> Xiang Ma, Ph.D. Student
> College of Engineering
> Utah State University
> E-mail:marxwo...@gmail.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] GPSDO fails to lock

[Marcus D Leech via USRP-users]

How are you delivering the GPS antenna signal to the USRPs?  Via a splitter? 
Does that splitter provide DC pass-through?

Sent from my iPhone

> On Feb 18, 2021, at 7:07 AM, Johannes Demel via USRP-users 
>  wrote:
> 
> Just a quick follow-up. The B210 finally got a GPS lock. (I had to wait for 
> ~2h). Though, all N310s still don't.
> 
>> On 18.02.21 10:12, Johannes Demel via USRP-users wrote:
>> Hi all,
>> I have some N310s and a B210 that I try to sync with a GPSDO. All of them 
>> recognize their GPSDOs but fail to lock.
>> My phone can see ~7 Satellites. We have a RPi with a GPS module that locks 
>> to GPS in the same hall. We switched antennas but still, we can't sync any 
>> of the USRPs to GPS.
>> I tried:
>> ```
>> lib/uhd/utils/query_gpsdo_sensors
>> ```
>> and
>> ```
>> lib/uhd/examples/sync_to_gps
>> ```
>> but even after a day, they always return "GPS does not have lock" and 
>> "WARNING:  GPS not locked - time will not be accurate until locked".
>> `gpsmon` on the N310s reports 0 Satellites. But it has a list of satellites.
>> Since we have several devices in that room that are able to acquire a lock 
>> but none of our USRPs with their GPSDOs, I wonder what is going on. Do they 
>> need a very strong signal?
>> Cheers
>> Johannes
> 
> ___
> 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] shared_ptr does not name a template type in Cross-compile of GR 3.7 with UHD 3.15 SDK

[Marcus D Leech via USRP-users]

This should probably be cross posted to the discuss-gnuradio mailing list just 
to get some more gnuradio-specific eyes on it. 

Sent from my iPhone

> On Feb 17, 2021, at 2:26 PM, Dennis Trask via USRP-users 
>  wrote:
> 
> I have UHD 3.15 successfully cross-compiled for E310 on Ubuntu 18.04 host. 
> Now trying to cross-compile GnuRadio 3.7. My cmake is:
> 
> cmake 
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>  -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr 
> -DCMAKE_ASM_COMPILER_ARG1:STRING="-mcpu=cortex-a9" ../
> 
> It looks like the build is erroneously looking for shared_ptr in namespace 
> std instead of namespace boost, but I'm not sure how to set this up for 
> success. Does anyone see where I have gone wrong?
> 
> I'm getting the following error stream:
> 
> [ 34%] Building CXX object 
> gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block_gateway_impl.cc.o
> In file included from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager_base.h:26,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:27,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcregisterhelpers.h:26,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/basic_block.h:42,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/lib/basic_block.cc:27:
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpc_shared_ptr_selection.h:34:32:
>  error: 'shared_ptr' in namespace 'std' does not name a template type
>  #define GR_RPC_SHARED_PTR std::shared_ptr
> ^~
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager_base.h:34:13:
>  note: in expansion of macro 'GR_RPC_SHARED_PTR'
>  typedef GR_RPC_SHARED_PTR 
> rpcserver_booter_base_sptr;
>  ^
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpc_shared_ptr_selection.h:34:27:
>  note: 'std::shared_ptr' is only available from C++11 onwards
>  #define GR_RPC_SHARED_PTR std::shared_ptr
>^~~
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager_base.h:34:13:
>  note: in expansion of macro 'GR_RPC_SHARED_PTR'
>  typedef GR_RPC_SHARED_PTR 
> rpcserver_booter_base_sptr;
>  ^
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpc_shared_ptr_selection.h:34:32:
>  error: 'shared_ptr' in namespace 'std' does not name a template type
>  #define GR_RPC_SHARED_PTR std::shared_ptr
> ^~
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_base.h:49:13:
>  note: in expansion of macro 'GR_RPC_SHARED_PTR'
>  typedef GR_RPC_SHARED_PTR rpcserver_base_sptr;
>  ^
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpc_shared_ptr_selection.h:34:27:
>  note: 'std::shared_ptr' is only available from C++11 onwards
>  #define GR_RPC_SHARED_PTR std::shared_ptr
>^~~
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_base.h:49:13:
>  note: in expansion of macro 'GR_RPC_SHARED_PTR'
>  typedef GR_RPC_SHARED_PTR rpcserver_base_sptr;
>  ^
> In file included from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_booter_aggregator.h:28,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:28,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcregisterhelpers.h:26,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/basic_block.h:42,
>  from 
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/lib/basic_block.cc:27:
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_aggregator.h:47:42:
>  error: 'rpcmanager_base::rpcserver_booter_base_sptr' has not been declared
>  void registerServer(rpcmanager_base::rpcserver_booter_base_sptr server);
>   ^~
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_aggregator.h:120:42:
>  error: 'rpcserver_booter_base_sptr' is not a member of 'rpcmanager_base'
>  typedef std::vector 
> rpcServerMap_t;
>   ^~
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_aggregator.h:120:42:
>  error: 'rpcserver_booter_base_sptr' is not a member of 'rpcmanager_base'
> /home/labuser/rfnoc/src/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_aggregator.h:120:68:
>  error: template argument 1 is invalid
>  typedef std::vector 
> 

Re: [USRP-users] How to use 2 N310 for TX and RX

[Marcus D. Leech via USRP-users]

On 02/11/2021 05:04 AM, Johannes Demel wrote:

Hi,

yes, I just attach a grc file for GR 3.9 that I use to test things.

It works if I specify `addr=...` or `addr0=...` with one device. If I 
switch to 2 devices `addr=,addr1=...` it fails.


It seems like UHD tries to initialize the devices twice.


[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_3.15.0.0-62-g7a3f1516
[INFO] [MPMD] Initializing 2 device(s) in parallel with args: 
mgmt_addr0=192.168.20.213,type0=n3xx,product0=n310,serial0=319841B,claimed0=False,mgmt_addr1=192.168.21.218,type1=n3xx,product1=n310,serial1=3180AF3,claimed1=False,addr0=192.168.20.213,addr1=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=external
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,clock_source=external,master_clock_rate=122.88e6,product=n310,mgmt_addr=192.168.20.213'.
[INFO] [0/Replay_0] Initializing block control (NOC ID: 
0x4E91A004)
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,product=n310,master_clock_rate=122.88e6,clock_source=external,mgmt_addr=192.168.21.218'.
[INFO] [0/Radio_0] Initializing block control (NOC ID: 
0x12AD10011312)


[...]

[INFO] [1/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [MPMD] Initializing 2 device(s) in parallel with args: 
mgmt_addr0=192.168.20.213,type0=n3xx,product0=n310,serial0=319841B,claimed0=True,mgmt_addr1=192.168.21.218,type1=n3xx,product1=n310,serial1=3180AF3,claimed1=True,addr0=192.168.20.213,addr1=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=external
[ERROR] [RPC] Someone tried to claim this device again (From: 
192.168.20.34)



If I use only one device, it looks like this:


[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_3.15.0.0-62-g7a3f1516
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.20.213,type=n3xx,product=n310,serial=319841B,claimed=False,addr0=192.168.20.213,master_clock_rate=122.88e6,clock_source=external,time_source=external
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,clock_source=external,master_clock_rate=122.88e6,product=n310,mgmt_addr=192.168.20.213'.
[INFO] [0/Replay_0] Initializing block control (NOC ID: 
0x4E91A004)


[...]

[INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)


The last 4 lines are suspicious because they indicate that 
synchronization is performed twice. Also, most of the time during 
start up is spend there.


Anyways, I attached my MWE flowgraph. I'd be happy if you could tell 
me how to fix my issue.


Cheers
Johannes


Johannes:

I'm copying Michael Dickens from Ettus Engineering on this, and also, 
continuing this thread on the usrp-users mailing list would be
  more useful than on the discuss-gnuradio list, as there are folks on 
the usrp-users list who have done multi-N310 configurations

  successfully.

In particular, Ali Dormiani (sdorm...@eng.ucsd.edu) has at least 6 N310 
operating in their lab with a single host:


Hello fellow N310 users. My lab has 6 N310's all operating and streaming 
to a single data server (10 Gbe links).


We use GNU Radio for everything. The software is great for controlling 
multiple devices with many antennas easily (highly recommended). My 
experience with native C++ UHD driver commands is rather limited.


I'm personally hampered by only having a single N310 at my disposal, so 
I can't reproduce your issue.






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

Re: [USRP-users] Python API install help - Ubuntu 20.04

[Marcus D. Leech via USRP-users]

On 02/11/2021 09:53 AM, Casey Wolsieffer wrote:

Actually i got it, for my case it was in

export PYTHONPATH="/usr/local/lib/python3/dist-packages/"

Semi-new to this so still figuring out some of the stuff that is 
probably obvious. Will throw this line in ~/.bash_profile


Thank you!
Some Linux distributions put locally-installed Python packages in 
"dist-packages" and some in "site-packages".  I simply mention
  all potential places in my PYTHONPATH, and then don't have to worry 
about it--except when some distro decides to be even more

  creative about where such packages are installed...




On Thu, Feb 11, 2021, 9:46 AM Casey Wolsieffer > wrote:


I tried your suggestion as well Rob to no avail. Also, thank you
both for your responses

On Thu, Feb 11, 2021, 9:44 AM Casey Wolsieffer mailto:cwols...@gmail.com>> wrote:

I did sudo make install yes,


I'm assuming you mean /usr/local, I tried that in .conf file
but that doesn't seem to work either


On Thu, Feb 11, 2021, 8:57 AM Marcus D Leech
mailto:patchvonbr...@gmail.com>> wrote:

Your install prefix is /use/local

Did you sudo make install?



Sent from my iPhone

> On Feb 11, 2021, at 8:30 AM, Casey Wolsieffer via
USRP-users mailto:usrp-users@lists.ettus.com>> wrote:
>
> 
> Hello, I have tried several times to install Python3 uhd
on my system but when I attempt >>>import uhd in python3
environment I always receive ModuleNotFoundError: no
module named 'uhd'
>
> As far as I can see there are no hang ups on install and
after $make, I run $make test and get 0 out of 82 fails.
Below is my enabled components after I run
>
> $cmake ../
>
> I've also put a uhd.conf file in my ld.so.conf file and
ran $sudo ldconfig. Although I'm not certain I'm putting
in correct path, right now it's
[my_directory]/uhd/host/build/lib/
>
> I'm on Ubuntu 20.04, any help is greatly appreciated!
>
> -- ##
> -- # UHD enabled components
> -- ##
> --   * LibUHD
> --   * LibUHD - C API
> --   * LibUHD - Python API
> --   * Examples
> --   * Utils
> --   * Tests
> --   * USB
> --   * B100
> --   * B200
> --   * USRP1
> --   * USRP2
> --   * X300
> --   * MPMD
> --   * SIM
> --   * N300
> --   * N320
> --   * E320
> --   * E300
> --   * OctoClock
> --   * Manual
> --   * API/Doxygen
> --   * Man Pages
> --
> -- ##
> -- # UHD disabled components
> -- ##
> --   * DPDK
> --
> -- **
> -- * You are building the UHD development master branch.
> -- * For production code, we recommend our stable,
> -- * releases or using the release branch (maint).
> -- **
> -- Building version: 4.0.0.0-93-g3b9ced8f
> -- Using install prefix: /usr/local
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
/home/casey/Projects/UHD/uhd/host/build
>
>
> ___
> 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] Python API install help - Ubuntu 20.04

[Marcus D. Leech via USRP-users]

On 02/11/2021 09:44 AM, Casey Wolsieffer wrote:

I did sudo make install yes,


I'm assuming you mean /usr/local, I tried that in .conf file but that 
doesn't seem to work either



If you

find /usr/local -name "*uhd*"

What does that produce?




On Thu, Feb 11, 2021, 8:57 AM Marcus D Leech > wrote:


Your install prefix is /use/local

Did you sudo make install?



Sent from my iPhone

> On Feb 11, 2021, at 8:30 AM, Casey Wolsieffer via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:
>
> 
> Hello, I have tried several times to install Python3 uhd on my
system but when I attempt >>>import uhd in python3 environment I
always receive ModuleNotFoundError: no module named 'uhd'
>
> As far as I can see there are no hang ups on install and after
$make, I run $make test and get 0 out of 82 fails. Below is my
enabled components after I run
>
> $cmake ../
>
> I've also put a uhd.conf file in my ld.so.conf file and ran
$sudo ldconfig. Although I'm not certain I'm putting in correct
path, right now it's [my_directory]/uhd/host/build/lib/
>
> I'm on Ubuntu 20.04, any help is greatly appreciated!
>
> -- ##
> -- # UHD enabled components
> -- ##
> --   * LibUHD
> --   * LibUHD - C API
> --   * LibUHD - Python API
> --   * Examples
> --   * Utils
> --   * Tests
> --   * USB
> --   * B100
> --   * B200
> --   * USRP1
> --   * USRP2
> --   * X300
> --   * MPMD
> --   * SIM
> --   * N300
> --   * N320
> --   * E320
> --   * E300
> --   * OctoClock
> --   * Manual
> --   * API/Doxygen
> --   * Man Pages
> --
> -- ##
> -- # UHD disabled components
> -- ##
> --   * DPDK
> --
> -- **
> -- * You are building the UHD development master branch.
> -- * For production code, we recommend our stable,
> -- * releases or using the release branch (maint).
> -- **
> -- Building version: 4.0.0.0-93-g3b9ced8f
> -- Using install prefix: /usr/local
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
/home/casey/Projects/UHD/uhd/host/build
>
>
> ___
> 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] Python API install help - Ubuntu 20.04

[Marcus D Leech via USRP-users]

Your install prefix is /use/local

Did you sudo make install?



Sent from my iPhone

> On Feb 11, 2021, at 8:30 AM, Casey Wolsieffer via USRP-users 
>  wrote:
> 
> 
> Hello, I have tried several times to install Python3 uhd on my system but 
> when I attempt >>>import uhd in python3 environment I always receive 
> ModuleNotFoundError: no module named 'uhd'
> 
> As far as I can see there are no hang ups on install and after $make, I run 
> $make test and get 0 out of 82 fails. Below is my enabled components after I 
> run
> 
> $cmake ../
> 
> I've also put a uhd.conf file in my ld.so.conf file and ran $sudo ldconfig. 
> Although I'm not certain I'm putting in correct path, right now it's 
> [my_directory]/uhd/host/build/lib/
> 
> I'm on Ubuntu 20.04, any help is greatly appreciated!
> 
> -- ## 
> -- # UHD enabled components   
> -- ## 
> --   * LibUHD 
> --   * LibUHD - C API 
> --   * LibUHD - Python API 
> --   * Examples 
> --   * Utils 
> --   * Tests 
> --   * USB 
> --   * B100 
> --   * B200 
> --   * USRP1 
> --   * USRP2 
> --   * X300 
> --   * MPMD 
> --   * SIM 
> --   * N300 
> --   * N320 
> --   * E320 
> --   * E300 
> --   * OctoClock 
> --   * Manual 
> --   * API/Doxygen 
> --   * Man Pages 
> --  
> -- ## 
> -- # UHD disabled components  
> -- ## 
> --   * DPDK 
> --  
> -- ** 
> -- * You are building the UHD development master branch. 
> -- * For production code, we recommend our stable, 
> -- * releases or using the release branch (maint). 
> -- ** 
> -- Building version: 4.0.0.0-93-g3b9ced8f 
> -- Using install prefix: /usr/local 
> -- Configuring done 
> -- Generating done 
> -- Build files have been written to: /home/casey/Projects/UHD/uhd/host/build
> 
> 
> ___
> 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] E310 with v4.0.0.0 Image: Configure Static IP

[Marcus D. Leech via USRP-users]

On 02/10/2021 10:01 AM, Rob Kossler wrote:
I don't know about the E310, but on the N310, I found files in 
/data/network which is where I needed to make changes such as these.

Rob
Indeed, just programmed a V4.0.0.0 SG1 image onto my E310, and the 
eth0.network file is in /data/network.  This probably has to do with

  the fact that it's a mender-based system.

Changed the eth0.network file under /data/network, rebooted, and the 
address is statically configured as desired.




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

Re: [USRP-users] Ettus USRP B200 mini - FPGA compatibility number

[Marcus D Leech via USRP-users]

To amplify on a point Rob made. You have to power cycle the B2xx to load a new 
image into it.  


Sent from my iPhone

> On Feb 10, 2021, at 9:53 AM, Rob Kossler via USRP-users 
>  wrote:
> 
> 
> When you run uhd_images_downloader, which version of UHD is shown in the 
> console?  I can see in the console pictures below that UHD version 3.010.003 
> is running (which is pretty old).  My guess is that you have multiple copies 
> of UHD on your system.
> 
> The way it works is the following: when you run uhd_images_downloader, the 
> script automatically downloads the FPGA image that is associated with that 
> specific version of UHD and installs it in /share/uhd/images/.  
> Later, when you run any application that uses UHD and the B200mini, UHD will 
> transfer that image (from that same folder) over USB to the device to load 
> the FPGA (at least the first time you run UHD after plugging the device).
> Rob
> 
>> On Wed, Feb 10, 2021 at 4:54 AM Elise Breivik Smebye via USRP-users 
>>  wrote:
>> Hi, I am new to UHD, USRP and FPGA.
>> I am trying to use a Ettus USRP B200 mini to monitor the network traffic 
>> between two android phones with GNU radio with this guide 
>> https://github.com/bastibl/gr-ieee802-11.
>> When running the example file "wifi_tx_grc" I get a FPGA compatibility 
>> number error.
>>  
>> 
>> GNU Radio test
>>  
>> I have also tried to follow this guide https://github.com/srsLTE/srsLTE
>> and get the same error. I have run "uhd_images_donwloader" and get that all 
>> images are up to.
>>  
>> 
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Hope anyone can help.
>> 
>> ___
>> 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] E310 with v4.0.0.0 Image: Configure Static IP

[Marcus D. Leech via USRP-users]

On 02/09/2021 05:04 PM, dtra...@tampabay.rr.com wrote:

Thanks, Marcus.

That was actually what I attempted first. As described in the man page 
(https://www.freedesktop.org/software/systemd/man/systemd.network.html) I 
created eth0.network under /etc/systemd/network/, with these contents:


[Match]
Name=eth0

[Network]
Address=192.168.200.2/24

The system seemed to ignore this configuration, however.




OK, what does:

systemctl |grep -i net

Yield?

What does:

ip link

Return?




-

From: "Marcus D. Leech via USRP-users"
To: usrp-users@lists.ettus.com
Cc:
Sent: Tuesday February 9 2021 4:42:34PM
Subject: Re: [USRP-users] E310 with v4.0.0.0 Image: Configure Static IP

On 02/09/2021 04:35 PM, Dennis Trask via USRP-users wrote:

I have re-imaged the SD card for my E310 with the v4.0.0.0 image.
I cannot figure out how to set a static IP address on eth0 at
boot-up. I created an /etc/network/interfaces file that looks like
this:

auto eth0
iface eth0 inet static
address 192.168.200.2
netmask 255.255.255.0

I can run the command "ifup eth0" and bring up the interface with
the desired configuration, but it does not initialize when I reboot.

The SD image I am using was obtained with the command:
uhd_images_downloader -t e310 -t sg3

I built the uhd_images_downloder from source, and it's version
is 4.0.0.HEAD-0-g90ce6062.

Dennis



___
USRP-users mailing list
"mailto:USRP-users@lists.ettus.com;>USRP-users@lists.ettus.com
"http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com;>
target=
"_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

It almost certainly is running systemd/networkd

So look under /etc/systemd/networkd

In Linux, there have historically been many different ways to 
configure network devices, and even under systemd, there are a couple of
  different schemes "out there".  I believe that in a UHD 4 system 
image on E310, it is based on Networkd.





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

Re: [USRP-users] Usrp b210 without duplexer

[Marcus D Leech via USRP-users]

The maximum power at any receive port should not exceed -15dBm. 

If you’re doing full duplex into a shared antenna then yes you need to use a 
duplexor. 

This isn’t strictly a USRP issue—it’s a generic RF engineering practice that is 
older than most of us here. 

Sent from my iPhone

> On Feb 9, 2021, at 5:17 PM, Ashutosh Singh via USRP-users 
>  wrote:
> 
> Hi all ,
> If I use my USRP b210 without duplexer to transmit and receive  the signals 
> from other USRP , will it not damage my USRP ?
> 
> 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] E310 with v4.0.0.0 Image: Configure Static IP

[Marcus D. Leech via USRP-users]

On 02/09/2021 04:35 PM, Dennis Trask via USRP-users wrote:
I have re-imaged the SD card for my E310 with the v4.0.0.0 image. I 
cannot figure out how to set a static IP address on eth0 at boot-up. I 
created an /etc/network/interfaces file that looks like this:


auto eth0
iface eth0 inet static
address 192.168.200.2
netmask 255.255.255.0

I can run the command "ifup eth0" and bring up the interface with the 
desired configuration, but it does not initialize when I reboot.


The SD image I am using was obtained with the command: 
uhd_images_downloader -t e310 -t sg3


I built the uhd_images_downloder from source, and it's version 
is 4.0.0.HEAD-0-g90ce6062.


Dennis



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

It almost certainly is running systemd/networkd

So look under /etc/systemd/networkd

In Linux, there have historically been many different ways to configure 
network devices, and even under systemd, there are a couple of
  different schemes "out there".  I believe that in a UHD 4 system 
image on E310, it is based on Networkd.



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

Re: [USRP-users] B210 NB-IoT frontend issues

[Marcus D. Leech via USRP-users]

On 02/09/2021 03:48 PM, Luca Lodigiani via USRP-users wrote:

Hello,

My team and I are doing some experiments with the USRP B210 and NB-IoT 
waveforms.
During tests we have observed a few issues with the RF output, that we 
would like to understand better, and /hopefully/​ fix or mitigate.   I 
must admit that we are not yet very familiar with USRP SDRs, so I 
apologize in advance for any stupid question!  There are so many 
options to tweak the USRP :-) !


This is what we have observed:

 1. Apparent RF leakage from RX to TX when idle (i.e. not transmitting
the 180 kHz NB-IoT carrier).  Our B210 was connected to an RF
matrix where other signals in other channels not immediately
adjacent to our center frequency also exist, and, every time we
were not transmitting, some of those signals (a MHz away) were
picked up from the RX and “leaked” into the TX – this could be
observed from a spectrum analyzer connected to the B210 TX and it
appears to be picking up quite a wide bandwidth (more than 5-10 MHz).
 1. Is this a known issue with the B210 RF frontend?
 2. Does anyone have any suggestions on how to mitigate it (if
even possible)?
 3. We tried limiting RX bandwidth as described here
https://files.ettus.com/manual/page_usrp_b200.html#b200_fe_bw , but
it seems not change anything at least when idle. Any ideas?

Given that the leakage path that you're (I think) talking about would be 
VERY VERY early in the RF chain inside the AD9361 chip, setting
  analog bandwidth would have ZERO effect, since that sets the *IF* 
bandwidth--well after the bits and pieces you're likely dealing with.
  I haven't looked at the TX/RX isolation spec in the AD9361 
data-sheet, but it would surprise me very much if it were better than 50dB.
  It's pretty hard inside such a tiny tiny piece of silicon to isolate 
RF signal pathways more than that.   What power levels is the RX2 port
  seeing in your application--your "RF matrix" really needs to not be 
presenting more than about -15dBm to the RX2 port(s), or there's

  potential for damage.

Also, when you talk about 180kHz carrier, you're talking *bandwidth* or 
center frequency?  The center frequency on the B210 cannot go

 below about 50MHz.



1.



 1. Out-of-band emissions and spectral regrowth:  The output NB-IoT
carrier shows quite large out-of-band emissions (~-30 dBc @200 kHz
from center frequency, -50 dBc @400 kHz).
 1. Could this be due to non-linear distortion caused by the B210
frontend (AD9361) ?
 2. Would limiting TX analog bandwidth with set_tx_bandwidth(bw)
help here?

It might  Help to lower TX analog bandwidth, but UHD automatically sets 
it based on your sample rate.  Also try reducing baseband magnitude

  a little bit, as well as reducing TX gain a little bit.


 1. Any other suggestions?

I also have some other general questions...:

 1. Even after reading this
(https://files.ettus.com/manual/page_power.html ) I am still not
super clear about if and how the set_tx_power_reference() (and
rx)  affect the gain level.  I think understand TX gain setting
will obviously affect the output power though.

The tx_power_reference() API is new, so I cannot comment on how it works 
out in practice. The B2xx have about 80dB of TX gain setting
  range, but with peak power output of about +7dBm over most of its 
frequency range, I'd say only the top 30dB is really useful.


 1. When talking about multiple "gain stages", how does this translate
to the B210?  Different stages of the AD9361 ?


Yes, different stages within the AD9361 in the case of B2xx.


 1. How are set_tx_bandwidth and set_rx_bandwidth implemented in
practice in the B210?

By using features inside the AD9361 to set the effective analog 
bandwidth in front of/behind the ADCs/DACs.  I'm not sure whether
  the implementation inside the AD9361 is purely-analog (like 
switched-capacitor filters, and changing clocks), or a hybrid approach
  that uses the DSP logic inside the AD9361.  The ADCs and DACs in the 
AD936x family operate at very high sample rates internally,
  and use DSP logic to provide the actual 
delivered-to-digital-interface sample rates, so there's room to do both 
a digital and analog
  approach in providing the necessary effective analog bandwidth. But 
UHD normally picks an analog bandwidth setting that is
  appropriate to the desired sample rate.  The only time this may not 
be appropriate is if your actual signal is very much narrower than

  is implied by the selected sample rate.



Many thanks
Luca



This communication is private and confidential and may contain 
information that is proprietary, privileged or otherwise legally 
exempt from disclosure. If you have received this message in error, 
please notify the sender immediately by e-mail and delete all copies 
of the message. In 

Re: [USRP-users] Error Testing UHD Build on E310 with uhd_usrp_probe

[Marcus D. Leech via USRP-users]

On 02/04/2021 12:12 PM, dtra...@tampabay.rr.com wrote:
Good info. Thanks. I am attempting to burn a new image to the SD card. 
I 
downloaded https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.14.1.1/e3xx_e320_sdimg_default-v3.14.1.1.zip 
which contains usrp_e320_fs.sdimg. Will this work to boot my e310?


Dennis

I'm going to say "almost certainly YES".  I haven't had a chance to try 
that image, and my lab is currently in a state of flux--we're moving
  to a new location and everything is in turmoil, so I can't burn that 
image myself right now.




-

From: "Marcus D. Leech"
To: dtra...@tampabay.rr.com
Cc: "usrp-users@lists.ettus.com"
Sent: Wednesday February 3 2021 9:25:58PM
Subject: Re: [USRP-users] Error Testing UHD Build on E310 with 
uhd_usrp_probe


On 02/02/2021 04:20 PM, dtra...@tampabay.rr.com wrote:
> From the root directory of the radio, I did: find . -name "ld-linux*"
>
> That command produced no results, either.
>
> If I am following the instructions
> at 
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source,

> should I expect to find this library under
> /home/root/newinstall/usr/lib? Or should it be on the image installed
> on the SD card under /lib?
>
> I have followed the above instructions to the letter, except for one
> change. After I cloned gr-ettus, I made sure to checkout the maint-3.7
> branch, to match the gnuradio version. However, I don't believe this
> should have any affect on the UHD cross-compile, should it?
>
>
So, here is what I have on my E310:

root@plood:~# find /lib -name *ld-*
/lib/ld-2.21.so
/lib/.debug/ld-2.21.so
/lib/ld-linux-armhf.so.3

I think your E310 filesystem may not be quite correct.



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

Re: [USRP-users] GPSDO and PPS on USRP N300

[Marcus D. Leech via USRP-users]

On 02/04/2021 03:30 AM, Puertas Blanco, Roberto via USRP-users wrote:


Hi Marcus,

My goal is to get NTP daemon running on N300 synced with GPSDO and 
PPS. Could it be that the GPSDO time is internally latched with the 
PPS line? If this is the case then I guess that it would not be 
necessary to read the PPS.


I have seen the “Device Synchronization” section  and “sync_to_gps”  
example in the USRP HW Driver and USRP Manual but  I am not sure if I 
have to do this if I just want to synchronize the NTP and system time 
on just one USRP N300.


Thanks,

Roberto


Indeed, it depends on *why* you want NTPD/GSPD on the *HOST* to "see" a 
1PPS signal.


If you want precise radio syncrhonization, that's already accomplished 
with the procedure used in sync_to_gps.**Using that procedure in
  your applications will guarantee that the timestamp-clock on your 
radio is precisely aligned to GPS time.  Placing the LInux host

  "in the loop" will not contribute to precise time-stamps.

*
*In USRPs, the GPSDO module exists for the benefit of the radio, and 
only secondarily for the benefit of the embedded Linux host--

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

Re: [USRP-users] Error Testing UHD Build on E310 with uhd_usrp_probe

[Marcus D. Leech via USRP-users]

On 02/02/2021 04:20 PM, dtra...@tampabay.rr.com wrote:

From the root directory of the radio, I did: find . -name "ld-linux*"

That command produced no results, either.

If I am following the instructions 
at https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source, 
should I expect to find this library under 
/home/root/newinstall/usr/lib? Or should it be on the image installed 
on the SD card under /lib?


I have followed the above instructions to the letter, except for one 
change. After I cloned gr-ettus, I made sure to checkout the maint-3.7 
branch, to match the gnuradio version. However, I don't believe this 
should have any affect on the UHD cross-compile, should it?




So, here is what I have on my E310:

root@plood:~# find /lib -name *ld-*
/lib/ld-2.21.so
/lib/.debug/ld-2.21.so
/lib/ld-linux-armhf.so.3

I think your E310 filesystem may not be quite correct.


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

Re: [USRP-users] GPSDO and PPS on USRP N300

[Marcus D. Leech via USRP-users]

On 02/03/2021 02:31 AM, Puertas Blanco, Roberto via USRP-users wrote:


Hello,

Is there any way to get the PPS pulse from PS side  (ARM) in the USRP 
N300? I would like to know if the PPS is mapped through the /dev/pps 
or if it is embedded into GPSDO module.


Thanks,

Roberto


The answer (based on the version of the system image that I have) is 
no.  The PPS line does not "manifest" as /dev/pps on the ARM CPU.






Este correo electrónico y, en su caso, cualquier fichero anexo al 
mismo, contiene información de carácter confidencial exclusivamente 
dirigida a su destinatario o destinatarios. Si no es vd. el 
destinatario indicado, queda notificado que la lectura, utilización, 
divulgación y/o copia sin autorización está prohibida en virtud de la 
legislación vigente. En el caso de haber recibido este correo 
electrónico por error, se ruega notificar inmediatamente esta 
circunstancia mediante reenvío a la dirección electrónica del remitente.

Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) 
confidential information that is exclusively addressed to its 
recipient(s). If you are not the indicated recipient, you are informed 
that reading, using, disseminating and/or copying it without 
authorisation is forbidden in accordance with the legislation in 
effect. If you have received this email by mistake, please immediately 
notify the sender of the situation by resending it to their email address.

Avoid printing this message if it is not absolutely necessary.


___
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] Error Testing UHD Build on E310 with uhd_usrp_probe

[Marcus D. Leech via USRP-users]

On 02/02/2021 12:53 PM, dtra...@tampabay.rr.com wrote:

Here is the output, Marcus:

root@ni-e31x-3199693:~/newinstall# file 
/home/root/newinstall/usr/bin/uhd_usrp_probe
/home/root/newinstall/usr/bin/uhd_usrp_probe: ELF 32-bit LSB 
executable, ARM, EABI5 version 1 (SYSV), dynamically linked, 
interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, 
BuildID[sha1]=5c924895fbe10218be809ba29f88d7993fb117d7, with 
debug_info, not stripped


root@ni-e31x-3199693:~/newinstall# which uhd_usrp_probe
/home/root/newinstall/usr/bin/uhd_usrp_probe

Appreciate the help.

Dennis



Hmm, see if:

/lib/ld-linux-armhf.so.3


Is actually there and executable



-

From: "Marcus D. Leech via USRP-users"
To: usrp-users@lists.ettus.com
Cc:
Sent: Monday February 1 2021 4:06:23PM
Subject: Re: [USRP-users] Error Testing UHD Build on E310 with 
uhd_usrp_probe


On 02/01/2021 04:01 PM, Dennis Trask via USRP-users wrote:

I am attempting to set up a development environment to write
software for the E310 by cross-compiling on Ubuntu 18.04. I am
using the instructions here:

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

I have followed all the instructions to build UHD and am now in
the section "Mount and test the UHD build". When I run
uhd_usrp_probe on the E310, I get the following ouput:

root@ni-e31x-3199693:~/newinstall# uhd_usrp_probe

-sh: /home/root/newinstall/usr/bin/uhd_usrp_probe: No such file or
directory

If you do:

file /home/root/newinstall/usr/bin/uhd_usrp_probe

What do you get?

If you do:

which uhd_usrp_probe

What do you get?


I'm not sure where to look for the source of this issue. Has
anyone else seen this or have an idea of what to look for?

Thanks,

Dennis



___
USRP-users mailing list
"mailto:USRP-users@lists.ettus.com;>USRP-users@lists.ettus.com
"http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com;>
target=
"_blank">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] DPDK troubles (invalid ELF header loading dpdk library)

[Marcus D Leech via USRP-users]

Unfortunately that’s one I can’t help with. I don’t have any DPDK capable 
machines at my disposal. 

I vaguely recall that you have to be root for DPDK to work. Perhaps that’s the 
issue?

Sent from my iPhone

> On Feb 1, 2021, at 7:11 PM, Rob Kossler  wrote:
> 
> 
> I'm not convinced anything went wrong in the build of DPDK.  The build didn't 
> indicate any problems.  But I wouldn't be surprised to find out that things 
> aren't being installed where they are expected.  
> 
> In any case, I realized a mistake in my original post which accounts for the 
> discrepancy in the location of the library file mentioned in the error.  I 
> had been fooling with the uhd.conf setting for "dkdk_driver" which I had 
> changed on one system but not the other. 
> 
> And most recently, I accidentally commented out this setting completely and 
> things seem to be better.  The new error is the following.  Not sure why I'm 
> getting this error message.  Suggestions welcome.
> 
> EAL: Detected 8 lcore(s)
> EAL: Detected 1 NUMA nodes
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> EAL: No free hugepages reported in hugepages-1048576kB
> EAL: Probing VFIO support...
> EAL: VFIO support initialized
> [ERROR] [DPDK] No available DPDK devices (ports) found!
> EAL: FATAL: already called initialization.
> EAL: already called initialization.
> 
> 
>> On Mon, Feb 1, 2021 at 6:23 PM Marcus D. Leech via USRP-users 
>>  wrote:
>> On 02/01/2021 06:15 PM, Rob Kossler via USRP-users wrote:
>>> Hi,
>>> I have 2 systems (each with host PC and N310) for which I'm having similar 
>>> issues in trying to get DPDK up and running.  After going through the UHD 
>>> Manual DPDK instructions and DPDK app note, I am past the point at which 
>>> the "dpdk-devbind" seems to work fine, but I get the following error when I 
>>> run benchmark_rate.
>>> 
>>> I am running Ubuntu 20.04.LTS and installed DPDK 18.11.11 by 
>>> downloading/building from source. I built UHD (latest 4.0) from source and 
>>> it seemed happy finding DPDK and building with DPDK support. It seems like 
>>> a compatibility issue, but I can't figure it out. Any suggestions?
>>> Rob
>>> 
>>> // *** this is the error on System 1
>>> EAL: /usr/local/lib/libdpdk.so: invalid ELF header
>>> EAL: FATAL: Cannot init plugins
>>> EAL: Cannot init plugins
>>> 
>>> // this is the error on System 2 (nearly the same but different library)
>>> EAL: 
>>> /usr/local/share/dpdk/x86_64-native-linuxapp-gcc/lib//librte_pmd_ark.a: 
>>> invalid ELF header
>>> EAL: FATAL: Cannot init plugins
>>> EAL: Cannot init plugins
>>> 
>>> 
>> This would seem to indicate that something very horrible went wrong in the 
>> build or DPDK--creating ELF headers that aren't correct for the
>>  type of hardware they're being used on.
>> 
>> ___
>> 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] DPDK troubles (invalid ELF header loading dpdk library)

[Marcus D. Leech via USRP-users]

On 02/01/2021 06:15 PM, Rob Kossler via USRP-users wrote:

Hi,
I have 2 systems (each with host PC and N310) for which I'm having 
similar issues in trying to get DPDK up and running. After going 
through the UHD Manual DPDK instructions and DPDK app note, I am past 
the point at which the "dpdk-devbind" seems to work fine, but I get 
the following error when I run benchmark_rate.


I am running Ubuntu 20.04.LTS and installed DPDK 18.11.11 by 
downloading/building from source. I built UHD (latest 4.0) from source 
and it seemed happy finding DPDK and building with DPDK support. It 
seems like a compatibility issue, but I can't figure it out. Any 
suggestions?

Rob

// *** this is the error on System 1
EAL: /usr/local/lib/libdpdk.so: invalid ELF header
EAL: FATAL: Cannot init plugins
EAL: Cannot init plugins

// this is the error on System 2 (nearly the same but different library)
EAL: 
/usr/local/share/dpdk/x86_64-native-linuxapp-gcc/lib//librte_pmd_ark.a: invalid 
ELF header

EAL: FATAL: Cannot init plugins
EAL: Cannot init plugins


This would seem to indicate that something very horrible went wrong in 
the build or DPDK--creating ELF headers that aren't correct for the

 type of hardware they're being used on.

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

Re: [USRP-users] Error Testing UHD Build on E310 with uhd_usrp_probe

[Marcus D. Leech via USRP-users]

On 02/01/2021 04:01 PM, Dennis Trask via USRP-users wrote:


I am attempting to set up a development environment to write software 
for the E310 by cross-compiling on Ubuntu 18.04. I am using the 
instructions here: 
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source


I have followed all the instructions to build UHD and am now in the 
section "Mount and test the UHD build". When I run uhd_usrp_probe on 
the E310, I get the following ouput:


root@ni-e31x-3199693:~/newinstall# uhd_usrp_probe

-sh: /home/root/newinstall/usr/bin/uhd_usrp_probe: No such file or 
directory



If you do:

file /home/root/newinstall/usr/bin/uhd_usrp_probe

What do you get?

If you do:

which uhd_usrp_probe

What do you get?


I'm not sure where to look for the source of this issue. Has anyone 
else seen this or have an idea of what to look for?


Thanks,

Dennis



___
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] check if GPSDO is locked

[Marcus D. Leech via USRP-users]

On 01/29/2021 11:26 AM, Achilleas Anastasopoulos via USRP-users wrote:

HI all,

I am looking at an old N210 with a GPSDO and a GPS antenna connected.

Is there a uhd script or snippet of code (python) that I can use to 
probe the USRP and check if it has acquired lock from the GSP?


Any help would be appreciated.
thanks
Achilleas


If you look at the sync_to_gps example code, it probes the "gps_locked" 
sensor.





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

Re: [USRP-users] uhd4.0 and blocks with multiple ports

[Marcus D. Leech via USRP-users]

On 01/26/2021 12:33 AM, dario via USRP-users wrote:
Thanks for answering so quickly. The reason i posted here is that it's 
actually uhd which is complaining the topology is not compatible, not 
gnuradio. I can see that there are several blocks that have multiple 
in/out and i didn't realize phosphor now has different ports but i 
still don't understand what i could have done wrong to have such 
error. As i was mentioning the framework starts, writes registers of 
my block and then when committing topology it fails saying 
rfnoc::graph::detail node ... cannot handle its current topology!


Thanks,

Dario

Sorry, I missed that this was RFNOC.





 Messaggio originale 
Da: Aaron Rossetto via USRP-users 
Data: 25/01/21 23:28 (GMT+01:00)
A: USRP-users@lists.ettus.com
Oggetto: Re: [USRP-users] uhd4.0 and blocks with multiple ports

I agree that this question is more in the domain of GNURadio, but I do
want to point out that RFNoC 4.0 blocks most certainly can have
different numbers of inputs and outputs. A good example is the RFNoC
Fosphor block:

https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/lib/rfnoc/fosphor
https://github.com/EttusResearch/uhd/blob/master/host/include/uhd/rfnoc/blocks/fosphor.yml

The GR 3.8 support for this block (and other UHD 4.0 RFNoC blocks) is
in gr-ettus:

https://github.com/EttusResearch/gr-ettus/blob/master/grc/ettus_rfnoc_fosphor.block.yml

Best regards,
Aaron

On Mon, Jan 25, 2021 at 3:25 PM Marcus D Leech via USRP-users
 wrote:
>
> This is clearly a question for the discuss-gnuradio mailing list.
>
> Sent from my iPhone
>
> > On Jan 25, 2021, at 2:43 PM, dario via USRP-users 
 wrote:

> >
> > 
> > Hi,
> > I created a block with two output ports and one input port however 
when i try to connect it via stream endpoints gnuradio companion 
claims it doesn't know how to handle this. I then added a sexond inout 
as i recall that on uhd 3.15 it is necessary to have as many inputs as 
outputs but it gave back the same error now saying it doesn't know how 
to connect blocks with two inputs and two outputs.
> > I'm a bit confuse because it seems radio for example has two 
outputs however it is statically connected. Is it at all possible to 
have a dynamic connection of a block with multiple outputs? What is 
the possible reason why node manager reports it doesn't support this 
connection?

> >
> > Thanks,
> >
> > Dario
> >
> > ___
> > 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 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] uhd4.0 and blocks with multiple ports

[Marcus D Leech via USRP-users]

This is clearly a question for the discuss-gnuradio mailing list. 

Sent from my iPhone

> On Jan 25, 2021, at 2:43 PM, dario via USRP-users 
>  wrote:
> 
> 
> Hi,
> I created a block with two output ports and one input port however when i try 
> to connect it via stream endpoints gnuradio companion claims it doesn't know 
> how to handle this. I then added a sexond inout as i recall that on uhd 3.15 
> it is necessary to have as many inputs as outputs but it gave back the same 
> error now saying it doesn't know how to connect blocks with two inputs and 
> two outputs.
> I'm a bit confuse because it seems radio for example has two outputs however 
> it is statically connected. Is it at all possible to have a dynamic 
> connection of a block with multiple outputs? What is the possible reason why 
> node manager reports it doesn't support this connection?
> 
> Thanks,
> 
> Dario
> 
> ___
> 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] x3xx schematics incomplete

[Marcus D Leech via USRP-users]

I believe those pages cover the proprietary PCIE chip made by NI and are 
omitted deliberately. 

Sent from my iPhone

> On Jan 25, 2021, at 1:29 AM, 张忠山 via USRP-users  
> wrote:
> 
> x3xx.pdf should have 28 sheets, but only 23 is there.
> 
> sheet 13, 14 15, 16, 17 missing
> 
> Where can I find them?
> Or not provide these sheet? 
> 
> -- 
> Best Regards,
> zzs
> 
> 
> ___
> 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] N310 Tuning Two Channels with Two Threads

[Marcus D. Leech via USRP-users]

On 01/24/2021 03:08 PM, Glenn Hazelwood via USRP-users wrote:
Thanks for your replies. I only saw e-mail for the first reply, 
strangely. I saw the other replies from the daily digest.


I initially tried one thread with two channels with a 
set_rx_frequency() call for each and the tune time was roughly twice 
as much as one channel, one tune ( ~240 ms ).


I then tried the two channel two thread case with channel 0 and 1 and 
got a weird error about epsilon for difference between the new 
frequency compared to the 'previous' frequency? (Very rough 
paraphrase, sorry)


At first I was completely lost. But then I noticed that the error 
message had a path to the source file with the set_rx_frequency() 
function for the N310. The set_rx_frequency() function uses a mutex 
lock. That definitely blocks the other thread calling set_rx_frequency().


That means that even with two threads/two channels or even four 
threads/four channels it can only tune one channel at a time.


The fix for my error, was to use channel 0 and channel 2, not channel 
0 and channel 1. Channels 0 and 1 share an LO and Channels 2 and 3 
share an LO? The tune time was still double (~240 ms ) since only one 
channel could be tuned at a time.
That may be a hardware architecture thing--the AD9371 uses either an SPI 
or I2C interface for command and control (can't remember which),
   and there may only be one of those busses on the N310--I don't know 
for sure.  So you have to mutex access to that bus.


The AD936x and AD937x have an architecture where the two channels share 
an LO.  On the N310, there are *TWO* AD9371, giving
  a total of 4 channels, but with shared LO for 0,1  and 2,3.  But 
likely they share an I2C/SPI bus for command/control.  The main
  latency, however, is the time it takes for the chips to re-tune. The 
buses themselves are reasonably speedy, as far as I know--probably

  operating at 1Mbit.


I know that I cannot avoid the AD9731s taking ~120 ms to retune. I was 
hoping that I could at least do more tunings per 120 ms with multiple 
channels.


Maybe an X310 with the TwinRX daughterboards and something like in the 
examples:


https://github.com/EttusResearch/uhd/blob/master/host/examples/twinrx_freq_hopping.cpp

will work better?
Certainly more flexible, since there are various LO-sharing topologies 
available to you, depending on what you want to do.
  The underlying PLL synthesizers are likely much faster, but decidedly 
not "instant".  There's an inherent tension in PLL synthesizer
  design between residual phase-noise and tuning time.  Radios that do 
fast frequency hopping use specialized synthesizers that
  sacrifice some things to get very-fast hopping times.  But such 
synthesizers aren't really appropriate for a general-purpose

  radio.



--
Diftor heh smusma
-Famous Vulcan Phrase ;)

Previous Messages:

Rob Kossler rkossler at nd.edu <http://nd.edu>
Thu Jan 21 17:53:14 EST 2021

After reading Marcus' reply, it occurred to me that you really might not
need multiple threads to achieve the factor of 2 improvement you are
looking for.  I think if you call set_rx_freq() it is a non-blocking call
so you should be able to set the 2 freqs, wait for them both to settle,
then get the results simultaneously.  I think you can do it from 1 thread.
Rob

On Thu, Jan 21, 2021 at 4:01 PM Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com <http://lists.ettus.com>> wrote:

> On 01/21/2021 02:56 PM, Glenn Hazelwood via USRP-users wrote:
>
> I have an N310 and I wish to scan from 10 MHz to 5910 MHz with two
> channels. The frontend bandwidth is 100 MHz. So I do 60 tunings 
overall. I

> am directly using the UHD 3.15.0.0 C++ API
>
> The retune time is typically ~120 ms. My sample rate is 125 Msps.
> Therefore, the time to receive samples is relatively small. For example,
> receiving time for 32768 samples is ~1.3 ms. WIth one thread and one
> channel, my overall tune and receive time for the 60 tunings is 
~7200 ms.

>
> I wanted to try to reduce the overall runtime by using two threads 
and two
> channels. One thread would do half the tunings and the other thread 
would

> do the other half at the same time.
>
> I see that I can make separate rx_streamers in separate threads, 
each with

> its own channel to receive samples. I think rx_streamers[chan].recv()
> should work for two threads. I'm not so confident about
> 'usrp->set_rx_frequency()' for two threads.
>
> Is it possible to have two separate threads each tune to different
> frequencies at the same time with the N310?
>
> Also: Is there a way to search the Archives to see if someone has 
already

> asked this question. Google doesn't always seem to help.
>
> -
> Diftor heh smusma
> -Famous Vulcan Phrase ;)
>
> Tuning time is an artifact of the hardware (AD9371 in this case)--which
> isn't really fast on re-tuning.  It has

Re: [USRP-users] N310 Tuning Two Channels with Two Threads

[Marcus D. Leech via USRP-users]

On 01/21/2021 02:56 PM, Glenn Hazelwood via USRP-users wrote:
I have an N310 and I wish to scan from 10 MHz to 5910 MHz with two 
channels. The frontend bandwidth is 100 MHz. So I do 60 tunings 
overall. I am directly using the UHD 3.15.0.0 C++ API


The retune time is typically ~120 ms. My sample rate is 125 Msps. 
Therefore, the time to receive samples is relatively small. For 
example, receiving time for 32768 samples is ~1.3 ms. WIth one thread 
and one channel, my overall tune and receive time for the 60 tunings 
is ~7200 ms.


I wanted to try to reduce the overall runtime by using two threads and 
two channels. One thread would do half the tunings and the other 
thread would do the other half at the same time.


I see that I can make separate rx_streamers in separate threads, each 
with its own channel to receive samples. I think 
rx_streamers[chan].recv() should work for two threads. I'm not so 
confident about 'usrp->set_rx_frequency()' for two threads.


Is it possible to have two separate threads each tune to different 
frequencies at the same time with the N310?


Also: Is there a way to search the Archives to see if someone has 
already asked this question. Google doesn't always seem to help.


-
Diftor heh smusma
-Famous Vulcan Phrase ;)

Tuning time is an artifact of the hardware (AD9371 in this case)--which 
isn't really fast on re-tuning.  It has nothing to do with thread

  architecture/layout.

Further, channels 0 and 1 will always be tuned to the same RF frequency, 
due to the LO architecture of the AD9371, similarly 2 and 3 will

  always use the same LO frequency.


You can certainly spread sample-handling across multiple threads, and 
use the two available RF tunings (across the two RF chips) to speed
  things up a bit (cut the effective latency in half by interleaving).  
But you're not going to get more than a factor of two.



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

Re: [USRP-users] Overflow / Underflow Questions

[Marcus D. Leech via USRP-users]

On 01/20/2021 05:34 PM, Spam Blocker via USRP-users wrote:


We have an application that requires about 640Mbps of transmit and 
640Mbps of receive samples bandwidth.   We have a high performance 
Dell laptop hooked to a B205.


Questions:
1. Do the different versions of UHD support different throughput rates?
For the B2xx series, the different UHD versions will show only very 
minor difference in maximum achievable sample rates.
2. Are there maximum sample rates for the B205 that would restrict the 
throughput reaching the numbers we need.
The maximum sample rate of the B2xx is 56Msps in each direction, which 
means roughly 56MHz of bandwidth into and out of your
  application.  How that translates into *mbits* of data depends very 
very very much on your particular application, coding efficiency,
  modulation efficiency, channel characteristics, Eb/No, etc. That's up 
to you and your particular application, and whatever your

  compute platform can deliver.

The USRP SDRs don't inherently *know* anything about what you're doing 
*within* the bandwidth they dutifully transport back and forth.
  Higher order modulations and coding schemes take more compute power, 
so that's almost always your limiting factor.



3. Is there a receive and transmit throughput test that I can use to 
see what the maximum is for our platform?


Thanks
K-


There is the "benchmark_rate" test application that is usually located in:

/uhd/examples

This will give you an idea of what your computer can move back-and-forth 
between itself and the USRP, absent any additional load from

  doing anything "real" with those samples.

I would spend some time here:

https://kb.ettus.com/Knowledge_Base


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

Re: [USRP-users] tune speed ussue

[Marcus D Leech via USRP-users]

The problem is there are only a small number of calibration-cache registers, so 
managing that cache and having the cache management not ALSO contribute to 
latency issues is problematic. 

Sent from my iPhone

> On Jan 19, 2021, at 12:56 PM, David Evans via USRP-users 
>  wrote:
> 
> Hi all,
> I am not an expert on this, but recently speaking to someone a little more in 
> the know than I...
> Marcus is right, also it is apparently possible to pre-calibrate in advance 
> and save the calibration settings to registers on the AD9361, thus making the 
> tune time constant.
> Just a thought,
> Cheers,
> Dave
> 
> 
>> On 11/01/2021 13:32, Marcus D Leech via USRP-users wrote:
>> This is probably just a quirk of the way the calibrations cache works in the 
>> AD9361 chip.
>> 
>> The chip isn’t really designed for fast frequency hopping, and when you 
>> retune, internal recalibrations need to happen on the chip, except for small 
>> frequency changes.
>> 
>> 
>> Sent from my iPhone
>> 
>>>> On Jan 11, 2021, at 6:22 AM, Андрей А via USRP-users 
>>>>  wrote:
>>> 
>>> 
>>> Hello
>>> 
>>> I testing b200mini in receiver mode and found strange result with tune time 
>>> .
>>> When I start from 100MHz and tune with step 20MHz at freq 200 -> 220 and 
>>> 120 -> 100 get almost 100 times slowly time then others.
>>> When I start form 101MHz time increase only first pass and then all OK.
>>> 
>>> Source code and terminal screenshots in attachments.
>>> 
>>> Thank you
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Guaranteeing synchronous startup of X310 and N210

[Marcus D Leech via USRP-users]

That’s not likely to work. Given the different internal architectures of the 
two devices and different clicking schemes. 

For one the DDC architecture is different leading to different effective group 
delays. 



Sent from my iPhone

> On Jan 19, 2021, at 12:33 PM, Manav Kohli via USRP-users 
>  wrote:
> 
> 
> Dear USRP mailing list,
> 
> Hope everyone is well. I have a GNU radio flowgraph with a USRP N210 and USRP 
> X310 synchronized with the Octoclock. When starting the flowgraph, I can see 
> a random sample offset between the N210 and X310. As the two radios are 
> synchronized, the sample offset does not change for the duration of running 
> the flowgraph, but it is random every time the flowgraph is started. This is 
> not amenable to the time slotted system I am trying to work on.
> 
> I am aware that the X310 and N210 may not be simultaneously used in a USRP 
> Sink or USRP Source block (or in UHD, in a multi_usrp object). With this in 
> mind, is it even possible to guarantee that the X310 and N210 have the same 
> startup time, namely that they begin transmitting and receiving at exactly 
> the same time?
> 
> Thank you very much!
> Manav
> ___
> 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] Setting E320 to use fixed IP Address on RJ45 eth0

[Marcus D. Leech via USRP-users]

On 01/15/2021 04:06 AM, Mark D via USRP-users wrote:


Hi,

I’m trying to set an E320 USRP to use a fixed IP address on the RJ45 port.

I’ve tried following the instructions in the USRP Manual at 
https://files.ettus.com/manual/page_usrp_e3xx.html


The manual says that settings for the SFP+ port is stored in 
 /etc/systemd/networkd/sfp0.network.


My E320 doesn’t have that folder, there is one “/etc/systemd/network/” 
but no “/etc/systemd/networkd/” (i.e. no d after network). I think 
maybe  is a typing error in the manual and the folder name should be 
network.


The folder at this location is empty, so doesn’t contain the SFP+ 
setting file.


I have created in this folder a file eth0.network with the following 
content:


---

[Match]

Name=eth0

[Network]

Address=192.168.1.60



However this doesn’t seem to have any effect. When I use ifconfig to 
show the status of network connections eth0 is showing as 
“UP-BRAODACST RUNNING MULTICAST” but no IP address is set.


Any ideas on how I can set a fixed address?

Mark


I don't have one of these, but it seems like there's both an SFP port 
(for high-speed sample transport), and a "management" port with

  an ordinary RJ-45 connector.  Which one do you want to set?

Also, what does:

ifconfig


produce?  We want to get a list of the network interface names on the 
machine.



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

Re: [USRP-users] B210 TX from file of complex samples

[Marcus D. Leech via USRP-users]

On 01/15/2021 02:27 AM, Hai Nguyen via USRP-users wrote:

Hello,

I'm trying to transmit complex samples (e.g. BPSK chips) using B210 
and GNUradio. My flowgraph is very simple: A file source connected to 
a USRP sink (cpu format fc64), sample rate is 1e6. However the USRP 
seems not to transmit anything (no red light, and nothing on the 
spectrum) and also there is no error message. I tried with various 
gain values but still saw nothing.


I tried the same thing with an X310 and it worked fine. What would be 
the cause for the B210 and are there any ways I can make it work?


Thank you,
Hai

What does:

uhd_usrp_probe --args type=b200

GIve you?

What TX gain setting are you using?   The devices based on AD9361 have 
an unusually large gain-control range, going up to about 80dB.
  So if you're used to gain range stopping at 31.5dB, you'll be "low" 
by about 50dB.


What frequency?   The B210 can tune from about 70Mhz to 6GHz.


m 



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

Re: [USRP-users] E312 Battery Question

[Marcus D Leech via USRP-users]

As long as it had power it will run fine without the battery as far as I know. 

Sent from my iPhone

> On Jan 14, 2021, at 12:20 PM, David Scott via USRP-users 
>  wrote:
> 
> 
> Hi all,
> 
> 
> 
> I need to carry out some development and testing with the USRP E312 for work 
> in the lab. However, due to the lockdown in the UK I am not able to 
> physically get to the device except for some initial setting up (network 
> etc.).
> 
> 
> 
> I know that the device should not be plugged in for more than 24 hours so I 
> am wondering if it is possible to run the device with the battery 
> disconnected? 
> 
> Will the E312 function without the battery connected internally? And are 
> their any snags I should be aware of?
> 
> 
> 
> Many Thanks,
> 
> David
> 
> 
> 
> P Please consider the environment before printing this e-mail. 
> ___
> 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] Changing the transmitted samples per packet

[Marcus D Leech via USRP-users]

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


Sent from my iPhone

> On Jan 13, 2021, at 11:51 AM, Ephraim Moges via USRP-users 
>  wrote:
> 
> 
> Good morning,
> 
> Is their a simple command like tx_streamer.get_max_num_samps that sets the 
> maximum number samples per packet?
> 
> Thank you,
> 
> Moges
> ___
> 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] USRP sample rate and bandwidth

[Marcus D. Leech via USRP-users]

On 01/13/2021 01:08 AM, Koyel Das (Vehere) via USRP-users wrote:

Hi,

The USRP sample rate and bandwidth are two different parameters in 
gnuradio so if I want 20 MHz bandwidth and 100 MSps sample rate then 
will setting bandwidth = 20 MHz and sample rate = 100 MHz serve my 
purpose? Normally sample rate (100 MHz in this case) is the bandwidth 
unless filter is used so does that mean USRP is filtering out 20 MHz 
keeping sample rate at 100 MHz by itself?


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com //
Indeed, FOR HARDWARE WITH VARIABLE BANDWIDTH, this parameter sets the 
analog filter bandwidth ahead of the ADC.


Many hardware configurations, however, have fixed analog bandwidth ahead 
of the ADC, and this parameter setting will do

  nothing in those situations.

Hardware based on the AD9361 or AD9371 (USRP B2xx, USRP N3xx, USRP E31x) 
has this control, as do some of the older

  daughtercards--DBSRX2, TVRX2.


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

Re: [USRP-users] Spectrum analyzer not picking received signal from USRP-GNU Radio

[Marcus D Leech via USRP-users]

Your description is insufficient in detail for anyone to give you any advice at 
all.  

The USRP does not transmit from
It’s RX2 input, so I’m not sure what you expect to see on your spectrum 
analyzer. 

You haven’t said exactly how and what you’re transmitting—what tools and 
applications, nor how they’re configured. 

Sent from my iPhone

> On Jan 12, 2021, at 1:25 PM, AKINYELE ITAMAKINDE via USRP-users 
>  wrote:
> 
> 
> Hello,
> I collected  spectrum analyzer RF input to Rx2 of the USRP, I was able to 
> obtain the Tx power and Bandwidth of Tx signal. At the Rx end, I also 
> connected the antenna to the Rx1/Tx1, and Rx2 to the RF input of the spectrum 
> analyzer, but Spectrum analyzer was not picking the received signal. What 
> could be the problem?
> Thanks.
> Akinyele
> ___
> 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] UHD_STREAM_MODE_NUM_SAMPS_AND_DONE

[Marcus D. Leech via USRP-users]

On 01/11/2021 10:11 AM, Андрей А via USRP-users wrote:

Hello

Is threre need set num_samps field in uhd_stream_cmd_t when
stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE
and
stream_now = true?

Thank you.



Yes, I believe so.


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

Re: [USRP-users] tune speed ussue

[Marcus D Leech via USRP-users]

This is probably just a quirk of the way the calibrations cache works in the 
AD9361 chip. 

The chip isn’t really designed for fast frequency hopping, and when you retune, 
internal recalibrations need to happen on the chip, except for small frequency 
changes.


Sent from my iPhone

> On Jan 11, 2021, at 6:22 AM, Андрей А via USRP-users 
>  wrote:
> 
> 
> Hello 
> 
> I testing b200mini in receiver mode and found strange result with tune time .
> When I start from 100MHz and tune with step 20MHz at freq 200 -> 220 and 120 
> -> 100 get almost 100 times slowly time then others.
> When I start form 101MHz time increase only first pass and then all OK.
> 
> Source code and terminal screenshots in attachments.
> 
> Thank you
> 
> 
> 
> 
> ___
> 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] Transmit underruns

[Marcus D. Leech via USRP-users]

On 01/09/2021 03:50 PM, Barry Duggan via USRP-users wrote:

Hi Ron,

Thank you for your test flowgraph. It works fine when using the wav 
file, BUT when I change to an Audio Source block (mic) I get the 
underruns. So I still have the problem. I've experimented with various 
sizes of 'send_buff_size' and I even put in a Fractional Resampler to 
raise the interpolation factor above the theoretical value.


I am now running on Ubuntu 20.04 and GRC 3.8.2.0

Any further suggestions?

Thanks,
Barry Duggan KV4FV

---

On Tue Jan 5 20:33:24 EST 2021, Ron Economos wrote:

Here's an ssb flow graph that's known to work. You can select the
sideband with the default option of the QT GUI Chooser block before you
start the flow graph (you can't change filter taps on the fly).

The test file is here.

http://www.w6rz.net/ssbaudio.wav

Ron

On 1/5/21 15:29, Barry Duggan via USRP-users wrote:
> Ubuntu 20.10
> GRC 3.9.0.RC0
> UHD 4.0
> B200mini
> USRP_ssb_xmt.grc - https://pastebin.com/ypyERUGE
>
> I have experimented with various combinations of send_buff_size and
> send_frame_size but continue to get underruns while transmitting. I've
> also tried setting the Audio Source 'OK to Block' to 'Yes' and to
> 'No'. What is the right combination of parameters to minimize or
> eliminate the underruns?
>
> Thanks for your help!
>
> 73,
> ---
> Barry Duggan KV4FV
> https://github.com/duggabe
>

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
You're probably running into the "two clock" problem.  Without any kind 
of "smart" elastic buffer between two pieces of hardware with

  different clocks, this problem is *guaranteed* to occur at some point.

Further, things like pulseaudio will sometimes (in my experience) only 
do a half-hearted job of sample-rate conversion for audiohardware that
  doesn't support the requested sample rate, which means that samples 
aren't actually being delivered at close-enough to the requested rate

  to "survive" the rigors of the two-clock problem.



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

Re: [USRP-users] X310/UBX as a monostatic transceiver (e.g. RFID reader)?

[Marcus D Leech via USRP-users]

Indeed, a 900Mhz duplexor with a 400Khz split is an extreme challenge. 

If the TX and RX really do need to operate at the same time on more or less the 
same frequency, then you have some plumbing to do for sure. 

Sent from my iPhone

> On Jan 5, 2021, at 12:07 AM, Marcus D Leech  wrote:
> 
> To do a little expectation-setting, the narrowband MDS of a modern, not that 
> spectacular, UHF RX chain of better than -140dBm is not that unusual. So when 
> I talk about a sensitive RX chain, I’m talking about those sorts of levels.
> 
> In that kind of context, -24dBm seems deafeningly loud, and -80dBm seems kind 
> of normal. One must of course make adjustments for PSD and decide what 
> constitutes “narrowband”.
> 
> Sent from my iPhone
> 
>> On Jan 4, 2021, at 11:49 PM, Marcus D Leech  wrote:
>> 
>> If the TX and RX frequencies are a few 100kHz different then what you want 
>> is a duplexor arrangement where the TX frequency is strongly attenuated 
>> ahead of the RX. 
>> 
>> This is how repeaters work when multicoipled to a single antenna. The TX 
>> frequency is often attenuated 90dB in the RX path. 
>> 
>> 
>> 
>> Sent from my iPhone
>> 
 On Jan 4, 2021, at 11:33 PM, Lukas Haase  wrote:
>>> 
>>> Hi Marcus,
>>> 
> On 01/04/2021 12:25 PM, Lukas Haase wrote:
 In an RFID system, the RX is *designed* to be up-close-and-snugly with
 the other ends TX.  There's NO reason to have an input
 stage that is sensitive in the usual RF sense.  So, completely
 different engineering goals than in a typical RF system.
>>> 
>>> That's not quite true. Sensitivity *is* important (in the RF sense) because 
>>> it defines operating distance.
>>> Yes, many people claim RFID systems are forward link limited (which was 
>>> true) but state-of-the art tags can have a sensivivity of -24dBm which 
>>> corresponds to over 20m free space, 900 MHz.
>>> The response from the tag at the reader is around -80dBm. The R2000 chip 
>>> that I mentioned has a sensitivity in excess of that.
>>> 
>>> Indeed, this is the reason why *sensitivity* (due to self interference) is 
>>> the limiting factor in RFID.
>>> 
> I have thought of a limiter already. This could be an option.
> It's true, I haven't found limiters with lower power levels.
> 
> Two questions here:
> 
> - How/why would they add to the noise figure?
 Any limiter diode has shunt capacitance.  Which means that the degree to
 which input power is shunted to ground is proportional
 to the input frequency and shunt capacitance.   ANY attenuation
 (whether resistive dissipation or shunt-to-ground pathways) in
 front of the first gain stage adds *DIRECTLY* to the noise figure of
 that stage.   So, let's say you have a nice small-signal LNA with
 a notional noise figure of 0.5dB, and you put 10dB of loss in front
 of it--the noise figure now becomes 10.5dB.  For RFID type applications
 this doesn't matter that much--see my "up close and snugly"
 comments.But for "ordinary" RF receive chains, you generally want
 to minimize noise figure while maximizing gain and linearity.
 
 There are exceptions--for example at HF (below 30MHz or so), the input
 noise is *utterly dominated* by galactic background noise and
 atmospherics--there's no point in having an input stage with a noise
 figure below perhaps 5-10dB.  So for HF, input stages tend to
 be optimized for linearity at higher input levels--because even
 distant signals can be quite strong at HF--particularly on the lower end.
 
> - The large self-interfere would result in clipping (hard 
> nonlinearities). Is this any problem for the LNA (gain desensitivisation 
> etc.)
 Well.  Yeah.  That's what the P1dB parameter is all about--the input
 level at which gain is compressed by 1dB.
 
 The overall take-away here is that generic radios (whether they be SDRs
 or others) should be thought of as *components* in an
 overall *engineered RF system*.   That may mean things like relays to
 shunt the RX pathway during TX, circulators, attenuators,
 diplexors, filters, RF-plumbing-in-general.
>>> 
>>> Yes.
>>> 
>>> To clarify limiter vs non-limiter.
>>> My self interfering signal from TX can be up to 20-25dBm. The desired 
>>> signal is a modulation bandwidth (few 100 kHz) away and the receiver should 
>>> be as sensitive as possible to that signal.
>>> 
>>> Now I have the two options:
>>> 
>>> 1.) Adding a normal attenuator of 40dB. This ensures the USRP input is 
>>> always less than 25-40=-15dBm but it also reduces my desired signal by 
>>> 40dB. In other wirds, my noise figure worsens by 40dB, as you mentioned.
>>> 
>>> 2.) Adding an RF limiter with flat leakage +5dBm (I found SKY16602-632LF). 
>>> Afterwards I add a 20dB attenuator to get the max to 5-20=-15dBm.
>>> 
>>> If I understand your explanation correctly, there is no real difference 
>>> between these two (because the 

Re: [USRP-users] X310/UBX as a monostatic transceiver (e.g. RFID reader)?

[Marcus D Leech via USRP-users]

To do a little expectation-setting, the narrowband MDS of a modern, not that 
spectacular, UHF RX chain of better than -140dBm is not that unusual. So when I 
talk about a sensitive RX chain, I’m talking about those sorts of levels.

In that kind of context, -24dBm seems deafeningly loud, and -80dBm seems kind 
of normal. One must of course make adjustments for PSD and decide what 
constitutes “narrowband”.

Sent from my iPhone

> On Jan 4, 2021, at 11:49 PM, Marcus D Leech  wrote:
> 
> If the TX and RX frequencies are a few 100kHz different then what you want 
> is a duplexor arrangement where the TX frequency is strongly attenuated ahead 
> of the RX. 
> 
> This is how repeaters work when multicoipled to a single antenna. The TX 
> frequency is often attenuated 90dB in the RX path. 
> 
> 
> 
> Sent from my iPhone
> 
>> On Jan 4, 2021, at 11:33 PM, Lukas Haase  wrote:
>> 
>> Hi Marcus,
>> 
 On 01/04/2021 12:25 PM, Lukas Haase wrote:
>>> In an RFID system, the RX is *designed* to be up-close-and-snugly with
>>> the other ends TX.  There's NO reason to have an input
>>>  stage that is sensitive in the usual RF sense.  So, completely
>>> different engineering goals than in a typical RF system.
>> 
>> That's not quite true. Sensitivity *is* important (in the RF sense) because 
>> it defines operating distance.
>> Yes, many people claim RFID systems are forward link limited (which was 
>> true) but state-of-the art tags can have a sensivivity of -24dBm which 
>> corresponds to over 20m free space, 900 MHz.
>> The response from the tag at the reader is around -80dBm. The R2000 chip 
>> that I mentioned has a sensitivity in excess of that.
>> 
>> Indeed, this is the reason why *sensitivity* (due to self interference) is 
>> the limiting factor in RFID.
>> 
 I have thought of a limiter already. This could be an option.
 It's true, I haven't found limiters with lower power levels.
 
 Two questions here:
 
 - How/why would they add to the noise figure?
>>> Any limiter diode has shunt capacitance.  Which means that the degree to
>>> which input power is shunted to ground is proportional
>>>  to the input frequency and shunt capacitance.   ANY attenuation
>>> (whether resistive dissipation or shunt-to-ground pathways) in
>>>  front of the first gain stage adds *DIRECTLY* to the noise figure of
>>> that stage.   So, let's say you have a nice small-signal LNA with
>>>  a notional noise figure of 0.5dB, and you put 10dB of loss in front
>>> of it--the noise figure now becomes 10.5dB.  For RFID type applications
>>>  this doesn't matter that much--see my "up close and snugly"
>>> comments.But for "ordinary" RF receive chains, you generally want
>>>  to minimize noise figure while maximizing gain and linearity.
>>> 
>>> There are exceptions--for example at HF (below 30MHz or so), the input
>>> noise is *utterly dominated* by galactic background noise and
>>>  atmospherics--there's no point in having an input stage with a noise
>>> figure below perhaps 5-10dB.  So for HF, input stages tend to
>>>  be optimized for linearity at higher input levels--because even
>>> distant signals can be quite strong at HF--particularly on the lower end.
>>> 
 - The large self-interfere would result in clipping (hard nonlinearities). 
 Is this any problem for the LNA (gain desensitivisation etc.)
>>> Well.  Yeah.  That's what the P1dB parameter is all about--the input
>>> level at which gain is compressed by 1dB.
>>> 
>>> The overall take-away here is that generic radios (whether they be SDRs
>>> or others) should be thought of as *components* in an
>>>  overall *engineered RF system*.   That may mean things like relays to
>>> shunt the RX pathway during TX, circulators, attenuators,
>>>  diplexors, filters, RF-plumbing-in-general.
>> 
>> Yes.
>> 
>> To clarify limiter vs non-limiter.
>> My self interfering signal from TX can be up to 20-25dBm. The desired signal 
>> is a modulation bandwidth (few 100 kHz) away and the receiver should be as 
>> sensitive as possible to that signal.
>> 
>> Now I have the two options:
>> 
>> 1.) Adding a normal attenuator of 40dB. This ensures the USRP input is 
>> always less than 25-40=-15dBm but it also reduces my desired signal by 40dB. 
>> In other wirds, my noise figure worsens by 40dB, as you mentioned.
>> 
>> 2.) Adding an RF limiter with flat leakage +5dBm (I found SKY16602-632LF). 
>> Afterwards I add a 20dB attenuator to get the max to 5-20=-15dBm.
>> 
>> If I understand your explanation correctly, there is no real difference 
>> between these two (because the limiter would still crushes signal and with 
>> it desensitizes the desired signal on top).
>> Is this correct?
>> 
>> Would you prefer one option over the other?
>> 
>> Thanks again,
>> Lukas
>> 
>> 

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

Re: [USRP-users] X310/UBX as a monostatic transceiver (e.g. RFID reader)?

[Marcus D Leech via USRP-users]

If the TX and RX frequencies are a few 100kHz different then what you want is a 
duplexor arrangement where the TX frequency is strongly attenuated ahead of the 
RX. 

This is how repeaters work when multicoipled to a single antenna. The TX 
frequency is often attenuated 90dB in the RX path. 



Sent from my iPhone

> On Jan 4, 2021, at 11:33 PM, Lukas Haase  wrote:
> 
> Hi Marcus,
> 
>> On 01/04/2021 12:25 PM, Lukas Haase wrote:
>> In an RFID system, the RX is *designed* to be up-close-and-snugly with
>> the other ends TX.  There's NO reason to have an input
>>   stage that is sensitive in the usual RF sense.  So, completely
>> different engineering goals than in a typical RF system.
> 
> That's not quite true. Sensitivity *is* important (in the RF sense) because 
> it defines operating distance.
> Yes, many people claim RFID systems are forward link limited (which was true) 
> but state-of-the art tags can have a sensivivity of -24dBm which corresponds 
> to over 20m free space, 900 MHz.
> The response from the tag at the reader is around -80dBm. The R2000 chip that 
> I mentioned has a sensitivity in excess of that.
> 
> Indeed, this is the reason why *sensitivity* (due to self interference) is 
> the limiting factor in RFID.
> 
>>> I have thought of a limiter already. This could be an option.
>>> It's true, I haven't found limiters with lower power levels.
>>> 
>>> Two questions here:
>>> 
>>> - How/why would they add to the noise figure?
>> Any limiter diode has shunt capacitance.  Which means that the degree to
>> which input power is shunted to ground is proportional
>>   to the input frequency and shunt capacitance.   ANY attenuation
>> (whether resistive dissipation or shunt-to-ground pathways) in
>>   front of the first gain stage adds *DIRECTLY* to the noise figure of
>> that stage.   So, let's say you have a nice small-signal LNA with
>>   a notional noise figure of 0.5dB, and you put 10dB of loss in front
>> of it--the noise figure now becomes 10.5dB.  For RFID type applications
>>   this doesn't matter that much--see my "up close and snugly"
>> comments.But for "ordinary" RF receive chains, you generally want
>>   to minimize noise figure while maximizing gain and linearity.
>> 
>> There are exceptions--for example at HF (below 30MHz or so), the input
>> noise is *utterly dominated* by galactic background noise and
>>   atmospherics--there's no point in having an input stage with a noise
>> figure below perhaps 5-10dB.  So for HF, input stages tend to
>>   be optimized for linearity at higher input levels--because even
>> distant signals can be quite strong at HF--particularly on the lower end.
>> 
>>> - The large self-interfere would result in clipping (hard nonlinearities). 
>>> Is this any problem for the LNA (gain desensitivisation etc.)
>> Well.  Yeah.  That's what the P1dB parameter is all about--the input
>> level at which gain is compressed by 1dB.
>> 
>> The overall take-away here is that generic radios (whether they be SDRs
>> or others) should be thought of as *components* in an
>>   overall *engineered RF system*.   That may mean things like relays to
>> shunt the RX pathway during TX, circulators, attenuators,
>>   diplexors, filters, RF-plumbing-in-general.
> 
> Yes.
> 
> To clarify limiter vs non-limiter.
> My self interfering signal from TX can be up to 20-25dBm. The desired signal 
> is a modulation bandwidth (few 100 kHz) away and the receiver should be as 
> sensitive as possible to that signal.
> 
> Now I have the two options:
> 
> 1.) Adding a normal attenuator of 40dB. This ensures the USRP input is always 
> less than 25-40=-15dBm but it also reduces my desired signal by 40dB. In 
> other wirds, my noise figure worsens by 40dB, as you mentioned.
> 
> 2.) Adding an RF limiter with flat leakage +5dBm (I found SKY16602-632LF). 
> Afterwards I add a 20dB attenuator to get the max to 5-20=-15dBm.
> 
> If I understand your explanation correctly, there is no real difference 
> between these two (because the limiter would still crushes signal and with it 
> desensitizes the desired signal on top).
> Is this correct?
> 
> Would you prefer one option over the other?
> 
> Thanks again,
> Lukas
> 
> 

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

Re: [USRP-users] X310/UBX as a monostatic transceiver (e.g. RFID reader)?

[Marcus D. Leech via USRP-users]

On 01/04/2021 12:25 PM, Lukas Haase wrote:

In an RFID system, the RX is *designed* to be up-close-and-snugly with 
the other ends TX.  There's NO reason to have an input
  stage that is sensitive in the usual RF sense.  So, completely 
different engineering goals than in a typical RF system.


I have thought of a limiter already. This could be an option.
It's true, I haven't found limiters with lower power levels.

Two questions here:

- How/why would they add to the noise figure?
Any limiter diode has shunt capacitance.  Which means that the degree to 
which input power is shunted to ground is proportional
  to the input frequency and shunt capacitance.   ANY attenuation 
(whether resistive dissipation or shunt-to-ground pathways) in
  front of the first gain stage adds *DIRECTLY* to the noise figure of 
that stage.   So, let's say you have a nice small-signal LNA with
  a notional noise figure of 0.5dB, and you put 10dB of loss in front 
of it--the noise figure now becomes 10.5dB.  For RFID type applications
  this doesn't matter that much--see my "up close and snugly" 
comments.But for "ordinary" RF receive chains, you generally want

  to minimize noise figure while maximizing gain and linearity.

There are exceptions--for example at HF (below 30MHz or so), the input 
noise is *utterly dominated* by galactic background noise and
  atmospherics--there's no point in having an input stage with a noise 
figure below perhaps 5-10dB.  So for HF, input stages tend to
  be optimized for linearity at higher input levels--because even 
distant signals can be quite strong at HF--particularly on the lower end.



- The large self-interfere would result in clipping (hard nonlinearities). Is 
this any problem for the LNA (gain desensitivisation etc.)
Well.  Yeah.  That's what the P1dB parameter is all about--the input 
level at which gain is compressed by 1dB.


The overall take-away here is that generic radios (whether they be SDRs 
or others) should be thought of as *components* in an
  overall *engineered RF system*.   That may mean things like relays to 
shunt the RX pathway during TX, circulators, attenuators,

  diplexors, filters, RF-plumbing-in-general.


Thanks,
Lukas





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

Re: [USRP-users] X310/UBX as a monostatic transceiver (e.g. RFID reader)?

[Marcus D. Leech via USRP-users]

On 01/03/2021 07:17 PM, Lukas Haase via USRP-users wrote:

Hi,

I would like to use an X310 with UBX in a monostatic antenna configuration 
(same frequency range). This is for example common in RFID readers.

My transmit power is 30dBm (ZHL-25W-272+ after the USRP), fed into a 6dBi 
antenna.

Now if I use a circulator, I find isolation of around 15dB (e.g. 
https://www.everythingrf.com/products/rf-microwave-circulators/mesa-microwave/769-185-mmccc700a).
 This means my RX input sees 15dBm. Stupidly, the UBX datasheet wants a maximum 
input signal of -15dBm. So it's 30dB too strong!

Alternatively, I could use a directional coupler. However, the directivity is 
typically around 20dB (e.g. 
https://www.everythingrf.com/products/directional-couplers/rf-lambda/45-89-rfdc8m3g10d)
 which brings me to +10dBm at the RX input. If I assume directivity is not an 
issue, the signal at RX is limited by the S11 of the antenna (typically 15dB). 
With 10dB of coupling: 30dBm-15dB-10dB=5dBm. Still too high and a incurs a 10dB 
noise figure penalty.

As another option, I could add 30dB attenuator after the circulator. But this 
results in an unacceptable 30dB noise figure penalty.

Do I understand anything wrong or is a monostatic TRX just not possible with 
USRP?


It's not even *slightly* "stupid".   An RX front-end that is sensitive 
enough to connect directly to an antenna and be able to receive low signal
  levels (typical of over-the-air work) CANNOT have excessive input 
power.  If it does, the coupla-molecules-layer-thick gate layer in the
  input amplifier transistor will simply cease to exist.  This is not 
peculiar to USRPs--ALL over-the-air receivers designed to be sensitive in
  the VHF bands and above have this problem.   You can put in limiter 
diodes, but such diodes are usually "limited" to a lowest power level
  of perhaps +5dBm, and will inherently add to the noise-figure of the 
RX chain.


If you're operating at frequencies below perhaps 100MHz, you can simply 
put +10dB attenuation in-line with your RX chain, improving
  the TX/RX isolation by that amount.  Ettus quotes -15dBm because 
several of the USRP devices have front-ends that don't want more than
  -15dBm at the input terminal--some of them are more robust, by about 
10dB or so.  But it's just a "prudent" level for a receiver intended
  for over-the-air work.  In normal situations, a signal of -15dBm at 
the input terminals to the reciever is "barn burner" loud, and as I 
indicated
  for receive amplifiers, as you go much about -10dBm input power, 
there's a risk of damaging the 1st-stage input amplifier.  That's just the

  nature of VHF/UHF small-signal transistors.



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

Re: [USRP-users] Hacking E310 units for synchronization

[Marcus D Leech via USRP-users]

UHD has always been a very generic device API—necessarily so due to the large 
variety of hardware types in the USRP “line up”. 

Having said that there’s nothing that prevents you from diving into the code on 
both the software and FPGA side to create and expose whatever you want. 

Sent from my iPhone

> On Jan 3, 2021, at 1:23 PM, Ofer Saferman via USRP-users 
>  wrote:
> 
> 
> Hello Marcus,
> 
> Thank you for your reply.
> 
> Is there support today in software for direct register writes to the AD9361 
> device for the E310?
> If there is, I think I can use SYNC and a modified firmware to implement 
> Multi-chip synchronization.
> 
> Regards,
> Ofer Saferman
> 
>> On Sun, Jan 3, 2021 at 7:00 PM  wrote:
>> -- Forwarded message --
>> From: "Marcus D. Leech" 
>> To: usrp-users@lists.ettus.com
>> Cc: 
>> Bcc: 
>> Date: Sat, 02 Jan 2021 15:18:06 -0500
>> Subject: Re: [USRP-users] Hacking E310 units for synchronization
>> On 01/02/2021 02:44 AM, Ofer Saferman via USRP-users wrote:
>> > Hello,
>> >
>> > I must say that I am a bit frustrated.
>> > When I purchased multiple E310 units it was with the hope I will be 
>> > able to synchronize them mainly based on: 
>> > https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices,
>> >  
>> > it shows the E310 as MIMO capable and having a reference clock input.
>> > Of course, now I know that not to be true. At least the reference 
>> > clock part. It seems that the MIMO part might be incorrect as well.
>> >
>> > If I hack the clock and patch an external clock connector to be used 
>> > instead of the internal TCXO will I be able, using existing UHD 
>> > software and firmware, to synchronize multiple E310 units?
>> >
>> > I will be able to provide a common clock to multiple units and I will 
>> > be able to provide a 1-PPS signal through the SYNC pins of multiple 
>> > units that is generated from the same common clock.
>> > I need these E310 to transmit and have their base-band samples 
>> > perfectly time aligned.
>> >
>> > How is multi-chip synchronization of the AD9361 devices being done by 
>> > UHD? By using the SYNC pin and setting 
>> > usrp->set_time_source("external")? Is it enough? Do I need to handle 
>> > it on my own? How?
>> >
>> > I figured the internal TCXO frequency of E310 is 40 MHz. Can I provide 
>> > an external clock of different frequency? Maybe 10 MHz? Or does it 
>> > require a major change in software or firmware?
>> >
>> > Does anybody have a different idea how to get E310 units synchronized 
>> > at sample level without voiding the warranty and hacking an external 
>> > clock?
>> >
>> > Please help.
>> >
>> > Regards,
>> > Ofer Saferman
>> >
>> >
>> The E310 was never designed for multi-unit MIMO, although it does 2x2 
>> MIMO just fine, and there are plenty of folks using it for that,
>>including stacks for various wireless protocols.  The AD9361 
>> inherently supports 2x2 MIMO due to the shared LO architecture between
>>the two TX and two RX channels.
>> 
>> The AD9361 SYNC_IN pin does get tied to the Zynq FPGA, but the UHD 
>> code-base doesn't use it.I'll note that for most telecom-type
>>MIMO implementations, zero-phase-offset is NOT a requirement, just 
>> ongoing phase coherence.
>> 
>> Similarly the B2xx series does 2x2 MIMO just fine, but it was never 
>> designed for multi-unit MIMO, although due to the clocking architecture,
>>the B2xx could likely (no guarantees) be made to do a multi-unit MIMO 
>> implementation.
>> 
>> The SYNC input connector on the E310 is designed to:
>> 
>>(A) Provide a higher longer-term quality than the on-board clock.
>>(B) Allow for TDM synchronization on system deployments where that is 
>> important.
>> 
>> Due to the high residual phase-noise of the DPLL implementation on the 
>> SYNC input on the E310, it cannot be used to produce a working
>>multi-unit MIMO (or any other kind of phase-coherent) application.
>  
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. ___
> 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] implementation of member functions in gnuradio blocks

[Marcus D. Leech via USRP-users]

On 01/02/2021 08:55 PM, Linda20071 via USRP-users wrote:



  I installed gnuradio from source via "gitclone" command. Thus, I
  would assume all the source files


  should be in my computer. However, I am able to find
  mpsk_receiver_cc.h, but not its


  implementation: mpsk_receiver_cc.cc. I am interested in taking a
  look at the implementation


  of a member function mpsk_receiver_cc(...).


Does this mean some function implementations are intentionally hidden 
by the software company? Is there a way to pull this .cc file out?


MATLAB makes all its implementations accessible to its users, which is 
very convenient.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This is the kind of question that is best targetted at the 
discuss-gnuradio mailing list, rather than here.


But this issue-tracker issue probably explains what you're seeing:

https://github.com/gnuradio/gnuradio/issues/1083


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

Re: [USRP-users] Hacking E310 units for synchronization

[Marcus D. Leech via USRP-users]

On 01/02/2021 02:44 AM, Ofer Saferman via USRP-users wrote:

Hello,

I must say that I am a bit frustrated.
When I purchased multiple E310 units it was with the hope I will be 
able to synchronize them mainly based on: 
https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices, 
it shows the E310 as MIMO capable and having a reference clock input.
Of course, now I know that not to be true. At least the reference 
clock part. It seems that the MIMO part might be incorrect as well.


If I hack the clock and patch an external clock connector to be used 
instead of the internal TCXO will I be able, using existing UHD 
software and firmware, to synchronize multiple E310 units?


I will be able to provide a common clock to multiple units and I will 
be able to provide a 1-PPS signal through the SYNC pins of multiple 
units that is generated from the same common clock.
I need these E310 to transmit and have their base-band samples 
perfectly time aligned.


How is multi-chip synchronization of the AD9361 devices being done by 
UHD? By using the SYNC pin and setting 
usrp->set_time_source("external")? Is it enough? Do I need to handle 
it on my own? How?


I figured the internal TCXO frequency of E310 is 40 MHz. Can I provide 
an external clock of different frequency? Maybe 10 MHz? Or does it 
require a major change in software or firmware?


Does anybody have a different idea how to get E310 units synchronized 
at sample level without voiding the warranty and hacking an external 
clock?


Please help.

Regards,
Ofer Saferman


The E310 was never designed for multi-unit MIMO, although it does 2x2 
MIMO just fine, and there are plenty of folks using it for that,
  including stacks for various wireless protocols.  The AD9361 
inherently supports 2x2 MIMO due to the shared LO architecture between

  the two TX and two RX channels.

The AD9361 SYNC_IN pin does get tied to the Zynq FPGA, but the UHD 
code-base doesn't use it.I'll note that for most telecom-type
  MIMO implementations, zero-phase-offset is NOT a requirement, just 
ongoing phase coherence.


Similarly the B2xx series does 2x2 MIMO just fine, but it was never 
designed for multi-unit MIMO, although due to the clocking architecture,
  the B2xx could likely (no guarantees) be made to do a multi-unit MIMO 
implementation.


The SYNC input connector on the E310 is designed to:

  (A) Provide a higher longer-term quality than the on-board clock.
  (B) Allow for TDM synchronization on system deployments where that is 
important.


Due to the high residual phase-noise of the DPLL implementation on the 
SYNC input on the E310, it cannot be used to produce a working

  multi-unit MIMO (or any other kind of phase-coherent) application.



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

Re: [USRP-users] USRP B210 UHD library installation issue

[Marcus D. Leech via USRP-users]

On 12/31/2020 04:49 PM, Ashutosh Singh wrote:

Hi Marcus,
I tried tha as well but i think adding PPA repo is the onlY way to go 
(many UHD dependencies get solved by adding PPA repo and because of 
that some issues won't occur LATER while running the binary. Issues 
occurring about uhd library shared_ptr and all):



I am not able to compile my binary on one system but its working fine 
on another system:



root@yy217925:/home/lab_5g/LTE-D2D/cmake_targets# *./build_oai -I
--UE*
Will install external packages
Will compile UE
CMAKE_CMD=cmake ..
RF HW set to None
Flags for Deadline scheduler: False
Flags for CPU Affinity: False
2. Setting the OAI PATHS ...
OPENAIR_DIR= /home/lab_5g/LTE-D2D
FreeDiameter prefix not found, install freeDiameter if EPC, HSS
Installing packages
Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease
Hit:6 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease
Ign:5 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic InRelease
Err:7 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic Release
  404  Not Found [IP: 23.253.215.39 443]
Reading package lists... Done
E: The repository
'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.
build have failed




Please help!!


This looks like a problem with the way OAI tries to build itself.  I 
don't use that stack myself, so I can't really help.


There are perhaps others on here with OAI experience.

I'll note that using the standard-repo provided UHD + friends seems to 
work fine for me for various test applications and Gnu Radio
  applications, so your issue is mostly because the OAI build insists 
on that PPA, and the PPA is currently unavailable.



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

Re: [USRP-users] USRP B210 UHD library installation issue

[Marcus D. Leech via USRP-users]

On 12/30/2020 03:54 PM, Ashutosh Singh wrote:

Any update over it !!

I'll point out that unless you need the latest UHD, Ubuntu 18.04 
(Bionic) packages UHD already--


sudo apt-get install libuhd*

Should do the trick without requiring the PPA.




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

Re: [USRP-users] USRP B210 UHD library installation issue

[Marcus D Leech via USRP-users]

Ettus R are aware of the issue. But it being Christmas break there likely 
won’t be any action for a couple of days. 



Sent from my iPhone

> On Dec 30, 2020, at 3:54 PM, Ashutosh Singh  
> wrote:
> 
> 
> Any update over it !!
> 
>> On Tue, Dec 29, 2020 at 6:28 PM Marcus D. Leech via USRP-users 
>>  wrote:
>>> On 12/29/2020 12:18 PM, Ashutosh Singh via USRP-users wrote:
>> 
>>> Hi ,
>>> I am trying to install the UHD libraries using binaries provided by Ettus 
>>> research following below page:
>>> USRP Hardware Driver and USRP Manual: Binary Installation (ettus.com)
>>> 
>>> 
>>> My System :
>>> 
>>> NAME="Ubuntu"
>>> VERSION="18.04.5 LTS (Bionic Beaver)"
>>> 
>>> 
>>> 
>>> Error:
>>> 
>>> root@yy217925:/home/lab_5g/openairinterface5g/openairinterface5g/cmake_targets/lte_build_oai/build#
>>>  sudo add-apt-repository ppa:ettusresearch/uhd
>>> 
>>>  More info: https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
>>> Press [ENTER] to continue or Ctrl-c to cancel adding it.
>>> 
>>> Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease
>>> Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease
>>> Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease
>>> Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease
>>> Hit:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu bionic InRelease
>>> Hit:7 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease
>>> Ign:6 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic 
>>> InRelease
>>> Err:8 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic 
>>> Release
>>>   404  Not Found [IP: 23.253.215.39 443]
>>> Reading package lists... Done
>>> E: The repository 
>>> 'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic Release' 
>>> does not have a Release file.
>>> N: Updating from such a repository can't be done securely, and is therefore 
>>> disabled by default.
>>> N: See apt-secure(8) manpage for repository creation and user configuration 
>>> details.
>>> 
>>> 
>>> 
>>> Please help me solve it !!
>>> 
>>> 
>>> 
>> 
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> This looks like broken PPA infrastructure.  I have a query in to Ettus 
>> engineering to see what's going on .
>> 
>> 
>> ___
>> 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] DMA FIFO latency with X310

[Marcus D Leech via USRP-users]

Dear lord. The calculator on my iPhone only goes to 1e8 in portrait mode. I had 
not noticed, so I slipped a decimal place. Doh!!

Sent from my iPhone

> On Dec 30, 2020, at 11:48 AM, EJ Kreinar  wrote:
> 
> 
> Simple math is not working out for me today-- Maybe it's the holidays??
> 
> I think a 9000 *byte* packet would be 9000*8/1e9 = 72 microseconds
> 
> ... However the FFT input needs 8192 *samples* which is 8192*4*8/1e9 = 262 
> microseconds!
> 
> Seems like your latency is driven by sending data over the network here
> 
> EJ
> 
>> On Wed, Dec 30, 2020, 11:37 AM Marcus D Leech  
>> wrote:
>> Simple math. 
>> 
>> A 9000 *byte* packet is 72000 *bits*
>> 
>> At 1.0e9 *bits/sec* that’s a latency of 720usec
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> > On Dec 30, 2020, at 8:55 AM, Jorge Arroyo Giganto via USRP-users 
>> >  wrote:
>> > 
>> > 
>> > Hi EJ,
>> > 
>> > Yes, I tried replacing the DMA FIFO with a normal FIFO and the latency got 
>> > a bit worse and more irregular (I'm guessing that's due to not smoothing 
>> > that burstiness in the Ethernet interface with the DMA FIFO you mentioned).
>> > 
>> > I have just tried your graph suggestion (Host -> FFT -> FIFO -> Host) and 
>> > the latency looks about the same but in the FFT block instead. Also I had 
>> > to use packets with spp=256 in the tx streamer in order to match the spp 
>> > that the FFT block accepts or I would get an error when building the 
>> > streamer. Maybe making the FFT block somehow be able to accept bigger 
>> > packets would decrease the latency?
>> > 
>> > About the theoretical latency for a packet of 8192 bytes you mention, 
>> > shouldn't it be 8192*4 bytes assuming that each sample is a sc16 (2 bytes 
>> > for the real part and 2 bytes for the imaginary part of each sample)? Then 
>> > this latency I am experiencing would make more sense?
>> > 
>> > Thank you so much for your feedback, I will also keep in mind your comment 
>> > about the way I am using RFNoC.
>> > 
>> > Best regards,
>> > 
>> > Jorge
>> > 
>> > ___
>> > 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] DMA FIFO latency with X310

[Marcus D Leech via USRP-users]

Simple math. 

A 9000 *byte* packet is 72000 *bits*

At 1.0e9 *bits/sec* that’s a latency of 720usec



Sent from my iPhone

> On Dec 30, 2020, at 8:55 AM, Jorge Arroyo Giganto via USRP-users 
>  wrote:
> 
> 
> Hi EJ,
> 
> Yes, I tried replacing the DMA FIFO with a normal FIFO and the latency got a 
> bit worse and more irregular (I'm guessing that's due to not smoothing that 
> burstiness in the Ethernet interface with the DMA FIFO you mentioned).
> 
> I have just tried your graph suggestion (Host -> FFT -> FIFO -> Host) and the 
> latency looks about the same but in the FFT block instead. Also I had to use 
> packets with spp=256 in the tx streamer in order to match the spp that the 
> FFT block accepts or I would get an error when building the streamer. Maybe 
> making the FFT block somehow be able to accept bigger packets would decrease 
> the latency?
> 
> About the theoretical latency for a packet of 8192 bytes you mention, 
> shouldn't it be 8192*4 bytes assuming that each sample is a sc16 (2 bytes for 
> the real part and 2 bytes for the imaginary part of each sample)? Then this 
> latency I am experiencing would make more sense?
> 
> Thank you so much for your feedback, I will also keep in mind your comment 
> about the way I am using RFNoC.
> 
> Best regards,
> 
> Jorge
> 
> ___
> 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] USRP B210 UHD library installation issue

[Marcus D. Leech via USRP-users]

On 12/29/2020 12:18 PM, Ashutosh Singh via USRP-users wrote:

Hi ,
I am trying to install the UHD libraries using binaries provided by 
Ettus research following below page:
USRP Hardware Driver and USRP Manual: Binary Installation (ettus.com) 




My System :

NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"



*Error:*


/root@yy217925:/home/lab_5g/openairinterface5g/openairinterface5g/cmake_targets/lte_build_oai/build#*sudo
add-apt-repository ppa:ettusresearch/uhd*/
/
/
/ More info:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd
/
/Press [ENTER] to continue or Ctrl-c to cancel adding it./
/
/
/Hit:1 http://nl.archive.ubuntu.com/ubuntu bionic InRelease/
/Hit:2 http://nl.archive.ubuntu.com/ubuntu bionic-updates InRelease/
/Hit:3 http://nl.archive.ubuntu.com/ubuntu bionic-backports InRelease/
/Hit:4 http://nl.archive.ubuntu.com/ubuntu bionic-security InRelease/
/Hit:5 http://ppa.launchpad.net/ettusresearch/uhd/ubuntu bionic
InRelease/
/Hit:7 http://repo.zabbix.com/zabbix/5.0/ubuntu bionic InRelease/
/Ign:6 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic InRelease/
/Err:8 https://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic
bionic Release/
/  404 Not Found [IP: 23.253.215.39 443]/
/Reading package lists... Done/
/E: The repository
'http://files.ettus.com/binaries/uhd/repo/uhd/ubuntu/bionic bionic
Release' does not have a Release file./
/N: Updating from such a repository can't be done securely, and is
therefore disabled by default./
/N: See apt-secure(8) manpage for repository creation and user
configuration details./



Please help me solve it !!




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This looks like broken PPA infrastructure.  I have a query in to Ettus 
engineering to see what's going on .



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

Re: [USRP-users] Where is GNU Radio Live SDR Environment ISO?

[Marcus D. Leech via USRP-users]

On 12/24/2020 03:52 AM, Mattei Rinaldo via USRP-users wrote:

Hi to All,

please someone kind enough to give me the link to download the GNU 
Radio Live SDR Environment ISO. I have a N210 with GPS and I can't get 
it to work.
The ping is there but always "UHD device not found". Maybe with this 
ISO I would succeed.


I take advantage of this email to make many wishes for happy holidays 
to everyone. Best wishes for all good!


Giuseppe


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

Please share the complete output of:

uhd_usrp_probe --args type=n200


With us, and we can help diagnose.


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

Re: [USRP-users] Synchronization of E310 units

[Marcus D Leech via USRP-users]

You can use the external SYNC input to feed in a common 1PPS signal. 

Then set your time source to “external”. I suspect you’ll only do a little 
better than the two independent GPS receivers. 



Sent from my iPhone

> On Dec 23, 2020, at 4:50 PM, Ofer Saferman via USRP-users 
>  wrote:
> 
> 
> Hello,
> 
> I asked a few weeks ago about the possibility to use the internal GPS 
> receivers of the E310 to synchronize multiple units.
> Someone explained that the internal GPS receiver and its associated 
> synchronization algorithm are not good enough and I will not get 
> synchronization that is better than several tenths of microseconds.
> 
> What would you suggest is the best way to synchronize E310 units so that they 
> will be synchronized at base-band sample level? I mean that when transmitting 
> from 2 (or more) different E310 units the Tx samples will be perfectly 
> time-aligned on different units.
> 
> I noticed there is a SYNC input and somewhere I read that it is possible to 
> provide an external 1PPS signal. Could someone comment on this feature? 
> Explain if it works? How to make it work in terms of software setup?
> Maybe the SYNC input can be used differently for synchronization?
> 
> Is there another way to achieve the synchronization that I want, given that 
> the E310 has no external reference clock input?
> 
> Regards,
> Ofer Saferman
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. ___
> 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] Connection problems

[Marcus D Leech via USRP-users]

It’s clearly not an N210 if you’re getting LIBUsB errors. Perhaps it’s a B210?

This sounds like insufficient power being supplied by your USB controller. Try 
an external power supply if it’s a B210. 

Sent from my iPhone

> On Dec 21, 2020, at 6:50 AM, Philipp Schach via USRP-users 
>  wrote:
> 
> 
> Hi guys! 
> I am new here and needed some help. My name is Philipp and I am a student at 
> HTW Berlin in Germany.
> We have built a small test network with srsLTE in our lab. The network 
> consists of a computer with a USRP N210 and a Virtual Access GW2028 as UE 
> with a Pi. The computer runs the eNodeB service of srsLTE with Open5GS as 
> EPC. The network was built by another student last semester. It was 
> configured for band 3 at 1800 MHz. Now the network should run in band 31 at 
> 450 MHz. Basically it runs as well. The GW2028 successfully logs in. However, 
> after a short time there is an error with the USRB N210:
> 
> [ERROR] [UHD] An unexpected exception was caught in a task loop.The task loop 
> will now exit, things may not work.EnvironmentError: IOError: usb rx8 
> transfer status: LIBUSB_TRANSFER_NO_DEVICE
> /home/u1804/srsLTE_20_10/srsLTE/lib/src/phy/rf/rf_uhd_imp.cc.228: USRP 
> reported the following error: EnvironmentError: IOError: usb rx6 transfer 
> status: LIBUSB_TRANSFER_NO_DEVICE
> 
> After the appearance the command "uhd_find_devices" returns wrong answers. 
> The serial number is no longer returned completely or no device is found at 
> all. After a restart it runs again for a few minutes and then crashes again 
> with the error.
> In band 3, everything was supposedly running relatively stable. 
> 
> Unfortunately, due to Corona, I am not at the university in the lab every 
> day, but I plan to be there in the next few days.
> If more information is needed, I will submit it when I am on site. Currently 
> running a version of Ubuntu 18 as operating system. UHD is installed in 
> version 3.15.
> 
> Has anyone had this problem before, or could kindly help me?
> 
> Greetings Philipp
> ___
> 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] B210 USRP TX Spectrum Channel Differences

[Marcus D. Leech via USRP-users]

On 12/14/2020 09:44 AM, Nieland, Michael via USRP-users wrote:


Dear all,

we are using two B210 USRP’s to generate and receive DQPSK Signals at 
1.53 GHz (two TX and two  RX channels). The USRP’s use FW Version 8.0 
and FPGA Version 16.0 (Hardware Revision 4). We found that there are 
quite significant differences in spurious output between the two tx 
channels on the B210. I attached screenshots of my spectrum analyzer 
measurements demonstrating this behavior.


A couple of more details about the setup:

-  USRP connected and powered via USB3

-  No external reference used for the above measurements

-  The signals are generated using a GnuRadio flowgraph

The spurious signals are always present and independent of the TX Gain 
setting, the digital signal amplitude and the signal frequency. We 
observed the same behavior on another B210 USRP. We are assuming this 
is hardware related but are wondering if UHD settings also play a role 
here and if there is a way to possibly improve the performance of 
channel 2 in particular (~20 dB difference at 1.52 GHz spur between 
channel 1 and channel 2).


Best regards

Michael Nieland


This is probably just a hardware quirk of the AD9361 chip that forms 
nearly the entirety of the RF chain on the B2xx series USRPs.


The spur on the 2nd channel looks like it's still about -40dBc, which I 
believe is "in spec" for the AD9361 chip.




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

Re: [USRP-users] LO phase alignment for multiple B200s

[Marcus D. Leech via USRP-users]

On 12/14/2020 10:19 AM, Bach Nguyen via USRP-users wrote:

Hi all,

I was using my 2 B200s to measure the magnitude and phase difference 
in voltage gain of two signal chains on-site and I notice that there 
is a random phase offset between the 2 inputs. I read the USRP Manual 
on Device Synchronization and realize that I was tuning the 2 B200 
asynchronously, even though I had them start streaming synchronously 
using the external PPS. There are several things that I would like to 
ask and clarify:


 1. Does the usrp->set_command_time(cmd_time) set all the subsequent
command (before clear_command_time()) to start after cmd_time
seconds or they will start at the exact cmd_time instant in the
time registers?

The timed commands trigger at the time instant in the on-board timestamp 
registers.


 1. Once I retune the 2 B200s simultaneously to centre frequency f1,
then the device is closed or re-tuned to other frequency, f2, if I
re-tune it back to center frequency f1, would the phase offset
between the 2 B200 RX streams be the same as original, when I
firstly re-tuned it?

No.  Since the B200 DO NOT SUPPORT timed-tuning, and since there's no 
hardware support for the necessary re-synch feature, you can't
  get a predictable phase-offset between two B200s, even with shared 
10Mhz reference, 1PPS, and the use of timed commands.


 1. Does the phase offset, after re-tuning, varies with different
centre frequency (ie. offset at frequency f1 different from
frequency f2)?


Yes.  That's just a property of PLL synthesizers without phase re-synch.


 1. My code was a modified version of the rx_samples_to_file.cpp, with
the synchronization principle mentioned below. Would it be enough
to make the 2 B200s synchronized with constant phase offset
between LOs? Besides, the program was started for a week, then
stopped completely, and re-started again after a few days (I
regard this as "device is closed", and re-initialized) , would the
phase offset between LO, in this case, remains constant as before
the stop?


No.  See above.

The program I used has 2 threads, each for 1 B200. The threads' tasks 
(after adding the LO alignment part) are:


  * 1st thread: Call set_time_unknown_pps() on the 1st B200,once done,
send sync_signal to 2nd B200. Then use the set_command_time(3.0),
set_rx_freq(fc,0) and clear_command_time() for LO phase offset.
  * 2nd thread: Keep polling the sync_signal, once it receives, use
set_time_next_pps(1.0) to synchronize the 2 B200. Once done, I use
the set_command_time(3.0), set_rx_freq(fc,0) and
clear_command_time() for LO phase offset.
  * After the above steps, both threads have a while loop to keep
polling the value of time register for the last PPS, if it is 5
seconds then the stream command is issued in both threads. After
that, I use the rx_stream->recv to record the samples from the 2
B200s.

Cheers,
Bach


___
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] Problem with x310 io error

[Marcus D Leech via USRP-users]

What type of Ethernet connextion are you using?

What type of PC? Does your Ethernet card have an 82579LM controller chip?

Are you running under a VM or on the physical hardware?




Sent from my iPhone

> On Dec 12, 2020, at 11:19 PM, Basse Ang via USRP-users 
>  wrote:
> 
> Hi
> 
> Just have an issue, my x310 always get this error:
> 
> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_3.15.0.0-release
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929b
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
> _endianness = uhd::ENDIANNESS_BIG]
>   at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:50
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
> (CE_00_Port_30) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
> uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned 
> int]
>   at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:151
> 
> Error: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response 
> packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
> uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned 
> int]
>   at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:151
> 
> 
> Anyone has experienced it too? Could you help me please. thank you.
> 
> Regards
> Bass
> ___
> 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] UBX160 TX "noise figure"?

[Marcus D Leech via USRP-users]

I think you’d mentioned you have a spectrum analyzer. What does it have to say 
about the SNR of your signal?

Sent from my iPhone

> On Dec 8, 2020, at 2:41 PM, Lukas Haase via USRP-users 
>  wrote:
> 
> 
> Hi Marino,
>  
> Thank you for confirming the -139dBm/Hz. Indeed, with my sampling rate of 5 
> MSps, this is -139+dB10(5e6)=-72dBm, which was exactly my prediction from my 
> initial message.
>  
> For the RX line noise floor, I am sure it's the usual -169dBm/Hz (5dB NF) ... 
> at least if I disconnect the TX->RX connection, that's what I get.
>  
> Thanks again for your input! If you could think of anything else I could try 
> to narrow down things please let me know.
>  
> Thanks,
> Lukas
>  
>  
>  
>  
> Gesendet: Dienstag, 08. Dezember 2020 um 03:29 Uhr
> Von: "cyberphox" 
> An: "Lukas Haase" 
> Betreff: Re: [USRP-users] UBX160 TX "noise figure"?
> I work out the TX noise floor is around -139dBm/Hz at roughly similar step 
> attenuator setting, this results in similar Snr you predict 
>  
> Your setup seems fine unfortunately at the moment I can’t think of what else 
> at the moment. 
>  
> Are you sure about the RX line up noise floor? 
>  
> Will keep head scratching ...
>  
> Have a good day!
>  
> Marino 
>  
>  
>  
>> On Mon, 7 Dec 2020 at 18:00, Lukas Haase  wrote:
>> Hi Marino,
>>  
>> I don't think it's a BW/RBW related issue ... My measurements (noise, signal 
>> etc.) are pretty consistent otherwise.
>> I think I am doing things right in my setup.
>>  
>>  
>> That's why I am asking if maybe something is wrong with my original question 
>> about the "TX SNR" of the USRP. Maybe our conclusions on the noise figure in 
>> the TX are wrong?
>>  
>> Thanks,
>> Lukas
>>  
>>  
>>  
>> Gesendet: Montag, 07. Dezember 2020 um 04:47 Uhr
>> 
>> Von: "cyberphox" 
>> An: "Lukas Haase" 
>> Betreff: Re: [USRP-users] UBX160 TX "noise figure"?
>> The power remaining from the phase noise skirt contributes but even without 
>> it as you show is still quite a lot different. It’s not a measurement 
>> bandwidth/rbw related issue?
>>  
>>  
>>  
>>> On Mon, 7 Dec 2020 at 08:56, Lukas Haase  wrote:
>>> Hi Marino,
>>>  
>>> Ok, so when my TX is set to 20dB and the full range is 31.5, then the 
>>> attenuator should be set to 11.5dB.
>>>  
>>> How I get the information from my plots:
>>> The SNR=38.7dB value is taken by taking the DFT and setting all bins but 
>>> the signal bin to zero and calculating 20*log(std(ideal)/std(ideal-orig)). 
>>> Signal period is integer multiple of sampling period and leakage does not 
>>> exist (at least to the degree it could be relevant). Of course, this SNR 
>>> includes everything, incl. phase noise skirt
>>> The orange signal is generated by adding white Gaussian noise to the ideal 
>>> signal such that it has XdB SNR. I sweep over multiple SNR values until I 
>>> get visual correspondance. From my plot you can see that the white noise 
>>> floor is this signal (yellow) matches the received signal (red). The SNR 
>>> for the yellow signal is 50dB. Therefore I can conclude that the SNR of the 
>>> signal is 50dB if I only take thermal noise into account
>>> Yes, I have measured the noise floor with signal off. It matches exactly 
>>> with my expectations (-102dBm at RX gain=20)
>>>  
>>> Thanks,
>>> Lukas
>>>  
>>> Gesendet: Montag, 07. Dezember 2020 um 03:46 Uhr
>>> 
>>> Von: "cyberphox" 
>>> An: "Lukas Haase" 
>>> Betreff: Re: [USRP-users] UBX160 TX "noise figure"?
>>> Hi Lukas,
>>>  
>>> Thanks for your reply! 
>>>  
>>> I was meaning the attenuator of the TX before the amplifiers. 
>>>  
>>> Also from your plots were do you take your noise floor from? Are you 
>>> reading from the top of the phase noise skirt?  
>>>  
>>> Have you measured the noise floor with signal off?  
>>>  
>>> Also it is worth doing this measurement with different power levels just in 
>>> case you have some non-linearity  issues
>>>  
>>> Kind regards 
>>> Marino
>>>  
 On Mon, 7 Dec 2020 at 08:33, Lukas Haase  wrote:
 Hi Marino,
  
 Which digital attenuator do you mean?
  
 The 46.43dB attenuation that I use in the TX-RX loopback is just composed 
 of static, passive attenuators
 The receive gain is set to 20dB. Hence I assume I do not make use of the 
 6dB "digital gain" in the ADC and from the remaining 31.6dB gain I use 20. 
 Hence I the "digital attenuator" should be 11.5dB if that answers your 
 question?
 At a receive gain of 20dB, the noise figure is ~5dB, according to specs 
 and measurements. -174+5+dB10(5e6)=-102dBm which is exactly what I measure 
 without a signal applied.
 Thanks,
 Lukas
  
 Gesendet: Montag, 07. Dezember 2020 um 03:23 Uhr
 Von: "cyberphox" 
 An: "Lukas Haase" 
 Cc: "Marcus D. Leech" , USRP-users@lists.ettus.com
 
 Betreff: Re: [USRP-users] UBX160 TX "noise figure"?
 Hi Lukas,
  
 What setting do you have the digital attenuator set to?
  
  
 Kind 

Re: [USRP-users] UBX160 TX "noise figure"?

[Marcus D. Leech via USRP-users]

On 12/06/2020 08:33 PM, Lukas Haase wrote:

Hi Marcus,
Thanks again!
I did now the following experiment: I connected TX to RX back-to-back 
with 46.43dB attenuation in between. I set TX gain and RX gain to 20dB 
and transmit a single CW at -3dBFS.
This means my output power is *Pout=11.44dBm* (cross checked with 
spectrum analyzer) and on RX I sould have Pin=-34.99dBm. Indeed, 
calculating the RMS of the received signal and converting to dBm, I 
get *Pin=-35.0224dBm*. Spot on!

The red line is what I receive on the PSD (blue is the TX that I send):
As you can see from the annotation, the measured "SNR" of the received 
signal is only 38.7dB. I think this is mainly caused by the phase 
noise skirt (and potentially the I/Q image).
In order to keep only consider thermal noise, I add random noise to 
the original CW (using randn(...)+1i*randn(...) in MATLAB) until it 
matches roughly the white noise floor of the received signal. It's 
*SNRoutput=50dB* (yellow line).
Now, according to our discussion below, at Gtx=20, we should have 
*SNRoutput=72dB* (assuming thermal noise only).

Where could the *22dB difference* in SNR come from?
Thanks!
Lukas
PS: I am aware of phase noise, DC offsets, I/Q imbalance etc. But as 
you can see from my plot, I am /only /considerung thermal noise. The 
thermal noise of the receiver should be orders of magnitude lower (at 
least -102dBm) so the receiver noise should not limit the results either.


This is a UBX-to-UBX loopback, or UBX-to-TwinRX loopback?   The gain 
ranges on the two are different.



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

Re: [USRP-users] USRP B200 Function Question

[Marcus D Leech via USRP-users]

Similarly it’s easy to get B2xx working with a super cheap SBC like the rPi 
boards or Odroids etc. 

Sent from my iPhone

> On Dec 7, 2020, at 2:16 PM, Rob Kossler via USRP-users 
>  wrote:
> 
> 
> Mark,
> Just this past Friday, I had success controlling a B200mini directly from an 
> N310 using the USB2 port on the N310.  Such a use case limits you to USB2 
> streaming for the B2xx and it also hogs CPU cycles from the N310.  Let me 
> know if this is of interest to you I can can provide more info.
> Rob
> 
>> On Mon, Dec 7, 2020 at 1:56 PM Mark McAllister via USRP-users 
>>  wrote:
>> My senior design team at California State University Northridge is current 
>> using a USRP N210 as a  local oscillator for a smart antenna array. 
>> 
>> We're considering purchasing something from the B200 series in order to 
>> replace it since we are current borrowing our N210. 
>> 
>> Our concern is that the B200 specifies the use of USB 3.0 for connecting to 
>> a host computer, and we are currently connecting both an N210 and N310 to a 
>> router which connects all signals to a host computer.
>> 
>> My main question is whether or not the B200 series will run properly using a 
>> USB to Ethernet adapter or if the device MUST be connected directly to the 
>> host computer via USB. 
>> 
>> Thank you for your time, 
>> Mark McAllister
>> ___
>> 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] USRP B200 Function Question

[Marcus D Leech via USRP-users]

I’ve never had much luck with USB over Ethernet devices with either USRP1 or 
B2xx



Sent from my iPhone

> On Dec 7, 2020, at 1:56 PM, Mark McAllister via USRP-users 
>  wrote:
> 
> 
> My senior design team at California State University Northridge is current 
> using a USRP N210 as a  local oscillator for a smart antenna array. 
> 
> We're considering purchasing something from the B200 series in order to 
> replace it since we are current borrowing our N210. 
> 
> Our concern is that the B200 specifies the use of USB 3.0 for connecting to a 
> host computer, and we are currently connecting both an N210 and N310 to a 
> router which connects all signals to a host computer.
> 
> My main question is whether or not the B200 series will run properly using a 
> USB to Ethernet adapter or if the device MUST be connected directly to the 
> host computer via USB. 
> 
> Thank you for your time, 
> Mark McAllister
> ___
> 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] b210 and x310 synchronisation from non-GPSDO external clock

[Marcus D. Leech via USRP-users]

On 12/07/2020 11:24 AM, BERTOLINI Rodolphe via USRP-users wrote:

Dear all,

I put both mailing list (OAI and USRP) because both may have something to do 
with my problem. I apologize if it is not appropriate.

I would like to synchronize a b210 and an x310 using a square signal generated 
by a function generator. It has a 10MHz ref output, so I generate a 1Hz square 
clock through a regular front output.
Except the output voltage, is there something I should care about ? I use them 
with OAI, and they both are used as LTE base stations. When the base station is 
on external ref, UE doesn't detect the base station. When the base station is 
on internal ref, UE detects base station broadcasts and connects to the base 
station.

Note 1 : PPS and REF are well detected by the USRP, when I change for example 
PPS frequency, x310 led changes respectively.
Note 2 : only one USRP is used at the same time, I want to make it work first 
with only one base stations, and then when base stations are both on and 
synchronised
Note 3 : in OAI code, there is something like :

usrp_master_clock = 30.72e6;
args += boost::str(boost::format(",master_clock_rate=%f") % usrp_master_clock);
args += ",num_send_frames=256,num_recv_frames=256, send_frame_size=7680, 
recv_frame_size=7680" ;

Is this master clock related to the sampling rate, or should it be changed to 
10MHz?
The master clock rate is related to the available sampling rates, and 
not the external reference frequency, which is 10MHz.  The B210 is
  quite flexible in its master clock rate, but the X310 is much more 
limited in the master-clock rates it supports.






Note 4 : I looked at the spectrum of signal sent by base station, I don't see 
any difference between the setup with external clock and the setup with 
internal clock
Unless you have your spectrum analyser set-up for very-fine resolution, 
you likely won't see much difference--the internal clocks are

  already pretty good.




Any pointer would be much appreciated
Thank you.

Regards,
Rodolphe
___
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] Using GPS disciplining on E310

[Marcus D. Leech via USRP-users]

On 12/04/2020 03:46 PM, Rob Kossler via USRP-users wrote:

Hi Ofer,
Here is my understanding
- The E310 can sync to a PPS signal (either external input or obtained 
from GPS).  From this PPS, the E310 derives the 10MHz ref signal and 
uses that as ref for LO signal.  So, there will be lots of phase 
variation between the LOs in all of your E310 devices even though they 
will all be trying to stay in sync with a 1 pulse-per-second signal.
Basically, the E310 implements a "poor man's GPSDO" with the built-in 
GPS module it has.  It's the same algorithm as is used in the
  B205mini series for the sync input.The control algorithm isn't 
that good, and you cannot maintain coherence among multiple E310s

  using this.


- Regarding your time synchronization question, there are examples of 
setting the E310 clock (using set_time_next_pps, I think) to match the 
GPS clock.  Thus, all of your E310s could have the same time.  But, 
how do you plan to control all of your E310s when you want the 
transmit to turn on? Will you have an SSH session to each of them?

Rob

Once all your E310 radio system clocks agree on time, you can used timed 
streaming.


The "sync_to_gps" example application should give some broad help in 
setting up GPS synchronization.



On Fri, Dec 4, 2020 at 2:28 PM Ofer Saferman via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hello,
I would like to synchronize several E310 devices.
It is my understanding that the only way to do that is by
connecting a GPS antenna and performing disciplining to a derived
1-PPS signal.
I have a few questions to help me better understand how to make it
work:
1. Does GPS disciplining achieve frequency lock between devices or
phase lock?
2. How to start transmitting at the exact moment on all
synchronized devices? Can the unit clock be synchronized to GPS
clock? and then just start the transmission with some delay from
unit clock on all devices? Can someone share the relevant C
commands to perform the time synchronization to GPS clock or point
to a relevant code example?

Thanks,
Ofer Saferman


-- 
This message has been scanned for viruses and

dangerous content by *MailScanner* ,
and is
believed to be clean. ___
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] Questions regarding tx_waveforms

[Marcus D Leech via USRP-users]

Try reducing the baseband signal magnitude and RF gain—does that reduce the 
unwanted harmonic content?

What offset value are you using? I typically use a value that is a bit more 
than half my application bandwidth.

Some Amount of unwanted mixing and distortion products are *inevitable* with 
any general purpose transmit chain, and the usual strategy in purpose-built 
radios is the use of output filters. 

Sent from my iPhone

> On Dec 2, 2020, at 1:48 PM, Carlo Venier via USRP-users 
>  wrote:
> 
> 
> Hi,
> 
> I have a few questions regarding tx_waveforms script. 
> I'm using an USRP B200mini.
> 
> How can I delete (or reduce) the DC component when using tx_waveform?
> 
> When I set --freq=f0, specifying --lo_offset=(df0), how do I remove (or 
> reduce) the mirrored replica at (f0+2*f0) that is generated? Do you have any 
> advice to suggest? 
> 
> Thank you in advance, 
> 
> Carlo
> 
> ___
> 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 doesn't find USRP B205

[Marcus D. Leech via USRP-users]

On 11/30/2020 01:27 PM, Jens Hoffmann wrote:

uhd_images_downloader output:


Again, you have TWO UHD library installations.The version that Gnu 
Radio is linked against is 3.13, whereas your

  uhd tools, like uhd_usrp_probe are apparently 3.15.

My *guess* is that you installed Gnu Radio from the packages repository, 
then did a UHD source install to give you UHD 3.15.


Which cannot work properly.

Unless you really need 3.15, you should uninstall it, and possibly 
uninstall and re-install Gnu Radio and UHD from the packages repository.




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

Re: [USRP-users] UBX160 TX "noise figure"?

[Marcus D. Leech via USRP-users]

On 11/30/2020 01:54 PM, Lukas Haase wrote:

Hi Marcus,
That makes sense, thanks.
Would you be willing to confirm if what I am doing here is correct?
To first order, the DAC has an SNR of 98dB (16 bit). Then I use Fries' 
equation to get the NF of the following stages (for the filter and the 
attenuator, the noise figure is equal to its attenuation). The NF is 
dominated by the 2nd and third term.
Then I subtract the NF from the SNR which gives me an output SNR 
somewhere between 92dB and 67dB. Does that sound right?

For the attenuator term, just assign it a NF (in dB) of (31.5 - TXGAIN).

The noise figure of an attenuator is just the attenuation 
value--similarly for the filter.  Just pretend it's a fixed attenuator 
with 0 gain.


So the 'noise figure' after the DAC is just  2+(31.5 - TXGAIN) then 
factor in the gains and noise figures of the amplifiers.




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

Re: [USRP-users] UBX160 TX "noise figure"?

[Marcus D Leech via USRP-users]

The output SNR will be utterly dominated by the inherent DAC noise. 

There’s a good article here:

https://www.analog.com/media/en/training-seminars/tutorials/MT-001.pdf

Sent from my iPhone

> On Nov 30, 2020, at 4:03 AM, Lukas Haase via USRP-users 
>  wrote:
> 
> Hello,
> 
> Does anyone know what the *TX* noise figure (output SNR) of the UBX160 is?
> Roughly?
> For simplicity, can neglect phase noise and assume white noise floor.
> 
> In words, if I transmit a full-scale sinusoidal signal, what will be the 
> noise floor around that signal?
> 
> Of course, this will depend on TX Gain setting.
> 
> For example, a -3dBFS signal at TX gain 25 gives -3+25-5.56 = 16.44dBm. What 
> will roughly be the noise power (and hence SNR)?
> 
> Thanks,
> Lukas
> 
> 
> PS: Usually we are interested in receiver (not transmitter) noise but the TX 
> SNR can be relevant for self-interference.
> 
> 
> ___
> 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] Fwd: E310: Change MAC Address?

[Marcus D Leech via USRP-users]

I have a query In to Ettus engineering on this. I can’t find any documentation 
on changing the MAC. 

The u-boot environment thinks of the MAC address as precious and once it is 
set, it won’t let you change it or delete it. 

Presumably a fresh image from the download site has code that sets the u-boot 
env from hardware, which then “locks” it. U-boot used to use text files for the 
environment but now it’s in a binary format AFAiR. 

Sent from my iPhone

> On Nov 27, 2020, at 2:21 PM, Andrew Payne via USRP-users 
>  wrote:
> 
> 
> Thanks Aneesh but the decompiled dts file has no mention of the exact MAC 
> address for eth0, but just to read from the eeprom from what I can gather. 
> Plus an md5sum of the dtb file on the sdimg from Ettus is the same checksum 
> as an e310 that has booted.
> 
>> On Fri, Nov 27, 2020 at 1:40 PM Philip Balister  wrote:
>> On 11/27/20 1:34 PM, aneesh patel via USRP-users wrote:
>> > Hi Andrew,
>> > The MAC may be in the devicetree blobs in the boot area of the SD image.
>> > You will need dtcedit to decompile, edit, and recompile as needed.
>> 
>> I don't think so, since the first time the card boots it does read from
>> the i2c eeprom.
>> 
>> I'm guessing u-boot sets the ethaddr env var and saves it in the
>> environment, but I forget where that might be saved. Need to review the
>> u-boot configuration for setting about the u-boot env (maybe getting
>> saved to the sd card).
>> 
>> Anyone from Ettus paying attention? This is a pretty serious problem for
>> people copying cards and using them in different units. The correct
>> behavior is follow the MAC address programmed into the i2c eeprom.
>> 
>> Philip
>> 
>> > Amp
>> > 
>> > Sent from Yahoo Mail on Android 
>> >  
>> >   On Fri, Nov 27, 2020 at 1:23 PM, Andrew Payne via 
>> > USRP-users wrote:   
>> > ___
>> > 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: E310: Change MAC Address?

[Marcus D Leech via USRP-users]

Near as I can tell the e310 gets its MAC from the motherboard i2c eeprom. 

Sent from my iPhone

> On Nov 25, 2020, at 12:55 PM, Andrew Payne via USRP-users 
>  wrote:
> 
> 
> So does the U-Boot environment determine the MAC address of eth0 prior to 
> booting the kernel?  Or is it during the make of the boot image?  I just find 
> it a stretch to believe that I am running an image on a number of SDRs, and 
> they're all using the same MAC address, possibly from the e310 for which the 
> boot image was generated?
> 
> 
> 
>> On Wed, Nov 25, 2020 at 8:59 AM Philip Balister  wrote:
>> Mine is different, but both seem to be from the National Instruments
>> block (which is good):
>> 
>> root@ni-e31x-30D280A:~# ifconfig
>> eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:02:37
>>   inet addr:192.168.11.152  Bcast:192.168.11.255
>> 
>> I see a warning early in boot about using a MAC address from ROM. I'm
>> not sure where that came from.
>> 
>> Philip
>> 
>> On 11/25/20 8:36 AM, Andrew Payne via USRP-users wrote:
>> > -- Forwarded message -
>> > From: Andrew Payne 
>> > Date: Wed, Nov 25, 2020 at 8:35 AM
>> > Subject: Re: [USRP-users] E310: Change MAC Address?
>> > To: Philip Balister 
>> > 
>> > 
>> > It is: 00:80:2f:19:4c:37
>> > 
>> > When is that .patch file ran, is it during compilation of the BSP?  When
>> > would I see that error message printf("I2C EEPROM MAC address read
>> > failed\n");?
>> > 
>> > How could I experiment with compiling a new BSP with the UHD 3.15
>> > environment loaded, so then I may insert my own MAC Address or get the i2c
>> > EEPROM read to work? Do I need
>> > https://github.com/EttusResearch/meta-ettus
>> > and
>> > https://github.com/Xilinx/u-boot-xlnx
>> > and may be use this guide:
>> > https://opencpi.github.io/bsp_e310/Ettus_E3xx_Getting_Started_Guide.pdf
>> > ?
>> > 
>> > Thanks,
>> > Andrew
>> > 
>> > 
>> > On Wed, Nov 25, 2020 at 8:26 AM Philip Balister  
>> > wrote:
>> > 
>> >> What is that mac address? I'd like to see if it matches mine.
>> >>
>> >> If I recall correctly, the mac address is flashed into the i2c eeprom,
>> >> u-boot is supposed to read that and use it. Factory test should set it
>> >> up uniquely. But my memories fade. Inspecting the u-boot source might
>> >> show us 
>> >>
>> >>
>> >> https://github.com/EttusResearch/meta-ettus/blob/zeus/meta-e31x/recipes-bsp/u-boot/files/0001-ni-zynq-Add-support-for-NI-E31x-SG1-SG3-boards.patch#L397
>> >>
>> >> I didn't sift through the ifdef's though.
>> >>
>> >> Philip
>> >>
>> >> On 11/24/20 7:28 PM, Andrew Payne via USRP-users wrote:
>> >>> Is there a way to change the mac address of my e310s?  I have imaged
>> >>> several e310s using the image file in
>> >>> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/, and
>> >> they
>> >>> all have the same MAC address.
>> >>>
>> >>> On some searching around the web I can see that it is likely that the MAC
>> >>> address parameter is specified as a U-boot parameter.  I'd like to know
>> >>> what my options are for changing it.
>> >>>
>> >>> Thanks,
>> >>> Andrew
>> >>>
>> >>>
>> >>> ___
>> >>> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Carrier frequency jumps on E310

[Marcus D. Leech via USRP-users]

On 11/24/2020 02:38 PM, Luke Whittlesey wrote:

I'm in the process, but it's a lengthy process. There is something
messed up with the C API in 3.15, so it doesn't work for me as a
simple drop in replacement. Would it be wise to try to jump straight
to 4.0?

The jump to 4.0 might be more traumatic.



On Tue, Nov 24, 2020 at 2:40 PM Marcus D Leech  wrote:

R suggest updating to a UHD 3.15 environment first.

Sent from my iPhone


On Nov 24, 2020, at 1:54 PM, Luke Whittlesey  wrote:

I'm seeing this on two E310s that are a few years old. I just swapped
the sd card into a brand-new E310 and I am NOT seeing the frequency
jumps. So, same exact software, but different aged E310s. Is there
possibly a difference in hardware leading to this?


On Tue, Nov 24, 2020 at 1:04 PM Luke Whittlesey
 wrote:

I would say they are proportional to frequency. Attached is what it
looks like at 5GHz. There are jumps of 400Hz and 220Hz.


On Tue, Nov 24, 2020 at 11:50 AM Marcus D Leech  wrote:

Try at lower and higher frequencies—are the jumps the same or proportional to 
frequency?

Sent from my iPhone


On Nov 24, 2020, at 11:27 AM, Luke Whittlesey via USRP-users 
 wrote:

On the E310 I'm seeing discrete jumps in the carrier. The carrier will
intermittently jump around in steps of about 50Hz. Sometimes it will
jump by about 200Hz. I've attached a waterfall display, but I don't
know if attachments will make it through.

My setup is:
E310 SG3
UHD3.11 using the C-api
Timing Reference is "internal"
Center Frequency 1GHz
I/Q signal is a stream of 1,0... for a CW at the carrier

I can see the same thing when I set the timesource to "gpsdo", but I
wouldn't expect it when I set it to "internal". My gut says that this
is being caused by some timesource correction loop. If this is the
case is there a way to disable this?

Thank you

___
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] Carrier frequency jumps on E310

[Marcus D Leech via USRP-users]

R suggest updating to a UHD 3.15 environment first. 

Sent from my iPhone

> On Nov 24, 2020, at 1:54 PM, Luke Whittlesey  
> wrote:
> 
> I'm seeing this on two E310s that are a few years old. I just swapped
> the sd card into a brand-new E310 and I am NOT seeing the frequency
> jumps. So, same exact software, but different aged E310s. Is there
> possibly a difference in hardware leading to this?
> 
>> On Tue, Nov 24, 2020 at 1:04 PM Luke Whittlesey
>>  wrote:
>> 
>> I would say they are proportional to frequency. Attached is what it
>> looks like at 5GHz. There are jumps of 400Hz and 220Hz.
>> 
>>> On Tue, Nov 24, 2020 at 11:50 AM Marcus D Leech  
>>> wrote:
>>> 
>>> Try at lower and higher frequencies—are the jumps the same or proportional 
>>> to frequency?
>>> 
>>> Sent from my iPhone
>>> 
 On Nov 24, 2020, at 11:27 AM, Luke Whittlesey via USRP-users 
  wrote:
 
 On the E310 I'm seeing discrete jumps in the carrier. The carrier will
 intermittently jump around in steps of about 50Hz. Sometimes it will
 jump by about 200Hz. I've attached a waterfall display, but I don't
 know if attachments will make it through.
 
 My setup is:
 E310 SG3
 UHD3.11 using the C-api
 Timing Reference is "internal"
 Center Frequency 1GHz
 I/Q signal is a stream of 1,0... for a CW at the carrier
 
 I can see the same thing when I set the timesource to "gpsdo", but I
 wouldn't expect it when I set it to "internal". My gut says that this
 is being caused by some timesource correction loop. If this is the
 case is there a way to disable this?
 
 Thank you
 
 ___
 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] Carrier frequency jumps on E310

[Marcus D Leech via USRP-users]

Try at lower and higher frequencies—are the jumps the same or proportional to 
frequency?

Sent from my iPhone

> On Nov 24, 2020, at 11:27 AM, Luke Whittlesey via USRP-users 
>  wrote:
> 
> On the E310 I'm seeing discrete jumps in the carrier. The carrier will
> intermittently jump around in steps of about 50Hz. Sometimes it will
> jump by about 200Hz. I've attached a waterfall display, but I don't
> know if attachments will make it through.
> 
> My setup is:
> E310 SG3
> UHD3.11 using the C-api
> Timing Reference is "internal"
> Center Frequency 1GHz
> I/Q signal is a stream of 1,0... for a CW at the carrier
> 
> I can see the same thing when I set the timesource to "gpsdo", but I
> wouldn't expect it when I set it to "internal". My gut says that this
> is being caused by some timesource correction loop. If this is the
> case is there a way to disable this?
> 
> Thank you
> 
> ___
> 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] X310 UBX digital tune not occurring?

[Marcus D Leech via USRP-users]

Could you confirm which version of UHD you’re using?

There has historically been a problem using both TwinRx and UBX on the same 
X310 due to clocking requirement conflicts. 

But that has been fixed in UHD4

Want to eliminate that as a possibility first. 

Sent from my iPhone

> On Nov 23, 2020, at 11:42 AM, Dustin Widmann  wrote:
> 
> Marcus,
> 
> I do have access to sig gens, but I would have to take everything into town 
> to do that. (sanest thing to do during covid
> was to bring portable things home...)
> 
> What I do have handy though is a spectrum analyzer (albeit, not a 
> particularly good one, but when working with a narrow
> span it should be able to give results that are good enough)
> 
> What I observed is this:
> tx freq MHz meas freq [MHz] deviation [Hz] 60.050  60.048800  
>   1200
> 61.050  61.050100   -100
> 62.050  62.051200   -1200
> 63.050  63.052533   -2533
> 64.050  64.053600   -3600
> 65.050  65.054933   -4933
> 66.050  66.0440006000
> 67.050  67.0450674933
> 68.050  68.. Missed this one
> 69.050  69.0477332267
> 70.050  70.0488001200
> 
> 
> For reference, what I observed with the twinrx was as follows
> freqtarget bin/freq actual bin/freq diff bin/freq  dsp 
> freq 
> 60MHz   524.288 (50e3)  512 (48,828) 12.288 (1,172)  1160 
>   
> 61MHz   524.288 (50e3)  525 (50,068) -0.712 (-68) -61 
>   
> 62MHz   524.288 (50e3)  538 (51,308)-13.712 (-1,308)-1282 
>   
> 63MHz   524.288 (50e3)  551 (52,547)-26.712 (-2,547)-2503 
>   
> 64MHz   524.288 (50e3)  563 (53,692)-38.712 (-3,692)-3724 
>   
> 65MHz   524.288 (50e3)  576 (54,932)-51.712 (-4,932)-4945 
>   
> 66MHz   524.288 (50e3)  461 (43,964) 63.288 (6,036)  6044 
>   
> 
> Having taken the TwinRX out of the loop, it seems I'm getting very similar 
> results. 
> 
> Dustin
> 
> 
>> On Sat, 2020-11-21 at 13:43 -0500, Marcus D. Leech wrote:
>>> On 11/21/2020 08:28 AM, Dustin Widmann wrote:
>>> Marcus,
>>> 
>>> I tried it without timed commands last night. It was landing on the
>>> same frequencies as it did with timed commands i.e. didn't fix that
>>> problem.
>>> 
>>> Dustin
>> OK, thanks for doing the test.
>> 
>> I wonder if you have a precise signal generator so you can confirm
>> that 
>> the RX side is on-frequency?
>> 
>> 
>>> 
>>> On Wed, 2020-11-18 at 20:05 -0500, Marcus D. Leech wrote:
>>>> On 11/18/2020 07:34 PM, Dustin Widmann wrote:
>>>>> On Wed, 2020-11-18 at 18:27 -0500, Marcus D. Leech via USRP-
>>>>> users
>>>>> wrote:
>>>>> Marcus,
>>>>> 
>>>>> Oh, sorry, I missed the first bit. I'm using the on-board
>>>>> clock.
>>>>> And
>>>>> perhaps I should explain the table with a little bit more
>>>>> detail:
>>>>> * 1st col: The *target* frequency. The RX was tuned to this
>>>>> frequency.
>>>>> The TX was tuned to that frequency + an offset (in this case,
>>>>> 50KHz
>>>>> for
>>>>> all datapoints).
>>>>> * 2nd col: Where the tone is expected to land, both bin and
>>>>> (baseband)
>>>>> frequency; in this case, a 50KHz offset for all datapoints,
>>>>> which
>>>>> corresponded to bin 524 with a 2^20 FFT.
>>>>> * 3rd col: where the tone was observed (both bin and
>>>>> frequency).
>>>>> * 4th col: difference between the target and expectation
>>>>> * 5th col: dsp freq (from uhd::tune_result_t.actual_dsp_freq)
>>>>> * 6th col: what the difference would be if I offset the
>>>>> observed
>>>>> frequency by the claimed dsp frequency
>>>>> 
>>>>> Dustin
>>>>> 
>>>> Right, I understand the chart now.
>>>> 
>>>> So, this is rather odd.
>>>> 
>>>> I assume this is under timed commands, yes?  What happens if you
>>>> don't
>>>> use timed commands--just to check to see
>>>> if the DSP frequency change is getting skipped under timed
>>>> commands?
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
> 

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

Re: [USRP-users] Poor Data Rates with the USRP E312

[Marcus D Leech via USRP-users]

The E31x series really are intended for applications where all the high sample 
rate stuff happens in the FPGA. 

The ARM cpu is only dual core and runs at under 1Ghz. 

The scenario you describe is a lot like what we used to call “network mode” for 
the E31x, and it was never recommended for that type of scenario. 





Sent from my iPhone

> On Nov 22, 2020, at 9:21 PM, Joe Crossen via USRP-users 
>  wrote:
> 
> 
> Hi all, 
> 
> I'm attempting to use the USRP E312 as a wifi node using the gr-ieee802.11 
> module... 
> though for now I'm testing basic USRP functionality with a couple of simple 
> GNU graphs. 
> 
> Here's my setup:
> - the host is an Ubuntu 18.04 virtual machine with a bridged adaptor. 
> Firewall disabled. 
> - the USRP is the E312, connected via ethernet to the host network.  
> - the host and USRP are both running GR3.8 and UHD4.0 (Zeus branch). 
> - the host can see the USRP with uhd_usrp_probe.
> - the USRP is running the following GNU graph - UHD:USRP Source -> UDP Sink.
> - host is running the following GNU graph - UDP Source -> QT GUI Sink.
> - all block parameters are default.
> 
> I'm experiencing the following issues:
> 1. For sample rates > ~2Msps, the USRP spams overrun "O" and "D" characters 
> (what does the "D" signify?) , regardless of whether the host graph is 
> running or not.
> 2. At any sample rate the host graph spams the following message (when the 
> USRP graph is running) - "gr::log :WARN: udp_source0 - Too much data; 
> dropping packet."
> 
> And a question:
> 3. What sample rates are realistic for this setup, and what are the 
> limitations? wifi channels span 20MHz, so I'm hoping to run at 20Msps
> 
> Thanks,
> Joe
> 
> 
> 
> 
> ___
> 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