[USRP-users] Re: "buffer_double_mapped :warning: allocate_buffer:" for dvbt_rx_8k.grc

[Marcus D. Leech]

On 07/10/2024 12:43, h57jaf...@gmail.com wrote:


Hi, I am running “dvbt_rx_8k.grc” with sample ts file. The result save 
to the output file and also with UDP sink I can see the video stream 
in the vlc. But every time it stop after a while and generated output 
ts file with fixed size of 25.2MB. here is the warning I receive gnu 
radio:


QSocketNotifier: Can only be used with threads started with QThread

buffer_double_mapped :warning: allocate_buffer: tried to allocate 10 
items of size 6048. Due to alignment requirements 128 were allocated. 
If this isn't OK, consider padding your structure to a power-of-two 
bytes. On this platform, our allocation granularity is 4096 bytes.


buffer_double_mapped :warning: allocate_buffer: tried to allocate 43 
items of size 1504. Due to alignment requirements 128 were allocated. 
If this isn't OK, consider padding your structure to a power-of-two 
bytes. On this platform, our allocation granularity is 4096 bytes.


buffer_double_mapped :warning: allocate_buffer: tried to allocate 4 
items of size 48384. Due to alignment requirements 16 were allocated. 
If this isn't OK, consider padding your structure to a power-of-two 
bytes. On this platform, our allocation granularity is 4096 bytes.


buffer_double_mapped :warning: allocate_buffer: tried to allocate 10 
items of size 6048. Due to alignment requirements 128 were allocated. 
If this isn't OK, consider padding your structure to a power-of-two 
bytes. On this platform, our allocation granularity is 4096 bytes.


buffer_double_mapped :warning: allocate_buffer: tried to allocate 40 
items of size 1632. Due to alignment requirements 128 were allocated. 
If this isn't OK, consider padding your structure to a power-of-two 
bytes. On this platform, our allocation granularity is 4096 bytes.


buffer_double_mapped :warning: allocate_buffer: tried to allocate 10 
items of size 6048. Due to alignment requirements 128 were allocated. 
If this isn't OK, consider padding your structure to a power-of-two 
bytes. On this platform, our allocation granularity is 4096 bytes.


any solution. thank you.


This is the wrong mailing list for Gnu Radio questions, particularly GR 
questions about a very-specific GR-based application.


Use the discuss-gnuradio mailing list instead.

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

[USRP-users] Re: Antena selection with RFNoC

[Marcus D. Leech]

On 07/10/2024 08:04, Maria Muñoz wrote:

Hi all,

We are using UHD 4.0 with RFNoC and GNURadio in an E320 device.

We've always used the RF-A antenna channel without problems, but now 
we are trying to use the RF-B channel and are unsure how to configure 
the rfnoc radio block to do that.
We have also tried to put both channels receiving and transmitting but 
only the RF-A LEDs are on. We do the same with the UHD source block, 
and it works that way.

How can we configure the RFNoC radio block second channel?

Kind Regards,

Maria


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
If you look at the rfnoc_rx_to_file.cpp example, it has two parameters 
on the command line:


"radio-id"

and "radio-chan"

That correspond to the parameters you need when using RFNoC

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

[USRP-users] Re: Using 10GbE to stream receiver data to remote FPGA

[Marcus D. Leech]

On 05/10/2024 15:54, steve.wake...@roke.co.uk wrote:


Thanks, I am struggling to see how this would connect to the RFNOC 
block. Are there any examples as to how the RFNOC block is architected 
to allow a remote streamer?


Thanks


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Assuming your "stuff" terminates in an RX streamer block, I think this 
sets it up:


https://files.ettus.com/manual/page_stream.html#stream_remote

But I don't know about architectures that might side-step the streaming 
blocks in RFNoC.


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

[USRP-users] Re: ADC saturation problem in USRP X310

[Marcus D. Leech]

On 18/10/2024 11:35, je.amg...@gmail.com wrote:


Hello,

I am currently facing an issue with ADC saturation on a USRP X310 
equipped with a UBX daughterboard. We are conducting measurements 
using an LTE signal and a sinusoidal input signal, but it seems that 
the ADC is saturating, leading to a loss of dynamic range in our 
measurements.


Test context:
We are transmitting (using a generator) an LTE signal with a power of 
-50 dBm at a center frequency of 1815 MHz. Then, we add a sinusoidal 
signal at 1865 MHz with a power of -30 dBm. This second, more powerful 
signal seems to be causing the ADC to saturate, even though we don’t 
see it directly in the IQ samples due to the digital filtering applied 
downstream.


Problem:
We suspect that the ADC saturation occurs before IQ conversion and is 
therefore masked by the digital filters. This results in a loss of 
dynamic range in our measurements, and we feel that adjusting the gain 
based on the IQ samples may not be reliable.


Question:
How can this ADC saturation be detected upstream of the IQ processing? 
Are there tools or methods to directly monitor the sample values at 
the output of the ADC in the USRP (before digital filtering) to 
prevent saturation?
Do you have any advice for implementing an automatic gain controller 
(AGC) based on reliable saturation indicators?
We would appreciate any suggestions or experiences in resolving this 
issue. If you have encountered a similar problem or have ideas on how 
to address it, we would be happy to hear your recommendations.


Thank you very much for your help!


A -30dBm signal applied at the antenna inputs, and then amplified 
greatly by the amplifier/mixer/gain-chain ahead of the ADC
  would very-likely saturate the ADC.   A -30dBm signal from an "over 
the air" antenna is one that is thunderingly loud in
  the real world.  It would not surprise me to find that gain elements 
ahead of the ADC are *also* becoming non-linear.


Turn your gain down.

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

[USRP-users] Re: ADC saturation problem in USRP X310

[Marcus D. Leech]

On 18/10/2024 12:06, Brian Padalino wrote:
Your options are to sample at 184.32 MHz and decimate in the host 
machine down to 30.72 MHz for LTE decoding, or if that isn't an option 
then you need to place an RFNoC block at the output of the radio but 
before the DDC which will give you an input power estimate that you 
can read from the host periodically.  You need to feed that into your 
AGC algorithm as another input.


Note the block can just update an internal register that you poll and 
not produce any samples.


Brian
Without knowing much about LTE DSP and DR requirements, once your gain 
level is at a level where you have adequate SNR in most
  cases, then the only thing remaining is if your downstream DSP 
algorithms require that samples be in the "saturated" {-1,+1}

  domain, that can be done DSP-wise without ever touching the RF gain.




On Fri, Oct 18, 2024 at 11:57 AM Patrice PAJUSCO 
 wrote:


Dear Marcus,

thank you for your answer. Just to clarify the problem a little
better.
We use a UBX160 daughter card.
To have optimal SNR, an automatic gain control has been
implemented based on the max IQ value.
The sample rate is 30.72 for LTE decoding.
Unfortunately, high power exists outside our useful band (30.72
MHz) but inside the bandwidth of the 160 daughter card (sampled by
the 200 MHz ADC).
We expected the AGC to saturate... but after DSP filtering process
by the motherboard, the IQ samples got with UHD is no longer
saturated.
As a result, the IQ max is low enough and AGC control continue to
increase the gain :-(
It is my current understanding of the situation.
Is there any way to have an estimate of the raw AGC input level
when the sample rate is not 200 MHz?
I hope to be clear enough... but surelty  not crystal clear :-)
Best regards

  Patrice

----
    *De: *"Marcus D. Leech" 
*À: *"usrp-users" 
*Envoyé: *Vendredi 18 Octobre 2024 17:38:43
*Objet: *[USRP-users] Re: ADC saturation problem in USRP X310

On 18/10/2024 11:35, je.amg...@gmail.com wrote:
>
> Hello,
>
> I am currently facing an issue with ADC saturation on a USRP X310
> equipped with a UBX daughterboard. We are conducting measurements
> using an LTE signal and a sinusoidal input signal, but it seems
that
> the ADC is saturating, leading to a loss of dynamic range in our
> measurements.
>
> Test context:
> We are transmitting (using a generator) an LTE signal with a
power of
> -50 dBm at a center frequency of 1815 MHz. Then, we add a
sinusoidal
> signal at 1865 MHz with a power of -30 dBm. This second, more
powerful
> signal seems to be causing the ADC to saturate, even though we
don’t
> see it directly in the IQ samples due to the digital filtering
applied
> downstream.
>
> Problem:
> We suspect that the ADC saturation occurs before IQ conversion
and is
> therefore masked by the digital filters. This results in a loss of
> dynamic range in our measurements, and we feel that adjusting
the gain
> based on the IQ samples may not be reliable.
>
> Question:
> How can this ADC saturation be detected upstream of the IQ
processing?
> Are there tools or methods to directly monitor the sample values at
> the output of the ADC in the USRP (before digital filtering) to
> prevent saturation?
> Do you have any advice for implementing an automatic gain
controller
> (AGC) based on reliable saturation indicators?
> We would appreciate any suggestions or experiences in resolving
this
> issue. If you have encountered a similar problem or have ideas
on how
> to address it, we would be happy to hear your recommendations.
>
> Thank you very much for your help!
>
>
A -30dBm signal applied at the antenna inputs, and then amplified
greatly by the amplifier/mixer/gain-chain ahead of the ADC
   would very-likely saturate the ADC.   A -30dBm signal from an
"over
the air" antenna is one that is thunderingly loud in
   the real world.  It would not surprise me to find that gain
elements
ahead of the ADC are *also* becoming non-linear.

Turn your gain down.

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

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

[USRP-users] Re: Assistance with RFNoC Keep-One-In-N Block For Radiometer Application

[Marcus D. Leech]

On 16/10/2024 20:55, Ekin Su Sacin wrote:

Hello,

I am working on modifying rfnoc_keep_one_in_n.v code for a Dicke 
radiometer application. My goal is to generate a Dicke clock for 
different modes and to obtain the accumulated power of the incoming 
signal over half of the Dicke cycle. I am using this block to produce 
a Dicke clock from front-panel GPIO and using the n register to define 
different modes in addition to defining the number of kept samples. 
These modes determine which GPIO pins will be active. Additionally, I 
use the complex_to_magsq module to compute the power of the incoming 
signal. I have verified the Dicke clock output from GPIO using an 
oscilloscope. It responds correctly to changes in the n value at the 
application level.


When I try to sample a sinusoidal wave, it produces the sawtooth 
pattern for kept samples which looks correct. Initially, I thought 
that by adjusting the n value and data rate at the application level 
to cover half of the Dicke cycle, I could obtain accumulated results 
over this period, which would match the last value of the sawtooth. 
However, this approach isn't working as expected. I am using a 200 MHz 
clock, resulting in a half-Dicke period of 327.68 µs. To match this, I 
set the data rate to ensure an integer number of samples per Dicke 
period, such as 25 MSPS. I ran the following command for testing: 
./rfnoc_rx_to_file --args addr=192.168.10.2 --freq 28e6 --nsamps 0 
--rate 25e6 --block-id KeepOneInN --n_value 8192,and for testing, I 
applied a 27 MHz sinusoidal input. However, this setup yields 
inconsistent results. When I change the rate to 20 MSPS or other 
values, the results seem more accurate. I also experimented with 
different n values like 4, 20, and 40, which produced sawtooth 
patterns with varying periods as expected. However, my primary goal is 
to gather data specifically at the end of each half-Dicke cycle rather 
than picking samples during the cycle.


I suspect there may be a synchronization issue between the block and 
the Dicke clock. Could you provide suggestions based on my objectives, 
or is there an alternative approach that might be more effective than 
adjusting the n value? I am also adding modified parts of the code below.


Thank you in advance for your support. I look forward to your response.

Best regards,

Ekin


In output state machine, sample_reg[31:16]   <= v1o[31:16];
                sample_reg[15:0]  <= v2o[31:16];

...

always @(posedge clk) begin
if (reset) begin
   k <= 0;
         dicke_1 <= 0;
         dicke_ch <= 0;
         ctrl_cal_1 <= 0;
         ctrl_ref_1 <= 0;
         ctrl_v_1 <= 0;
         v1o <= 32'd0;
         v2o <= 32'd0;
end

else if (~reset) begin
k <= k+1;
if (k == 65536) begin // yields dicke freq = 1.53 kHz
      k <= 0;
      dicke_1 <= ~dicke_1;
      dicke_ch <= 1;
end

if (dicke_ch == 1) begin  // if dicke clock phase changed
  if (n == 4) begin // Ref-V
   if (~dicke_1) begin
      ctrl_cal_1 <= 0;
      ctrl_ref_1 <= 1;
      ctrl_v_1 <= 0;
   end else begin
      ctrl_cal_1 <= 0;
      ctrl_ref_1 <= 0;
      ctrl_v_1 <= 1;
   end
 end
 else begin  // Cal-Ref (mode 1 for anything else)
   if (~dicke_1) begin
      ctrl_cal_1 <= 1;
      ctrl_ref_1 <= 0;
      ctrl_v_1 <= 0;
   end else begin
      ctrl_cal_1 <= 0;
      ctrl_ref_1 <= 1;
      ctrl_v_1 <= 0;
   end
 end
 dicke_ch <= 0;   v1o <= 32'd0;  v2o <= 32'd0;
end
                 else if (dicke_ch==0) begin
                      if (s_axis_tvalid && s_axis_tready && o_tvalid) 
begin

                          if (dicke_1 == 0) begin
       v1o <= v1o + o_tdata;
                           end
                           else if (dicke_1 == 1) begin
                               v2o <= v2o + o_tdata;
                           end
                      end
        end
end
   end

99% of the folks on here would have no idea what a Dicke Radiometer 
is.    I do.  But unfortunately, I'm not much of an FPGA guy.


You haven't mentioned which USRP you're using, with which 
daughtercard(s).  What are your ultimate bandwidth requirements?


Given your "test" frequency of 28MHz, I'm guessing this is some kind of 
HF radiometer, so I can't imagine that you're
  dealing with "eye-watering" bandwidth.  Have you considered a purely 
host-based implementation?  Gain drift in
  modern RF hardware is small enough, and slow enough, that a fairly 
"lazy" Dicke-switching cadence could probably
  be used, and it could probably be managed from the host side.  Due to 
uncertainties of how many samples there may
  be "in flight", my approach to this in the (distant, mind) past has 
been to simply discard some samples after a state-change
  of the Dicke hardware.  This has negligible impact on radiometer 
sensitivity.


I'm able to do 50Msps of simple radiometer-like "things" into a host 
computer that is 11 years old.   So with more modern
  PC hardware, this shouldn't be a problem to manage

[USRP-users] Re: Assistance with RFNoC Keep-One-In-N Block For Radiometer Application

[Marcus D. Leech]

On 17/10/2024 03:56, Martin Braun wrote:
I'm one of the 99% and I didn't even bother to Google what a Dicke 
radiometer is. Nor do I have even half of Marcus' RF and RA knowledge.


But I know a thing or two about RFNoC. Here's what I gather from your 
email:

- You are capturing a radio signal from some source
- You are also generating a clock signal (which presumably gets 
applied to your capture device?)
  - I'm guessing that this clock signal controls which part of the 
time domain signal you're actually capturing, but the USRP's receiver 
will be free-running, so if you're not capturing continuously, that 
means you have gaps in your Rx signal you want to remove? (Again, just 
guessing)

- You are having trouble synchronizing

Now my mission here is usually to steer people successfully towards 
RFNoC (and what you've done already is pretty impressive), but in this 
case I agree with Marcus that a software approach might be sufficient. 
Can you not simply generate your Dicke-clock-signal in software and 
generate it on the B-side of your device, instead of on the GPIO? 
USRPs will take care of synchronizing Tx and Rx signals in time (with 
some offset, but that can be calibrated and you seem perfectly capable 
of doing so). This seems more like a GNU Radio task than an RFNoC task.


If not, then I blame my ignorance in this particular field -- maybe 
you can ask a more specific question.


--M
So, a *simple* radiometer is a radio that measures the emitted power of 
some phenomenon--usually of natural origins.
  Used in various science disciplines where radio might play a role, 
and in Radio Astronomy in particular.    Passive meteorology

  also uses radiometers to measure various things.

Now, a *Dicke* radiometer (named after the inventor) acknowledges that 
receiver chains aren't perfect, and in particular, have
  gains that aren't perfectly stable over "extended" (for various 
values of "extended") time-scales.   So, Robert Dicke, in 1946,
  invented a type of radiometer that allows you to "factor out' most of 
the gain variability of a system.  It's simple enough.
  Arrange for the input of your receiver to be switched between the 
"measured value/phenomenon" and a stable noise source
  arranged to produce a noise level that is comparable to the thing 
you're measuring.    In a hardware Dicke Radiometer, it's
  easy enough to synchronize your switching waveform (that switches the 
front-end between "thing" and "noise source"), and
  the detector machinery--a simple approach that I've seen used is to 
have the output of the detector stage inverted prior
  to being processed by a hardware integrator.  In this way, the 
integrator gives you a (stabilized value) that is the difference

  between "thing" and "noise source".

Flash forward several decades to using digital signal processing chains 
for this, and you end up dealing with some amount
  of uncertainty about which samples correspond to which switching 
state of the Dicke Switching machinery.    So the radio
  needs, at some level, to help with this.   One approach is to tag 
samples somehow.  Another approach is to have the chain
  just sort of "know" what the cadence is and arrange  buffering to 
exactly match the cadence.    Still another would be to
  have your integrator block in the radio "know" that it's time to deal 
with inverted samples or non-inverted samples, based

  on your switching waveform.

Still another approach would be to have your FPGA chain "tag" samples in 
a way that is *implicit*, by having the switching
  waveform perhaps assert a high-order bit in samples, or to multiply 
the samples by 1 if "thing" and maybe "4" if "noise source".
  This allows a downstream processor to sort samples into two distinct 
populations and do the required subtraction on a
  regular basis.  In many radiometer applications the noise levels 
expected from "thing" vary by only quite small amounts around
  some centroid value--in the case of a terrestrial radiometer looking 
at the sea or ground, one would expect a range of
  blackbody equivalent temperatures in the range of perhaps 250K to 
perhaps 320K, ignoring RFI, or "weird" effects.


Another approach is to have the noise source represent a noise level 
that is distinguishably-different than the noise levels
  expected from "thing" and again sort incoming samples into distinct 
populations.  This should work for many
  natural phenomenon that one might want to measure with a microwave 
radiometer, since the dynamic range of

  "thing" is typically fairly small.

Just a bit of tutorial background.  Most (not all, I admit) folks on 
here are from the telecom/wireless/SIGINT/passive-radar
  side of the "house" and may be

[USRP-users] Re: Octoclock CDA-2990 produces no signals

[Marcus D. Leech]

On 03/10/2024 16:49, shapkiqua...@gmail.com wrote:


Upon power up, the Octoclock should show all green LEDs on to the 
left. After several seconds, the “External” LED should turn off, and 
the PPS should begin to blink once per second. Instead ,this Octoclock 
simply goes frozen in a state in which the “Internal” “External” and 
“Status” LEDs remain stuck on. Nothing occurs after an hour of 
waiting. The stuck LEDs are shown in the attached image.


An oscilloscope was used to test the unit, and no signals are produced 
by any output. No PPS signals are generated, no 10MHz are seen from 
any of the front panel SMAs.


How should I proceed with troubleshooting this Octoclock?


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
The CDA-2990 is a clock *DISTRIBUTION* module.  It has no built-in GPSDO 
unit unless you have populated one.



https://www.ettus.com/all-products/octoclock/

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

[USRP-users] Re: Octoclock CDA-2990 produces no signals

[Marcus D. Leech]

On 03/10/2024 18:27, shapkiqua...@gmail.com wrote:


Dear Marcus,

Thanks for the reply. I have two of these Octoclocks and the second 
one is doing exactly what I said. It is blinking the PPS and sending a 
10MHz square wave to an SOC’s REF_CLK. This is happening right now, a 
few feet to my right. These are identical models. I can take a photo 
if you like.


On the frozen/broken unit, there is a GPSDO decal sticker on the back 
side. We have been using it for its PPS and 10MHz output signals for 
many weeks now. Both signals appear clearly on an oscilloscope. Only 
today it has failed.


What should I try now? Should I log into it via network?


Ah, indeed.  That's why I qualified my previous answer with "if there 
hasn't been a GPSDO unit fitted".


You could check the GPS antenna to make sure it's getting GPS signal, 
but the GPSDOs that are used in those units normally

  provide 1PPS and 10MHz regardless of the state of GPS lock.

You should use the official customer support channels to see if you can 
get an RMA issued for this unit:


https://www.ni.com/my-support/s/service-requests





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

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

[USRP-users] Re: Using 10GbE to stream receiver data to remote FPGA

[Marcus D. Leech]

On 05/10/2024 13:51, steve.wake...@roke.co.uk wrote:


We have a system in RFNOC that receives data at 100MSps. We want to 
stream this to a remote FPGA card over the 10GbE.


Is this possible, and if so do we need to create our own RFNOC block 
to do this or can we use UHD libraries in some way?


Tha nks.


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

This might be helpful:

https://files.ettus.com/manual/page_stream.html#stream_remote

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

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph on USRP N310

[Marcus D. Leech]

On 29/10/2024 05:43, pigatoimdeafrance...@gmail.com wrote:


Hello,

I am having trouble setting up the USRPN310. Logs of $ 
uhd_find_devices are:


