Re: [USRP-users] USRP X310 over PCIe: Recommended setup? (Windows, Linux, which one?)

[Wheberth Damascena Dias via USRP-users]

Hi Lukas, I use pretty much this setup (Ubuntu 18 + X310 over PCIe).

You can install kernel 4.15.0 from ubuntu repository and reinstall the
driver. It work just fine. You may also need to download some RFNoC XML
files that are missing on Ubuntu repositories (see:
https://bugs.launchpad.net/ubuntu/+source/uhd/+bug/1780805).

Make sure to configure the PCIe slot to PCIe Gen 1 on the bios.

Regards,
Wheberth

Em seg, 24 de fev de 2020 15:23, Lukas Haase via USRP-users <
usrp-users@lists.ettus.com> escreveu:

> Hi,
>
> I have used USRP X310 over PCIe and gnuradio on Windows for quite a bit. I
> suffered from large connectivity issues so I wanted to switch to Linux for
> quite some time. Also, I need to start modifying gnuradio/uhd source which
> is even more painful in Windows.
>
> I set up an Ubuntu 18.04 system (which is not exactly new) and in the last
> step Linux NI RIO Installation fails. And
> https://files.ettus.com/manual/page_ni_rio_kernel.html states:
> "Currently, the latest supported kernel version is 4.2.x.". What a bummer!
>
> Is there any way to get USRP X310 + PCIe working on Ubuntu 18.04?
> If not, what is the recommended setup when someone needs PCIe, gnuradio,
> source code?
> I would really prefer a Debian-like Linux system that's not completely
> outdated (such as pre-bionic).
>
> Best,
> Lukas
>
>
> PS:
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 18.04.4 LTS
> Release:18.04
> Codename:   bionic
> $ uname -a
> Linux station 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59
> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] linuhd 3.14.1.1 Problem in setting rx frequecy on n310

[Paolo Palana via USRP-users]

Hello to all the mailing list.

I've a little problem in setting the rx frequency on my n310 when I need
to acquire from all 4 channels.

I use the n310 directly in my program using libuhd. The code I use in
order to set the rx_frequency is:

    First of all set the subdevs:

     if(vm.count("subdev")){
            mUsrp->set_rx_subdev_spec(mSubDev);
        }

        

     for(size_t i=0; iset_rx_freq(tune_request, i);
        cout << boost::format("New RX Freq chan %d: %f MHz...") % i
% (mUsrp->get_rx_freq(i)/1e6) << endl << endl;
        }


The output I can see on my console confirm that every channel should
have the rigth frequency.

Of course this is not the case.


Suppose I wont acquire from A:0 RX2 (if I use TX/RX is the same) and A:1
RX2  tuning the first device at 654.0 MHZ

and the second to 896.8 MHZ. What happen is that both channels are tuned
to the last frequency (I'm sure of it because I tested it with a signal
generator).

I'm unable to understand why this happen. Any help is apreciated.

Thank you






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

Re: [USRP-users] Time synchronization of multiple B210s not working with multiple channels

[Michael Wentz via USRP-users]

Marcus,

Thanks for the suggestion. I added set_subdev_spec('A:A A:B') for the 2
channel case, but the results are the same.

I also tried this code with a pair of X310s receiving. The results are
somewhat similar:
- Channel 0 (A:0) across 2 devices: no delay
- Channel 1 (B:0) across 2 devices: no delay
- Channels 0 and 1 (A:0 B:0) across 2 devices: channel 0 is in sync between
the two, but channel 1 is not - and channel 1 is not in sync with channel 0
on either device.
- Unlike with the B210s, the X310s both report the same time after
streaming.

I've done this in the past with many X310s (each with 2 channels) with
success, but that was with an older/pre-RFNoC UHD circa 2016. I'm using
pretty much the same code here. Anything else I can try to time sync
multiple devices?

-Michael

On Mon, Feb 24, 2020 at 9:07 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/24/2020 05:10 PM, Michael Wentz via USRP-users wrote:
>
> Hi,
>
> I'm trying to synchronize multiple B210s to receive data at the same time.
> I'm only concerned about sample time alignment across devices, and am aware
> there is a phase offset that will need to be calibrated out separately.
> I've had success with 1 RX channel across 2 B210s, but something seems
> wrong when using 2 RX channels across 2 B210s.
>
> I've pasted a program below to help reproduce this issue. It uses 1 B210
> to TX noise and 2 separate B210s to RX at the same time. There is a 40 dB
> attenuator on the output of the transmitting B210, then a 4 way splitter,
> and equal length cables to both receivers on the other 2 B210s.
> Additionally, the 2 receiving B210s get 10 MHz and PPS from a common
> OctoClock-G.
>
> Here are 10 observations of sample offsets between devices (1 MSPS rate):
> Only channel 0 on both RX: [0,0,0,0,0,0,0,0,0,0]
> Only channel 1 on both RX: [0,0,0,0,0,0,0,0,0,0]
> Channels 0 and 1 simultaneously on both
> RX: [14,1,-126,48,2,-88,17,-204,-96,2]
>
> In the 2 channel case both channels on one device are always aligned, but
> are offset from the channels on the other device. Both of the receiving
> B210s show the same time last PPS when asked before the streams start. The
> times in the RX metadata also match. But after the streams stop, the
> devices respond with different times - neither of which are correct - and
> the difference between them matches what I'm measuring.
>
> I'm using UHD 3.14.1.1 and GNU Radio 3.8 on RHEL 7.7. Any ideas?
>
> Thanks,
> Michael
>
> --
>
> #!/usr/bin/env python3
>
> from gnuradio import gr, uhd, analog, blocks
> import time
> import numpy as np
>
> tx_serial = '30D1***'
> rx_serials = ['3153***', '3153***']
> rx_channels = [0, 1]
>
> n_rx = len(rx_serials)
> n_chan = len(rx_channels)
>
> class top_block(gr.top_block):
> def __init__(self):
> gr.top_block.__init__(self)
>
> # transmit path
> noise_src = analog.noise_source_c(analog.GR_GAUSSIAN, 0.1)
> tx_strm_args = uhd.stream_args(cpu_format='fc32', channels=[0])
> tx = uhd.usrp_sink('serial=' + tx_serial, tx_strm_args)
> tx.set_clock_rate(16e6)
> tx.set_samp_rate(1e6)
> tx.set_center_freq(1e9)
> tx.set_gain(40)
> tx.set_antenna('TX/RX')
> self.connect(noise_src, tx)
>
> # receive path
> rx_strm_args = uhd.stream_args(cpu_format='fc32',
> channels=rx_channels)
> self.rx = [None]*n_rx
> head = [None]*n_rx*n_chan
> file_sink = [None]*n_rx*n_chan
> for i in range(n_rx):
> self.rx[i] = uhd.usrp_source('serial=' + rx_serials[i],
> rx_strm_args)
> self.rx[i].set_clock_rate(16e6)
> self.rx[i].set_samp_rate(1e6)
> self.rx[i].set_center_freq(1e9)
> self.rx[i].set_gain(40)
> self.rx[i].set_antenna('RX2')
> self.rx[i].set_time_source('external')
> self.rx[i].set_clock_source('external')
> for j in range(n_chan):
> ch = i*n_chan + j
> head[ch] = blocks.head(2*gr.sizeof_float, 1)
> f = 'rx_%d%d.dat' % (i, j)
> file_sink[ch] = blocks.file_sink(2*gr.sizeof_float, f)
> file_sink[ch].set_unbuffered(True)
> self.connect((self.rx[i], j), head[ch], file_sink[ch])
>
> # make sure 10 MHz ref is locked
> for i in range(n_rx):
> while not self.rx[i].get_mboard_sensor('ref_locked').to_bool():
> print('RX %d waiting for 10 MHz ref lock...' % i)
> time.sleep(1)
> print('RX %d 10 MHz ref locked' % i)
>
> # time sync the two receivers
> for i in range(n_rx):
> t = self.rx[i].get_time_last_pps().get_real_secs()
> print('RX %d time before align: %r' % (i, t))
> time_last_pps = self.rx[0].get_time_last_pps().get_real_secs()
> while time_last_pps ==
> self.rx[0].get_time_last_pps().get_real_secs():

Re: [USRP-users] Issues using TwinRX and x310 (phase shift)