ERROR: ld.so : object '/opt/uhd/lib/libuhd.so.4.4.0' 
from LD_PRELOAD cannot be preloaded (cannot open shared object file): 
ignored. [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.4.0.HEAD-0-g5fac246b



- UHD Device 0

Device Address: serial: 3249D76 addr: 192.168.20.2 claimed: False 
fpga: XG mgmt_addr: 192.168.10.2 mgmt_addr: 192.168.20.2 name: 
ni-n3xx-3249D76 product: n310 type: n3xx


The command $ uhd_usrp_probe highlights issues regarding the host-USRP 
connection:


ERROR: ld.so : object '/opt/uhd/lib/libuhd.so.4.4.0' 
from LD_PRELOAD cannot be preloaded (cannot open shared object file): 
ignored. [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.4.0.HEAD-0-g5fac246b [INFO] [MPMD] Initializing 1 device(s) in 
parallel with args: 
mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=3249D76,name=ni-n3xx-3249D76,fpga=XG,claimed=False,addr=192.168.20.2 
[WARNING] [MPM.RPCServer] A timeout event occured! [INFO] 
[MPM.PeriphManager] init() called with device args 
`fpga=XG,mgmt_addr=192.168.10.2,name=ni-n3xx-3249D76,product=n310,clock_source=internal,time_source=internal'. 
[ERROR] [RFNOC::MGMT] EnvironmentError: IOError: recv error on socket: 
Connection refused [ERROR] [RFNOC::GRAPH] IO Error during GSM 
initialization. EnvironmentError: IOError: recv error on socket: 
Connection refused [ERROR] [RFNOC::GRAPH] Caught exception while 
initializing graph: EnvironmentError: IOError: recv error on socket: 
Connection refused Error: RuntimeError: Failure to create rfnoc_graph.


Can anybody help me with this? Thanks.

Regards,

Francesco


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

Can you ping the N310 at the given address?

Is your firewall configured to allow packets to port 49152?

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

[USRP-users] Re: X310 - RfnocError: OpTimeout: Control operation timed out waiting for ACK

[Marcus D. Leech]

On 24/10/2024 16:36, c1337rog...@gmail.com wrote:


Hi all,

My setup: Ubuntu 20.04, UHD_4.7.0.HEAD-0-ga5ed1872, DPDK_19.11, X310 
w/ newly updated XG image, Intel X710 NIC


I’m trying to get DPDK working with the X310 but I’m failing on step 
0. Running any of the example programs (without DPDK for now) gives me 
the same error:

|
/usr/local/lib/uhd/examples$ ./benchmark_rate --rx_rate 10e6 
--rx_channels 1 --args addr=192.168.30.2,second_addr=192.168.41.2|


|[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; DPDK_19.11; 
UHD_4.7.0.HEAD-0-ga5ed1872|


|[00:00:00.000200] Creating the usrp device with: 
addr=192.168.30.2,second_addr=192.168.41.2...|


|[INFO] [X300] X300 initialization sequence...|

|[INFO] [X300] Maximum frame size: 8000 bytes.|

|[INFO] [X300] Maximum frame size: 8000 bytes.|

|[INFO] [X300] Radio 1x clock: 200 MHz|

|[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: 
RfnocError: OpTimeout: Control operation timed out waiting for ACK|


|Error: RuntimeError: Failure to create rfnoc_graph.|

I know the 192.168.41.2 address is non-standard… this is correct 
though and I can ping both addresses just fine. There’s no errors when 
running uhd_find_devices. uhd_usrp_probe fails with the same error as 
the example programs.


Any thoughts on what’s wrong here? Disclaimer: this X310 is a 
community resource so I can’t speak to the full pedigree. I did just 
update the FPGA after a fresh UHD 4.7 install and image_downloader run


Thanks,

Chris


Try running with just a single address.  Particular for things like 
uhd_usrp_probe, you don't need both ports.  Then you can move on

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

[USRP-users] Re: Drop packets and sequence errors during X410 DPDK benchmark test

[Marcus D. Leech]

On 29/10/2024 19:38, dhpanch...@gmail.com wrote:


Hi,

I’m trying to conduct the UHD benchmark test using DPDK on X410 radio. 
I’m using the NI Dual 100 Gigabit Ethernet PCIe NIC card, using the 
Mellanox drivers, and have the UC_200 fpga image loaded on the radio. 
However, I keep experiencing packet drops and sequence errors when I 
do that. Any idea why that’s happening?


/usr/local/lib/uhd/examples$ sudo ./benchmark_rate --args 
"type=x4xx,product=x410,addr=192.168.20.3,mgmt_addr=192.168.1.3,use_dpdk=1" 
--priority "high" --multi_streamer --rx_rate 245.76e6 --rx_subdev 
"B:1" --tx_rate 245.76e6 --tx_subdev "B:0"


[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11; 
UHD_4.7.0.HEAD-0-ga5ed1872


EAL: Detected CPU lcores: 32

EAL: Detected NUMA nodes: 1

EAL: Detected shared linkage of DPDK

EAL: Multi-process socket /var/run/dpdk/rte/mp_socket

EAL: Selected IOVA mode 'VA'

EAL: No available 1048576 kB hugepages reported

EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :01:00.0 
(socket 0)


EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :01:00.1 
(socket 0)


TELEMETRY: No legacy callbacks, legacy socket not created

[00:00:00.000109] Creating the usrp device with: 
type=x4xx,product=x410,addr=192.168.20.3,mgmt_addr=192.168.1.3,use_dpdk=1...


[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.1.3,type=x4xx,product=x410,serial=328AFD7,name=ni-x4xx-328AFD7,fpga=UC_200,claimed=False,addr=192.168.20.3,use_dpdk=1


[INFO] [MPM.PeriphManager] init() called with device args 
`fpga=UC_200,mgmt_addr=192.168.1.3,name=ni-x4xx-328AFD7,product=x410,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'.


Using Device: Single USRP:

Device: X400-Series Device

Mboard 0: x410

RX Channel: 0

RX DSP: 0

RX Dboard: B

RX Subdev: 1

TX Channel: 0

TX DSP: 0

TX Dboard: B

TX Subdev: 0

[00:00:01.970153754] Setting device timestamp to 0...

[00:00:01.971248509] Testing receive rate 245.76 Msps on 1 channels

Setting TX spb to 1992

[00:00:01.972147276] Testing transmit rate 245.76 Msps on 1 channels

U[D00:00:02.502074084] Detected Rx sequence error.

U[D00:00:03.501866063] Detected Rx sequence error.

U[D00:00:04.501965973] Detected Rx sequence error.

U[D00:00:05.501905705] Detected Rx sequence error.

U[D00:00:06.501533956] Detected Rx sequence error.

U[D00:00:07.501567020] Detected Rx sequence error.

U[D00:00:08.501554331] Detected Rx sequence error.

U[D00:00:09.501610267] Detected Rx sequence error.

U[D00:00:10.501971471] Detected Rx sequence error.

U[D00:00:11.501931301] Detected Rx sequence error.

[00:00:11.973155250] Benchmark complete.

Benchmark rate summary:

Num received samples: 2344330478

Num dropped samples: 113209128

Num overruns detected: 0

Num transmitted samples: 2335492512

Num sequence errors (Tx): 0

Num sequence errors (Rx): 10

Num underruns detected: 10

Num late commands: 0

Num timeouts (Tx): 0

Num timeouts (Rx): 0

Done!


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
I don't think "multi_streamer" is going to do anything for you here, 
since you're only configuring a single channel in each direction.
  I *THINK* multi_streamer will have ZERO effect, but you could try 
again without it.


Doing the math, your system is trying to move about 2Gbyte/second 
into/out-of that NIC, and it may be running out of

  bus bandwidth and/or CPU.

I assume that you've configured your CPU for "Performance" mode?

IF you cut the sample-rate in half, do you still see this problem?

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

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph on USRP N310

[Marcus D. Leech]

On 29/10/2024 12:53, pigatoimdeafrance...@gmail.com wrote:


Yes, both SFP+ ports are connected to the host.

Host side, the ip addresses are:


|enp3s0f0: flags=4163 mtu 9000|

|inet 192.168.20.1 netmask 255.255.255.0 broadcast 0.0.0.0|

|ether 7c:c2:55:7b:35:7e txqueuelen 1000 (Ethernet)|

|RX packets 4616 bytes 432264 (432.2 KB)|

|RX errors 0 dropped 90 overruns 0 frame 0|

|TX packets 2518 bytes 1371160 (1.3 MB)|

|TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0|


|enp3s0f1: flags=4163 mtu 9000|

|inet 192.168.10.1 netmask 255.255.255.0 broadcast 0.0.0.0|

|ether 7c:c2:55:7b:35:7f txqueuelen 1000 (Ethernet)|

|RX packets 1226 bytes 945608 (945.6 KB)|

|RX errors 0 dropped 198 overruns 0 frame 0|

|TX packets 15263 bytes 18973321 (18.9 MB)|

|TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0|


whereas N310 the interfaces are:


|sfp0 Link encap:Ethernet HWaddr 00:80:2F:34:A1:BD|

|inet addr:192.168.10.2 Bcast:192.168.10.255 Mask:255.255.255.0|

|UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1|

|RX packets:3403 errors:0 dropped:0 overruns:0 frame:0|

|TX packets:1079 errors:0 dropped:0 overruns:0 carrier:0|

|collisions:0 txqueuelen:1000|

|RX bytes:869430 (849.0 KiB) TX bytes:62857 (61.3 KiB)|

|sfp1 Link encap:Ethernet HWaddr 00:80:2F:34:A1:BE|

|inet addr:192.168.20.2 Bcast:192.168.20.255 Mask:255.255.255.0|

|UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1|

|RX packets:3775 errors:0 dropped:0 overruns:0 frame:0|

|TX packets:403 errors:0 dropped:0 overruns:0 carrier:0|

|collisions:0 txqueuelen:1000|

|RX bytes:338406 (330.4 KiB) TX bytes:603205 (589.0 KiB)|

Both 192.168.20.2 and 192.168.10.2 can be pinged correctly.


“udpv“ protocol was a typo of mine. The output of cmd |$sudo 
firewall-cmd --list-ports| is:


|49152/udp|


In the past when this has happened, it was due to swapping the cables on 
the two ports.    Check that.


If that doesn't work, trying temporarily disabling your firewall entirely.

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

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph on USRP N310

[Marcus D. Leech]

On 29/10/2024 11:42, pigatoimdeafrance...@gmail.com wrote:


Hi Marcus,

N310 can be pinged with both addresses.

I set up port 49152 and should be listed:


$sudo firewall-cmd --list-ports

49152/udpv


however, the problem still persists



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
WHe
When you say "both ports", do you mean that you have both SFP+ ports 
connected to your host?  Can you confirm the IP
  address configuration of your host NICs, and the addresses on the 
N310?   On the N310 with the default FPGA image,
  that supports 1GiGe on SFP0 and 10GiGe on SFP1, the addresses are 
192.168.10.2 and 192.168.20.2.


The management (RJ-45) port is DHCP enabled by default, so it will have 
whatever address was assigned by your

  network.

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

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph on USRP N310

[Marcus D. Leech]

On 29/10/2024 11:42, pigatoimdeafrance...@gmail.com wrote:


Hi Marcus,

N310 can be pinged with both addresses.

I set up port 49152 and should be listed:


$sudo firewall-cmd --list-ports

49152/udpv

I'm not that familiar with "firewalld", but a protocol of "udpv" should 
perhaps be "udp" instead?





however, the problem still persists



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

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

[USRP-users] Re: Drop packets and sequence errors during X410 DPDK benchmark test

[Marcus D. Leech]

On 04/11/2024 20:12, dhpanch...@gmail.com wrote:


I got it work. It seems RT_RUNTIME_SHARE disabled was the culprit. I 
re-enabled it using these instructions and the benchmark worked 
without packet drops or underruns:


*Underruns Every Second with DPDK + Ubuntu*

With Linux kernels 5.10 and beyond, we have observed periodic 
underruns on systems that otherwise have no issues. These Linux kernel 
versions are the default for Ubuntu 20.04.3 LTS and later. The 
underrun issue is due to the |RT_RUNTIME_SHARE| feature being disabled 
by default in these versions of the Linux kernel (shown as 
|NO_RT_RUNTIME_SHARE|). The following procedure can be used to enable 
this feature. This process was tested on Linux kernel version 5.13; 
the procedure may be slightly different on other kernel versions. To 
determine the Linux kernel version of your system, in a terminal issue 
the command |uname -r|.


|$ sudo -s $ cd /sys/kernel/debug/sched $ cat features | tr ' ' '\n' | 
grep RUNTIME_SHARE NO_RT_RUNTIME_SHARE $ echo RT_RUNTIME_SHARE > 
features $ cat features | tr ' ' '\n' | grep RUNTIME_SHARE 
RT_RUNTIME_SHARE|


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

I never would have suspected a kernel scheduler subtlety.  But, there it is:

https://lore.kernel.org/lkml/c596a06773658d976fb839e02843a459ed4c2edf.1479204252.git.bris...@redhat.com/

It's fantastic that you found this!

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

[USRP-users] Re: Drop packets and sequence errors during X410 DPDK benchmark test

[Marcus D. Leech]

On 30/10/2024 13:38, dhpanch...@gmail.com wrote:


I had to change my 100G IP address to 192.168.120.2 and channels on 
the X410 to “A”.


I set the CPU to Performance Mode and lowered the sample rate to 
122.88e6.


However, I’m still experiencing dropped packets and sequence errors.

/usr/local/lib/uhd/examples$ sudo ./benchmark_rate --args 
"type=x4xx,product=x410,addr=192.168.120.2,mgmt_addr=192.168.1.3,use_dpdk=1" 
--priority "high" --rx_rate 122.88e6 --rx_subdev "A:1" --tx_rate 
122.88e6 --tx_subdev "A:0"


[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11; 
UHD_4.7.0.HEAD-0-ga5ed1872


EAL: Detected CPU lcores: 32

EAL: Detected NUMA nodes: 1

EAL: Detected shared linkage of DPDK

EAL: Multi-process socket /var/run/dpdk/rte/mp_socket

EAL: Selected IOVA mode 'VA'

EAL: No available 1048576 kB hugepages reported

EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :01:00.0 
(socket 0)


EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :01:00.1 
(socket 0)


TELEMETRY: No legacy callbacks, legacy socket not created

[00:00:00.94] Creating the usrp device with: 
type=x4xx,product=x410,addr=192.168.120.2,mgmt_addr=192.168.1.3,use_dpdk=1...


[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.1.3,type=x4xx,product=x410,serial=328AFD7,name=ni-x4xx-328AFD7,fpga=UC_200,claimed=False,addr=192.168.120.2,use_dpdk=1


[INFO] [MPM.PeriphManager] init() called with device args 
`fpga=UC_200,mgmt_addr=192.168.1.3,name=ni-x4xx-328AFD7,product=x410,use_dpdk=1,clock_source=internal,time_source=internal,initializing=True'.


Using Device: Single USRP:

Device: X400-Series Device

Mboard 0: x410

RX Channel: 0

RX DSP: 0

RX Dboard: A

RX Subdev: 1

TX Channel: 0

TX DSP: 0

TX Dboard: A

TX Subdev: 0

[00:00:01.954717000] Setting device timestamp to 0...

[00:00:01.955999062] Testing receive rate 122.88 Msps on 1 channels

Setting TX spp to 1992

[00:00:01.956816655] Testing transmit rate 122.88 Msps on 1 channels

U[00:00:02.575486749] Detected Rx sequence error.

DU[00:00:03.575529623] Detected Rx sequence error.

DU[00:00:04.575537036] Detected Rx sequence error.

DU[00:00:05.575477062] Detected Rx sequence error.

DU[00:00:06.575465296] Detected Rx sequence error.

DU[00:00:07.575549183] Detected Rx sequence error.

DU[00:00:08.575539569] Detected Rx sequence error.

DU[00:00:09.575532702] Detected Rx sequence error.

DU[00:00:10.575479853] Detected Rx sequence error.

DU[00:00:11.575464597] Detected Rx sequence error.

D[00:00:11.958336752] Benchmark complete.

Benchmark rate summary:

Num received samples: 1176736199

Num dropped samples: 52167456

Num overruns detected: 0

Num transmitted samples: 1168152624

Num sequence errors (Tx): 0

Num sequence errors (Rx): 10

Num underruns detected: 10

Num late commands: 0

Num timeouts (Tx): 0

Num timeouts (Rx): 0

Done!


My /root/.config/uhd.conf file:

[use_dpdk=1]

dpdk_mtu=9000

dpdk_driver=/usr/lib/x86_64-linux-gnu/dpdk/pmds-22.0/

dpdk_corelist=10,11

dpdk_num_mbufs=4095

dpdk_mbuf_cache_size=315

[dpdk_mac=b8:3f:d2:b0:d7:58]

dpdk_lcore = 11

dpdk_ipv4 = 192.168.120.33/24

#dpdk_num_desc = 4096


I have attached screenshot of the performance GUI and system monitor 
of the CPU usage



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

This is on a "bare metal" system, and NOT on a VM, I assume?

I just ran a test (using a different USRP) doing 125Msps of receive into 
my system, over a cheap 10GiGe card.  Worked without
  ANY dropped samples--just using the "benchmark_rate" application as 
you have.  My system is a 8-year-old dual-chip,
  6-core Xeon system with 32G of memory, running on Ubuntu 22.04. Your 
system SHOULD be capable of MUCH more.



I assume you've followed the various bits of advice here:

https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#Increasing_Ring_Buffers

I wonder if you have a PHY-layer issue with your cabling?



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

[USRP-users] Re: Signal Distortion and Phase Issues with USRP B210

[Marcus D. Leech]

On 11/11/2024 10:10, Marcus Müller wrote:


Hello!

Regarding what you see in trailing, my guess is that this is the step 
response of the built-in DC offset cancellation filter; "DC offset 
cancellation" is high-pass filter behaviour. This affects only 
frequencies in your signal that are very low. It is meant to remove 
imperfections that happen on every quadrature mixer&ADC device. So, 
unless you really see a problem with the signal itself, this is 
probably fine! You say you have an issue with this, but don't explain 
the actual issue.


The phase in that trailing part can remain constant, that's OK. The 
step response of a real-valued filter is real, and you should simply 
see the phase of the last output sample at the moment of "input 
switchoff".


Regarding "Amplitude and Signal length": I can't really tell what 
you're showing us here. What kind of signal did you feed into the 
USRP? Where does it come from? At which frequency? What is the USRP 
tuned to? What's its sample rate? Most importantly: What is it that 
worries you about this? As far as I can tell, this might seem normal, 
and not an issue!



Best regards,
Marcus

What type of signal?  Narrowband signals can be considerably more 
affected by DC-offset correction than wideband
  signals.  One can use offset-tuning to move the signal outside the 
"view" of the DC-offset correction.  The second

  argument to "tune_request" allows you to specify an offset.

Also, how are these devices connected?  "Over the air" or with a cable.  
If with a cable, please ensure that there's
  adequate attenuation in the cable to prevent overload or even damage 
to the B210 front-end.




On 11.11.24 14:18, yibinden...@outlook.com wrote:


Hi everyone,

I'm working on a project where I generate a signal and simultaneously 
receive it using both the Pluto SDR and the USRP B210. However, I’m 
running into some unexpected issues with the B210's reception, and 
I’m hoping for some guidance.


Here are the main problems I’m encountering:

*Signal Trailing*: As shown in the figures, The signal received by 
the Pluto has clear boundaries, while the signal received by the B210 
has noticeable trailing compared to the Pluto.


*Strange Phase Characteristics*: The phase behavior of the 
B210-received signal is unusual. Specifically，during the trailing 
phase of the signal, the phase remains constant, which is unexpected. 
When there is no signal, the phase appears to be chaotic.


*Amplitude and Signal Length*: As shown in the figure, when the 
signal length is relatively short, both the maximum and the average 
amplitude increase as the signal length grows.


I suspect that each sample might be significantly broadened in the 
time domain, but since I am not entirely familiar with the USRP 
B210's hardware processing, I am unsure if this is the root cause. I 
am wondering if these issues could potentially be improved by 
modifying the hardware configuration, such as adjusting the filter 
settings or other parameters. The code I’m using for the B210 
receiver is attached.


Has anyone experienced similar issues or have suggestions on 
adjusting the B210's configuration or setup to address these 
distortions? Any insights would be greatly appreciated.


Thanks in advance for your help!


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


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

[USRP-users] Re: UHD with DPDK minimum requirement

[Marcus D. Leech]

On 26/10/2024 12:15, Mehran Memarnejad wrote:

Hi,
Following the instructions on this link 
, I want to 
get the UHD work with DPDK so that I can transfer samples from E320 to 
Host.


Question 1: The PC has an Intel Core i7 CPU and I don't know whether 
it can handle a 10G NIC with DPDK or not? Does DPDK support Intel Core 
i Series?


Question 2: I have an Intel Core i7 CPU with Mellanox Connect-X 3 NIC. 
The OS is Ubuntu 18.04 and the UHD version is 4.4.0. Is this setup Ok 
for 10G NIC?


Thanks in advance for your help

___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
I'd be somewhat shocked if Ubuntu 18.04 was adequate to host any version 
of DPDK that would work with UHD 4.4.0, although
  I don't know for sure.  I don't think DPDK, per se, cares about what 
CPU family it finds itself on.  Whether your computer can'
  "handle" a 10Gig NIC depends on whether it has the appropriate PCI-e 
bus width for your card, and other things that are
  harder to definitively quantify like bus and memory bandwidth and CPU 
speed.  I run a 10G NIC on a dual-XEON server that
  is about 10 years old.  Works just fine.  But I'm running it on 
Ubuntu 22.04.  I don't use DPDK because I don't need to

  ingest samples at rates that would make DPDK necessary.



Ubuntu 18.04 is very old at this point.___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Reg. MSB (only) trasmission

[Marcus D. Leech]

On 18/09/2024 04:08, Brajesh wrote:
I am able to program N210 FPGA using newly generated .bit file. I am 
trying to transmit MSB (1-bit only ) from the N210 board and 
faithfully process these MSBs at the receiver end.


Would appreciate some information on how it can be achieved. A pointer 
or two is the need of hour.


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

You're going to need to give *WAY* more details here, Brajesh.

Where do these 1-bits come from? The host computer?  How are they 
modulated onto an RF carrier?


More details will allow people to understand what it is you're trying to 
achieve, and can possibly help you.  The above

  is, I have to say, next-to-useless for that purpose.

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

[USRP-users] Re: Automatically power on after power loss

[Marcus D. Leech]

On 19/09/2024 17:28, Eugene Grayver wrote:

Hi,

The 'soft' button on the N32x does not have an 'on' state.  The X310 
has a real button that can be pushed in.  I have remote N32x devices 
that are not (easily) accessible.  How can I make sure they power up 
after a power outage?


Thanks.

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

Eugene:

I believe that what you want is this:

https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_mg_eeprom_flags

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

[USRP-users] Re: Automatically power on after power loss

[Marcus D Leech]

Yes. There’s an identical paragraph in the same document for N32x. 

Sent from my iPhone

> On Sep 20, 2024, at 11:48 AM, Eugene Grayver  wrote:
> 
> 
> Hi Marcus,
> 
> Thanks for the quick response as usual.  The wiki says the flag is specific 
> to N310.  Does it apply to N3xx (i.e. 320/321) as well?
> 
> Thanks.
> From: Eugene Grayver
> Sent: Thursday, September 19, 2024 2:28 PM
> To: usrp-users 
> Subject: Automatically power on after power loss
>  
> Hi,
> 
> The 'soft' button on the N32x does not have an 'on' state.  The X310 has a 
> real button that can be pushed in.  I have remote N32x devices that are not 
> (easily) accessible.  How can I make sure they power up after a power outage?
> 
> Thanks.
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: KAS kirkstone build of ni-titanium-rev5 on x410 with Vitis-AI Library and DPU drivers: Mainline kernel incompatible with zocl DPU driver; possible to use linux-xlnx kernel and make ti

[Marcus D. Leech]

On 01/10/2024 12:09, mruane--- via USRP-users wrote:


Hi all!

I’m an FPGA developer, dragged into the Yocto world a few years ago 
with the move to Zynq and ZynqMP architectures. As a research group, 
we mainly develop on Xilinx dev boards like the ZCU102 MPSoC, and 
ZCU111 RFSoC.


Having recent success adding the Xillinx Deep-Learning Processor (DPU) 
to the FPGA fabric, building the Vitis-AI libraries into the rootfs, 
and accelerating ML applications on various models, we decided to move 
things over to an x410 to take advantage of the RFSoC in a complete 
SDR product.


The FPGA design was straight forward, and the Make-based FPGA build 
scripts, which I am typically not a fan of, was quite well thought 
out, worked wonderfully, and was easy to modify to customize the flow, 
and add changes to the block design. With a little digging, it was 
also fairly straightforward to incorporate the changes into the 
XSA/device tree for use in building the rootfs.


It's interesting that 48 years after "Make" first appeared in PWB Unix 
(and then later editions), the software DEV world is still
  using some form of it.   Because the need to encapsulate the 
dependency graph AND the "recipes" for building a descendant
  from an ancestor is still something that is needed--particularly for 
build automation of even modest-sized projects.


When I was a teen, I developed a text editor (which, at the time, all 
the cool kids did), and I was fortunate that, a year after
  I started it, "Make" showed up on the version of Unix we were 
using.   That made keeping track of things vastly easier

  than the ad-hoc mechanisms I had been using.

I suspect that the modern hatred for Make and its variants is because 
modern devs are used to their fave IDE having some
  kind of automated dependency tracking and recipe system as a 
built-in, and fail to recognize the need to *divorce* that
  aspect of things from what amounts to a "really fancy code 
editor".    Nobody in production wants the build recipe to be
  "OK, now click here.   Ok, select  in the menu.  Then .  
Then hit 'go'.  Ok, now, do the following 12 things."

  Which has been my experience with things like VS in the past.

One can argue about the choice of particular Make dialect, but even 
solidly into the 3rd decade of the 21st century, something

  Make-like is still a vital tool in production software development.

Ok, I admit.  This is a rant.  It doesn't answer your question in any 
useful way.    I'm afraid I'm not particularly familiar with

  The X410 and FPGA+Yocto dev flows in particular.


Incorporating the Vitis-AI libraries and DPU drivers into the 
KAS/Kirkstone/Mender/Titanium build system is another story. Long 
story short, after the typical, lengthy, Yocto debug process, it 
ultimately fails at what seems to be a kernel incompatibility between 
the mainline kernel and the Vitis-AI requirements. This particular 
time, it manifests as syntax errors in the zocl module compilation, 
though I suspect it is actually a cascading series of failures that 
can not be solved one at a time.


Researching the failure on the Xilinx forum leads to assertions that 
certain parts of the Vitis-AI libraries (as well as many other Xilinx 
applications that exercise features of the FPGA) require the Xilinx 
fork of the Linux Kernel, linux-xlnx.


Has anyone attempted to switch kernels in a UHD system, or to 
integrate the linux-xlnx kernel features into the UHD kernel?



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

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

[USRP-users] Re: x300 reset script

[Marcus D. Leech]

On 19/09/2024 12:02, cyberphox wrote:

Thank you and I look forward to hearing back from you & your colleagues.
So according to one of the FPGA folks on the "inside", there should be 
ZERO difference

  between the x300_reset.py and simply doing a power-cycle.

The reset script simply sends a special message to the ZPU, which 
immediately forces a *hard* reset on
  the FPGA--which will cause it to reset itself, and load the running 
FPGA image from the EEPROM.  This is

  exactly what happens at power-up.


On Thu, 19 Sept 2024 at 15:38, Marcus D. Leech 
 wrote:


On 19/09/2024 09:44, cyberp...@gmail.com wrote:
>
> Hi all,
>
> I am using this the x300_reset.py script to reset the FPGA and
would
> like to know a bit more about what is it resetting etc.
>
(https://github.com/EttusResearch/uhd/blob/UHD-4.0/host/utils/x300_reset.py)
>
> Power off and on does not seem to get as clean result as when I
issue
> this reset.
>
> thanks,
>
> Marino
>
>
There's not a lot of info on this utility, and it isn't officially
supported, although we've recommended its use in the past.

Most of the R&D crew at Ettus/NI/Emerson are at the Gnu Radio
conference
this week, but I've reached out to someone
   in our support org who might know.


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

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

[USRP-users] Re: x300 reset script

[Marcus D. Leech]

On 19/09/2024 09:44, cyberp...@gmail.com wrote:


Hi all,

I am using this the x300_reset.py script to reset the FPGA and would 
like to know a bit more about what is it resetting etc. 
(https://github.com/EttusResearch/uhd/blob/UHD-4.0/host/utils/x300_reset.py)


Power off and on does not seem to get as clean result as when I issue 
this reset.


thanks,

Marino


There's not a lot of info on this utility, and it isn't officially 
supported, although we've recommended its use in the past.


Most of the R&D crew at Ettus/NI/Emerson are at the Gnu Radio conference 
this week, but I've reached out to someone

  in our support org who might know.





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

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

[USRP-users] Re: KAS kirkstone build of ni-titanium-rev5 on x410 with Vitis-AI Library and DPU drivers: Mainline kernel incompatible with zocl DPU driver; possible to use linux-xlnx kernel and make ti

[Marcus D. Leech]

On 02/10/2024 20:08, mruane--- via USRP-users wrote:


Hi Marcus!

Hahaha  I thoroughly enjoyed the rant!    I think you are correct 
about Make and its variations.   Indispensable seems an understatement 
for something that is so pervasive in software development.   As I 
mentioned, I am primarily an FPGA developer.   At some point, when the 
Zynq and ZynqMP SoCs were released, the software community seemed to 
(initially, at least) scatter when they saw "FPGA" in the name, and I 
found myself inadvertently "volun-told" to be responsible for building 
Linux releases with custom drivers for my hardware. :-)  It was 
horrifying! :-)


You don't see Make involved in FPGA builds as frequently as you'd 
expect, considering the popularity of SoCs these days.  As a 
self-proclaimed "Crusty Old Hardware Guy", I'm not permitted to 
actually say out loud that I think Make is a good addition to the FPGA 
development flow... ;-)  ...but I have to admit that I've been 
pleasantly surprised by how easily all aspects of a build can be 
automated, once the initial setup is done.


I think what keeps me from jumping in completely, is that many aspects 
of FPGA development are still very much grounded in Hardware 
Development principles and techniques, processes in which a GUI is 
supremely helpful.   At the end of the day, I still need to see a 
schematic, block diagram, or wave-forms.  To that end, however, with 
the x410 UHD build, I was impressed by how straight-forward it was to 
modify the Make files and build Tcl scripts to create the project, 
build the IP, and open it in the GUI for me to inspect and continue in 
my normal FPGA-dev flow.


Hahaha   I tried to keep this short, but I apparently reply to rants 
with...more ranting.   :-)


Thanks for the reply!

Mike

I will observe that many of the doctrines which purely-software people 
take for granted, like abstraction and modularity, tend
  to be entirely-absent from the purely-hardware mindset.  There's good 
reasons for this.   Software people want to abstract away
  from the implementation details, wheres strictly hardware people, 
just want to implement the details.   FPGA "stuff" is in the

  aetherial realm that exists between the two...

Make emerged from the necessities of managing modular software, which 
necessarily meant a flotilla of source files, etc.

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

[USRP-users] Re: Ettus USRP X310 with Different Daughterboards

[Marcus D. Leech]

On 02/10/2024 20:17, Q W via USRP-users wrote:

Hello,

I just started using USRP for a project. I have a Ettus X310 with a 
UBX160, a LFTX and a LFRX installed on the motherboard. The X310 
motherboard is quite old purchased in 2016/2017. Labview is used as 
the software platform.


After connecting X310 with PC via 1G Ethernet cable, I was required to 
upgrade the firmware. Then I had a warning (see the screenshot below) 
when trying to upgrade. I didn't proceed. I contacted NI and was 
advised that in order to turn an Ettus USRP to an NI USRP, the 
daughterboards installed must be the same. Also Labview doesn't 
support the configuration with two different daughterboards. However, 
due to the requirement of the project, I will have to use these 
daughterboards to cover all the frequence bands I am interested in. I 
couldn't afford to buy a second motherboard either.


Inline image

I would like to know if it's possible to use the X310 and the 
daughterboards available to me at the moment. If NI and Labview have 
restrictions on the daughterboards, can I use other software tools 
such as UHD and Gnuradio?


Kind regards,
Tom

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

Your configuration should be supportable in a UHD+Gnu Radio environment.

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

[USRP-users] Re: First 10 Samples From First Receive Always 0

[Marcus D. Leech]

On 07/11/2024 15:46, Chris Wozny wrote:
Thank you! The sample delay induced by the filter taps makes sense. Is 
there a best practice that folks go with to deal with this or is it so 
insignificant that people don't care? I was thinking of either 
requesting 10 more samples and skipping the first 10 when writing to 
the filesystem / reading them into the software that consumes them.

I think it depends very much on the application.

There are other things that may be "surprising" if you aren't used to 
systems that sample the physical world.  If you
  start sampling right after a re-tune event, for example, there will 
inevitably be transients in the data.  This can be
  kind of unsettling for people who have spent most of their time in 
the strictly-digital world of computers and
  at the higher-layers of comms systems, where everything is already 
nicely quantized for you and delivered in

  nice neat bits...






On Thu, Nov 7, 2024 at 3:03 PM Marcus D. Leech 
 wrote:


On 07/11/2024 14:53, Chris Wozny wrote:
> I had noticed that the first ten samples of my application were
always
> coming up as zero regardless of whether it was 8-bits on host or
> 16-bits on host. I went down the path of trying to reproduce a
minimal
> example to share with this mailing list, however I then realized
that
> even the example "rx_timed_samples.cpp" was also producing the same
> results. This occurred with two different b200minis and a B210 with
> UHD 4.7.0.0. I had to de-boostify the source code to run on my
system
> and specify a center frequency and receive gain, but am able to
> reproduce this issue every time. I've confirmed that a signal is
> present by using a signal generator for one setup and also with
an OTA
> setup tuned to 2421 MHz with AGC disabled and receive gain set
to 70 dB.
>
> Has anyone observed this issue or can anyone else reproduce it
using
> the timed receive example as well? Sorry if I am missing critical
> details that would help diagnose the issue, let me know if any
> additional information would be helpful.
>
> - Chris
>
The signal must necessarily pass through some digital filtering on
the
way between the antenna and your application.
   Those digital filters have a certain length, and thus group delay.
That filter must necessarily have *some* value already
   in it prior to your samples being presented to it.

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


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

[USRP-users] Re: First 10 Samples From First Receive Always 0

[Marcus D. Leech]

On 07/11/2024 14:53, Chris Wozny wrote:
I had noticed that the first ten samples of my application were always 
coming up as zero regardless of whether it was 8-bits on host or 
16-bits on host. I went down the path of trying to reproduce a minimal 
example to share with this mailing list, however I then realized that 
even the example "rx_timed_samples.cpp" was also producing the same 
results. This occurred with two different b200minis and a B210 with 
UHD 4.7.0.0. I had to de-boostify the source code to run on my system 
and specify a center frequency and receive gain, but am able to 
reproduce this issue every time. I've confirmed that a signal is 
present by using a signal generator for one setup and also with an OTA 
setup tuned to 2421 MHz with AGC disabled and receive gain set to 70 dB.


Has anyone observed this issue or can anyone else reproduce it using 
the timed receive example as well? Sorry if I am missing critical 
details that would help diagnose the issue, let me know if any 
additional information would be helpful.


- Chris

The signal must necessarily pass through some digital filtering on the 
way between the antenna and your application.
  Those digital filters have a certain length, and thus group delay.   
That filter must necessarily have *some* value already

  in it prior to your samples being presented to it.

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

[USRP-users] Re: Trouble connecting to an x300

[Marcus D. Leech]

On 25/10/2024 13:18, Chad Spooner wrote:

All:

I'm having trouble controlling an Ettus x300 SDR using Ubuntu 22 servers.

The brief description (details below) is that I can ping the device, 
but I can't see it using

uhd_find_devices or uhd_usrp_probe or uhd_fft etc.

I've looked around on the web for tips, but nothing is helping. In 
particular,

I made sure to punch a hole in the firewall using

   sudo iptables -A INPUT -p udp --sport 49152 -j ACCEPT

Details
---
I'm using two Ubuntu 22.04.5 servers. The UHD versions are the same on 
each:


   UHD 4.1.0.5-3

One uses gnuradio 3.10.7.0 and the other 3.10.1.1.

Both servers can connect to and control an Ettus x310 with two UBX 
daughterboards;
uhd_fft runs fine. The x310 has default (10 GB) IP address of 
192.168.40.2.


The x300 has one UBX daughterboard and one WBX daughterboard. When I 
connect either
server to the x300 via 10 GB ethernet, I can ping the device at 
192.168.40.4:


cmspooner>ping 192.168.40.4
PING 192.168.40.4 (192.168.40.4) 56(84) bytes of data.
64 bytes from 192.168.40.4: icmp_seq=1 ttl=64 time=0.058 ms
64 bytes from 192.168.40.4: icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from 192.168.40.4: icmp_seq=3 ttl=64 time=0.048 ms
64 bytes from 192.168.40.4: icmp_seq=4 ttl=64 time=0.026 ms
64 bytes from 192.168.40.4: icmp_seq=5 ttl=64 time=0.027 ms
64 bytes from 192.168.40.4: icmp_seq=6 ttl=64 time=0.042 ms
^C
--- 192.168.40.4 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5104ms
rtt min/avg/max/mdev = 0.026/0.039/0.058/0.011 ms

(We set the IP address this way long ago and I've been using it 
successfully

until recently.)

But uhd_usrp_probe returns:

cmspooner>uhd_usrp_probe --args="addr=192.168.40.4"
[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
Error: LookupError: KeyError: No devices found for ->
Device Address:
    addr: 192.168.40.4

and uhd_find_devices gives:

cmspooner>uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
No UHD Devices Found

I attempted to reflash the FPGA:

cmspooner>uhd_image_loader --args="type=x300,addr=192.168.40.4"
[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
No applicable UHD devices found

I'm probably missing something simple. Any advice?

Chad
Is it possible that you set the IP addresses of your *HOST* to the 
address intended for the USRP?


Those ping times are suspiciously low.

I run an X310 on a Ubuntu 22.04 server with single 10Gbit port on the 
2nd SFP+ interface with 192.168.40.2, and it works

  just fine.





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

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

[USRP-users] Re: X310 - RfnocError: OpTimeout: Control operation timed out waiting for ACK

[Marcus D. Leech]

On 25/10/2024 13:32, c1337rog...@gmail.com wrote:


Hi Marcus,

Thank you for the suggestion. Unfortunately, this did not solve the 
issue I’m seeing. Every command that interfaces with the radio aside 
from uhd_find_devices terminates with:


|[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: 
RfnocError: OpTimeout: Control operation timed out waiting for ACK|


|Error: RuntimeError: Failure to create rfnoc_graph.|

All other communication with the radio seems to be working totally 
fine… Could this be a firewall issue?


Thanks,

Chris


Make sure that you "open up" ports 49152 and 49153 on your firewall.

Also, is it possible that you have your cables swapped?




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

[USRP-users] Re: Drop packets and sequence errors during X410 DPDK benchmark test

[Marcus D. Leech]

On 04/11/2024 20:12, dhpanch...@gmail.com wrote:


I got it work. It seems RT_RUNTIME_SHARE disabled was the culprit. I 
re-enabled it using these instructions and the benchmark worked 
without packet drops or underruns:


*Underruns Every Second with DPDK + Ubuntu*

With Linux kernels 5.10 and beyond, we have observed periodic 
underruns on systems that otherwise have no issues. These Linux kernel 
versions are the default for Ubuntu 20.04.3 LTS and later. The 
underrun issue is due to the |RT_RUNTIME_SHARE| feature being disabled 
by default in these versions of the Linux kernel (shown as 
|NO_RT_RUNTIME_SHARE|). The following procedure can be used to enable 
this feature. This process was tested on Linux kernel version 5.13; 
the procedure may be slightly different on other kernel versions. To 
determine the Linux kernel version of your system, in a terminal issue 
the command |uname -r|.


|$ sudo -s $ cd /sys/kernel/debug/sched $ cat features | tr ' ' '\n' | 
grep RUNTIME_SHARE NO_RT_RUNTIME_SHARE $ echo RT_RUNTIME_SHARE > 
features $ cat features | tr ' ' '\n' | grep RUNTIME_SHARE 
RT_RUNTIME_SHARE|


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

Just to fill people in, this appears in the DPDK document:

https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD

But NOT in the general "Performance Tuning Tips and Tricks", which is 
the one I'm most familiar with:


https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks


We will probably move that note on RT_RUNTIME_SHARE to the "Performance 
Tuning" document, or at least

  replicate it.

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

[USRP-users] Re: starting radios in parallel

[Marcus D. Leech]

On 20/11/2024 14:40, ja...@gardettoengineering.com wrote:


I have a project where I have to start up a series of N320 radios.  
Currently we do it sequentially and that can take some time.  Is there 
a way to do them in parallel? I thought I saw somewhere that the 
driver was the limiting factor for being able to have separate threads 
start up the devices at the same time to speed things up, is that 
really the case?



The multi-usrp interface will start each radio in sequence.  Is this a 
situation where you want to bring it up, do only
  a small amount of sample traffic, and then shut it down?  What is the 
use case.


You could have multiple multi_usrp objects, each in their own thread.  
That *should* work, but you'll lose the
  sample time-alignment that UHD does for radios within a single 
multi_usrp object.



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

[USRP-users] Re: Real-world experience with X440

[Marcus D. Leech]

On 15/11/2024 16:52, Eugene Grayver wrote:

Hi,

I am considering the X440 for a wideband record/playback system.  What 
benchmarks has Ettus done?


Is there any hardware out there that can continuously stream (one way, 
TX or RX) the full 8 Gsps (i.e. 2x 4 Gsps) for the combined bandwidth 
of 2x 1.6 GHz?  Assuming DPDK is used, there is still an issue with 
getting packets to/from different cores/threads.  Are the packet 
streams configurable to allow hardware-level queues that map to 
different IRQs/cores?  How does the TX side work (that's usually a lot 
harder to maintain than RX)?


Thanks.

I don't have any direct experience with X440.  But I know that newer 
versions of "benchmark_rate" have an option for
  handling different streams in different threads, so that might help 
you with your own code.


Ingesting 3.2Gsps all by itself is a compu-difficult problem, let alone 
trying to actually *DO* anything with those samples.
  It has frequently been the case with USRPs that at introduction, 
their ability to produce high-speed samples outstrips

  the ability of extant computers to ingest those samples.

I know that a LONG time ago, UHD experimented with multi-threaded 
"gather" from the network interface for even
  a single stream.  The problem that was immediately apparent was that 
the MUTEX traffic that was required, along
  with dealing with the potential re-ordering when multiple threads are 
gathering buffers of samples, lead to much

  poorer overall performance.

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

[USRP-users] Re: USRP sink with GPIO

[Marcus D. Leech]

On 19/11/2024 11:02, Tim Vancauwenbergh wrote:

Dear,

I am revisiting an issue I encountered earlier. I have a flow that 
generates pulses with spaces between them continuously. To switch 
between the RX and TX paths on a single antenna, I tried utilizing 
GPIO to control an RF switch.


Tests were conducted on a B210 and X310. Initially, I used GPIO tags 
on a USRP sink, but this caused continuous underruns. A sample rate of 
4 MHz was used. I then switched to using bursts in combination with 
ATR, but the issue persists. The USRP is unable to keep up, resulting 
in significant underruns.


My goal is to send pulses at specific times and have the GPIO state 
follow accordingly. When sending 0s or no samples, the GPIO state 
should be low; otherwise, it should be high.


Could you advise on how to achieve this? I have attached my embedded 
Python block code, which is positioned just before the USRP sink 
block. This block adds the tags for the start and end of bursts and 
handles the initial GPIO setup. For reference, I have also included 
the manual GPIO control block.


Thank you for your assistance.


Best regards,

Tim Vancauwenbergh

Generally "U" underruns are caused by your *host computer* being unable 
to "keep up" with the USRP, NOT the other
  way around.  The USRP internal performance is entirely deterministic. 
If you program it to take in 4Msps, it will

  be able to do that forever.

I'll note that Python blocks DO NOT PERFORM at the same performance 
level as C++ blocks.  By a significant margin.
  I note that in one of your blocks, you're individually iterating 
through samples looking for some kind of trigger.
  This is guaranteed to have very poor performance characteristics, and 
is unlikely to be able to "keep up" at anything

  beyond perhaps 1Msps, but that will depend very much on your computer.

Also, (and I don't know if this is your issue), you can't schedule timed 
buffers hugely in advance of when they will
  actually get scheduled on the hardware--the hardware has very little 
buffering.


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

[USRP-users] Re: B210 power and gain levels

[Marcus D. Leech]

On 20/11/2024 05:02, Marcus Müller wrote:
Depends on the gain you set, and the frequency you're working on. I 
wish I could give you a simple number or even just a graph over gain, 
but it's necessarily a two-parameter thing. You will have to measure.


At max gain, you'd expect full scale output to be achieved dep in 
the negative dBm.


Best regards,
Marcus Müller

I'll augment what my colleague has said.

The amount of gain in the path will vary over frequency--perhaps by a 
few dB.   But also from device to device,

  by 1-2dB.

The "gain" setting doesn't actually tell you anything about total RF 
gain between antenna and ADC.  It's a
  "gain control" setting, which in RF paths is nearly-always 
implemented with distributed attenuators.  The
  total gain ahead of the ADC may be more or less than 72dB. If the 
total path is gain at "MAX" is 50dB,
  then that 72dB gain-control range takes you down to a spot where you 
have -22dB of gain.


If your goal is to estimate the power at the antenna port using a 
strictly "numerical" approach based on the
  gain setting, you are in a state of sin.    You MUST calibrate over 
your entire expected operating space,
  including center frequency and sample rate, and at various gain 
settings (although the gain setting should

  be largely linear).

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

[USRP-users] Re: Runtime error

[Marcus D. Leech]

On 18/11/2024 02:19, Hamdüsena BİLGİ (BİLGEM) via USRP-users wrote:

Hello dear usrp users,

After a succesfull uhd_usrp_probe when trying to run the Ettus E320 on 
Gnu Radio I get the following error message:


QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

Qt GUI: Could not restore geometry: restoreGeometry(self, 
Union[QByteArray, bytes, bytearray]): argument 1 has unexpected type 
'NoneType'


[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_3.15.0.0-release


[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=33CB10C,name=ni-e320-33CB10C,fpga=1G,claimed=False,addr=192.168.10.2


Traceback (most recent call last):

File "/home/user/calismalar/uhd_deneme.py", line 190, in 

main()

File "/home/user/calismalar/uhd_deneme.py", line 168, in main

tb = top_block_cls()

File "/home/user/calismalar/uhd_deneme.py", line 85, in __init__

self.uhd_usrp_source_0 = uhd.usrp_source(

RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC 
function 'get_num_xbars'




I updated GNU Radio from 3.8 to 3.10. The versions on the device are:


gnuradio-config-info -v

3.10.7.0



uhd_config_info --version

UHD 4.7.0.0-0-ga5ed1872



uhd_find_devices

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.7.0.0-0-ga5ed1872


--

-- UHD Device 0

--

Device Address:

serial: 33CB10C

addr: 192.168.10.2

claimed: False

fpga: 1G

mgmt_addr: 192.168.10.2

name: ni-e320-33CB10C

product: e320

type: e3xx



python3 --version

Python 3.8.10



g++ --version

g++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0




While GNU Radio is running, it detects the UHD version as 
|UHD_3.15.0.0-release|. What could be the reason for this, and how can 
I resolve it?



___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
This is because you have a "mixed version" system on your Ubuntu 
system.  How did you upgrade Gnu Radio from

 the version packaged by Ubuntu 20.04?

It's likely that what happened was that you did a source build of Gnu 
Radio, and it found the packaged UHD library

  on your system (3.15), and used that.

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

[USRP-users] Re: LED quickly turns back off X410

[Marcus D. Leech]

On 26/11/2024 14:36, dhpanch...@gmail.com wrote:


Its a high-end ASUS desktop machine with 128 GB RAM:
description: Desktop Computer

product: System Product Name (SKU)

vendor: ASUS

version: System Version

serial: System Serial Number

width: 64 bits

capabilities: smbios-3.5.0 dmi-3.5.0 smp vsyscall32

configuration: boot=normal chassis=desktop family=To be filled by 
O.E.M. sku=SKU uuid=f3e615b3-efb6-49fa-381a-581122bbff40


*-core

description: Motherboard

product: ROG MAXIMUS Z790 HERO

vendor: ASUSTeK COMPUTER INC.

physical id: 0

version: Rev 1.xx

serial: 221011025300497

slot: Default string

*-firmware

description: BIOS

vendor: American Megatrends Inc.

physical id: 0

version: 2202

date: 04/17/2024

size: 64KiB

capacity: 16MiB

capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd 
int13floppynec int13floppytoshiba int13floppy360 int13floppy1200 
int13floppy720 int13floppy2880 int5printscreen int14serial 
int17printer int10video acpi usb biosbootspecification uefi


*-memory

description: System Memory

physical id: c

slot: System board or motherboard

size: 128GiB

*-bank:0

description: DIMM Synchronous 4200 MHz (0.2 ns)

product: KF556C40-32

vendor: Kingston

physical id: 0

serial: CE344740

slot: Controller0-DIMM0

size: 32GiB

width: 64 bits

clock: 4200MHz (0.2ns)

*-bank:1

description: DIMM Synchronous 4200 MHz (0.2 ns)

product: KF556C40-32

vendor: Kingston

physical id: 1

serial: E1345EF2

slot: Controller0-DIMM1

size: 32GiB

width: 64 bits

clock: 4200MHz (0.2ns)

*-bank:2

description: DIMM Synchronous 4200 MHz (0.2 ns)

product: KF556C40-32

vendor: Kingston

physical id: 2

serial: D0349087

slot: Controller1-DIMM0

size: 32GiB

width: 64 bits

clock: 4200MHz (0.2ns)

*-bank:3

description: DIMM Synchronous 4200 MHz (0.2 ns)

product: KF556C40-32

vendor: Kingston

physical id: 3

serial: 4A348668

slot: Controller1-DIMM1

size: 32GiB

width: 64 bits

clock: 4200MHz (0.2ns)

*-cache:0

description: L1 cache

physical id: 1d

slot: L1 Cache

size: 384KiB

capacity: 384KiB

capabilities: synchronous internal write-back data

configuration: level=1

*-cache:1

description: L1 cache

physical id: 1e

slot: L1 Cache

size: 256KiB

capacity: 256KiB

capabilities: synchronous internal write-back instruction

configuration: level=1

*-cache:2

description: L2 cache

physical id: 1f

slot: L2 Cache

size: 16MiB

capacity: 16MiB

capabilities: synchronous internal write-back unified

configuration: level=2

*-cache:3

description: L3 cache

physical id: 20

slot: L3 Cache

size: 36MiB

capacity: 36MiB

capabilities: synchronous internal write-back unified

configuration: level=3

*-cache:4

description: L1 cache

physical id: 21

slot: L1 Cache

size: 512KiB

capacity: 512KiB

capabilities: synchronous internal write-back data

configuration: level=1

*-cache:5

description: L1 cache

physical id: 22

slot: L1 Cache

size: 1MiB

capacity: 1MiB

capabilities: synchronous internal write-back instruction

configuration: level=1

*-cache:6

description: L2 cache

physical id: 23

slot: L2 Cache

size: 16MiB

capacity: 16MiB

capabilities: synchronous internal write-back unified

configuration: level=2

*-cache:7

description: L3 cache

physical id: 24

slot: L3 Cache

size: 36MiB

capacity: 36MiB

capabilities: synchronous internal write-back unified

configuration: level=3

*-cpu

description: CPU

product: Intel(R) Core(TM) i9-14900K

vendor: Intel Corp.

physical id: 25

bus info: cpu@0

version: 6.183.1

serial: To Be Filled By O.E.M.

slot: LGA1700

size: 5696MHz

capacity: 5700MHz

width: 64 bits

clock: 100MHz

capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 
apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse 
sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art 
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid 
aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx 
est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe 
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 
3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced 
tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 
smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni 
xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk avx_vnni 
dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp 
hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq tme 
rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr ibt 
flush_l1d arch_capabilities cpufreq


configuration: cores=24 enabledcores=24 microcode=297 threads=24


I’m implementing a custom-made filter block with the output data. I 
lowered the sample rate to 61.44 MHz and am still noticing the green 
light turn off when i connect the custom-made filter block to the UHD 
source block.


Also, under stream args, I set the following parameters: 
num_recv_frames=5,

[USRP-users] Re: Module Not Found Error

[Marcus D. Leech]

On 26/11/2024 00:53, Hamdüsena BİLGİ (BİLGEM) wrote:

I installed dependecies

sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig 
python3-numpy python3-mako python3-sphinx python3-lxml doxygen 
libfftw3-dev libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev 
python3-pyqt5 liblog4cpp5-dev libzmq3-dev python3-yaml python3-click 
python3-click-plugins python3-zmq python3-scipy python3-gi 
python3-gi-cairo gobject-introspection gir1.2-gtk-3.0 build-essential 
libusb-1.0-0-dev python3-docutils python3-setuptools 
python3-ruamel.yaml python-is-python3


and /created//directory, cloned the USRP Hardware Driver (UHD 4.0 
branch) from Ettus Research GitHub repository./


*git clone*--*branch UHD-4.7 https://github.com/ettusresearch/uhd.git uhd*

//

cd /uhd/host/
mkdir build
cd build
cmake ..
make
make test
sudo make install
sudo ldconfig

You need to explicitly enable the Python API in the build, see:

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




*Kimden: *"Marcus D. Leech" 
*Kime: *"usrp-users" 
*Gönderilenler: *25 Kasım Pazartesi 2024 18:04:27
*Konu: *[USRP-users] Re: Module Not Found Error

On 25/11/2024 09:12, Hamdüsena BİLGİ (BİLGEM) via USRP-users wrote:


Hello dear usrp users,

I want to write code using the UHD Python APIs, but I get an error
when I try to run import uhd. UHD works properly in GNU Radio, but
when I try to work with Python 3.8 from the terminal or in VSCode,
I encounter the following error. How can I resolve this issue?

*export PYTHONPATH=/usr/local/lib/python3/dist-packages/:$PYTHONPATH*

python3.8
Python 3.8.10
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import uhd
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'uhd'



The versions on the device are:
 gnuradio-config-info --v
v3.8.5.0-6-g57bd109d
---

uhd_config_info --version

UHD 4.7.0.0-0-ga5ed1872

--


uhd_find_devices

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
UHD_4.7.0.0-0-ga5ed1872

--

-- UHD Device 0

--

Device Address:

serial: 33CB10C

addr: 192.168.10.2

claimed: False

fpga: 1G

mgmt_addr: 192.168.10.2

name: ni-e320-33CB10C

product: e320

type: e3xx





python3 --version

Python 3.8.10



g++ --version

g++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0


How did you install UHD?   The Python API for UHD is different from 
the interface that Gnu Radio uses for UHD -- they're

  different things.

When you build UHD, you have to configure it to build the direct 
Python support for UHD.  It's likely that didn't

  happen when it was built.



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

[USRP-users] Re: n310 | Error: failed receiving packet. RfnocError

[Marcus D. Leech]

On 26/11/2024 11:10, Houshang wrote:
Many thanks for prompt reply Marcus! Please find attached the printout 
for that probe command you asked for.
OK, so the next thing to do is to test your network capacity between 
your host computer and the N310:


benchmark_rate --args 
"type=n3xx,product=n310,addr=10.10.0.100,master_clock_rate=125e6" 
--rx_rate 25e6 --tx_rate 25e6





On Tue, 26 Nov 2024 at 16:59, Marcus D. Leech 
 wrote:


On 26/11/2024 10:18, Houshang wrote:

Hello

I have following UHD version on my server:

/ad@bm-super11-intel:~/houshang$ uhd_config_info --version
UHD 4.7.0.0-0ubuntu1~jammy1
ad@bm-super11-intel:~/houshang$ ssh root@10.10.0.100/

And the following UHD version on my n310:

/root@ni-n3xx-32000F1:~# uhd_config_info --version
UHD 4.7.0.0-0-ga5ed1872
root@ni-n3xx-32000F1:~# /

They are the same and my n310 is updated with the following file:

/ad@bm-super11-intel:~/houshang$ md5sum
/usr/share/uhd/images/usrp_n310_fpga_HG.bit
532b338d6861268c05a4fd9837ca80e5
 /usr/share/uhd/images/usrp_n310_fpga_HG.bit
ad@bm-super11-intel:~/houshang$ /

I am running srsRAN gNB on my server (/Commit 9d5dd742a/). A
version of srs of srsRAN that is compiled with /UHD 4.7.0.0./


Here are the error messages I get:

/ gNB started ===
Type  to view help
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Late: 2805; Underflow: 2238; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Late: 0; Underflow: 5; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK.
Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control
operation timed out waiting for ACK./


And obviously it is not working with this amount of errors.

Can anyone help me with this please? Is it a bug in the UHD
version? Or is there something I am missing here?

Thanks
Houshang


Try "the basics" first.

What does:

uhd_usrp_probe --args "type=n3xx,product=n310,addr=192.168.10.2"


Produce (you might have to change the addr to whatever the address
is of your N310).


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



--

*Houshang Azizi*

*Test Engineer*

logo <https://www.accelleran.com/>

*(32) 492195241*

*houshang.az...@accelleran.com <mailto:em...@accelleran.com>*

*www.accelleran.com* <http://www.accelleran.com/>

linkedin icon <https://www.linkedin.com/company/accelleran> twitter 
icon <https://twitter.com/accelleran> youtube icon 
<https://www.youtube.com/channel/UCrAEtqWp21cibZgSFVIEx2g?themeRefresh=1>


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

[USRP-users] Re: n310 | Error: failed receiving packet. RfnocError

[Marcus D. Leech]

On 26/11/2024 11:46, Houshang wrote:
10.10.0.100 <http://10.10.0.100>: I use it as the management ip of 
n310 and it is ETHERNET 1G.
10.10.2.100 <http://10.10.2.100>: I use it as the other ip of n310 for 
data and it is Fiber 10G.


With srsRAN I want to do 20MHz, TDD, N78 band, 2X2 MIMO. So DL will be 
something around 120 Mbps and UL will be something around 11.5 Mbps.
But this issue happens before even Attaching a UE. Meaning I don't 
even run data and I see this error:

I cannot help with srsRAN, maybe others know more about it.

But your N310 is essentially working, and your issue is likely with 
configuration of your application (srsRAN?).



/
/
/--== srsRAN gNB (commit 9d5dd742a) ==--


The PRACH detector will not meet the performance requirements with the 
configuration {Format 0, ZCZ 0, SCS 1.25kHz, Rx ports 1}.

Lower PHY in quad executor mode.
Available radio types: uhd.
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; 
UHD_4.7.0.0-0ubuntu1~jammy1

[INFO] [LOGGING] Fastpath logging disabled at runtime.
Making USRP object with args 
'use_dpdk=0,type=n3xx,mgmt_addr=10.10.0.100,addr=10.10.2.100,master_clock_rate=122.88e6,send_frame_size=8500,recv_frame_size=8500'
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=10.10.0.100,type=n3xx,product=n310,serial=32000F1,name=ni-n3xx-32000F1,fpga=HG,claimed=False,use_dpdk=0,addr=10.10.2.100,master_clock_rate=122.88e6,send_frame_size=8500,recv_frame_size=8500
[INFO] [MPM.PeriphManager] init() called with device args 
`fpga=HG,master_clock_rate=122.88e6,mgmt_addr=10.10.0.100,name=ni-n3xx-32000F1,product=n310,recv_frame_size=8500,send_frame_size=8500,use_dpdk=0,clock_source=internal,time_source=internal'.
[WARNING] [MPMD] DPDK was requested but is not available, falling back 
to regular UDP

[WARNING] [MPMD] Cannot create DPDK transport, falling back to UDP
[INFO] [MULTI_USRP]     1) catch time transition at pps edge
[INFO] [MULTI_USRP]     2) set times next pps (synchronously)
[WARNING] [MPMD] Cannot create DPDK transport, falling back to UDP
[WARNING] [MPMD] Cannot create DPDK transport, falling back to UDP
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
[WARNING] [MPMD] Cannot create DPDK transport, falling back to UDP
[WARNING] [MPMD] Cannot create DPDK transport, falling back to UDP
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
Cell pci=1, bw=20 MHz, 2T2R, dl_arfcn=626668 (n78), dl_freq=3400.02 
MHz, dl_ssb_arfcn=626304, ul_freq=3400.02 MHz


N2: Connection to AMF on 10.55.7.40:38412 <http://10.55.7.40:38412> 
completed
Warning: Configured PRACH occasion collides with PUCCH RBs ([0..1) 
intersects [0..3)). Some interference between PUCCH and PRACH is expected.
Warning: Configured PRACH occasion collides with PUCCH RBs ([0..1) 
intersects [0..3)). Some interference between PUCCH and PRACH is expected.

 gNB started ===
Type  to view help
Late: 5347; Underflow: 3213; Overflow: 1;
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.

Late: 4; Underflow: 0; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK./


On Tue, 26 Nov 2024 at 17:37, Marcus D. Leech 
 wrote:


On 26/11/2024 11:32, Houshang wrote:

Hi Marcus
I ran the benchmark command on both ip of the n310 and attached
you can find the printout.

I"m going to guess that one of your interfaces is operating at
1Gbit, while the other is operating at 10Gbit?

I don't know what rates the srsRAN software runs the interface at,
but clearly in your 2nd example, on the
  other IP, it's able to support 25Msps without any issue.




On Tue, 26 Nov 2024 at 17:22, Marcus D. Leech
 wrote:

On 26/11/2024 11:10, Houshang wrote:

Many thanks for prompt reply Marcus! Please find attached
the printout for that probe command you asked for.

OK, so the next thing to do is to test your network capacity
between your host computer and the N310:

benchmark_rate --args
"type=n3xx,product=n310,addr=10.10.0.100,master_clock_rate=125e6"
--rx_rate 25e6 --tx_rate 25e6




On Tue, 26 Nov 2024 at 16:59, Marcus D. Leech
 wrote:

On 26/11/2024 10:18, Houshang wrote:

Hello

I have following UHD version on my server:

/ad@bm-super11-intel:~/houshang$ uhd_config_info --version
UHD 4.7.0.0-0ubuntu1~jammy1
ad@bm-super11-intel:~/houshang$ ssh root@10.10.0.100/

And the following UHD version on my n310:

/root@ni-n3xx-32000F1:~# uhd_config_info --version
UHD 4.7.0.0-0-ga

[USRP-users] Re: n310 | Error: failed receiving packet. RfnocError

[Marcus D. Leech]

On 26/11/2024 11:32, Houshang wrote:

Hi Marcus
I ran the benchmark command on both ip of the n310 and attached you 
can find the printout.
I"m going to guess that one of your interfaces is operating at 1Gbit, 
while the other is operating at 10Gbit?


I don't know what rates the srsRAN software runs the interface at, but 
clearly in your 2nd example, on the

  other IP, it's able to support 25Msps without any issue.




On Tue, 26 Nov 2024 at 17:22, Marcus D. Leech 
 wrote:


On 26/11/2024 11:10, Houshang wrote:

Many thanks for prompt reply Marcus! Please find attached the
printout for that probe command you asked for.

OK, so the next thing to do is to test your network capacity
between your host computer and the N310:

benchmark_rate --args
"type=n3xx,product=n310,addr=10.10.0.100,master_clock_rate=125e6"
--rx_rate 25e6 --tx_rate 25e6




On Tue, 26 Nov 2024 at 16:59, Marcus D. Leech
 wrote:

On 26/11/2024 10:18, Houshang wrote:

Hello

I have following UHD version on my server:

/ad@bm-super11-intel:~/houshang$ uhd_config_info --version
UHD 4.7.0.0-0ubuntu1~jammy1
ad@bm-super11-intel:~/houshang$ ssh root@10.10.0.100/

And the following UHD version on my n310:

/root@ni-n3xx-32000F1:~# uhd_config_info --version
UHD 4.7.0.0-0-ga5ed1872
root@ni-n3xx-32000F1:~# /

They are the same and my n310 is updated with the following
file:

/ad@bm-super11-intel:~/houshang$ md5sum
/usr/share/uhd/images/usrp_n310_fpga_HG.bit
532b338d6861268c05a4fd9837ca80e5
 /usr/share/uhd/images/usrp_n310_fpga_HG.bit
ad@bm-super11-intel:~/houshang$ /

I am running srsRAN gNB on my server (/Commit 9d5dd742a/). A
version of srs of srsRAN that is compiled with /UHD 4.7.0.0./


Here are the error messages I get:

/ gNB started ===
Type  to view help
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Late: 2805; Underflow: 2238; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Late: 0; Underflow: 5; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK.
Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout:
Control operation timed out waiting for ACK./


And obviously it is not working with this amount of errors.

Can anyone help me with this please? Is it a bug in the UHD
version? Or is there something I am missing here?

Thanks
Houshang


Try "the basics" first.

What does:

uhd_usrp_probe --args "type=n3xx,product=n310,addr=192.168.10.2"


Produce (you might have to change the addr to whatever the
address is of your N310).


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



-- 


*Houshang Azizi*

*Test Engineer*

logo <https://www.accelleran.com/>

*(32) 492195241*

*houshang.az...@accelleran.com <mailto:em...@accelleran.com>*

*www.accelleran.com* <http://www.accelleran.com/>

linkedin icon <https://www.linkedin.com/company/accelleran>
twitter icon <https://twitter.com/accelleran> youtube icon
<https://www.youtube.com/channel/UCrAEtqWp21cibZgSFVIEx2g?themeRefresh=1>






--

*Houshang Azizi*

*Test Engineer*

logo <https://www.accelleran.com/>

*(32) 492195241*

*houshang.az...@accelleran.com <mailto:em...@accelleran.com>*

*www.accelleran.com* <http://www.accelleran.com/>

linkedin icon <https://www.linkedin.com/company/accelleran> twitter 
icon <https://twitter.com/accelleran> youtube icon 
<https://www.youtube.com/channel/UCrAEtqWp21cibZgSFVIEx2g?themeRefresh=1>

[USRP-users] Re: n310 | Error: failed receiving packet. RfnocError

[Marcus D. Leech]

On 26/11/2024 10:18, Houshang wrote:

Hello

I have following UHD version on my server:

/ad@bm-super11-intel:~/houshang$ uhd_config_info --version
UHD 4.7.0.0-0ubuntu1~jammy1
ad@bm-super11-intel:~/houshang$ ssh root@10.10.0.100/

And the following UHD version on my n310:

/root@ni-n3xx-32000F1:~# uhd_config_info --version
UHD 4.7.0.0-0-ga5ed1872
root@ni-n3xx-32000F1:~# /

They are the same and my n310 is updated with the following file:

/ad@bm-super11-intel:~/houshang$ md5sum 
/usr/share/uhd/images/usrp_n310_fpga_HG.bit
532b338d6861268c05a4fd9837ca80e5 
 /usr/share/uhd/images/usrp_n310_fpga_HG.bit

ad@bm-super11-intel:~/houshang$ /

I am running srsRAN gNB on my server (/Commit 9d5dd742a/). A version 
of srs of srsRAN that is compiled with /UHD 4.7.0.0./



Here are the error messages I get:

/ gNB started ===
Type  to view help
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.

Late: 2805; Underflow: 2238; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.

Late: 0; Underflow: 5; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.

Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.

Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK.

Late: 0; Underflow: 4; Overflow: 0;
Error: failed receiving packet. RfnocError: OpTimeout: Control 
operation timed out waiting for ACK./



And obviously it is not working with this amount of errors.

Can anyone help me with this please? Is it a bug in the UHD version? 
Or is there something I am missing here?


Thanks
Houshang


Try "the basics" first.

What does:

uhd_usrp_probe --args "type=n3xx,product=n310,addr=192.168.10.2"


Produce (you might have to change the addr to whatever the address is of 
your N310).


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

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

[Marcus D Leech]

Also try running at a lower sample rate at first. Just to see that you have the 
logic correct. 

Sent from my iPhone

> On Mar 12, 2021, at 9:18 AM, Rob Kossler  wrote:
> 
> 
> Is there any chance that your code is attempting to set the master clock 
> rate?  If so, perhaps see what happens if you don't set it in order to let it 
> be set automatically.
> 
>> On Fri, Mar 12, 2021 at 8:55 AM Oliver Towlson  
>> wrote:
>> Hi everyone
>> 
>>  
>> 
>> Thanks so much for your quick responses. Seems like the thing we were 
>> missing was that subdev spec – once that was set it was straightforward to 
>> generate the code.
>> 
>>  
>> 
>> We tried running it and got the following:
>> 
>>  
>> 
>> [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; 
>> UHD_3.15.0.0-2build5
>> 
>> [INFO] [X300] X300 initialization sequence...
>> 
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> 
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> 
>> [INFO] [X300] Radio 1x clock: 200 MHz
>> 
>> [INFO] [X300] Radio 1x clock: 200 MHz
>> 
>> [INFO] [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
>> 
>> [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1317 MB/s)
>> 
>> [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1301 MB/s)
>> 
>> [INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
>> 
>> [INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
>> 
>> [INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0)
>> 
>> [INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0)
>> 
>> [INFO] [1/DUC_0] Initializing block control (NOC ID: 0xD0C0)
>> 
>> [INFO] [1/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>> 
>> [WARNING] [X300] Cannot update master clock rate! X300 Series does not allow 
>> changing the clock rate during runtime.
>> 
>> terminate called after throwing an instance of 'uhd::io_error'
>> 
>>   what():  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-FRfZNJ/uhd-3.15.0.0/host/lib/rfnoc/ctrl_iface.cpp:151
>> 
>>  
>> 
>> Aborted (core dumped)
>> 
>>  
>> 
>> Googling didn’t result in any answers beyond resetting the whole device. But 
>> it does seem like a common error. As you say, the 4xRF_in set-up is fairly 
>> standard so I’m not sure what is causing the issue. The example 
>> rx_samples_to_file script runs fine (although it doesn’t seem to write 
>> anything, but it does seems to stream data fine)
>> 
>>  
>> 
>> Let me know if you need any more information.
>> 
>>  
>> 
>> Thanks very much
>> 
>>  
>> 
>> Oliver
>> 
>> 
>> P Please consider the environment before printing this e-mail.
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: import error gnuradio

[Marcus D. Leech]

On 03/12/2021 08:49 AM, COURANT Frederique - Contractor via USRP-users 
wrote:


Hi Users,

When I try to run my flow graph I have this error :

from .blocks_python import *

ImportError: 
/usr/local/lib/python3/dist-packages/gnuradio/blocks/-blocks_python.cpython-38-x86_64-linux-gnu.so 
: undefined symbol: 
_/ZN2gr6blocks12wavfile/_sink4makeEPKcijNS0_16wavfile_format_tENS-0_19wavfile_subformat_tEb


Someone has solutions for resolve this problem please ?

I work with UHD4.0 and gnuradio3.9

Thanks.

Best regards.



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
This error is from inside Gnu Radio, involving the wavefile sink. That's 
not a USRP/UHD problem and discussing on the

  discuss-gnuradio mailing list would be better.

However, this class of error usually means you have libraries that are 
inconsistent on your system, likely from multiple

  incompatible compile/build attempts.

This *might* be fixed with a simple:

sudo ldconfig

But more guidance would be available from the discuss-gnuradio mailing list.


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

[USRP-users] Re: [UHD 4.0.0.0] USRP 2901 How is it possible to know if fpga is loaded

[Marcus D Leech]

This device loads its FPGA image whenever it has been power cycled and you 
start a session with it. The Images would be in the data files associated with 
your UHD installation. 

You cannot establish a session with it unless there’s a functional FPgA image 
loaded and running.   

Sent from my iPhone

> On Mar 12, 2021, at 12:25 PM, Serge Manigault via USRP-users 
>  wrote:
> 
> 
> Hello,
> 
> I’m knew to this forum.
> 
> I would like to know if there is a command to check the fpga loading status.
> 
> And/Or to reset the fpga status to factory setting.
> 
> Best regards,
> 
> Serge
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Where do I find this call to change it.

[Marcus D Leech]

I think we need more context. 

Is this from a program you write yourself?

Someone else’s code?

A Gnuradio flow graph? Your own? Someone else’s?



Sent from my iPhone

> On Mar 12, 2021, at 3:02 PM, Jerrid Plymale  
> wrote:
> 
> 
> Hello All,
>  
> Here is the warning message I am trying to solve:
>  
> [WARNING] [MULTI_USRP] Calling multi_usrp::recv_async_msg() is deprecated and 
> can lead to unexpected behaviour. Prefer calling tx_stream::recv_async_msg().
>  
> I am trying to solve this warning message when I am running my USRP X310, but 
> I have not had any luck finding the file I need to edit. Can anyone direct me 
> on how to solve this problem?
>  
> Best Regards,
>  
> Jerrid Plymale
>  
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Where do I find this call to change it.

[Marcus D Leech]

ok so this is likely a case of your gr-UHD assuming an older API for 
recv_async_msg. 

This is just a warning that eventually that older API will go away. 

Probably if you had totally up to date everything, or a UHD library that was of 
an earlier vintage that matched he-UHD, yiu wouldn’t get this message. 

Sent from my iPhone

> On Mar 12, 2021, at 3:20 PM, Jerrid Plymale  
> wrote:
> 
> 
> Hello Marcus,
>  
> This is coming from a Gnuradio flowgraph that I created myself. It’s got USRP 
> Rx and Tx blocks, a block that takes samples of the signal and preforms some 
> DSP, and a bunch of GUI variable control and variable display blocks.
>  
> Best Regards,
>  
> Jerrid
>  
> From: Marcus D Leech  
> Sent: Friday, March 12, 2021 12:17 PM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Where do I find this call to change it.
>  
> I think we need more context. 
>  
> Is this from a program you write yourself?
>  
> Someone else’s code?
>  
> A Gnuradio flow graph? Your own? Someone else’s?
>  
>  
>  
> Sent from my iPhone
> 
> 
> On Mar 12, 2021, at 3:02 PM, Jerrid Plymale  
> wrote:
> 
> 
> Hello All,
>  
> Here is the warning message I am trying to solve:
>  
> [WARNING] [MULTI_USRP] Calling multi_usrp::recv_async_msg() is deprecated and 
> can lead to unexpected behaviour. Prefer calling tx_stream::recv_async_msg().
>  
> I am trying to solve this warning message when I am running my USRP X310, but 
> I have not had any luck finding the file I need to edit. Can anyone direct me 
> on how to solve this problem?
>  
> Best Regards,
>  
> Jerrid Plymale
>  
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Where do I find this call to change it.

[Marcus D. Leech]

On 03/12/2021 04:39 PM, Jerrid Plymale wrote:
Ok, so what you're saying is I need to update Gnuradio to a newer 
version? The way I have my software setup is everything is installed 
into virtual environments. So when I initially started using the USRP, 
I created an environment that had UHD 3.15 and Gnuradio 3.8 installed. 
When I saw UHD 4.0 released, I created a new environment with UHD 4.0 
and  Gnuradio 3.8 installed. So do I need to update Gnuradio to 3.9?


Best Regards,

Jerrid
TBH, I'm not sure which versions of gr-uhd will prompt the message, that 
is coming from the UHD library.


But, like I said, it's just a *WARNING*.  Things will still work just 
fine.  It's basically saying the "in the future, this will stop working".


I'll note that in my current code base (GR 3.8.2, 
55621a9709b219551b908e67ee88f6f7ad2593cb)  the recv_async_msg() call is 
still tied

  to the underlying multi_usrp device, and NOT the streamer.

Perhaps the current maintainer of gr-uhd can comment on whether this is 
fixed in a subsequent gr-uhd version (after GR 3.8.2)





Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android <https://aka.ms/ghei36>

--------
*From:* Marcus D Leech 
*Sent:* Friday, March 12, 2021 12:41:41 PM
*To:* Jerrid Plymale 
*Cc:* USRP-users@lists.ettus.com 
*Subject:* Re: [USRP-users] Where do I find this call to change it.
ok so this is likely a case of your gr-UHD assuming an older API for 
recv_async_msg.


This is just a warning that eventually that older API will go away.

Probably if you had totally up to date everything, or a UHD library 
that was of an earlier vintage that matched he-UHD, yiu wouldn’t get 
this message.


Sent from my iPhone

On Mar 12, 2021, at 3:20 PM, Jerrid Plymale 
 wrote:




Hello Marcus,

This is coming from a Gnuradio flowgraph that I created myself. It’s 
got USRP Rx and Tx blocks, a block that takes samples of the signal 
and preforms some DSP, and a bunch of GUI variable control and 
variable display blocks.


Best Regards,

Jerrid

*From:* Marcus D Leech 
*Sent:* Friday, March 12, 2021 12:17 PM
*To:* Jerrid Plymale 
*Cc:* USRP-users@lists.ettus.com
*Subject:* Re: [USRP-users] Where do I find this call to change it.

I think we need more context.

Is this from a program you write yourself?

Someone else’s code?

A Gnuradio flow graph? Your own? Someone else’s?

Sent from my iPhone



On Mar 12, 2021, at 3:02 PM, Jerrid Plymale
mailto:jerrid.plym...@canyon-us.com>> wrote:



Hello All,

Here is the warning message I am trying to solve:

[WARNING] [MULTI_USRP] Calling multi_usrp::recv_async_msg() is
deprecated and can lead to unexpected behaviour. Prefer calling
tx_stream::recv_async_msg().

I am trying to solve this warning message when I am running my
USRP X310, but I have not had any luck finding the file I need to
edit. Can anyone direct me on how to solve this problem?

Best Regards,

Jerrid Plymale

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



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

[USRP-users] Re: Ettus N300 8-bit sample capture

[Marcus D Leech]

I do t think they implemented SC8 on any of the devices that have 10Gig 
interfaces available. 

Sent from my iPhone

> On Mar 16, 2021, at 8:42 AM, Nik Ansell  wrote:
> 
> 
> 
> Hello All,
>  
> I am trying to capture 8-bit samples using an Ettus USRP N300, rather than 
> the default of 16-bit (sc16).
> This is for scenarios where I can sacrifice some dynamic range for higher 
> data rates and also to run on slightly lower powered hardware.
>  
> UHD version info: linux; GNU C++ version 9.3.0; Boost_107100; 
> UHD_3.15.0.0-62-g7a3f1516
> The Ettus is connected over a network cable and not USB.
> I am using the HG FPGA firmware,  which is v5.3 according to the output of 
> `uhd_usrp_probe`
>  
> I have tried two options so far:
> Benchmark_rate from the uhd examples directory:
> GNU Radio
>  
> This benchmark_rate command below fails with the error message: “Error: 
> RuntimeError: [RX Streamer] Conflicting OTW types defined: args.otw_format = 
> 'sc8' <=> stream_sig.item_type = 'sc16'”
>  
> `/benchmark_rate --args 
> "type=n3xx,mgmt_addr=n.n.n.n,addr=n.n.n.n,master_clock_rate=122.88e6" 
> --duration 60 --channels "0" --rx_rate 40.96e6 --rx_subdev "A:0" --rx_otw sc8`
>  
> In GNU Radio, I am using a UHD block and configure the “Wire Format” 
> parameter to “Complex int8”. This produces exactly the same error:
>  
> RuntimeError: [RX Streamer] Conflicting OTW types defined: args.otw_format = 
> 'sc8' <=> stream_sig.item_type = 'sc16'
>  
> The v3.15 UHD documentation does not state the available otw formats: 
> https://files.ettus.com/manual_archive/v3.15.0.0/html/structuhd__stream__args__t.html
>  
> However, the v4 documentation does: 
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
>  
> Does anyone know if the N300 does indeed support 8-bit? And if so, how I can 
> implement it?
> 
> Kind Regards,
> Nik
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: How to create stream data from USRP (via PCI) using rfnoc block in c++

[Marcus D. Leech]

On 03/16/2021 07:10 AM, Sourin Mondal (Vehere) wrote:

Hi,
I am trying to stream data from USRP where the data passed through 
RFNOC block (in order to create a lowpass filter) before coming to 
host machine and I am trying to implement it using C++ code. I know 
how to stream data normally. i.e. without rfnoc block in c++. Can 
anyone please help me how to implement or the syntax to stream data 
via RFNOC block to host machine.


Thanking you.

with regards,


There is some getting-started information here:

https://kb.ettus.com/Getting_Started_with_RFNoC_Development

There are also a number of rfnoc-based examples in the source code tree, 
in the "host/examples" directory.





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

[USRP-users] Re: x310 PPS issues

[Marcus D Leech]

Could you post scope traces?  My guess is that the edges are not crisp enough 
for the 1PPS input processing. 

Sent from my iPhone

> On Mar 18, 2021, at 5:00 PM, Richard J. Muri  wrote:
> 
> 
> Hello,
>  
> I’m using a series of x310 USRPs synchronized together using both an external 
> 10 MHz reference and a PPS. I have two configurations: in my lab an Octoclock 
> provides the PPS signal, and in the field configuration I use a GPS 
> referenced stratum 1 NTP server.  
>  
> The lab configuration USRPs blink an LED on the front panel in time with the 
> PPS. The field configuration does not blink the LEDs at all. Both 
> configurations light the 10 MHz reference LED.
>  
> I am not fully sure if this is a problem. Occasionally when I run the 
> application in the field configuration, it works for about a minute and then 
> appears to drift out of sync, however most of the time everything seems to 
> operate as intended. It’s very possible my field configuration has other 
> issues, and my system has not quite reached the maturity to be running 
> multiple hour/day long test to measure drift on the application 
> synchronization.
>  
> I examined the PPS connection with a T cable and a scope. Both produce a PPS 
> pulse with a sharp spike to an initial voltage, followed by a longer 
> exponential curve up to 5V. The octoclock drives to 2.5V initially, and the 
> syncserver drives to 4V initial.
>  
> I have tried using shorter cables and a 6dB attenuator on the syncserver 
> connection to see if I could get the PPS to light, but neither seemed to have 
> any effect.
>  
> Does anybody have any guidance on how to make sure my x310s in the field 
> configuration are actually benefitting from the PPS?
>  
> Thank you!
> Richard
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: question of X300 revision

[Marcus D. Leech]

On 03/21/2021 04:16 AM, Oscar Pablo wrote:

Hi,
the public released X300 schematic is revision 1. i want to know if 
this revision is the revision in uhd source code. in uhd source code 
there is strange words "x300_clock_ctrl is not compatible with revs <= 
4 and maylead to locking issues" so what is the correct source 
code for revision less than 4?



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
My recollection is that hardware rev <= 4 were pre-production and you'll 
never see them "in the wild".



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

[USRP-users] Re: question of X300 revision

[Marcus D Leech]

Code sees like this, that support hardware must necessarily provide support for 
older equipment l—even models or revs that aren’t sold anymore. That’s just the 
nature of hardware drivers. 

The schematic update policy is a business thing that I’m not qualified to 
comment on. 

Sent from my iPhone

> On Mar 21, 2021, at 9:57 PM, Oscar Pablo  wrote:
> 
> 
> i don't understand why keep the the source code for the product that will 
> never show. and release a schematic for the product that will never show. if 
> there is no source code to support the schematic then this schematic is no 
> useful. i know x300 schematic hide the part of pcie. but if other part is ok 
> then it still have value for reference if someone want to use some part of 
> it. 
> 
> 
> From: Marcus D. Leech 
> Sent: Sunday, March 21, 2021 3:13 PM
> To: usrp-users@lists.ettus.com 
> Subject: [USRP-users] Re: question of X300 revision
>  
>> On 03/21/2021 04:16 AM, Oscar Pablo wrote:
>> Hi,
>> the public released X300 schematic is revision 1. i want to know if this 
>> revision is the revision in uhd source code. in uhd source code there is 
>> strange words "x300_clock_ctrl is not compatible with revs <= 4 and may
>> lead to locking issues" so what is the correct source code for revision less 
>> than 4?
>> 
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> My recollection is that hardware rev <= 4 were pre-production and you'll 
> never see them "in the wild".
> 
> 
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Strong noise added to signal transmitted by X310 with a UBX 40 daughterboard

[Marcus D Leech]

Is the j B is over-the-air or direct connection?

What frequency? Bandwidth?

Do you have TX and RX gain turned all the way up?

Can you share your flow-graphs, or minimum
Graphs that show the problem?

Sent from my iPhone

> On Mar 24, 2021, at 12:20 PM, Jerrid Plymale  
> wrote:
> 
> 
> Hello All,
>  
> I have been running tests in which I am transmitting a signal from one USRP 
> X310 that’s using a UBX 40 daughterboard, and that signal is being received 
> by another USRP X310 using a UBX 40 daughterboard. I have noticed that when I 
> have the receiving USRP running with the Gnuradio flowgraph active, as soon 
> as I start the transmitting USRP’s Gnuradio flowgraph, there is a jump in the 
> noise floor as it is seen by the receiving USRP, and its roughly a 14 dB 
> increase. This occurs even if I have the signal being transmitted muted. Does 
> anyone have any idea what the source of this added noise could be? It is 
> something that I need to mitigate as much as possible for the tests I am 
> running using these USRPs. Any feedback will be greatly appreciated, thanks!
>  
> Best Regards,
>  
> Jerrid
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Strong noise added to signal transmitted by X310 with a UBX 40 daughterboard

[Marcus D. Leech]

On 03/24/2021 05:10 PM, Jerrid Plymale wrote:


The devices are operating using direct connection via coax cables.

You absolutely need to put a 30dB attenuator in-line to prevent RX 
destruction in the case of "ooops" moments from setting the TX

  power output too high.

The target frequency is 1.57542 GHz, and our current bandwidth is 4 
MHz. We will need to increase the bandwidth to 20 MHz soon for further 
system development.


The TX and RX gain are maxed on the receiving hardware. The TX gain of 
the transmitting hardware is set to 0, as at max the noise strength 
increases to ~ 20 dB.


Attached are images of the FFT provided by the Frequency Sink in 
Gnuradio. Hopefully these give a visual aid for the problem at hand. 
When I have the transmitter USRP turned off (image 1), it would seem 
like the noise floor coming into the USRP is around -94 dB. When the 
transmitter is turned on and the flowgraph is started with the 
transmitted signal muted (I am using a python block with code to 
create custom signals that is then connected to a mute block that then 
connects to the UHD USRP sink block to be able to mute the signal 
during runtime), the noise floor increases to around -78 dB.


Best Regards,

Jerrid

You are likely just seeing the LO leakage, along with the inevitable 
phase-noise curve of the LO.




*From:* Marcus D Leech 
*Sent:* Wednesday, March 24, 2021 11:58 AM
*To:* Jerrid Plymale 
*Cc:* USRP-users@lists.ettus.com
*Subject:* Re: [USRP-users] Strong noise added to signal transmitted 
by X310 with a UBX 40 daughterboard


Is the j B is over-the-air or direct connection?

What frequency? Bandwidth?

Do you have TX and RX gain turned all the way up?

Can you share your flow-graphs, or minimum

Graphs that show the problem?

Sent from my iPhone



On Mar 24, 2021, at 12:20 PM, Jerrid Plymale
mailto:jerrid.plym...@canyon-us.com>> wrote:



Hello All,

I have been running tests in which I am transmitting a signal from
one USRP X310 that’s using a UBX 40 daughterboard, and that signal
is being received by another USRP X310 using a UBX 40
daughterboard. I have noticed that when I have the receiving USRP
running with the Gnuradio flowgraph active, as soon as I start the
transmitting USRP’s Gnuradio flowgraph, there is a jump in the
noise floor as it is seen by the receiving USRP, and its roughly a
14 dB increase. This occurs even if I have the signal being
transmitted muted. Does anyone have any idea what the source of
this added noise could be? It is something that I need to mitigate
as much as possible for the tests I am running using these USRPs.
Any feedback will be greatly appreciated, thanks!

Best Regards,

Jerrid

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



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

[USRP-users] Re: Strong noise added to signal transmitted by X310 with a UBX 40 daughterboard

[Marcus D Leech]

You don’t need 1PPS for this. Having an external high quality reference may 
help, assuming my guess about your issue is correct.  

What happens if your flow graph just simply emits a Cw tone, using the mute 
function perhaps tied to a GUI control or some such. 

Sent from my iPhone

> On Mar 24, 2021, at 7:13 PM, Jerrid Plymale  
> wrote:
> 
> 
> Ok, if that’s the case, would it help to have both USRPs connected to the 
> same 10 MHz reference signal and PPS? In this situation, would I need to 
> provide a secondary source for the PPS, or can that use the 10 Mhz reference 
> as well?
>  
> Best Regards,
>  
> Jerrid
>  
> From: Marcus D. Leech  
> Sent: Wednesday, March 24, 2021 2:23 PM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> On 03/24/2021 05:10 PM, Jerrid Plymale wrote:
> The devices are operating using direct connection via coax cables.
> You absolutely need to put a 30dB attenuator in-line to prevent RX 
> destruction in the case of "ooops" moments from setting the TX
>   power output too high.
> 
> 
>  
> The target frequency is 1.57542 GHz, and our current bandwidth is 4 MHz. We 
> will need to increase the bandwidth to 20 MHz soon for further system 
> development.
>  
> The TX and RX gain are maxed on the receiving hardware. The TX gain of the 
> transmitting hardware is set to 0, as at max the noise strength increases to 
> ~ 20 dB.
>  
> Attached are images of the FFT provided by the Frequency Sink in Gnuradio. 
> Hopefully these give a visual aid for the problem at hand. When I have the 
> transmitter USRP turned off (image 1), it would seem like the noise floor 
> coming into the USRP is around -94 dB. When the transmitter is turned on and 
> the flowgraph is started with the transmitted signal muted (I am using a 
> python block with code to create custom signals that is then connected to a 
> mute block that then connects to the UHD USRP sink block to be able to mute 
> the signal during runtime), the noise floor increases to around -78 dB.
>  
> Best Regards,
>  
> Jerrid 
> You are likely just seeing the LO leakage, along with the inevitable 
> phase-noise curve of the LO.
> 
> 
> 
>  
> From: Marcus D Leech  
> Sent: Wednesday, March 24, 2021 11:58 AM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> Is the j B is over-the-air or direct connection?
>  
> What frequency? Bandwidth?
>  
> Do you have TX and RX gain turned all the way up?
>  
> Can you share your flow-graphs, or minimum
> Graphs that show the problem?
> 
> Sent from my iPhone
> 
> 
> 
> On Mar 24, 2021, at 12:20 PM, Jerrid Plymale  
> wrote:
> 
> 
> Hello All,
>  
> I have been running tests in which I am transmitting a signal from one USRP 
> X310 that’s using a UBX 40 daughterboard, and that signal is being received 
> by another USRP X310 using a UBX 40 daughterboard. I have noticed that when I 
> have the receiving USRP running with the Gnuradio flowgraph active, as soon 
> as I start the transmitting USRP’s Gnuradio flowgraph, there is a jump in the 
> noise floor as it is seen by the receiving USRP, and its roughly a 14 dB 
> increase. This occurs even if I have the signal being transmitted muted. Does 
> anyone have any idea what the source of this added noise could be? It is 
> something that I need to mitigate as much as possible for the tests I am 
> running using these USRPs. Any feedback will be greatly appreciated, thanks!
>  
> Best Regards,
>  
> Jerrid
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>  
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: USRP N300 - Set RX bandwidth

[Marcus D Leech]

If you do t specify bandwidth at all, and rely on the automatic analog 
bandwidth setting what happens?

Normally UHD will set an analog bandwidth that is appropriate for the selected 
sample rate.



Sent from my iPhone

> On Mar 25, 2021, at 12:07 PM, Minutolo, Lorenzo  wrote:
> 
>  This is very interesting. I am trying to set the rx bandwidth on a N321 for 
> a while now.
> 
> Is there any workaround? Our bandwidth seems stuck at 8MHz while our 
> application needs much more. 
> 
> Thanks
> 
> Lorenzo
> 
>>> On Feb 25, 2021, at 10:32 AM, Marcus D. Leech via USRP-users 
>>>  wrote:
>>> 
>> 
>>> 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
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: USRP N300 - Set RX bandwidth

[Marcus D. Leech]

On 03/25/2021 12:07 PM, Minutolo, Lorenzo wrote:
This is very interesting. I am trying to set the rx bandwidth on a 
N321 for a while now.


Is there any workaround? Our bandwidth seems stuck at 8MHz while our 
application needs much more.


Thanks

Lorenzo

Sorry, on the N32x series, the analog bandwidth in front of the ADC is 
*fixed*, and bandwidth delivered to your application is controlled

  strictly by the selected sample-rate.


On Feb 25, 2021, at 10:32 AM, Marcus D. Leech via USRP-users 
 wrote:



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


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

[USRP-users] Re: Shared UHD Access

[Marcus D. Leech]

On 03/25/2021 01:23 PM, Ben Magistro wrote:
This might be more of a GNURadio question, but is it possible to share 
a single USRP device (E310 in this case) with two flowgraphs?  What I 
mean is the E310 has a "A" and "B" channel, could you use channel "A" 
with one flowgraph and "B" with another or does everything have to be 
implemented in a single flowgraph with the UHD sink/source configured 
to have two channels?  I'm guessing the latter due to how UHD 
interacts with the hardware.


Thanks!

Not directly--only a single process can "own" the interface.  But you 
can construct yourself a muxing layer.


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

[USRP-users] Re: Strong noise added to signal transmitted by X310 with a UBX 40 daughterboard

[Marcus D Leech]

If you move the TX out of band with respect to the RX do you still see the 
noise when the TX graph starts?



Sent from my iPhone

> On Mar 25, 2021, at 3:57 PM, Jerrid Plymale  
> wrote:
> 
> 
> So I was able to test setting up both USRPs with the same 10 MHz reference 
> signal, and there was no improvement to the noise being added.
>  
> If the flowgraph just emits a CW tone, we see a similar response, the added 
> noise is still there and at the same level, we just have the added spike of 
> the CW tone at the frequency we set it to.
>  
> Best Regards,
>  
> Jerrid
>  
> From: Marcus D Leech  
> Sent: Wednesday, March 24, 2021 5:01 PM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> You don’t need 1PPS for this. Having an external high quality reference may 
> help, assuming my guess about your issue is correct.  
>  
> What happens if your flow graph just simply emits a Cw tone, using the mute 
> function perhaps tied to a GUI control or some such. 
> 
> Sent from my iPhone
> 
> 
> On Mar 24, 2021, at 7:13 PM, Jerrid Plymale  
> wrote:
> 
> 
> Ok, if that’s the case, would it help to have both USRPs connected to the 
> same 10 MHz reference signal and PPS? In this situation, would I need to 
> provide a secondary source for the PPS, or can that use the 10 Mhz reference 
> as well?
>  
> Best Regards,
>  
> Jerrid
>  
> From: Marcus D. Leech  
> Sent: Wednesday, March 24, 2021 2:23 PM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> On 03/24/2021 05:10 PM, Jerrid Plymale wrote:
> The devices are operating using direct connection via coax cables.
> You absolutely need to put a 30dB attenuator in-line to prevent RX 
> destruction in the case of "ooops" moments from setting the TX
>   power output too high.
> 
> 
> 
>  
> The target frequency is 1.57542 GHz, and our current bandwidth is 4 MHz. We 
> will need to increase the bandwidth to 20 MHz soon for further system 
> development.
>  
> The TX and RX gain are maxed on the receiving hardware. The TX gain of the 
> transmitting hardware is set to 0, as at max the noise strength increases to 
> ~ 20 dB.
>  
> Attached are images of the FFT provided by the Frequency Sink in Gnuradio. 
> Hopefully these give a visual aid for the problem at hand. When I have the 
> transmitter USRP turned off (image 1), it would seem like the noise floor 
> coming into the USRP is around -94 dB. When the transmitter is turned on and 
> the flowgraph is started with the transmitted signal muted (I am using a 
> python block with code to create custom signals that is then connected to a 
> mute block that then connects to the UHD USRP sink block to be able to mute 
> the signal during runtime), the noise floor increases to around -78 dB.
>  
> Best Regards,
>  
> Jerrid 
> You are likely just seeing the LO leakage, along with the inevitable 
> phase-noise curve of the LO.
> 
> 
> 
> 
>  
> From: Marcus D Leech  
> Sent: Wednesday, March 24, 2021 11:58 AM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> Is the j B is over-the-air or direct connection?
>  
> What frequency? Bandwidth?
>  
> Do you have TX and RX gain turned all the way up?
>  
> Can you share your flow-graphs, or minimum
> Graphs that show the problem?
> 
> Sent from my iPhone
> 
> 
> 
> 
> On Mar 24, 2021, at 12:20 PM, Jerrid Plymale  
> wrote:
> 
> 
> Hello All,
>  
> I have been running tests in which I am transmitting a signal from one USRP 
> X310 that’s using a UBX 40 daughterboard, and that signal is being received 
> by another USRP X310 using a UBX 40 daughterboard. I have noticed that when I 
> have the receiving USRP running with the Gnuradio flowgraph active, as soon 
> as I start the transmitting USRP’s Gnuradio flowgraph, there is a jump in the 
> noise floor as it is seen by the receiving USRP, and its roughly a 14 dB 
> increase. This occurs even if I have the signal being transmitted muted. Does 
> anyone have any idea what the source of this added noise could be? It is 
> something that I need to mitigate as much as possible for the tests I am 
> running using these USRPs. Any feedback will be greatly appreciated, thanks!
>  
> Best Regards,
>  
> Jerrid
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>  
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Strong noise added to signal transmitted by X310 with a UBX 40 daughterboard

[Marcus D Leech]

Could you confirm that you’re using at least 30dB of attenuation in the coax 
link?

Sent from my iPhone

> On Mar 25, 2021, at 6:27 PM, Jerrid Plymale  
> wrote:
> 
> 
> Yes, moving TX out of the RX band has no affect on the noise level increase.
>  
> Best Regards,
>  
> Jerrid
>  
> From: Marcus D Leech  
> Sent: Thursday, March 25, 2021 2:29 PM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> If you move the TX out of band with respect to the RX do you still see the 
> noise when the TX graph starts?
>  
>  
> 
> Sent from my iPhone
> 
> 
> On Mar 25, 2021, at 3:57 PM, Jerrid Plymale  
> wrote:
> 
> 
> So I was able to test setting up both USRPs with the same 10 MHz reference 
> signal, and there was no improvement to the noise being added.
>  
> If the flowgraph just emits a CW tone, we see a similar response, the added 
> noise is still there and at the same level, we just have the added spike of 
> the CW tone at the frequency we set it to.
>  
> Best Regards,
>  
> Jerrid
>  
> From: Marcus D Leech  
> Sent: Wednesday, March 24, 2021 5:01 PM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> You don’t need 1PPS for this. Having an external high quality reference may 
> help, assuming my guess about your issue is correct.  
>  
> What happens if your flow graph just simply emits a Cw tone, using the mute 
> function perhaps tied to a GUI control or some such. 
> 
> Sent from my iPhone
> 
> 
> 
> On Mar 24, 2021, at 7:13 PM, Jerrid Plymale  
> wrote:
> 
> 
> Ok, if that’s the case, would it help to have both USRPs connected to the 
> same 10 MHz reference signal and PPS? In this situation, would I need to 
> provide a secondary source for the PPS, or can that use the 10 Mhz reference 
> as well?
>  
> Best Regards,
>  
> Jerrid
>  
> From: Marcus D. Leech 
> Sent: Wednesday, March 24, 2021 2:23 PM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> On 03/24/2021 05:10 PM, Jerrid Plymale wrote:
> The devices are operating using direct connection via coax cables.
> You absolutely need to put a 30dB attenuator in-line to prevent RX 
> destruction in the case of "ooops" moments from setting the TX
>   power output too high.
> 
> 
> 
> 
>  
> The target frequency is 1.57542 GHz, and our current bandwidth is 4 MHz. We 
> will need to increase the bandwidth to 20 MHz soon for further system 
> development.
>  
> The TX and RX gain are maxed on the receiving hardware. The TX gain of the 
> transmitting hardware is set to 0, as at max the noise strength increases to 
> ~ 20 dB.
>  
> Attached are images of the FFT provided by the Frequency Sink in Gnuradio. 
> Hopefully these give a visual aid for the problem at hand. When I have the 
> transmitter USRP turned off (image 1), it would seem like the noise floor 
> coming into the USRP is around -94 dB. When the transmitter is turned on and 
> the flowgraph is started with the transmitted signal muted (I am using a 
> python block with code to create custom signals that is then connected to a 
> mute block that then connects to the UHD USRP sink block to be able to mute 
> the signal during runtime), the noise floor increases to around -78 dB.
>  
> Best Regards,
>  
> Jerrid 
> You are likely just seeing the LO leakage, along with the inevitable 
> phase-noise curve of the LO.
> 
> 
> 
> 
> 
>  
> From: Marcus D Leech 
> Sent: Wednesday, March 24, 2021 11:58 AM
> To: Jerrid Plymale 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] Strong noise added to signal transmitted by X310 
> with a UBX 40 daughterboard
>  
> Is the j B is over-the-air or direct connection?
>  
> What frequency? Bandwidth?
>  
> Do you have TX and RX gain turned all the way up?
>  
> Can you share your flow-graphs, or minimum
> Graphs that show the problem?
> 
> Sent from my iPhone
> 
> 
> 
> 
> 
> On Mar 24, 2021, at 12:20 PM, Jerrid Plymale  
> wrote:
> 
> 
> Hello All,
>  
> I have been running tests in which I am transmitting a signal from one USRP 
> X310 that’s using a UBX 40 daughterboard, and that signal is being received 
> by another USRP X310 using a UBX 40 daughterboard. I have noticed that when I 
> have the receiving USRP running with the Gnuradio flowgraph activ

[USRP-users] Re: Strong noise added to signal transmitted by X310 with a UBX 40 daughterboard

[Marcus D. Leech]

On 03/25/2021 06:27 PM, Jerrid Plymale wrote:


Yes, moving TX out of the RX band has no affect on the noise level 
increase.


Best Regards,

Jerrid


OK, so, let's get Gnu Radio out of the way.

Using the tx_waveforms UHD example (usually in 
/lib/uhd/examples) try sending a CW tone with a --ampl 1.0e-7, 
and see what

  happens.

Here's the --help output for tx_waveforms:

UHD TX Waveforms Allowed options:
  --helphelp message
  --args argsingle uhd device address args
  --spb arg (=0)samples per buffer, 0 for default
  --nsamps arg (=0) total number of samples to transmit
  --rate argrate of outgoing samples
  --freq argRF center frequency in Hz
  --ampl arg (=0.30012) amplitude of the waveform [0 to 0.7]
  --gain arggain for the RF chain
  --ant arg antenna selection
  --subdev arg  subdevice specification
  --bw arg  analog frontend filter bandwidth in Hz
  --wave-type arg (=CONST)  waveform type (CONST, SQUARE, RAMP, SINE)
  --wave-freq arg (=0)  waveform frequency in Hz
  --ref arg (=internal) clock reference (internal, external, mimo, 
gpsdo)

  --pps arg PPS source (internal, external, mimo, gpsdo)
  --otw arg (=sc16) specify the over-the-wire sample mode
  --channels arg (=0)   which channels to use (specify "0", "1", 
"0,1",

etc)
  --int-n   tune USRP with integer-N tuning





*From:*Marcus D Leech 
*Sent:* Thursday, March 25, 2021 2:29 PM
*To:* Jerrid Plymale 
*Cc:* USRP-users@lists.ettus.com
*Subject:* Re: [USRP-users] Strong noise added to signal transmitted 
by X310 with a UBX 40 daughterboard


If you move the TX out of band with respect to the RX do you still see 
the noise when the TX graph starts?


Sent from my iPhone



On Mar 25, 2021, at 3:57 PM, Jerrid Plymale
mailto:jerrid.plym...@canyon-us.com>> wrote:



So I was able to test setting up both USRPs with the same 10 MHz
reference signal, and there was no improvement to the noise being
added.

If the flowgraph just emits a CW tone, we see a similar response,
the added noise is still there and at the same level, we just have
the added spike of the CW tone at the frequency we set it to.

    Best Regards,

Jerrid

*From:*Marcus D Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Wednesday, March 24, 2021 5:01 PM
*To:* Jerrid Plymale mailto:jerrid.plym...@canyon-us.com>>
*Cc:* USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] Strong noise added to signal
transmitted by X310 with a UBX 40 daughterboard

You don’t need 1PPS for this. Having an external high quality
reference may help, assuming my guess about your issue is correct.

What happens if your flow graph just simply emits a Cw tone, using
the mute function perhaps tied to a GUI control or some such.

Sent from my iPhone




On Mar 24, 2021, at 7:13 PM, Jerrid Plymale
mailto:jerrid.plym...@canyon-us.com>> wrote:



Ok, if that’s the case, would it help to have both USRPs
connected to the same 10 MHz reference signal and PPS? In this
situation, would I need to provide a secondary source for the
PPS, or can that use the 10 Mhz reference as well?

Best Regards,

Jerrid

*From:*Marcus D. Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Wednesday, March 24, 2021 2:23 PM
*To:* Jerrid Plymale mailto:jerrid.plym...@canyon-us.com>>
*Cc:* USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] Strong noise added to signal
transmitted by X310 with a UBX 40 daughterboard

On 03/24/2021 05:10 PM, Jerrid Plymale wrote:

The devices are operating using direct connection via coax
cables.

You absolutely need to put a 30dB attenuator in-line to
prevent RX destruction in the case of "ooops" moments from
setting the TX
  power output too high.




The target frequency is 1.57542 GHz, and our current
bandwidth is 4 MHz. We will need to increase the bandwidth
to 20 MHz soon for further system development.

The TX and RX gain are maxed on the receiving hardware.
The TX gain of the transmitting hardware is set to 0, as
at max the noise strength increases to ~ 20 dB.

Attached are images of the FFT provided by the Frequency
Sink in Gnuradio. Hopefully these give a visual aid for
the problem at hand. When I have the transmitter USRP
turned off (image 1), it would seem like the noise floor
coming into the

[USRP-users] Re: Strong noise added to signal transmitted by X310 with a UBX 40 daughterboard

[Marcus D. Leech]

On 03/25/2021 07:01 PM, Jerrid Plymale wrote:


We currently are not using a 30dB attenuator in the coax line, I was 
not aware that one was needed until you brought it up. We are looking 
into getting one ordered at the moment. Could this be the cause of the 
problem?


Best Regards,

Jerrid

The problem is that if you transmit directly into an RX with the TX 
power turned up, you can fry the RX.


It also provides a much more realistic simulation of an over-the-air 
link.   ANY receiver that is designed for "Over The Air" reception will
  have a pre-amp that doesn't like to receive power levels above about 
-15dBm (which for over-the-air signals is very very loud).


With the noise figure of your RX (if it isn't damaged already) being 
only about 4dB, it's going to be fairly sensitive to any low-level noise
  that happens to get coupled out of the X3xx electronics when the 
mixer and RF amplifier are "brought up" when a flow-graph is started.


Even when you're transmitting with a "0dB" setting, it can still be 
producing up to about -20dBm power output--the attenuator is
  31.5dB in 0.5dB steps, and the max Pout of the UBX is about +10dBm as 
I recall.  Now, with zeros going to the ADC, the IF port of
  the mixer isn't going to be seeing much power, but it won't be seeing 
exactly zero power because of the inevitable DAC noise.


It will be instructive to see your results with a 30dB attenuator 
in-line and using the suggested tx_waveforms test.






*From:*Marcus D Leech 
*Sent:* Thursday, March 25, 2021 3:40 PM
*To:* Jerrid Plymale 
*Cc:* USRP-users@lists.ettus.com
*Subject:* Re: [USRP-users] Strong noise added to signal transmitted 
by X310 with a UBX 40 daughterboard


Could you confirm that you’re using at least 30dB of attenuation in 
the coax link?


Sent from my iPhone



On Mar 25, 2021, at 6:27 PM, Jerrid Plymale
mailto:jerrid.plym...@canyon-us.com>> wrote:



Yes, moving TX out of the RX band has no affect on the noise level
increase.

Best Regards,

Jerrid

*From:*Marcus D Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Thursday, March 25, 2021 2:29 PM
*To:* Jerrid Plymale mailto:jerrid.plym...@canyon-us.com>>
*Cc:* USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] Strong noise added to signal
transmitted by X310 with a UBX 40 daughterboard

If you move the TX out of band with respect to the RX do you still
see the noise when the TX graph starts?

Sent from my iPhone




On Mar 25, 2021, at 3:57 PM, Jerrid Plymale
mailto:jerrid.plym...@canyon-us.com>> wrote:



So I was able to test setting up both USRPs with the same 10
MHz reference signal, and there was no improvement to the
noise being added.

If the flowgraph just emits a CW tone, we see a similar
response, the added noise is still there and at the same
level, we just have the added spike of the CW tone at the
        frequency we set it to.

Best Regards,

Jerrid

*From:*Marcus D Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Wednesday, March 24, 2021 5:01 PM
*To:* Jerrid Plymale mailto:jerrid.plym...@canyon-us.com>>
*Cc:* USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] Strong noise added to signal
transmitted by X310 with a UBX 40 daughterboard

You don’t need 1PPS for this. Having an external high quality
reference may help, assuming my guess about your issue is
correct.

What happens if your flow graph just simply emits a Cw tone,
using the mute function perhaps tied to a GUI control or some
such.

Sent from my iPhone





On Mar 24, 2021, at 7:13 PM, Jerrid Plymale
mailto:jerrid.plym...@canyon-us.com>> wrote:



Ok, if that’s the case, would it help to have both USRPs
connected to the same 10 MHz reference signal and PPS? In
this situation, would I need to provide a secondary source
for the PPS, or can that use the 10 Mhz reference as well?

Best Regards,

Jerrid

*From:*Marcus D. Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Wednesday, March 24, 2021 2:23 PM
*To:* Jerrid Plymale mailto:jerrid.plym...@canyon-us.com>>
*Cc:* USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] Strong noise added to signal
transmitted by X310 with a UBX 40 daughterboard

On 03/24/2021 05:10 PM, Jerrid Plymale wrote:

The devices are operating using direct connection via
coax cables.

  

[USRP-users] Re: B210 EVM

[Marcus D Leech]

At 30MSPS are you seeing any overruns? What is your master clock rate?

Sent from my iPhone

> On Mar 26, 2021, at 2:41 PM, Julian Arnold  wrote:
> 
> Chris,
> 
> I would say that your EVM is mainly affected by your SNR and your digital 
> receiver implementation (AGC / filters / clock recovery / equalizer / ...). 
> So without more details it’s going to be hard to say if what you  are seeing 
> is within limits.
> 
> Cheers,
> 
> Julian Arnold, M.Sc
> 
>>> Am 26.03.2021 um 18:29 schrieb christopher_beaud...@uml.edu:
>>> 
>> 
>> I'm capturing a 3 GHz QPSK signal with 5 MHz symbol rate by sampling the 
>> signal at 6 times the symbol rate. The B210 is externally referenced to a 
>> very clean 10 MHz reference. My measurements of the EVM sampling the signal 
>> for ~0.5 seconds are pretty poor ~30-40%. I can provide more setup details 
>> but I'm wondering if others can comment on what EVM I can expect. I'm hoping 
>> this isn't a fundamental limitation of this hardware system.
>> 
>> 
>> 
>> Thanks,
>> 
>> Chris
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: B210 EVM

[Marcus D Leech]

I would suggest going back to basics. What does the RX spectrum look like 
compared to the TX spectrum? Are you doing clock recovery on the RX side, or 
assuming both sides are synchronized?



Sent from my iPhone

> On Mar 26, 2021, at 4:38 PM, Beaudoin, Christopher J 
>  wrote:
> 
> 
> Hello Marcus,
> 
> Sorry for the terse nature of my previous message. To be 
> more specific, the precise symbol rate is 4.608 MHz so the actual sample rate 
> is 27.648 MHz; the USRP sets the master clock rate to 27.648 MHz when I 
> command the sample rate. I'm not seeing any overruns at this rate and we 
> spent a fair bit of time fine tuning the host machine to sustain this data 
> rate. It will sustain this rate for as long at 10 minutes without reporting 
> any "O" or "U" errors. I also embed the time stamps into the recorded data 
> file and post recording analysis does not indicate any time disruptions.
> 
> I'm certain that the mod signal (from my vector signal analyzer) has very low 
> EVM (~1%) as confirmed with my Rhode Schwartz signal analyzer. I've also 
> considered saturation of amplifier stages within the AD9361. With 55 dB of 
> gain, I obtain a rms ADC 16-bit state count of ~15000 for a -40 dBm input 
> level. As I understand this should be a suitable level given the B210's IIP3 
> spec is -20 dBm. I've also reduced the input level at constant gain and didnt 
> observe any net improvement in the EVM.
> 
> When properly configured, can I expect the B210 to yield an EVM better than 
> say 5%? 
> 
> Chris
> 
> 
> Creating the usrp device with: num_recv_frames=1024...
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> UHD_3.11.1.0-0-unknown
> [INFO] [B200] Detected Device: B210
> [INFO] [B200] Operating over USB 3.
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Setting master clock rate selection to 'automatic'.
> [INFO] [B200] Asking for clock rate 16.00 MHz...
> [INFO] [B200] Actually got clock rate 16.00 MHz.
> Using Device: Single USRP:
>   Device: B-Series Device
>   Mboard 0: B210
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
> 
> Setting RX Freq: 319900.000 Hz...
> Actual RX Freq: 319900.000 Hz...
> 
> Setting RX Rate:  27648000.000 Sps...
> [INFO] [B200] Asking for clock rate 27.648000 MHz...
> [INFO] [B200] Actually got clock rate 27.648000 MHz.
> Actual RX Rate:  27648000.081 Sps...
> 
> Setting RX Gain: 55.00 dB...
> Actual RX Gain: 55.00 dB...
> 
> Waiting for "lo_locked": ++ locked.
> 
> Press Ctrl + C to stop streaming...
> 
> From: Marcus D Leech 
> Sent: Friday, March 26, 2021 2:45 PM
> To: Julian Arnold 
> Cc: Beaudoin, Christopher J ; 
> USRP-users@lists.ettus.com 
> Subject: Re: [USRP-users] Re: B210 EVM
>  
> This e-mail originated from outside the UMass Lowell network.
> At 30MSPS are you seeing any overruns? What is your master clock rate?
> 
> Sent from my iPhone
> 
>>> On Mar 26, 2021, at 2:41 PM, Julian Arnold  wrote:
>>> 
>> Chris,
>> 
>> I would say that your EVM is mainly affected by your SNR and your digital 
>> receiver implementation (AGC / filters / clock recovery / equalizer / ...). 
>> So without more details it’s going to be hard to say if what you  are seeing 
>> is within limits.
>> 
>> Cheers,
>> 
>> Julian Arnold, M.Sc
>> 
>>> Am 26.03.2021 um 18:29 schrieb christopher_beaud...@uml.edu:
>>> 
>>> 
>>> I'm capturing a 3 GHz QPSK signal with 5 MHz symbol rate by sampling the 
>>> signal at 6 times the symbol rate. The B210 is externally referenced to a 
>>> very clean 10 MHz reference. My measurements of the EVM sampling the signal 
>>> for ~0.5 seconds are pretty poor ~30-40%. I can provide more setup details 
>>> but I'm wondering if others can comment on what EVM I can expect. I'm 
>>> hoping this isn't a fundamental limitation of this hardware system.
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> Chris
>>> 
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Intermittent problem with GPS synchronization for multiple E310 units

[Marcus D. Leech]

On 03/31/2021 06:49 AM, Ofer Saferman wrote:

Hello,

I have a system that uses 4 USRP E310 units.
Each unit is connected to a GPS antenna.
Time source is set to gpsdo.

I run the same software remotely on all 4 units from a PC. Software 
runs on the units themselves.
I print out messages to show if the reference is locked and the GPS is 
locked and also what is the GPS time that each unit was synchronized to.
In some cases the units synchronize to the same GPS time and in other 
cases there is 1 second difference between GPS time of different units 
thus causing the units to be unsynchronized.


I was wondering how this was possible.
The synchronization process (documented by others in the past on the 
mailing list) is:

* Wait for ref and GPS lock
* Wait for a pps edge (get_time_last_pps)
* Read gps_time value
* Sync system clock to GPS clock on next PPS edge (set_time_next_pps + 
1.0 sec)


Something similar is also implemented in the sync_to_gps example.

In order to debug the problem I decided to time the reading of the 
gps_time sensor to see if there is a clue why different units miss the 
PPS edge and lock to a time of the next second.


I was very surprised to find out that it takes between 0.9 to 1.2 
seconds to read the gps_time sensor.
This explains exactly why it is difficult to synchronize multiple 
units to the same time instance because if one unit takes 0.9 seconds 
to read the sensor and the other unit takes 1.2 seconds to read the 
sensor then each unit will lock on a different GPS time 1 second apart.


Here is a short software I wrote to time the gps_time sensor reading:
-
#include 
#include 
//#include 
#include 
#include 
#include 
#include 
#include 

namespace po = boost::program_options;

int UHD_SAFE_MAIN(int argc, char *argv[]){

std::string args;

po::options_description desc("Allowed options");
desc.add_options()
("help", "help message")
("args", po::value(&args)->default_value(""), "device 
address args")

;

po::variables_map vm;
po::store(po::parse_command_line(argc, argv, desc), vm);
po::notify(vm);

//print the help message
if (vm.count("help")){
std::cout << boost::format("Timinig of gps_time: %s") % desc 
<< std::endl;

return ~0;
}

uhd::device3::sptr usrp = uhd::device3::make(args);
//uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);

uhd::sensor_value_t gps_time = 
usrp->get_tree()->access("/mboards/0/sensors/gps_time").get();

//uhd::sensor_value_t gps_time = usrp->get_mboard_sensor("gps_time", 0);

std::chrono::steady_clock::time_point start_time, end_time;
std::chrono::duration time_diff; // Default unit for duration 
is seconds.


for(int ii=0 ; ii<20 ; ii++)
{
start_time = std::chrono::steady_clock::now();
gps_time = 
usrp->get_tree()->access("/mboards/0/sensors/gps_time").get();

//gps_time = usrp->get_mboard_sensor("gps_time", 0);
end_time = std::chrono::steady_clock::now();
time_diff = end_time - start_time;

std::cout << "gps_time[" << (boost::format("%02d") % ii) << "]: " << 
int64_t(gps_time.to_int()) << ". Time to read \"gps_time\": " << 
(boost::format("%0.9f") % time_diff.count()) << " seconds" << std::endl;

}

return 0;
}

Here are the results of one typical run:
gps_time[00]: 1617183840. Time to read "gps_time": 0.884164380 seconds
gps_time[01]: 1617183841. Time to read "gps_time": 0.877966469 seconds
gps_time[02]: 1617183842. Time to read "gps_time": 1.170869661 seconds
gps_time[03]: 1617183843. Time to read "gps_time": 0.882917987 seconds
gps_time[04]: 1617183844. Time to read "gps_time": 1.172120154 seconds
gps_time[05]: 1617183845. Time to read "gps_time": 0.879271985 seconds
gps_time[06]: 1617183846. Time to read "gps_time": 0.878609099 seconds
gps_time[07]: 1617183847. Time to read "gps_time": 1.115639282 seconds
gps_time[08]: 1617183848. Time to read "gps_time": 1.125365551 seconds
gps_time[09]: 1617183849. Time to read "gps_time": 0.843803231 seconds
gps_time[10]: 1617183850. Time to read "gps_time": 1.125065740 seconds
gps_time[11]: 1617183851. Time to read "gps_time": 0.847519817 seconds
gps_time[12]: 1617183852. Time to read "gps_time": 1.121398945 seconds
gps_time[13]: 1617183853. Time to read "gps_time": 0.844371533 seconds
gps_time[14]: 1617183854. Time to read "gps_time": 1.124722726 seconds
gps_time[15]: 1617183855. Time to read "gps_time": 0.845688380 seconds
gps_time[16]: 1617183856. Time to read "gps_time": 1.129568096 seconds
gps_time[17]: 1617183857. Time to read "gps_time": 0.882436229 seconds
gps_time[18]: 1617183858. Time to read "gps_time": 1.168227593 seconds
gps_time[19]: 1617183859. Time to read "gps_time": 0.881948247 seconds
---
In the code you can find commented out the usual way to access the 
sensor using multi_usrp and ge

[USRP-users] Re: 10us delay between the two X310 daughterboards in TX

[Marcus D Leech]

It’s like the semantics of “pC clock” synch causing this. Try changing to 
“unknown PPS”

Sent from my iPhone

> On Mar 31, 2021, at 10:43 AM, Lorenzo Bertizzolo 
>  wrote:
> 
> 
> Hi all,
> 
> I am experiencing a time synchronization issue internal to the USRP X310. 
> With the help of an oscilloscope, I measured an (apparently) constant delay 
> between the two X310 output TX ports of approximately 10~14 µs (picture 
> attached). 
>  
> I tried different bandwidths, both UHD 4 (UHD 4.0.0.0-25-g1a34ba8a) and UHD 
> 3.15 (UHD 3.15.0.0-62-g7a3f1516), and different X310 hardware, always 
> experiencing the same time delay.
> 
> To track down this issue I simplified my flowgraph. It now feeds data to the 
> two UHD USRP sink channels from file, using `packet_len’ tags accordingly 
> (picture attached). 
> I verified thanks to the QT scope that the two streams enter the USRP Sink 
> with the two tags at the same time. 
> 
> Setup:USRP X310 / UBX daughterboards / Gnuradio 3.8 with UHD 4, Gnuradio 3.7 
> with UHD 15
> 
> 
> It seems that either the USRP sink block or UHD are not sending out the 
> samples at the same time from the two X310 TX daughterboards. 
> Is there any misconfiguration in my setting that could be the root cause of 
> this issue?
> 
> Thanks,
> Lorenzo
> 
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Intermittent problem with GPS synchronization for multiple E310 units

[Marcus D Leech]

Sent from my iPhone

> On Mar 31, 2021, at 2:22 PM, Rob Kossler  wrote:
> 
> 
> Hi Ofer,
> Take a look at the Ettus source code gps_ctrl.cpp.  In particular, look at 
> the get_sentence() usage which in the case of "gps_time" waits for the next 
> occurrence (wait=true),  but for the others does not wait.  But this doesn't 
> fully explain the behavior you are seeing.  If you do the following:
> 1) wait for PPS time to change
> 2) read the "gps_time" sensor
> 3) set_time_next_pps (use the value you just read)
Add 1 to the time you just read before calling set_time_next_pps. 


> It should still work because the "gps_time" command should just wait until 
> the next PPS.  I guess it depends upon how "synchronized" are the received 
> NMEA string with the PPS edge.  Step 1 above waits for the PPS edge, but 
> maybe the NMEA string arrives 0.1 secs before or after that.  I don't really 
> know.  Perhaps you need to switch to using "gps_gpgga" such that there is no 
> additional wait added and also perhaps you should add step 1B which would be 
> just a fixed delay of perhaps 0.4 secs so that you will read the NMEA string 
> in between the PPS edges.
> Rob
> 
>> On Wed, Mar 31, 2021 at 1:22 PM Rob Kossler  wrote:
>> Hi Ofer,
>> I don't know why the "gps_time" sensor takes long to read. But, can you try 
>> the other sensors (perhaps there is a "gps_gpgga" sensor?)?  The time is 
>> embedded in these as well.  
>> Rob
>> 
>> 
>>> On Wed, Mar 31, 2021 at 12:21 PM Ofer Saferman  wrote:
>>> Marcus Hi,
>>> 
>>> If the gps_time "sensor" returns a value only once per second how come I 
>>> manage to read it sometimes in less than 1 second?
>>> In my code the situation is worse than the simple example below. It usually 
>>> takes more than 1 sec. to read it and sometimes even 1.7 or 1.8 seconds. I 
>>> don't understand how the size or complexity of the code affects the time it 
>>> takes to read gps_time.
>>> 
>>> How to treat your comment about the use of GPSD and good synchronization as 
>>> it relates to code?
>>> Should I not change the time source in code and go through the whole 
>>> process of synchronization using gps_time?
>>> Can I "assume" the systems are synced just by the effect they were 
>>> connected enough time to a GPS antenna? and then just access their time - 
>>> radio_ctrl->get_time_last_pps()?
>>> How to use this information programmatically?
>>> 
>>> Regards,
>>> Ofer Saferman
>>> 
>>> 
>>>> -- Forwarded message --
>>>> From: "Marcus D. Leech" 
>>>> To: usrp-users@lists.ettus.com
>>>> Cc: 
>>>> Bcc: 
>>>> Date: Wed, 31 Mar 2021 09:19:20 -0400
>>>> Subject: [USRP-users] Re: Intermittent problem with GPS synchronization 
>>>> for multiple E310 units
>>>> On 03/31/2021 06:49 AM, Ofer Saferman wrote:
>>>> > Hello,
>>>> >
>>>> > I have a system that uses 4 USRP E310 units.
>>>> > Each unit is connected to a GPS antenna.
>>>> > Time source is set to gpsdo.
>>>> >
>>>> > I run the same software remotely on all 4 units from a PC. Software 
>>>> > runs on the units themselves.
>>>> > I print out messages to show if the reference is locked and the GPS is 
>>>> > locked and also what is the GPS time that each unit was synchronized to.
>>>> > In some cases the units synchronize to the same GPS time and in other 
>>>> > cases there is 1 second difference between GPS time of different units 
>>>> > thus causing the units to be unsynchronized.
>>>> >
>>>> > I was wondering how this was possible.
>>>> > The synchronization process (documented by others in the past on the 
>>>> > mailing list) is:
>>>> > * Wait for ref and GPS lock
>>>> > * Wait for a pps edge (get_time_last_pps)
>>>> > * Read gps_time value
>>>> > * Sync system clock to GPS clock on next PPS edge (set_time_next_pps + 
>>>> > 1.0 sec)
>>>> >
>>>> > Something similar is also implemented in the sync_to_gps example.
>>>> >
>>>> > In order to debug the problem I decided to time the reading of the 
>>>> > gps_time sensor to see if there is a clue why different units miss the 
>>>> 

[USRP-users] Re: Intermittent problem with GPS synchronization for multiple E310 units

[Marcus D Leech]

Just use gettimeofday() or any of the myriad subtle variants available in boost 
to get you the Linux system time, and use that in a call to 
set_time_next_pps(). 

The fact that all your E310s will be running GPSD means they’ll be adjusting 
system time appropriately and they’ll all agree on what time it is, depending 
on the level of precision you need. 

Sent from my iPhone

> On Mar 31, 2021, at 3:50 PM, Ofer Saferman  wrote:
> 
> 
> Thank you Rob. Your suggestions are always helpful. I will look into using 
> gps_gpgga.
> Thank you Marcus. I am already adding one, per other examples posted here and 
> sync_to_gps example. Can you please comment how I can benefit from the fact 
> that E310 units use gpsd in Linux?
> 
> Regards,
> Ofer Saferman
> 
>> On Wed, Mar 31, 2021 at 10:13 PM Marcus D Leech  
>> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>>> On Mar 31, 2021, at 2:22 PM, Rob Kossler  wrote:
>>>> 
>>> 
>>> Hi Ofer,
>>> Take a look at the Ettus source code gps_ctrl.cpp.  In particular, look at 
>>> the get_sentence() usage which in the case of "gps_time" waits for the next 
>>> occurrence (wait=true),  but for the others does not wait.  But this 
>>> doesn't fully explain the behavior you are seeing.  If you do the following:
>>> 1) wait for PPS time to change
>>> 2) read the "gps_time" sensor
>>> 3) set_time_next_pps (use the value you just read)
>> Add 1 to the time you just read before calling set_time_next_pps. 
>> 
>> 
>>> It should still work because the "gps_time" command should just wait until 
>>> the next PPS.  I guess it depends upon how "synchronized" are the received 
>>> NMEA string with the PPS edge.  Step 1 above waits for the PPS edge, but 
>>> maybe the NMEA string arrives 0.1 secs before or after that.  I don't 
>>> really know.  Perhaps you need to switch to using "gps_gpgga" such that 
>>> there is no additional wait added and also perhaps you should add step 1B 
>>> which would be just a fixed delay of perhaps 0.4 secs so that you will read 
>>> the NMEA string in between the PPS edges.
>>> Rob
>>> 
>>>> On Wed, Mar 31, 2021 at 1:22 PM Rob Kossler  wrote:
>>>> Hi Ofer,
>>>> I don't know why the "gps_time" sensor takes long to read. But, can you 
>>>> try the other sensors (perhaps there is a "gps_gpgga" sensor?)?  The time 
>>>> is embedded in these as well.  
>>>> Rob
>>>> 
>>>> 
>>>>> On Wed, Mar 31, 2021 at 12:21 PM Ofer Saferman  wrote:
>>>>> Marcus Hi,
>>>>> 
>>>>> If the gps_time "sensor" returns a value only once per second how come I 
>>>>> manage to read it sometimes in less than 1 second?
>>>>> In my code the situation is worse than the simple example below. It 
>>>>> usually takes more than 1 sec. to read it and sometimes even 1.7 or 1.8 
>>>>> seconds. I don't understand how the size or complexity of the code 
>>>>> affects the time it takes to read gps_time.
>>>>> 
>>>>> How to treat your comment about the use of GPSD and good synchronization 
>>>>> as it relates to code?
>>>>> Should I not change the time source in code and go through the whole 
>>>>> process of synchronization using gps_time?
>>>>> Can I "assume" the systems are synced just by the effect they were 
>>>>> connected enough time to a GPS antenna? and then just access their time - 
>>>>> radio_ctrl->get_time_last_pps()?
>>>>> How to use this information programmatically?
>>>>> 
>>>>> Regards,
>>>>> Ofer Saferman
>>>>> 
>>>>> 
>>>>>> -- Forwarded message --
>>>>>> From: "Marcus D. Leech" 
>>>>>> To: usrp-users@lists.ettus.com
>>>>>> Cc: 
>>>>>> Bcc: 
>>>>>> Date: Wed, 31 Mar 2021 09:19:20 -0400
>>>>>> Subject: [USRP-users] Re: Intermittent problem with GPS synchronization 
>>>>>> for multiple E310 units
>>>>>> On 03/31/2021 06:49 AM, Ofer Saferman wrote:
>>>>>> > Hello,
>>>>>> >
>>>>>> > I have a system that uses 4 USRP E310 units.
>>>>>> > Each unit is connected to a GPS antenna.
>>>>>> 

[USRP-users] Re: Error init_usrp

[Marcus D. Leech]

On 04/01/2021 04:22 AM, COURANT Frederique - Contractor via USRP-users 
wrote:


Hi Users,

I have follow tutorials Getting Started with UHD and C++ but when I 
try to run init_usrp I have the following error :


Error: RuntimeError: For legacy APIs, all devices require the same 
number of radios, DDCs and DUCs.


Someone could help me to understand and resolve this error please ?

Best regards.

Fred


What arguments did you pass to the init_usrp example program?  More 
context is usually incredibly helpful in helping us help you.




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

[USRP-users] Re: Intermittent problem with GPS synchronization for multiple E310 units

[Marcus D. Leech]

On 04/01/2021 06:00 AM, Ofer Saferman wrote:

Hello Marcus,

I am working on E310 with the latest UHD-3.15 SD card image.
It seems not to include ntpd that is required to synchronize system 
time to GPS time.

Any idea how to install it on the E310?

Regards,
Ofer Saferman

sudo opkg install ntpd

should work, but it has been a while since I installed any packages on 
my E310.


The E310 is based on OpenEmbedded Linux, so all the info about 
installing and managing packages on OpenEmbedded apply.





On Wed, Mar 31, 2021 at 11:40 PM Marcus D Leech 
mailto:patchvonbr...@gmail.com>> wrote:


Just use gettimeofday() or any of the myriad subtle variants
available in boost to get you the Linux system time, and use that
in a call to set_time_next_pps().

The fact that all your E310s will be running GPSD means they’ll be
adjusting system time appropriately and they’ll all agree on what
time it is, depending on the level of precision you need.

Sent from my iPhone


On Mar 31, 2021, at 3:50 PM, Ofer Saferman mailto:o...@navigicom.com>> wrote:


Thank you Rob. Your suggestions are always helpful. I will look
into using gps_gpgga.
Thank you Marcus. I am already adding one, per other examples
posted here and sync_to_gps example. Can you please comment how I
can benefit from the fact that E310 units use gpsd in Linux?

Regards,
Ofer Saferman

On Wed, Mar 31, 2021 at 10:13 PM Marcus D Leech
mailto:patchvonbr...@gmail.com>> wrote:



Sent from my iPhone


On Mar 31, 2021, at 2:22 PM, Rob Kossler mailto:rkoss...@nd.edu>> wrote:


Hi Ofer,
Take a look at the Ettus source code gps_ctrl.cpp.  In
particular, look at the get_sentence() usage which in the
case of "gps_time" waits for the next occurrence
(wait=true),  but for the others does not wait.  But this
doesn't fully explain the behavior you are seeing.  If you
do the following:
1) wait for PPS time to change
2) read the "gps_time" sensor
3) set_time_next_pps (use the value you just read)

Add 1 to the time you just read before calling
set_time_next_pps.



It should still work because the "gps_time" command should
just wait until the next PPS.  I guess it depends upon how
"synchronized" are the received NMEA string with the PPS
edge. Step 1 above waits for the PPS edge, but maybe the
NMEA string arrives 0.1 secs before or after that.  I don't
really know. Perhaps you need to switch to using "gps_gpgga"
such that there is no additional wait added and also perhaps
you should add step 1B which would be just a fixed delay of
perhaps 0.4 secs so that you will read the NMEA string in
between the PPS edges.
Rob

On Wed, Mar 31, 2021 at 1:22 PM Rob Kossler mailto:rkoss...@nd.edu>> wrote:

Hi Ofer,
I don't know why the "gps_time" sensor takes long to
read. But, can you try the other sensors (perhaps there
is a "gps_gpgga" sensor?)?  The time is embedded in
these as well.
Rob


On Wed, Mar 31, 2021 at 12:21 PM Ofer Saferman
mailto:o...@navigicom.com>> wrote:

Marcus Hi,

If the gps_time "sensor" returns a value only once
per second how come I manage to read it sometimes in
less than 1 second?
In my code the situation is worse than the simple
example below. It usually takes more than 1 sec. to
read it and sometimes even 1.7 or 1.8 seconds. I
don't understand how the size or complexity of the
code affects the time it takes to read gps_time.

How to treat your comment about the use of GPSD and
good synchronization as it relates to code?
Should I not change the time source in code and go
through the whole process of synchronization using
gps_time?
Can I "assume" the systems are synced just by the
effect they were connected enough time to a GPS
antenna? and then just access their time -
radio_ctrl->get_time_last_pps()?
How to use this information programmatically?

        Regards,
Ofer Saferman


-- Forwarded message --
From: "Marcus D. Leech" mailto:patchvonbr...@gmail.com>>
To: usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
Cc:
Bcc:
Da

[USRP-users] Re: Intermittent problem with GPS synchronization for multiple E310 units

[Marcus D. Leech]

On 04/01/2021 06:00 AM, Ofer Saferman wrote:

Hello Marcus,

I am working on E310 with the latest UHD-3.15 SD card image.
It seems not to include ntpd that is required to synchronize system 
time to GPS time.

Any idea how to install it on the E310?

Regards,
Ofer Saferman

According to an old thread:

http://ettus.80997.x6.nabble.com/USRP-users-Setting-E310-time-to-GPS-time-td872.html

The standard system image should already be configured to use NTPD/GPSD 
to steer system time.





On Wed, Mar 31, 2021 at 11:40 PM Marcus D Leech 
mailto:patchvonbr...@gmail.com>> wrote:


Just use gettimeofday() or any of the myriad subtle variants
available in boost to get you the Linux system time, and use that
in a call to set_time_next_pps().

The fact that all your E310s will be running GPSD means they’ll be
adjusting system time appropriately and they’ll all agree on what
time it is, depending on the level of precision you need.

Sent from my iPhone


On Mar 31, 2021, at 3:50 PM, Ofer Saferman mailto:o...@navigicom.com>> wrote:


Thank you Rob. Your suggestions are always helpful. I will look
into using gps_gpgga.
Thank you Marcus. I am already adding one, per other examples
posted here and sync_to_gps example. Can you please comment how I
can benefit from the fact that E310 units use gpsd in Linux?

Regards,
Ofer Saferman

On Wed, Mar 31, 2021 at 10:13 PM Marcus D Leech
mailto:patchvonbr...@gmail.com>> wrote:



Sent from my iPhone


On Mar 31, 2021, at 2:22 PM, Rob Kossler mailto:rkoss...@nd.edu>> wrote:


Hi Ofer,
Take a look at the Ettus source code gps_ctrl.cpp.  In
particular, look at the get_sentence() usage which in the
case of "gps_time" waits for the next occurrence
(wait=true),  but for the others does not wait.  But this
doesn't fully explain the behavior you are seeing.  If you
do the following:
1) wait for PPS time to change
2) read the "gps_time" sensor
3) set_time_next_pps (use the value you just read)

Add 1 to the time you just read before calling
set_time_next_pps.



It should still work because the "gps_time" command should
just wait until the next PPS.  I guess it depends upon how
"synchronized" are the received NMEA string with the PPS
edge. Step 1 above waits for the PPS edge, but maybe the
NMEA string arrives 0.1 secs before or after that.  I don't
really know. Perhaps you need to switch to using "gps_gpgga"
such that there is no additional wait added and also perhaps
you should add step 1B which would be just a fixed delay of
perhaps 0.4 secs so that you will read the NMEA string in
between the PPS edges.
Rob

On Wed, Mar 31, 2021 at 1:22 PM Rob Kossler mailto:rkoss...@nd.edu>> wrote:

Hi Ofer,
I don't know why the "gps_time" sensor takes long to
read. But, can you try the other sensors (perhaps there
is a "gps_gpgga" sensor?)?  The time is embedded in
these as well.
Rob


On Wed, Mar 31, 2021 at 12:21 PM Ofer Saferman
mailto:o...@navigicom.com>> wrote:

Marcus Hi,

If the gps_time "sensor" returns a value only once
per second how come I manage to read it sometimes in
less than 1 second?
In my code the situation is worse than the simple
example below. It usually takes more than 1 sec. to
read it and sometimes even 1.7 or 1.8 seconds. I
don't understand how the size or complexity of the
code affects the time it takes to read gps_time.

How to treat your comment about the use of GPSD and
good synchronization as it relates to code?
Should I not change the time source in code and go
through the whole process of synchronization using
gps_time?
Can I "assume" the systems are synced just by the
effect they were connected enough time to a GPS
antenna? and then just access their time -
radio_ctrl->get_time_last_pps()?
How to use this information programmatically?

        Regards,
Ofer Saferman


-- Forwarded message --
From: "Marcus D. Leech" mailto:patchvonbr...@gmail.com>>
To: usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
Cc:
Bcc:
Date: Wed, 31 Mar 2021 09

[USRP-users] Re: Debugging with Visual Studio Code in v3.8

[Marcus D. Leech]

On 03/31/2021 03:47 PM, Jeff S wrote:
While using GNURadio v3.7, I used to be able to perform source-level 
debugging with Visual Studio Code (probably more often than I'd like 
to admit) using the instructions located at:


https://wiki.gnuradio.org/index.php/UsingVSCode


I have now upgraded to use v3.8 and just tried to do the same thing.  
But now with v3.8, I get "Unknown Source" for my code within the 
debugger.  I can start up and run just fine, but can't get to my 
source or breakpoints.  I built using:


cmake ../ -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_EXPORT_COMPILE_COMMANDS=true


so I could see that I get the "-g" in the compile commands is actually 
set.  Just curious if anyone else is using it or having troubles.  
Hopefully it's one of those obvious things I have done wrong.


Thanks,
Jeff



___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
This is definitely a question for the discuss-gnuradio mailing list, not 
usrp-users.



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

[USRP-users] Re: Problem with interfacing Raspberry Pi 4 to USRP B210 with Python API

[Marcus D Leech]

Perhaps look at the PyBombs recipe for your platform—there’s probably a 
compiler flag that needs to be set that you’re missing, but I don’t know what 
that is. 

Also, in general, you don’t need to become root to compile and build code—only 
needed during the “make install”



Sent from my iPhone

> On Apr 2, 2021, at 7:19 AM, Brendan Horsfield 
>  wrote:
> 
> 
> Hi Folks,
> 
> I would like to interface my Raspberry Pi 4 to a USRP B210 via the Python 
> API.  This requires the UHD driver to be built from source.  Unfortunately, 
> whenever I try this I encounter some errors that stop the build process in 
> its tracks.
> 
> Details of the error are as follows:
> 
> [ 53%] Linking CXX executable test_clock_synch
> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
> `__atomic_compare_exchange_8'
> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to `__atomic_load_8'
> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to `__atomic_store_8'
> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
> `__atomic_fetch_add_8'
> collect2: error: ld returned 1 exit status
> make[2]: *** [examples/CMakeFiles/test_clock_synch.dir/build.make:95: 
> examples/test_clock_synch] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1039: 
> examples/CMakeFiles/test_clock_synch.dir/all] Error 2
> make: *** [Makefile:163: all] Error 2
> 
> The process I have been using is as follows:
> 
> STEP 1:  INSTALL DEPENDENCIES
> sudo apt-get install libboost-all-dev libusb-1.0-0-dev doxygen 
> python3-docutils python3-mako python3-numpy python3-requests 
> python3-ruamel.yaml python3-setuptools cmake build-essential
> 
> STEP 2:  BUILD UHD DRIVER FROM SOURCE
> cd /home/pi
> mkdir workarea-uhd
> cd workarea-uhd
> git clone https://github.com/EttusResearch/uhd
> cd uhd
> git checkout v4.0.0.0
> cd host
> mkdir build
> cd build
> sudo cmake -DNEON_SIMD_ENABLE=OFF -DENABLE_PYTHON_API=ON ../
> sudo make  --->  (ERRORS OCCUR DURING "MAKE" PROCESS)
> 
> My system configuration is as follows:
> Hardware: Raspberry Pi 4 Model B Rev 1.4
> OS: Raspbian GNU/Linux 10 (buster) (32-bit, armv7l)
> Ettus USRP B210
> 
> Does anyone know what the problem could be, and how I can resolve it?
> 
> One final note:  Using PyBOMBS, I was able to successfully build & install 
> the UHD driver and connect to the USRP.  Unfortunately the PyBOMBS build does 
> not include the Python API, which is what I really want.  Is there a 
> different version of the PyBOMBS build that includes the Python API?
> 
> Thanks & Regards,
> Brendan.
> 
> 
>   
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Intermittent problem with GPS synchronization for multiple E310 units

[Marcus D Leech]

It may be the case that either the current OE image they use chronyd rather 
than ntpd. I have a query in to Ettus/NI R&D for guidance. 

Sent from my iPhone

> On Apr 2, 2021, at 7:26 AM, Ofer Saferman  wrote:
> 
> 
> Marcus Hi,
> 
> Your suggestion below to install ntpd does not work.
> The image does not include it. Although the old thread says otherwise I think 
> it refers to an older UHD release that did include ntpd.
> Any accurate instructions on how to install it anyway? 
> Maybe opkg should be configured to access another repository? 
> Doing: opkg list | grep ntpd, does not yield anything useful so it is not 
> just a question of typing it correctly.
> 
> Regards,
> Ofer Saferman
> 
>> On Thu, Apr 1, 2021 at 4:34 PM Marcus D. Leech  
>> wrote:
>> On 04/01/2021 06:00 AM, Ofer Saferman wrote:
>>> Hello Marcus,
>>> 
>>> I am working on E310 with the latest UHD-3.15 SD card image.
>>> It seems not to include ntpd that is required to synchronize system time to 
>>> GPS time.
>>> Any idea how to install it on the E310?
>>> 
>>> Regards,
>>> Ofer Saferman
>> sudo opkg install ntpd
>> 
>> should work, but it has been a while since I installed any packages on my 
>> E310.
>> 
>> The E310 is based on OpenEmbedded Linux, so all the info about installing 
>> and managing packages on OpenEmbedded apply.
>> 
>> 
>>> 
>>> On Wed, Mar 31, 2021 at 11:40 PM Marcus D Leech  
>>> wrote:
>>>> Just use gettimeofday() or any of the myriad subtle variants available in 
>>>> boost to get you the Linux system time, and use that in a call to 
>>>> set_time_next_pps(). 
>>>> 
>>>> The fact that all your E310s will be running GPSD means they’ll be 
>>>> adjusting system time appropriately and they’ll all agree on what time it 
>>>> is, depending on the level of precision you need. 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Mar 31, 2021, at 3:50 PM, Ofer Saferman  wrote:
>>>>> 
>>>>> 
>>>>> Thank you Rob. Your suggestions are always helpful. I will look into 
>>>>> using gps_gpgga.
>>>>> Thank you Marcus. I am already adding one, per other examples posted here 
>>>>> and sync_to_gps example. Can you please comment how I can benefit from 
>>>>> the fact that E310 units use gpsd in Linux?
>>>>> 
>>>>> Regards,
>>>>> Ofer Saferman
>>>>> 
>>>>> On Wed, Mar 31, 2021 at 10:13 PM Marcus D Leech  
>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On Mar 31, 2021, at 2:22 PM, Rob Kossler  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Hi Ofer,
>>>>>>> Take a look at the Ettus source code gps_ctrl.cpp.  In particular, look 
>>>>>>> at the get_sentence() usage which in the case of "gps_time" waits for 
>>>>>>> the next occurrence (wait=true),  but for the others does not wait.  
>>>>>>> But this doesn't fully explain the behavior you are seeing.  If you do 
>>>>>>> the following:
>>>>>>> 1) wait for PPS time to change
>>>>>>> 2) read the "gps_time" sensor
>>>>>>> 3) set_time_next_pps (use the value you just read)
>>>>>> Add 1 to the time you just read before calling set_time_next_pps. 
>>>>>> 
>>>>>> 
>>>>>>> It should still work because the "gps_time" command should just wait 
>>>>>>> until the next PPS.  I guess it depends upon how "synchronized" are the 
>>>>>>> received NMEA string with the PPS edge.  Step 1 above waits for the PPS 
>>>>>>> edge, but maybe the NMEA string arrives 0.1 secs before or after that.  
>>>>>>> I don't really know.  Perhaps you need to switch to using "gps_gpgga" 
>>>>>>> such that there is no additional wait added and also perhaps you should 
>>>>>>> add step 1B which would be just a fixed delay of perhaps 0.4 secs so 
>>>>>>> that you will read the NMEA string in between the PPS edges.
>>>>>>> Rob
>>>>>>> 
>>>>>>> On Wed, Mar 31, 2021 at 1:22 PM Rob Kossler  wrote:
>>>>

[USRP-users] Re: Problem with interfacing Raspberry Pi 4 to USRP B210 with Python API

[Marcus D Leech]

Sent from my iPhone

> On Apr 3, 2021, at 7:08 AM, Brendan Horsfield  QUESTION 2:  This whole process feels more difficult than it should be.  Why 
> isn't the Python API installed with the UHD driver by default?  Would I be 
> better off using another language (like C++) to control the USRP?
> 
> Thanks,
> Brendan.
> 
Well, NI/Ettus have zero control over how various distros choose to package and 
build UHD, similarly for PyBombs—PyBombs isn’t maintained by NI/Ettus. 

So if you “land” on a distro where the packaged UHD doesn’t include Python 
support, then you end up building UHD yourself. Which may entail the pain you 
encountered due to missing compiler flags. 

Because the Linux world is so incredibly diverse, it’s rare that the developer 
of a given code base is also responsible for packaging for a given 
distro/platform. That’s why there are “package maintainers” for each distro, 
and they’re the ones who end up making decisions like enabling support for 
various options, turning on “weird” compiler flags, etc. 

UHD is no different in this regard. 

> 
> 
>> On Fri, Apr 2, 2021 at 11:25 PM Marcus D Leech  
>> wrote:
>> Perhaps look at the PyBombs recipe for your platform—there’s probably a 
>> compiler flag that needs to be set that you’re missing, but I don’t know 
>> what that is. 
>> 
>> Also, in general, you don’t need to become root to compile and build 
>> code—only needed during the “make install”
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>>> On Apr 2, 2021, at 7:19 AM, Brendan Horsfield 
>>>>  wrote:
>>>> 
>>> 
>>> Hi Folks,
>>> 
>>> I would like to interface my Raspberry Pi 4 to a USRP B210 via the Python 
>>> API.  This requires the UHD driver to be built from source.  Unfortunately, 
>>> whenever I try this I encounter some errors that stop the build process in 
>>> its tracks.
>>> 
>>> Details of the error are as follows:
>>> 
>>> [ 53%] Linking CXX executable test_clock_synch
>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>> `__atomic_compare_exchange_8'
>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>> `__atomic_load_8'
>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>> `__atomic_store_8'
>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>> `__atomic_fetch_add_8'
>>> collect2: error: ld returned 1 exit status
>>> make[2]: *** [examples/CMakeFiles/test_clock_synch.dir/build.make:95: 
>>> examples/test_clock_synch] Error 1
>>> make[1]: *** [CMakeFiles/Makefile2:1039: 
>>> examples/CMakeFiles/test_clock_synch.dir/all] Error 2
>>> make: *** [Makefile:163: all] Error 2
>>> 
>>> The process I have been using is as follows:
>>> 
>>> STEP 1:  INSTALL DEPENDENCIES
>>> sudo apt-get install libboost-all-dev libusb-1.0-0-dev doxygen 
>>> python3-docutils python3-mako python3-numpy python3-requests 
>>> python3-ruamel.yaml python3-setuptools cmake build-essential
>>> 
>>> STEP 2:  BUILD UHD DRIVER FROM SOURCE
>>> cd /home/pi
>>> mkdir workarea-uhd
>>> cd workarea-uhd
>>> git clone https://github.com/EttusResearch/uhd
>>> cd uhd
>>> git checkout v4.0.0.0
>>> cd host
>>> mkdir build
>>> cd build
>>> sudo cmake -DNEON_SIMD_ENABLE=OFF -DENABLE_PYTHON_API=ON ../
>>> sudo make  --->  (ERRORS OCCUR DURING "MAKE" PROCESS)
>>> 
>>> My system configuration is as follows:
>>> Hardware: Raspberry Pi 4 Model B Rev 1.4
>>> OS: Raspbian GNU/Linux 10 (buster) (32-bit, armv7l)
>>> Ettus USRP B210
>>> 
>>> Does anyone know what the problem could be, and how I can resolve it?
>>> 
>>> One final note:  Using PyBOMBS, I was able to successfully build & install 
>>> the UHD driver and connect to the USRP.  Unfortunately the PyBOMBS build 
>>> does not include the Python API, which is what I really want.  Is there a 
>>> different version of the PyBOMBS build that includes the Python API?
>>> 
>>> Thanks & Regards,
>>> Brendan.
>>> 
>>> 
>>>   
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Problem with interfacing Raspberry Pi 4 to USRP B210 with Python API

[Marcus D Leech]

The C++ API is the standard API for UHD follows by the legacy C API and then 
the Python API.  The Python API is still considered experimental, and it will 
necessarily have performance issues—that’s just the nature of an interpreted 
language trying to do high performance real-time signal processing—even when 
you use things like numpy. 

Sent from my iPhone

> On Apr 3, 2021, at 7:37 PM, Brendan Horsfield 
>  wrote:
> 
> 
> Your point is well taken, although I confess I am still a bit surprised that 
> Python support is not the norm, given the popularity of this language in the 
> scientific & engineering community.  
> 
> Getting back to my problem:  Am I correct in assuming that the C++ API is 
> included as standard with every UHD build?  If so, rather than spending 
> days/weeks trying to add Python support to UHD on the Raspberry Pi, would it 
> be faster for me to just create a C++ function to communicate with the USRP, 
> and put a Python wrapper around it?
> 
>> On Sun, Apr 4, 2021 at 1:15 AM Marcus D Leech  
>> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Apr 3, 2021, at 7:08 AM, Brendan Horsfield >> QUESTION 2:  This whole process feels more difficult than it should be.  
>>> Why isn't the Python API installed with the UHD driver by default?  Would I 
>>> be better off using another language (like C++) to control the USRP?
>>> 
>>> Thanks,
>>> Brendan.
>>> 
>> Well, NI/Ettus have zero control over how various distros choose to package 
>> and build UHD, similarly for PyBombs—PyBombs isn’t maintained by NI/Ettus. 
>> 
>> So if you “land” on a distro where the packaged UHD doesn’t include Python 
>> support, then you end up building UHD yourself. Which may entail the pain 
>> you encountered due to missing compiler flags. 
>> 
>> Because the Linux world is so incredibly diverse, it’s rare that the 
>> developer of a given code base is also responsible for packaging for a given 
>> distro/platform. That’s why there are “package maintainers” for each distro, 
>> and they’re the ones who end up making decisions like enabling support for 
>> various options, turning on “weird” compiler flags, etc. 
>> 
>> UHD is no different in this regard. 
>> 
>>> 
>>> 
>>>> On Fri, Apr 2, 2021 at 11:25 PM Marcus D Leech  
>>>> wrote:
>>>> Perhaps look at the PyBombs recipe for your platform—there’s probably a 
>>>> compiler flag that needs to be set that you’re missing, but I don’t know 
>>>> what that is. 
>>>> 
>>>> Also, in general, you don’t need to become root to compile and build 
>>>> code—only needed during the “make install”
>>>> 
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>>> On Apr 2, 2021, at 7:19 AM, Brendan Horsfield 
>>>>>>  wrote:
>>>>>> 
>>>>> 
>>>>> Hi Folks,
>>>>> 
>>>>> I would like to interface my Raspberry Pi 4 to a USRP B210 via the Python 
>>>>> API.  This requires the UHD driver to be built from source.  
>>>>> Unfortunately, whenever I try this I encounter some errors that stop the 
>>>>> build process in its tracks.
>>>>> 
>>>>> Details of the error are as follows:
>>>>> 
>>>>> [ 53%] Linking CXX executable test_clock_synch
>>>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>>>> `__atomic_compare_exchange_8'
>>>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>>>> `__atomic_load_8'
>>>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>>>> `__atomic_store_8'
>>>>> /usr/bin/ld: ../lib/libuhd.so.4.0.0: undefined reference to 
>>>>> `__atomic_fetch_add_8'
>>>>> collect2: error: ld returned 1 exit status
>>>>> make[2]: *** [examples/CMakeFiles/test_clock_synch.dir/build.make:95: 
>>>>> examples/test_clock_synch] Error 1
>>>>> make[1]: *** [CMakeFiles/Makefile2:1039: 
>>>>> examples/CMakeFiles/test_clock_synch.dir/all] Error 2
>>>>> make: *** [Makefile:163: all] Error 2
>>>>> 
>>>>> The process I have been using is as follows:
>>>>> 
>>>>> STEP 1:  INSTALL DEPENDENCIES
>>>>> sudo apt-get install libboost-all-dev libusb-1.0-0-dev doxygen 
>>>>> python3-docutils python3-mako python3-numpy py

[USRP-users] Re: Problem with interfacing Raspberry Pi 4 to USRP B210 with Python API

[Marcus D Leech]

>> 
>> One caveat; the pi USB 3.0 interface can’t quite keep up with the B-210 and 
>> I get an overflow when capturing 20MSPS on 2 channels at about 500k samples. 
>> I don’t know if this is hardware or software, but if anyone knows of a 
>> solution, I’m all ears. Having said that, I can consistently and reliably 
>> capture 400-500k samples sized files.
>> 
Writing to the file system at 10s of MSPS is a very demanding application. At 
20Msps with complex-float samples, that’s 160Mbyte/second. It would be a 
miracle if a lowly rPi4 could sustain that. 

You can usually get away with shorter runs because of Linux write-behind cache. 
But once it starts needing to “commit” those writes to physical media the piper 
must be paid. 


>> I’d be happy to share the install instructions. They are lengthy. -page
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: DC power supply for B210

[Marcus D Leech]

5.5 x 2.1 is still correct. 

Sent from my iPhone

> On Apr 9, 2021, at 7:09 AM, brendan.horsfi...@vectalabs.com wrote:
> 
> 
> Hi All,
> 
> I am looking to purchase an external power supply for my USRP B210, but I 
> can’t figure out what size connector I should get. I found an old post where 
> the specs were given as outer shell = 5.5mm, pin diameter = 2.1mm, but that 
> was in 2011 for a USRP1.
> 
> Does anyone know what the latest specs are on the power connector that plugs 
> into the B210?
> 
> Thanks,
> 
> Brendan.
> 
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: B205 mini-i isn't found by uhd_find_devices

[Marcus D. Leech]

On 04/12/2021 12:06 PM, para...@kwesst.com wrote:


Hi everyone, I'm just starting out with the USRP B205 mini-i, and I'm 
having some issues.


I'm running Ubuntu 20.04 LTS, I've also installed the UHD toolchain 
using the instructions on the Ettus website (Building and Installing 
the USRP Open-Source toolchain (UHD and GNURadio) on Linux. The UHD 
version is v4.0.0.0.


So, after installing UHD and running the 'make test' diagnostic, 
everything passes 100%, so it seems like everything is working 
correctly. I've also made sure that the 'uhd-usrp.rules' file has been 
copied to the /etc/udev/rules.d directory.


When I plug in the B205 mini and do a 'lsusb', it finds a device with 
the VID/PID of 2500:0022 called "Cypress WestBridge". This is the B205 
because when I unplug and run 'lsusb' it disappears, then if I plug it 
back in it reappears. Great!


So next I try 'uhd_find_devices' and it finds nothing. It returns with:

[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_4.0.0.HEAD-0-g90ce6062


No UHD Devices Found

Questions:

1) Should the uhd-usrp.rules have a specific entry for the B205?


My "rules" file has the following for B2xx devices:

#B200
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020", 
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0021", 
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0022", 
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7813", 
MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7814", 
MODE:="0666"


You could try:

uhd_usrp_probe --args type=b200

If that fails, try again as root.

If it works as root, then you have a rules issue.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Help enabling CAN0 on E310

[Marcus D. Leech]

On 04/12/2021 12:48 PM, Rich Gopstein wrote:
Can anyone offer any suggestions?  I've been digging through TCL files 
looking for where I could enable the CAN0 controller, but nothing has 
worked so far.


Thanks.
Rich
I'll point out that USB-to-CAN adapters aren't that expensive. Might be 
a more-immediately-productive route.



On Tue, Apr 6, 2021 at 10:00 AM Rich Gopstein > wrote:


I have an E310 (sg3) that I need to enable the CAN controller on
and route the signals out to the GPIO connector.  After that, I'll
work on the Linux driver.

I'm a newbie to Vivado, so I could use some detailed help.  What
I've done so far:

  * Built an Ubuntu 18.04 system
  * Installed Vivado 2018.3.1
  * Downloaded the EttusResearch/fpga.git repo
  * Tested "make E310_sg3" both with and without the "GUI=1" setting.


I tried going in to Vivado and enabling the CAN0 controller, but I
wasn't able to figure out how to rebuild the design (or route the
signals to the GPIO connector)

Any help would be appreciated.

Rich



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


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

[USRP-users] Re: B205 mini-i isn't found by uhd_find_devices

[Marcus D Leech]

What does dmesg report when you plug the device in?

Sent from my iPhone

> On Apr 12, 2021, at 2:19 PM, para...@kwesst.com wrote:
> 
> 
> Thanks Dustin,
> 
> Did resetting the USB fix your problem?
> 
> I don’t think I’m having any USB issues per say, I can plug the B205 in and 
> after doing an ‘lsusb’ I can see the device on the bus. The problem I’m 
> having is that when I do a ‘uhd_find_devices’ it doesn’t find anything. My 
> gut feeling is telling me that there’s an issue with the hardware, but I’d 
> like to exhaust any other possibilities before trying to debug the actual 
> B205 itself.
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: B205 mini-i isn't found by uhd_find_devices

[Marcus D Leech]

There is no kernel-level
Driver for this device. It’s handled by Libusb 

Sent from my iPhone

> On Apr 12, 2021, at 3:34 PM, para...@kwesst.com wrote:
> 
> 
> I’ve been poking around trying to find out any more information on my issue 
> and I noticed this after running the ‘usb-devices’ command:
> 
> T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0
> 
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> 
> P: Vendor=2500 ProdID=0022 Rev=01.00
> 
> S: Manufacturer=Cypress
> 
> S: Product=WestBridge
> 
> S: SerialNumber=04BE
> 
> C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
> 
> I: If#=0x0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
> 
> 
> 
> The VID/PID are 2500:0022 so this is the B205 I have plugged in, but on the 
> very last line it says “Driver=(none).
> 
> Could there be something wrong with the UHD installation? Should I try a 
> different version than v4.0.0.0?
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: B205 mini-i isn't found by uhd_find_devices

[Marcus D Leech]

Also it may be blowing whatever power budget your port provides. Is it a USB2 
or USB3 port?



Sent from my iPhone

> On Apr 12, 2021, at 3:36 PM, Marcus D Leech  wrote:
> 
> There is no kernel-level
> Driver for this device. It’s handled by Libusb 
> 
> Sent from my iPhone
> 
>>> On Apr 12, 2021, at 3:34 PM, para...@kwesst.com wrote:
>>> 
>> 
>> I’ve been poking around trying to find out any more information on my issue 
>> and I noticed this after running the ‘usb-devices’ command:
>> 
>> T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0
>> 
>> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>> 
>> P: Vendor=2500 ProdID=0022 Rev=01.00
>> 
>> S: Manufacturer=Cypress
>> 
>> S: Product=WestBridge
>> 
>> S: SerialNumber=04BE
>> 
>> C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
>> 
>> I: If#=0x0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
>> 
>> 
>> 
>> The VID/PID are 2500:0022 so this is the B205 I have plugged in, but on the 
>> very last line it says “Driver=(none).
>> 
>> Could there be something wrong with the UHD installation? Should I try a 
>> different version than v4.0.0.0?
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: How to tx s16 file with tx_samples_from_file

[Marcus D Leech]

Complex baseband is the natural format for this stuff. If you have real-sampled 
data you’ll have to convert it into complex baseband first. 

Sent from my iPhone

> On Apr 12, 2021, at 9:32 PM, ?? WANG Cui  wrote:
> 
> 
> Hi,
> When I try tx_samples_from_file example, looks like it only take Complex data 
> format.
> However I have signal file in RF direct sample format (each data element 
> represent a sample value), say it is “s8” or “s16” format as defined in UHD 
> term.
> I wonder how can I transmit such file? Or must I convert it into Interleaved 
> I/Q (Complex) format?
> Thanks in advance,
>  
> iucganw
>  
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: How to tx s16 file with tx_samples_from_file

[Marcus D Leech]

The tx_samples_from_file application is just an example application. You are 
free to modify it to meet your needs, including converting real-samples data to 
complex baseband data  

The hardware, however, supports complex baseband data, In either sc16 or sc8 
format “over the wire”.   The host software (whether that’s the 
tx_samples_from_file example code or your own) is free to accept and convert 
files into the baseband format accepted by the radio hardware.  

Sent from my iPhone

> On Apr 12, 2021, at 10:08 PM, 王璀 WANG Cui  wrote:
> 
> 
> Thanks for reply.
> However for RF signal, IQ Complex signal double the file size, which is quite 
> inconvenient, it will be best that USRP can natively support such format. 
> (Even sometimes RF signal is in 4-bit, 1 bit format, and convert to I/Q will 
> be more than 10 times larger...)
>  
> From: Marcus D Leech  
> Sent: Tuesday, April 13, 2021 09:44 AM
> To: ?? WANG Cui 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] How to tx s16 file with tx_samples_from_file
>  
> Complex baseband is the natural format for this stuff. If you have 
> real-sampled data you’ll have to convert it into complex baseband first. 
> 
> Sent from my iPhone
> 
> 
> On Apr 12, 2021, at 9:32 PM, ?? WANG Cui  wrote:
> 
> 
> Hi,
> When I try tx_samples_from_file example, looks like it only take Complex data 
> format.
> However I have signal file in RF direct sample format (each data element 
> represent a sample value), say it is “s8” or “s16” format as defined in UHD 
> term.
> I wonder how can I transmit such file? Or must I convert it into Interleaved 
> I/Q (Complex) format?
> Thanks in advance,
>  
> iucganw
>  
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: How to tx s16 file with tx_samples_from_file

[Marcus D Leech]

No. A real-sampled signal would
Need to be sampled at twice the notional bandwidth. So the data rate is the 
same. 

Sent from my iPhone

> On Apr 12, 2021, at 11:59 PM, 王璀 WANG Cui  wrote:
> 
> 
> That make sense, I guess I would modify it to accept more format.
> However, for the hardware side, it accept only Complex OTW format, which 
> means it need double bandwidth from host (I am using B210, USB3). When 
> transmit high sample rate signal, it is very easy to underflow. If we can 
> upgrade firmware to handle format conversion on hardware level, it will ease 
> a lot on host computing resource and USB/NIC bandwidth and performance.
> Thanks!
>  
> From: Marcus D Leech  
> Sent: Tuesday, April 13, 2021 11:45 AM
> To: 王璀 WANG Cui 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] How to tx s16 file with tx_samples_from_file
>  
> The tx_samples_from_file application is just an example application. You are 
> free to modify it to meet your needs, including converting real-samples data 
> to complex baseband data  
>  
> The hardware, however, supports complex baseband data, In either sc16 or sc8 
> format “over the wire”.   The host software (whether that’s the 
> tx_samples_from_file example code or your own) is free to accept and convert 
> files into the baseband format accepted by the radio hardware.  
> 
> Sent from my iPhone
> 
> 
> On Apr 12, 2021, at 10:08 PM, 王璀 WANG Cui  wrote:
> 
> 
> Thanks for reply.
> However for RF signal, IQ Complex signal double the file size, which is quite 
> inconvenient, it will be best that USRP can natively support such format. 
> (Even sometimes RF signal is in 4-bit, 1 bit format, and convert to I/Q will 
> be more than 10 times larger...)
>  
> From: Marcus D Leech  
> Sent: Tuesday, April 13, 2021 09:44 AM
> To: ?? WANG Cui 
> Cc: USRP-users@lists.ettus.com
> Subject: Re: [USRP-users] How to tx s16 file with tx_samples_from_file
>  
> Complex baseband is the natural format for this stuff. If you have 
> real-sampled data you’ll have to convert it into complex baseband first. 
> 
> Sent from my iPhone
> 
> 
> 
> On Apr 12, 2021, at 9:32 PM, ?? WANG Cui  wrote:
> 
> 
> Hi,
> When I try tx_samples_from_file example, looks like it only take Complex data 
> format.
> However I have signal file in RF direct sample format (each data element 
> represent a sample value), say it is “s8” or “s16” format as defined in UHD 
> term.
> I wonder how can I transmit such file? Or must I convert it into Interleaved 
> I/Q (Complex) format?
> Thanks in advance,
>  
> iucganw
>  
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Contradictory overflow messages when recording rx samples with Python API

[Marcus D Leech]

Sent from my iPhone

> On Apr 13, 2021, at 3:05 AM, brendan.horsfi...@vectalabs.com wrote:
> 
> 
> Hi All,
> 
> I am using a Python script to capture a short burst of rx samples from my 
> B210. The script is based heavily on the Ettus example “benchmark_rate.py”, 
> with a couple of additional tweaks I took from the Ettus GitHub repo 
> (https://github.com/EttusResearch/uhd/blob/master/host/python/uhd/usrp/multi_usrp.py).
> 
> In my script I am calling my rx sampling function repeatedly using a “for" 
> loop. Any errors that occur during sampling are stored in a 
> uhd.types.RXMetadata() object, just like in the original Ettus script.
> 
> Here’s the strange part:
> 
> While the script is running, the letter ‘O’ is printed on the screen about 
> 50% of the time, which I believe is an overflow warning from the Fastpath 
> logger. However, the number of errors being detected by the RXMetadata() 
> object is almost zero. How can this be?
> 
> Some questions:
> 
> How seriously should I take the Fastpath ‘O’ warning? What does it actually 
> mean? Does it mean that this burst of samples will be corrupted/incomplete?
> 
It absolutely means that samples were lost. 

The metadata should include time stamps that will allow you to compute how much 
was lost. 

> Why is the RXMetadata object not returning an error every single time that 
> the Fastpath logger does?
> 
This I’m not certain of. 
> Thanks,
> 
> Brendan.
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: How to tx s16 file with tx_samples_from_file

[Marcus D. Leech]

On 04/13/2021 12:21 AM, 王璀 WANG Cui wrote:


I am not expert in this, do you mean if sample in real format, we must 
double the sample rate, to contain both I phase and Q phase information?


In my application, I just sample at baseband digital code rate 
(Nyquist Freq), and seems it works well when transmit. And when I 
convert it into I/Q, it just doubled the size, but seems doesn’t bring 
more benefit?


Is there good article can help me to clarify this concept? :)

Well, this is drifting into much-more-generic territory about signals 
and signal processing.


Indeed, the Nyquist sampling theorem states that a signal with bandwidth 
B must be sampled at 2B in order to properly contain

  all the information in a signal.

That can either be achieved by real-mode sampling at 2B, or 
complex-baseband sampling at B.  You can see that for the
  same sample-size, the amount of space occupied by such samples is 
identical.


I think we need to understand exactly what you have sampled, and how, 
and at what rate.  I think *you* need to understand

  that in more depth as well, before we can provide much meaningful help.





*From:*Marcus D Leech 
*Sent:* Tuesday, April 13, 2021 12:08 PM
*To:* 王璀WANG Cui 
*Cc:* USRP-users@lists.ettus.com
*Subject:* Re: [USRP-users] How to tx s16 file with tx_samples_from_file

No. A real-sampled signal would

Need to be sampled at twice the notional bandwidth. So the data rate 
is the same.


Sent from my iPhone



On Apr 12, 2021, at 11:59 PM, 王璀 WANG Cui mailto:iucg...@msn.com>> wrote:



That make sense, I guess I would modify it to accept more format.

However, for the hardware side, it accept only Complex OTW format,
which means it need double bandwidth from host (I am using B210,
USB3). When transmit high sample rate signal, it is very easy to
underflow. If we can upgrade firmware to handle format conversion
on hardware level, it will ease a lot on host computing resource
and USB/NIC bandwidth and performance.

Thanks!

*From:*Marcus D Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Tuesday, April 13, 2021 11:45 AM
*To:* 王璀WANG Cui mailto:iucg...@msn.com>>
*Cc:* USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] How to tx s16 file with
tx_samples_from_file

The tx_samples_from_file application is just an example
application. You are free to modify it to meet your needs,
including converting real-samples data to complex baseband data

The hardware, however, supports complex baseband data, In either
sc16 or sc8 format “over the wire”.   The host software (whether
that’s the tx_samples_from_file example code or your own) is free
to accept and convert files into the baseband format accepted by
the radio hardware.

Sent from my iPhone




On Apr 12, 2021, at 10:08 PM, 王璀 WANG Cui mailto:iucg...@msn.com>> wrote:



Thanks for reply.

However for RF signal, IQ Complex signal double the file size,
which is quite inconvenient, it will be best that USRP can
natively support such format. (Even sometimes RF signal is in
4-bit, 1 bit format, and convert to I/Q will be more than 10
times larger...)

*From:*Marcus D Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Tuesday, April 13, 2021 09:44 AM
*To:* ?? WANG Cui mailto:iucg...@msn.com>>
*Cc:* USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] How to tx s16 file with
tx_samples_from_file

Complex baseband is the natural format for this stuff. If you
have real-sampled data you’ll have to convert it into complex
baseband first.

Sent from my iPhone





On Apr 12, 2021, at 9:32 PM, ?? WANG Cui mailto:iucg...@msn.com>> wrote:



Hi,

When I try tx_samples_from_file example, looks like it
only take Complex data format.

However I have signal file in RF direct sample format
(each data element represent a sample value), say it is
“s8” or “s16” format as defined in UHD term.

I wonder how can I transmit such file? Or must I convert
it into Interleaved I/Q (Complex) format?

Thanks in advance,

iucganw

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



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

[USRP-users] Re: How to tx s16 file with tx_samples_from_file

[Marcus D. Leech]

On 04/13/2021 10:17 AM, 王璀 WANG Cui wrote:


I am testing with software generated GPS L1 C/A signal and the 
sampling rate is 1.023M sps, same as the C/A code rate 1.023M chips/s. 
The result baseband signal file can be tracked and positioned by 
gnss-sdr receiver.


So I am wondering: I am not using 2B sampling rate (say 2.046 sps), 
but seems the signal is still well recognized and decoded?


GPS L1 C/A is a BPSK system operating at a notional 1.023Mbits/second, 
which as a BPSK system occupies a bandwidth of 2X the
  notional bit rate, or 2.046MHz, requiring actually a minimum sample 
rate of 4.096Msps.   That's according to my cursory
  understanding of the GPS L1 C/A signal, but there are others here 
with more experience with GPS than me.




*From:*Marcus D. Leech 
*Sent:* Tuesday, April 13, 2021 10:03 PM
*To:* 王璀WANG Cui 
*Cc:* USRP-users@lists.ettus.com
*Subject:* Re: [USRP-users] How to tx s16 file with tx_samples_from_file

On 04/13/2021 12:21 AM, 王璀 WANG Cui wrote:

I am not expert in this, do you mean if sample in real format, we
must double the sample rate, to contain both I phase and Q phase
information?

In my application, I just sample at baseband digital code rate
(Nyquist Freq), and seems it works well when transmit. And when I
convert it into I/Q, it just doubled the size, but seems doesn’t
bring more benefit?

Is there good article can help me to clarify this concept? :)

Well, this is drifting into much-more-generic territory about signals 
and signal processing.


Indeed, the Nyquist sampling theorem states that a signal with 
bandwidth B must be sampled at 2B in order to properly contain

  all the information in a signal.

That can either be achieved by real-mode sampling at 2B, or 
complex-baseband sampling at B.  You can see that for the
  same sample-size, the amount of space occupied by such samples is 
identical.


I think we need to understand exactly what you have sampled, and how, 
and at what rate.  I think *you* need to understand

  that in more depth as well, before we can provide much meaningful help.





*From:*Marcus D Leech 
<mailto:patchvonbr...@gmail.com>
*Sent:* Tuesday, April 13, 2021 12:08 PM
*To:* 王璀WANG Cui  <mailto:iucg...@msn.com>
*Cc:* USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] How to tx s16 file with
tx_samples_from_file

No. A real-sampled signal would

Need to be sampled at twice the notional bandwidth. So the data
rate is the same.

Sent from my iPhone




On Apr 12, 2021, at 11:59 PM, 王璀 WANG Cui mailto:iucg...@msn.com>> wrote:



That make sense, I guess I would modify it to accept more format.

However, for the hardware side, it accept only Complex OTW
format, which means it need double bandwidth from host (I am
using B210, USB3). When transmit high sample rate signal, it
is very easy to underflow. If we can upgrade firmware to
handle format conversion on hardware level, it will ease a lot
on host computing resource and USB/NIC bandwidth and performance.

    Thanks!

*From:*Marcus D Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Tuesday, April 13, 2021 11:45 AM
*To:* 王璀WANG Cui mailto:iucg...@msn.com>>
*Cc:* USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] How to tx s16 file with
tx_samples_from_file

The tx_samples_from_file application is just an example
application. You are free to modify it to meet your needs,
including converting real-samples data to complex baseband data

The hardware, however, supports complex baseband data, In
either sc16 or sc8 format “over the wire”.   The host software
(whether that’s the tx_samples_from_file example code or your
own) is free to accept and convert files into the baseband
format accepted by the radio hardware.

Sent from my iPhone





On Apr 12, 2021, at 10:08 PM, 王璀 WANG Cui
mailto:iucg...@msn.com>> wrote:



Thanks for reply.

However for RF signal, IQ Complex signal double the file
size, which is quite inconvenient, it will be best that
USRP can natively support such format. (Even sometimes RF
signal is in 4-bit, 1 bit format, and convert to I/Q will
be more than 10 times larger...)

*From:*Marcus D Leech mailto:patchvonbr...@gmail.com>>
*Sent:* Tuesday, April 13, 2021 09:44 AM
*To:* ?? WANG Cui mailto:iucg...@msn.com>>
*Cc:* USRP-users@lists.ettus.com
<mailto:USRP-users@lists.ettus.com>
*Subject:* Re: [USRP-users] How to tx s16 file with
tx_samples_from_file

Co

[USRP-users] Re: B205 mini-i isn't found by uhd_find_devices

[Marcus D Leech]

This is the kind of error that happens when you have a “mixed” system with 
libraries and utilities from different builds. 

Also after rhe build/install did you “sudo ldconfig” ?

Sent from my iPhone

> On Apr 13, 2021, at 2:38 PM, Robin Coxe  wrote:
> 
> 
> Have you checked the B205mini-i board itself to ensure the USB connector pins 
> are soldered down securely?   There have been instances where a dislodged 
> connector caused USB connection issues.   (If not, you can either retouch the 
> connections yourself with a soldering iron or RMA to NI.)
> 
> 
> 
>> On Tue, Apr 13, 2021 at 11:32 AM  wrote:
>> Hi Marcus, thanks for the response. So I tried to do what you suggested, but 
>> unfortunately it’s giving me and error, and google isn’t being helpful at 
>> all, maybe you’ve seen this before?
>> 
>> /usr/local/lib64/uhd/utils/b2xx_fx3_utils: symbol lookup error: 
>> /usr/local/lib64/uhd/utils/b2xx_fx3_utils: undefined symbol: 
>> _ZN10b200_iface16fx3_state_stringB5cxx11Eh
>> 
>> 
>> 
>> It seems like the b2xx_fx3_utils is looking for a symbol it can find, is 
>> there something else I need to do before using the B2xx_fx3_utils?
>> 
>> Thanks!
>> 
>> 
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Contradictory overflow messages when recording rx samples with Python API

[Marcus D Leech]

That just sounds like a bug. The Python API is still considered experimental. 

Sent from my iPhone

> On Apr 13, 2021, at 9:22 PM, Brendan Horsfield 
>  wrote:
> 
> 
> Hi Marcus,
> 
> I have run some comparison tests between the C++ and Python versions of 
> "benchmark_rate", using a high sampling rate in order to force some overruns.
> 
> It appears that both versions are detecting & reporting overrun events 
> correctly.  However, when it comes to the number of dropped samples, the 
> Python version always returns zero for the number of dropped samples.
> 
> Do you have any idea why this is the case?  Is the resolution of the timer 
> less fine-grained in the Python implementation perhaps?
> 
> Thanks,
> Brendan.
> 
> 
>   
> 
>> On Tue, Apr 13, 2021 at 11:05 PM Marcus D Leech  
>> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>>> On Apr 13, 2021, at 3:05 AM, brendan.horsfi...@vectalabs.com wrote:
>>>> 
>>> 
>>> Hi All,
>>> 
>>> I am using a Python script to capture a short burst of rx samples from my 
>>> B210. The script is based heavily on the Ettus example “benchmark_rate.py”, 
>>> with a couple of additional tweaks I took from the Ettus GitHub repo 
>>> (https://github.com/EttusResearch/uhd/blob/master/host/python/uhd/usrp/multi_usrp.py).
>>> 
>>> In my script I am calling my rx sampling function repeatedly using a “for" 
>>> loop. Any errors that occur during sampling are stored in a 
>>> uhd.types.RXMetadata() object, just like in the original Ettus script.
>>> 
>>> Here’s the strange part:
>>> 
>>> While the script is running, the letter ‘O’ is printed on the screen about 
>>> 50% of the time, which I believe is an overflow warning from the Fastpath 
>>> logger. However, the number of errors being detected by the RXMetadata() 
>>> object is almost zero. How can this be?
>>> 
>>> Some questions:
>>> 
>>> How seriously should I take the Fastpath ‘O’ warning? What does it actually 
>>> mean? Does it mean that this burst of samples will be corrupted/incomplete?
>>> 
>> It absolutely means that samples were lost. 
>> 
>> The metadata should include time stamps that will allow you to compute how 
>> much was lost. 
>> 
>>> Why is the RXMetadata object not returning an error every single time that 
>>> the Fastpath logger does?
>>> 
>> This I’m not certain of. 
>>> Thanks,
>>> 
>>> Brendan.
>>> 
>>> ___
>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Contradictory overflow messages when recording rx samples with Python API

[Marcus D. Leech]

On 04/13/2021 11:23 PM, Brendan Horsfield wrote:
Fair enough.  To ensure that this problem is logged with the Ettus 
engineering team, is there an official mailing list or email address 
that I should report this bug to?

You can put an issue in the GitHub repository:

https://github.com/EttusResearch/uhd/issues

This is UHD4.0?  So this may be a pybind11 issue with it correctly 
packaging the metadata from the C++ layer.





On Wed, Apr 14, 2021 at 12:02 PM Marcus D Leech 
mailto:patchvonbr...@gmail.com>> wrote:


That just sounds like a bug. The Python API is still considered
experimental.

Sent from my iPhone


On Apr 13, 2021, at 9:22 PM, Brendan Horsfield
mailto:brendan.horsfi...@vectalabs.com>> wrote:


Hi Marcus,

I have run some comparison tests between the C++ and Python
versions of "benchmark_rate", using a high sampling rate in order
to force some overruns.

It appears that both versions are detecting & reporting overrun
events correctly.  However, when it comes to the number of
dropped samples, the Python version always returns zero for the
number of dropped samples.

Do you have any idea why this is the case?  Is the resolution of
the timer less fine-grained in the Python implementation perhaps?

Thanks,
Brendan.



On Tue, Apr 13, 2021 at 11:05 PM Marcus D Leech
mailto:patchvonbr...@gmail.com>> wrote:



Sent from my iPhone


On Apr 13, 2021, at 3:05 AM, brendan.horsfi...@vectalabs.com
<mailto:brendan.horsfi...@vectalabs.com> wrote:



Hi All,

I am using a Python script to capture a short burst of rx
samples from my B210. The script is based heavily on the
Ettus example “benchmark_rate.py”, with a couple of
additional tweaks I took from the Ettus GitHub repo

(https://github.com/EttusResearch/uhd/blob/master/host/python/uhd/usrp/multi_usrp.py).

In my script I am calling my rx sampling function repeatedly
using a “for" loop. Any errors that occur during sampling
are stored in a uhd.types.RXMetadata() object, just like in
the original Ettus script.

Here’s the strange part:

While the script is running, the letter ‘O’ is printed on
the screen about 50% of the time, which I believe is an
overflow warning from the Fastpath logger. However, the
number of errors being detected by the RXMetadata() object
is almost zero. How can this be?

Some questions:

 *

How seriously should I take the Fastpath ‘O’ warning?
What does it actually mean? Does it mean that this burst
of samples will be corrupted/incomplete?


It absolutely means that samples were lost.

The metadata should include time stamps that will allow you
to compute how much was lost.
https://github.com/EttusResearch/uhd/issues


 *

Why is the RXMetadata object not returning an error
every single time that the Fastpath logger does?


This I’m not certain of.


Thanks,

Brendan.

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




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

[USRP-users] Re: Calling C++ UHD functions from Python

[Marcus D Leech]

Wrapping C++ for Python usage is a very common thing to want to do in the 
Python world. 

UHD and GnuRadio have used Swig in the past and now use pybind11 in the latest 
codebases. 

https://realpython.com/python-bindings-overview/



Sent from my iPhone

> On Apr 16, 2021, at 9:16 AM, page heller  wrote:
> 
> 
> Yes. That is what we are doing. For instance, you may make your C++ 
> executable then call it like a command from Python3. Here, I call a custom 
> command b210col, then display thumbnails of the captured channels. I have a 
> different version for the pi which repeats the command call five times with a 
> 3 second delay between (for the pi 4). -page
> 
> #!/bin/bash
> #
> # This program captures a file containing data from
> # an Ettus Research B210, two channels Rx
> sudo rm /mnt/ramdisk/2021-*
> sudo rm /mnt/ramdisk/RF*
> cd '/mnt/ramdisk'
> sudo /home/page/workarea/uhd/host/build4/b210col -g 30. -c 15 -f 2462e+06
> python3 /home/page/esi/graphram.py
> cd '/home/page/'
> echo end bash
> 
> 
> On 4/15/21 9:23 PM, brendan.horsfi...@vectalabs.com wrote:
>> Hi there,
>> 
>> I am trying to measure some short bursts of Rx data with my B210 at a fairly 
>> high sampling rate. I need to perform this operation repeatedly, ideally 
>> several times per second. The advice I have received from Ettus is that this 
>> task is best implemented using C++.
>> 
>> The problem is that this task is part of a bigger project written entirely 
>> in Python. It is not feasible to re-write the entire project in C++ just to 
>> be able to talk to the B210.
>> 
>> My question is: Is there a relatively painless way that I can create a C++ 
>> function to perform the desired USRP measurement, and then call this 
>> function from Python?
>> 
>> Thanks,
>> 
>> Brendan.
>> 
>> 
>> 
>> ___
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Reflected power on USRP B200

[Marcus D Leech]

A circulator can give you an additional 20dB isolation. 

Putting 5d!m into the RX2 port will likely destroy the RX amplifier in the 
AD9361. 

Sent from my iPhone

> On Apr 19, 2021, at 9:12 AM, Martin Elfvelin via USRP-users 
>  wrote:
> 
> 
> Hello all,
> 
> I am planning on using a USRP B200 in a half-duplex communication system to 
> communicate with a CubeSat. The TX/RX port will be used for transmitting and 
> the RX2 port for receiving. The transmitting port will be connected to a 
> power amplifier with a 60W output, this will in turn connect to an RF switch 
> which will switch between the TX/RX (transmitting) and RX2 (receiving). The 
> RF switch has an isolation of ~40-43 dB which means from the 47.78 dBm 
> transmitted we will have roughly 5-8 dBm reflected to RX2. Since the SDR is 
> only rated to receive maximum 0 dBm I'm wondering if someone has any ideas on 
> how to handle this. I'm unsure if this power will simply fry the board and I 
> should implement a power limiter or if there are other workarounds.
> 
> Appreciate any help you can provide.
> Best regards,
> Martin Elfvelin
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Reflected power on USRP B200

[Marcus D. Leech]

On 04/19/2021 09:49 AM, Martin Elfvelin wrote:
Thank you for your input. Do you suggest adding a circulator to the 
system or rather replacing the switch with a circulator?


Best regards,
Martin

I'd say add a circulator in addition to your switch.


On Mon, Apr 19, 2021 at 3:43 PM Marcus D Leech 
mailto:patchvonbr...@gmail.com>> wrote:


A circulator can give you an additional 20dB isolation.

Putting 5d!m into the RX2 port will likely destroy the RX
amplifier in the AD9361.

Sent from my iPhone

> On Apr 19, 2021, at 9:12 AM, Martin Elfvelin via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:
>
> 
> Hello all,
>
> I am planning on using a USRP B200 in a half-duplex
communication system to communicate with a CubeSat. The TX/RX port
will be used for transmitting and the RX2 port for receiving. The
transmitting port will be connected to a power amplifier with a
60W output, this will in turn connect to an RF switch which will
switch between the TX/RX (transmitting) and RX2 (receiving). The
RF switch has an isolation of ~40-43 dB which means from the 47.78
dBm transmitted we will have roughly 5-8 dBm reflected to RX2.
Since the SDR is only rated to receive maximum 0 dBm I'm wondering
if someone has any ideas on how to handle this. I'm unsure if this
power will simply fry the board and I should implement a power
limiter or if there are other workarounds.
>
> Appreciate any help you can provide.
> Best regards,
> Martin Elfvelin
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>



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

[USRP-users] Re: UHD dual-install issue

[Marcus D. Leech]

On 04/19/2021 03:15 AM, brendan.horsfi...@vectalabs.com wrote:


Hi All,

I have just upgraded my laptop to the latest version of GNU Radio 
Companion (ver 3.8.2.0 (Python 3.6.9)), and am now trying to use it to 
monitor a block of spectrum with my USRP B210. Unfortunately the 
flowgraph won’t run (even though it ran in my old GNU Radio setup), 
and instead prints the following message to the console:


linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

UHD Warning:

EnvironmentError: IOError: Could not find path for image: usrp_b200_fw.hex

Using images directory: 

Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow 
the below instructions to download the images package.


Please run:

"/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

Traceback (most recent call last):

File "/home/anyone/Documents/Brendan/GNU-Radio/top_block.py", line 
244, in 


main()

File "/home/anyone/Documents/Brendan/GNU-Radio/top_block.py", line 
220, in main


tb = top_block_cls()

File "/home/anyone/Documents/Brendan/GNU-Radio/top_block.py", line 87, 
in __init__


channels=list(range(0,1)),

File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line 
125, in constructor_interceptor


return old_constructor(*args)

File "/usr/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line 
3259, in make


return _uhd_swig.usrp_source_make(device_addr, stream_args, 
issue_stream_cmd_on_start)


RuntimeError: LookupError: KeyError: No devices found for ->

Device Address:

serial: 318425D

The above message suggests GRC is calling version *003.010.003.000-0* 
of the UHD driver. This is weird, as last week I installed version 
*3.15.0.0* of the UHD driver on my laptop, after first uninstalling 
the old driver (or so I thought…).


However, if I run uhd_usrp_probe or uhd_find_devices, I get a message 
confirming that I am indeed running v3.15.0.0 of the UHD driver:


 *

linux; GNU C++ version 7.5.0; Boost_106501;
*UHD_3.15.0.HEAD-0-gaea0e2de*

If I look in the folder “/usr/lib/x86_64-linux-gnu/”, I find the files 
*libuhd.so.003.010.003* and *libuhd.so.3.15.0* are both present — but 
I am pretty sure there should only be one of them present!


This “dual-install” problem seems to be fairly common among USRP/GNU 
Radio users, but so far I haven’t found any actual solutions.


There is also a second error message in the above console output: 
*“EnvironmentError: IOError: Could not find path for image: 
usrp_b200_fw.hex”*. This is baffling, as I have run the script 
“/usr/local/lib/uhd/utils/uhd_images_downloader.py“ three times, and 
am confident that the FPGA images have downloaded successfully (for 
the record, they are in /usr/local/share/uhd/images).


If anyone can tell me how to resolve these problems, I would be very 
grateful!


Regards,

Brendan.


That means that the version of Gnu Radio you used to produce whatever 
app you have is linked against UHD 3.10.3, whereas all

  your UHD *utilities* are linked against the newer version.

What happens when you run:

gnuradio-config-info -v

What is in your PYTHONPATH?  Is it perhaps pointing to older python 
code, and you're picking up older (very older) python modules that

  are themselves linked against both an older GR and older UHD?


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

[USRP-users] Re: Possibility of LO synchronization between multiple USRP B210s

[Marcus D Leech]

There no way to do this with B210. 

The synthesizers in the AD9361 have no usable resynch feature AND the mixers 
are 2XL0 which introduces its own 180deg phase ambiguity. 



Sent from my iPhone

> On Apr 19, 2021, at 3:56 PM, zhang.we...@gmail.com wrote:
> 
> 
> Hi,
> 
> I am trying to use multiple USRP B210s for one specific application where 
> their LOs need to be synchronized, which should have a same initial phase. 
> However, it seems that the B210s does not support this feature. Could anyone 
> provide some suggestions?
> 
> 
> 
> Thank you,
> 
> Weite
> 
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com