[Rob Kossler via USRP-users]

Hi Etienne,
I didn't see anything about "timed commands" in your email.  These are
needed in order to get phase synchronization.  In particular, the
"set_time_now" function is a red flag because you should be using instead
"set_time_next_pps".  See this

topic regarding use of timed commands.
Rob


On Mon, Feb 24, 2020 at 1:43 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/24/2020 05:06 AM, VAILLANT.Etienne via USRP-users wrote:
>
> Hi all,
>
>
>
> I would like to perform DOA measurements and I am using a USRP x310 with
> two TwinRX.
>
>
>
> First I am trying to perform some very basic tests in order to understand
> what I am doing: I generate a CW at 1850 MHz, going through a power
> splitter (4-ways 0°), feeding the 4 inputs of the two TwinRX (A:0, A:1 and
> B:0, B:1).
>
> I save the raw IQ data via Gnuradio Companion in a file and I repeat the
> procedure several times, generating several files. All the files are saved
> with the same USRP tuning (I don’t stop or retune the signal/USRP between
> two acquisitions). Basically I just click on a *Save* QT GUI Check Box in
> GRC many times which triggers a *File Sink* block and thus generates as
> many files.
>
>
>
> Then I want to re-plot the signals from the IQ data via Matlab, and my
> problem is that I get some different phase shift between the signals.
> Please find attached a screenshot of 12 identical acquisitions (12
> successive clicks on *Save*). What is important to me is the phase shift
> between the two signals, and I expected it to be identical in all cases
> (since all the acquisitions are identical). It seems to be OK for almost
> all the acquisitions, except for the 8, 9 and 10, where the phase shift is
> different from all the others (and the three of them look identical…). I
> have perform this test several times and every time some random
> acquisitions are shifted from the others (sometimes there are 2 or 3
> different values of phase shift, it is not always 90° or else).
>
>
>
> There is something I misunderstood or I do wrong but I can’t find what. I
> have read some people with a similar issue discussing about the function
> *set_time_now()* but I don’t really know how to deal with it.
>
>
>
> To acquire the signal I am using either * UHD: USRP Source* block with 4
> channels or the *TwinRX USRP Source* block. In the first case, LO
> parameters are the following:
>
> -  Ch0 Source Internal / export True
>
> -  Ch1 Source Companion / export False
>
> -  Ch2 Source External / export False
>
> -  Ch3 Source External / export False
>
>
>
> I work on *Ubuntu* 18.04 (I can’t change since some other activities rely
> on this computer).
>
> -  *GRC* 3.7.10.1 (minimum version required for *gr-doa*
> application)
>
> -  *UHD* 3.10.3.0 (with the v3.10.1.0 recommended for *gr-doa 
> *application,
> my TwinRX were not detected (*Unknown*) via *uhd_usrp_probe*)
>
> -  *gr-doa* installed from source but all the make test have
> failed (I guess this is another topic since I don’t use *gr-doa*
> functions in my basic test presented above?).
>
>
>
> I am quite a new comer to this SDR world, thus any help would be much
> appreciated, thanks very much in advance!
>
>
>
> Kind regards,
>
>
>
> *Etienne VAILLANT*
>
>
>
> Perhaps you could share your GRC flow-graph with us?
>
> Also, there have been some phase-offset fixes in later versions of UHD,
> but it's not clear at this point whether that applies in your case or not,
>   which is where having the GRC flow-graph to look at would be useful.
>
> Cheers
>

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

Re: [USRP-users] linuhd 3.14.1.1 Problem in setting rx frequecy on n310

[Rob Kossler via USRP-users]

Hi Paolo,
The "A" daughterboard (for A:0 and A:1) only has one Rx LO (and one Tx LO)
such that both channels will always share the same LO.  The "B"
daughterboard is the same.  Thus you do not have independent RF control of
all four channels on the N310.  Does that make sense?
Rob

On Tue, Feb 25, 2020 at 8:44 AM Paolo Palana via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello to all the mailing list.
>
> I've a little problem in setting the rx frequency on my n310 when I need
> to acquire from all 4 channels.
>
> I use the n310 directly in my program using libuhd. The code I use in
> order to set the rx_frequency is:
>
> First of all set the subdevs:
>
>  if(vm.count("subdev")){
> mUsrp->set_rx_subdev_spec(mSubDev);
> }
>
> 
>
>  for(size_t i=0; i {
> cout << boost::format("Setting chan %d Freq: %f MHx") % (i)
> % (mFreqs[i]/1e6) << endl;
> uhd::tune_request_t tune_request(mFreqs[i]);
> tune_request.args = uhd::device_addr_t("mode_n=integer");
> mUsrp->set_rx_freq(tune_request, i);
> cout << boost::format("New RX Freq chan %d: %f MHz...") % i
> % (mUsrp->get_rx_freq(i)/1e6) << endl << endl;
> }
>
>
> The output I can see on my console confirm that every channel should
> have the rigth frequency.
>
> Of course this is not the case.
>
>
> Suppose I wont acquire from A:0 RX2 (if I use TX/RX is the same) and A:1
> RX2  tuning the first device at 654.0 MHZ
>
> and the second to 896.8 MHZ. What happen is that both channels are tuned
> to the last frequency (I'm sure of it because I tested it with a signal
> generator).
>
> I'm unable to understand why this happen. Any help is apreciated.
>
> Thank you
>
>
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] linuhd 3.14.1.1 Problem in setting rx frequecy on n310

[Marcus D. Leech via USRP-users]

On 02/25/2020 08:43 AM, Paolo Palana via USRP-users wrote:

Hello to all the mailing list.

I've a little problem in setting the rx frequency on my n310 when I need
to acquire from all 4 channels.

I use the n310 directly in my program using libuhd. The code I use in
order to set the rx_frequency is:

 First of all set the subdevs:

  if(vm.count("subdev")){
 mUsrp->set_rx_subdev_spec(mSubDev);
 }

 

  for(size_t i=0; iset_rx_freq(tune_request, i);
 cout << boost::format("New RX Freq chan %d: %f MHz...") % i
% (mUsrp->get_rx_freq(i)/1e6) << endl << endl;
 }


The output I can see on my console confirm that every channel should
have the rigth frequency.

Of course this is not the case.


Suppose I wont acquire from A:0 RX2 (if I use TX/RX is the same) and A:1
RX2  tuning the first device at 654.0 MHZ

and the second to 896.8 MHZ. What happen is that both channels are tuned
to the last frequency (I'm sure of it because I tested it with a signal
generator).

I'm unable to understand why this happen. Any help is apreciated.

Thank you

The N310 is based on the AD9371 RF Front-end chip.  There are two of 
them in an N310.  Those chips use a *SHARED* LO between the two channels,
  so you cannot set independent frequencies within the same chip (A:0 
A:1  or B:0 B:1).





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

Re: [USRP-users] Time synchronization of multiple B210s not working with multiple channels

[Marcus D. Leech via USRP-users]

On 02/25/2020 09:33 AM, Michael Wentz via USRP-users wrote:

Marcus,

Thanks for the suggestion. I added set_subdev_spec('A:A A:B') for the 
2 channel case, but the results are the same.


I also tried this code with a pair of X310s receiving. The results are 
somewhat similar:

- Channel 0 (A:0) across 2 devices: no delay
- Channel 1 (B:0) across 2 devices: no delay
- Channels 0 and 1 (A:0 B:0) across 2 devices: channel 0 is in sync 
between the two, but channel 1 is not - and channel 1 is not in sync 
with channel 0 on either device.
- Unlike with the B210s, the X310s both report the same time after 
streaming.

Let us focus on the B210 first.

I've been through your code, and I cannot find anything wrong with it.  
Now, I recall that there was a bug in earlier UHD with the two
  clocks in the B210 (each conceptual radio block in the FPGA includes 
its own time-of-day clock), and they wouldn't always get reset

  together, even with set_time_next_pps(), so there would be some skew.

This, or something related may be the root cause of your issue. The 
engineer who most recently worked on B210 is being consulted

  on this, and hopefully myself or Sam Reiter will have an answer soon.




I've done this in the past with many X310s (each with 2 channels) with 
success, but that was with an older/pre-RFNoC UHD circa 2016. I'm 
using pretty much the same code here. Anything else I can try to time 
sync multiple devices?


-Michael

On Mon, Feb 24, 2020 at 9:07 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 02/24/2020 05:10 PM, Michael Wentz via USRP-users wrote:

Hi,

I'm trying to synchronize multiple B210s to receive data at the
same time. I'm only concerned about sample time alignment across
devices, and am aware there is a phase offset that will need to
be calibrated out separately. I've had success with 1 RX channel
across 2 B210s, but something seems wrong when using 2 RX
channels across 2 B210s.

I've pasted a program below to help reproduce this issue. It uses
1 B210 to TX noise and 2 separate B210s to RX at the same time.
There is a 40 dB attenuator on the output of the transmitting
B210, then a 4 way splitter, and equal length cables to both
receivers on the other 2 B210s. Additionally, the 2 receiving
B210s get 10 MHz and PPS from a common OctoClock-G.

Here are 10 observations of sample offsets between devices (1
MSPS rate):
Only channel 0 on both RX: [0,0,0,0,0,0,0,0,0,0]
Only channel 1 on both RX: [0,0,0,0,0,0,0,0,0,0]
Channels 0 and 1 simultaneously on both
RX: [14,1,-126,48,2,-88,17,-204,-96,2]

In the 2 channel case both channels on one device are always
aligned, but are offset from the channels on the other device.
Both of the receiving B210s show the same time last PPS when
asked before the streams start. The times in the RX metadata also
match. But after the streams stop, the devices respond with
different times - neither of which are correct - and the
difference between them matches what I'm measuring.

I'm using UHD 3.14.1.1 and GNU Radio 3.8 on RHEL 7.7. Any ideas?

Thanks,
Michael

--

#!/usr/bin/env python3

from gnuradio import gr, uhd, analog, blocks
import time
import numpy as np

tx_serial = '30D1***'
rx_serials = ['3153***', '3153***']
rx_channels = [0, 1]

n_rx = len(rx_serials)
n_chan = len(rx_channels)

class top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)

# transmit path
noise_src = analog.noise_source_c(analog.GR_GAUSSIAN, 0.1)
tx_strm_args = uhd.stream_args(cpu_format='fc32',
channels=[0])
tx = uhd.usrp_sink('serial=' + tx_serial, tx_strm_args)
tx.set_clock_rate(16e6)
tx.set_samp_rate(1e6)
tx.set_center_freq(1e9)
tx.set_gain(40)
tx.set_antenna('TX/RX')
self.connect(noise_src, tx)

# receive path
rx_strm_args = uhd.stream_args(cpu_format='fc32',
channels=rx_channels)
self.rx = [None]*n_rx
head = [None]*n_rx*n_chan
file_sink = [None]*n_rx*n_chan
for i in range(n_rx):
self.rx[i] = uhd.usrp_source('serial=' +
rx_serials[i], rx_strm_args)
self.rx[i].set_clock_rate(16e6)
self.rx[i].set_samp_rate(1e6)
self.rx[i].set_center_freq(1e9)
self.rx[i].set_gain(40)
self.rx[i].set_antenna('RX2')
self.rx[i].set_time_source('external')
self.rx[i].set_clock_source('external')
for j in range(n_chan):
ch = i*n_chan + j
head[ch] = blocks.head(2*gr.sizeof_float, 1)
f = 'rx_%d%d.dat' % (i, j)
file_sink[ch] =
blocks.file_s

Re: [USRP-users] [Non-DoD Source] Re: RFNOC: 2 input/2 output block, synchronizing their outputs to GNURadio host

[Jonathon Pendlum via USRP-users]

Hello Andrew,

1.   I understand from Analog documentation that the AD9361 outputs
> 12-bit samples in two’s complement, is that right? Also I gather from
> tracing through the HDL, within e31x_core, the data is packed MSB-aligned,
> with LSBs 3…0 locked at 1’b0.  When you feed a 16-bit I, 16-bit Q sample
> into the complex_to_magphase IP block it outputs a 16-bit real, 16-bit
> phase result. So is the magnitude (16-bit real output) formatted the same
> way, i.e. {D11…D0, 4’d0}?  Does it not matter to that IP block whether it
> is MSB padded or LSB padded?  Is it also in 2’s complement?
>

Most blocks maintain the sc16 format (16-bit I and 16-bit Q 2s complement)
throughout the entire processing pipeline. The complex_to_magphase IP block
uses Xilinx's CORDIC IP and their documentation can explain how it works
internally. The CORDIC does not zero out output LSBs even if the input is a
left shifted 12-bit number. In fact, those bits will likely wiggle due to
the slight gain in the CORDIC block. Whether you choose to MSB or LSB pad
is a fixed point design decision as in where do you want to point your
decimal point at. Most blocks do not particularly care, although using full
scale signals with some blocks, such as the DUC, may degrade due to
clipping and you should shoot for using 90% of amplitude.

I would suggest testing the complex_to_magphase block by itself in a test
bench and make sure the output is monotonically increasing as you expect.


> 2.   Dynamic range of e310, if the samples are 12-bit then does this
> come out to 20*log10(4095) = 72.2 dB?  So I should be experiencing some
> abnormalities at the extremes?
>

I have not done any dynamic range testing on the E310 and there are not any
published numbers for the E310. The E310 is based on the AD0361, so you can
try looking at that part's datasheet.


> 3.   Since I have the analog bw set to 10 MHz, and I am feeding the
> SDR a CW signal which is very narrow in the spectrum, is it possible to
> actually max out the ADC with this bench setup?
>

This isn't something that I have tested, but I would expect you could. You
will have to be careful though, as too strong of an input signal will
damage the AD9361.


> 4.   Most import question, I’m using noc_block_fft as a guide for
> producing magnitude samples.  In that file mag_tdata[31:0] is assigned
> {1’b0, mag_tdata_int[15:0], 15’d0}, then that mag_tdata is fed to
> axi_round_and_clip wherein the first MSB is clipped, and truncated such
> that 16 bit data is outputted.  My question is: Does that not just clip the
> leading 0 off and round the LSB?  Then wouldn’t the host computer interpret
> this over the wire real uint16 as a two’s complement float or int, going
> negative as the MSB goes high?  How can I treat that result as an unsigned
> 16-bit int?


The easiest way is to set the over-the-wire (OTW) and CPU format to sc16 so
no conversion occurs and treat the value as uint16.

Jonathon

On Wed, Feb 19, 2020 at 3:39 PM Payne, William Andrew (Andrew) CIV USN NSWC
CD CRANE ID (USA)  wrote:

> Hello Jonathan,
>
>
>
> Fortunately, a lot of progress has been made since you mentioned some
> ideas for me, I was just hesitating to reply until I got stuck again.  I
> have been running on an e310 a 2-stream custom noc_block with axi wrappers
> set to simple mode successfully for the past few days, proving it is very
> much possible and not a difficult task.  I think the root cause of my
> problem was either:
>
> 1.   Not running make clean before make install in my rfnocmodtool
> directory
>
> 2.   Not inputting my settings registers correctly in the UHD
> nocsript.
>
> 3.   Not correctly setting up my GRC block xml file.
>
> 4.   Correcting a bug in my custom Verilog code in my noc_block.
>
>
>
> But now there is a slight issue that I hope you can help me out with.  My
> test bench is composed of the e310 receiving RF from a sig gen tuned to a
> center freq and sweeping the amplitude from noise floor to less than max
> input, running through my custom string of IP blocks that comprise my rfnoc
> block (complex to magnitude -> moving sum -> keep one in n).   Data streams
> through just fine, no timeouts, but sometimes I get odd results such as the
> magnitude going down a little when I expected it to keep rising with the
> sig gen input.
>
>
>
> I wanted to dig a little deeper into the sampling details from the rx
> front end.  Here’s my list of questions for you:
>
> 1.   I understand from Analog documentation that the AD9361 outputs
> 12-bit samples in two’s complement, is that right? Also I gather from
> tracing through the HDL, within e31x_core, the data is packed MSB-aligned,
> with LSBs 3…0 locked at 1’b0.  When you feed a 16-bit I, 16-bit Q sample
> into the complex_to_magphase IP block it outputs a 16-bit real, 16-bit
> phase result. So is the magnitude (16-bit real output) formatted the same
> way, i.e. {D11…D0, 4’d0}?  Does it not matter to that IP block whethe

Re: [USRP-users] Polling the "sample_rx" via a user defined register (B205mini)

[Jonathon Pendlum via USRP-users]

Hi Varban,

I am now getting random 32-bit values when polling it from the UHD (instead
> of a constant that indicates a "zero" reception)


Even with the antenna disconnected you can expect some LSBs to toggle due
to inherent receiver noise.

1) How should I interpret the 32-variable?
>

It is a short complex int where the upper 16-bits are I and the lower
16-bits are Q.


> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
>

Yes


> 2) Do I need new_rx_control?


No

Have I done this correctly in general, or there is something completely
> wrong in my approach?


What do you want to accomplish?

Jonathon

On Mon, Feb 17, 2020 at 5:03 AM Varban Metodiev via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> After exposing the *sample_rx* from radio_legacy.v
> 
>  to
> a user defined register and sampling it at rising edge of the *strobe_rx*,
> I am now getting random 32-bit values when polling it from the UHD (instead
> of a constant that indicates a "zero" reception). I am doing this with
> disconnected antenna using a modified rx_samples C++ example application.
>
> I have the following questions:
> 1) How should I interpret the 32-variable?
> 2) Is the strobe_rx the correct signal that indicates new sample arrival?
> 2) Do I need new_rx_control?
>
> Have I done this correctly in general, or there is something completely
> wrong in my approach?
>
> Thanks,
> Varban
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Closing Connection, X310 Problem

[Simon G4ELI via USRP-users]

Hi,

 

Question is in two related parts.

 

 

1 Closing Connection

 

In 3.10.0 when I was finished streaming data I would call

 

1.  m_usrp->reset() and 
2.  m_rx_stream->reset()

 

but in 3.15 LTS I don't see a way to reset / discard the pointers returned
from uhd::usrp::multi_usrp::make and m_usrp->get_rx_stream. The reset calls
no longer exist.

 

So, how do I correctly do this? 

 

 

 

2 X310

 

[Note - only a problem with the X310, B200 works well]

 

When I want to change the sample rate, for example from 1 Msps to 10 Msps:

 

1.  Close (see above)
2.  Create new m_usrp via uhd::usrp::multi_usrp::make
3.  Set new sample rate
4.  Call m_usrp->get_rs_stream but I get an exception: exception
054F (1359), RuntimeError: On node 0/DDC_0, output port 0 is already
connected 

 

So this refers back to 1 - how do I get the connection to the X310 fully
closed?

 

 

TIA

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

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

Re: [USRP-users] Closing Connection, X310 Problem

[Marcus D. Leech via USRP-users]

On 02/25/2020 03:59 PM, Simon G4ELI via USRP-users wrote:


Hi,

Question is in two related parts.

1 Closing Connection

In 3.10.0 when I was finished streaming data I would call

 1. m_usrp->reset() and
 2. m_rx_stream->reset()

but in 3.15 LTS I don’t see a way to reset / discard the pointers 
returned from uhd::usrp::multi_usrp::make and m_usrp->get_rx_stream. 
The reset calls no longer exist.


So, how do I correctly do this?


You should just be able to call the destructor:

https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a6c904057108e52d685b27496a11518db



2 X310

[Note – only a problem with the X310, B200 works well]

When I want to change the sample rate, for example from 1 Msps to 10 Msps:

 1. Close (see above)
 2. Create new m_usrp via uhd::usrp::multi_usrp::make
 3. Set new sample rate
 4. Call m_usrp->get_rs_stream but I get an exception: exception
054F (1359), RuntimeError: On node 0/DDC_0, output port 0 is
already connected

So this refers back to 1 – how do I get the connection to the X310 
fully closed?


The X310 takes 15-20 seconds to reset itself internally when you close 
the session with it.  There's never any reason to recreate the USRP
  object just to change the sample rate.  So if your frequency-changing 
code does that, and expects the USRP to "come back" immediately
  after you've reset it, there'll be some strange behavior at the 
network level.  So, yeah, sample-rate change shouldn't need anything so

  "drastic".





TIA

Simon Brown, G4ELI

https://www.sdr-radio.com



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


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