Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Nick Foster via USRP-users]

Could you post your flowgraph or UHD program, or the relevant excerpts? Are
the two RX channels being loaded simultaneously? Are you using timed
commands to start the RX and TX streams?

Nick

On Tue, Mar 6, 2018 at 11:52 AM Prager, Samuel M (334E) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> We are interested in using the E312 as a phase-sensitive radar sounder and
> have run into an interesting issue.
>
>
>
> We are measuring (relative) cable length by estimating linear phase slope
> from a 10MHz chirp pulse and are using the following test setup (attached):
>
>
>
> We have set the appropriate AD9361 registers to keep the VCO/PLL dividers
> on so that RXA (data) and RXB (calibration) are phase coherent. We perform
> pulse averaging on each channel and match filter with the cal channel pulse
> (shorter cable).
>
>
>
> We have noticed that the phase measurements remain stable within <*1 cm* 99%
> confidence interval for successive trials with multiple re-tunings of the
> LO over long periods of time. However, we have found that if the FPGA bit
> file is unloaded (put in idle mode) and then reloaded (either through
> power-cycle or termination of UHD-based application), the measured phase
> slope jumps randomly.
>
>
>
> We’re really scratching our heads over this behavior… multiple trials on a
> given ‘cycle’ remain stable around a mean value, but that value jumps
> around from cycle to cycle in a seemingly random way.
>
>
>
> I have attached plots for two tests - the vertical black dotted lines are
> placed to show when the E312 FPGA image was cycled. Each data point is
> taken from a separate LO tuning (ie. tune to 400mhz, collect data, tune to
> 1ghz, wait, tune to 400mhz, collect data,…)
>
>
>
> Any ideas about where could possibly be coming from? Is there somewhere in
> the E312 initialization that the relative path between RXA and RXB may be
> changed non-deterministically?
>
>
>
> I really appreciate any help!
>
>
>
> Thank you,
>
>
>
> Sam
>
>
> ___
> 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] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Prager, Samuel M (334E) via USRP-users]

Hi Nick,

Thanks for the response. I am streaming from one channel at a time. I switch 
between channels by toggling:

 _radio_ctrl->set_rx_streamer(false, _radio_chan);
 _radio_ctrl->set_rx_streamer(true, _calib_chan);

And then issue timed RX stream commands:

uhd::time_spec_t timenow = _radio_ctrl->get_time_now();
   uhd::time_spec_t time_spec = 
uhd::time_spec_t(seconds_in_future)+timenow;
stream_cmd.stream_now = false;
   stream_cmd.time_spec = time_spec;
issue_stream_cmd_override(stream_cmd, _radio_chan);

Where issue_stream_cmd_override() is the same as 
_radio_ctrl->issue_stream_cmd() except that it doesn’t check that the requested 
channel is active (easiest way I found to quickly switch between RXA and RXB). 
I also set the MCS register in the aD9361 initialization so that the two 
channels are phase coherent.

A signal generator upstream from the radio in the FPGA generates the TX pulse 
on request (with a timestamp to forward) and creates a vita header with the 
same timestamp used for the RX stream command, so TX and RX begin at the same 
clock cycle.

Thanks,

Sam

From: Nick Foster [mailto:bistrom...@gmail.com]
Sent: Tuesday, March 06, 2018 11:57 AM
To: Prager, Samuel M (334E) 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is 
reloaded

Could you post your flowgraph or UHD program, or the relevant excerpts? Are the 
two RX channels being loaded simultaneously? Are you using timed commands to 
start the RX and TX streams?
Nick

On Tue, Mar 6, 2018 at 11:52 AM Prager, Samuel M (334E) via USRP-users 
> wrote:
Hello,

We are interested in using the E312 as a phase-sensitive radar sounder and have 
run into an interesting issue.

We are measuring (relative) cable length by estimating linear phase slope from 
a 10MHz chirp pulse and are using the following test setup (attached):

We have set the appropriate AD9361 registers to keep the VCO/PLL dividers on so 
that RXA (data) and RXB (calibration) are phase coherent. We perform pulse 
averaging on each channel and match filter with the cal channel pulse (shorter 
cable).

We have noticed that the phase measurements remain stable within <1 cm 99% 
confidence interval for successive trials with multiple re-tunings of the LO 
over long periods of time. However, we have found that if the FPGA bit file is 
unloaded (put in idle mode) and then reloaded (either through power-cycle or 
termination of UHD-based application), the measured phase slope jumps randomly.

We’re really scratching our heads over this behavior… multiple trials on a 
given ‘cycle’ remain stable around a mean value, but that value jumps around 
from cycle to cycle in a seemingly random way.

I have attached plots for two tests - the vertical black dotted lines are 
placed to show when the E312 FPGA image was cycled. Each data point is taken 
from a separate LO tuning (ie. tune to 400mhz, collect data, tune to 1ghz, 
wait, tune to 400mhz, collect data,…)

Any ideas about where could possibly be coming from? Is there somewhere in the 
E312 initialization that the relative path between RXA and RXB may be changed 
non-deterministically?

I really appreciate any help!

Thank you,

Sam

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

Re: [USRP-users] N310 Questions

[Robin Coxe via USRP-users]

Hi Dave.  The official product announcement of the USRP N310 was just
posted today.   The N310 is now orderable!

On Mon, Mar 5, 2018 at 2:11 PM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Just saw that the N310 is officially on the ettus.com website.  Curious
> about the following:
>
>- The product pages says that it's not for fast tuning.  Should I
>expect roughly the same tuning times as the B2x0 radios?
>
> Currently, the tuning times are actually a bit slower than the B200/E310
(~140 ms) because the frequency is adjusted via SW SPI commands to the
AD9371 transceiver.   A future performance enhancement will be to implement
frequency tunes via GPIO lines from the FPGA.   The AD9371 was not designed
for fast frequency hopping.  The AD9371 has an embedded ARM Cortex-M0
processor that orchestrates an on-chip quadrature error correction (i.e.,
I/Q imbalance calibration) that takes an appreciable amount of time to
converge.  The fastest that the device will be ever be capable of tuning
without disabling this calibration is ~2 ms.


>
>- At the bottom of the page there is a note about only being able to
>tune 2 LOs independently.  Does this mean that even though there are 4 RX
>paths, you can only look on 2 large bands at the same time (assuming all
>the bands you want are > 200 MHz apart)?
>
> The N310 has two daughterboards, each of which have an AD9371. The
AD9371 has 2 Tx and 2 Rx channels per chip.  The 2 Tx and 2 Rx channels
each share an LO, so you can tune each daughtercard's transmitters and
receivers independently, but not all 4 transmitters and receivers
independently.For additional details, take a look at the AD9371 product
page:   http://www.analog.com/en/products/rf-microwave/integ
rated-transceivers-transmitters-receivers/wideband-transceiv
ers-ic/ad9371.html

>
>- Are timed commands supported the way they are for the N and X
>series?  I don't mean the limited timed command support that the B series
>radios have.
>
>  Timed commands do exist for the N310, however there is a subtlety here.
 Any interactions with AD9371 transceiver are not currently supported via
timed commands.   Future support is possible, but with accuracy in the
millisecond range.

>
>- If so, is there just one command FIFO like in the N and X series?
>
>
> Correct.


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

[USRP-users] OFDM TX/RX BER Calculator

[Sarah Tran via USRP-users]

Hi all,

I am trying to use the ofdm_tx.grc and ofdm_rx.grc to transmit data from one 
N210 controlled by a host to another N210 controlled by a separate host. 
Eventually I want to build an 8x8 MIMO system using OFDMA. I want to verify 
that the correct data is being received so I sent all of the decoded payload 
data into a file sink. The file I sent has 10e6 random samples from 0-255 being 
stored into bytes. I received at least 5x that amount to ensure that I got all 
the data. I imported the received data and the known sent data into Matlab and 
performed the cross-correlation. The figure looks kind of okay as it showed 
multiple peaks (see figure below). However when I went to actually calculate 
the BER, I never got more than 20% of the correct bits. It was behaving 
strangely as 20% of the bits would be correct in a row, and then after that it 
would just be completely wrong. I know the ofdm_tx.grc graphs inserts metadata 
into the signal, and my theory is that the meta data is also being decoded and 
it won’t match exactly what was sent in the file because of the extra 
information. My understanding might be completely off, so if anyone can clarify 
it would be greatly appreciated! I just want to be able to have a way that 
calculates the BER between what is transmitted and what is received.

Thank you for your time!!

[cid:image002.jpg@01D3B539.503832E0]

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

Re: [USRP-users] N310 Questions

[Dave NotTelling via USRP-users]

Robin,

 Thank you very much for the explanations!

-Dave

On Tue, Mar 6, 2018 at 3:26 PM, Robin Coxe  wrote:

> Hi Dave.  The official product announcement of the USRP N310 was just
> posted today.   The N310 is now orderable!
>
> On Mon, Mar 5, 2018 at 2:11 PM, Dave NotTelling via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Just saw that the N310 is officially on the ettus.com website.  Curious
>> about the following:
>>
>>- The product pages says that it's not for fast tuning.  Should I
>>expect roughly the same tuning times as the B2x0 radios?
>>
>> Currently, the tuning times are actually a bit slower than the B200/E310
> (~140 ms) because the frequency is adjusted via SW SPI commands to the
> AD9371 transceiver.   A future performance enhancement will be to implement
> frequency tunes via GPIO lines from the FPGA.   The AD9371 was not designed
> for fast frequency hopping.  The AD9371 has an embedded ARM Cortex-M0
> processor that orchestrates an on-chip quadrature error correction (i.e.,
> I/Q imbalance calibration) that takes an appreciable amount of time to
> converge.  The fastest that the device will be ever be capable of tuning
> without disabling this calibration is ~2 ms.
>
>
>>
>>- At the bottom of the page there is a note about only being able to
>>tune 2 LOs independently.  Does this mean that even though there are 4 RX
>>paths, you can only look on 2 large bands at the same time (assuming all
>>the bands you want are > 200 MHz apart)?
>>
>> The N310 has two daughterboards, each of which have an AD9371. The
> AD9371 has 2 Tx and 2 Rx channels per chip.  The 2 Tx and 2 Rx channels
> each share an LO, so you can tune each daughtercard's transmitters and
> receivers independently, but not all 4 transmitters and receivers
> independently.For additional details, take a look at the AD9371 product
> page:   http://www.analog.com/en/products/rf-microwave/integ
> rated-transceivers-transmitters-receivers/wideband-transceiv
> ers-ic/ad9371.html
>
>>
>>- Are timed commands supported the way they are for the N and X
>>series?  I don't mean the limited timed command support that the B series
>>radios have.
>>
>>  Timed commands do exist for the N310, however there is a subtlety here.
>  Any interactions with AD9371 transceiver are not currently supported via
> timed commands.   Future support is possible, but with accuracy in the
> millisecond range.
>
>>
>>- If so, is there just one command FIFO like in the N and X series?
>>
>>
>> Correct.
>
>
> -Robin
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] OFDM TX/RX BER Calculator

[Michael Dickens via USRP-users]

Hi Sarah - A few things to note on using the default GR OFDM using real
SDR devices that could be relevant here:
*  tx data amplification: This needs to be such that the data heading to
   UHD doesn't saturate on conversion. You can visually see this if you
   look at the raw Rx signal ... it will look mostly like OFDM in the
   center but then have significant side bands. With too little Tx data
   amplification, the signal will look very OFDM, but it might end up
   with the average signal peaks being not far enough above the noise
   floor. The Tx data amp value depends on which constellation you're
   using for the payload. An easy way to see all of this is to use a
   graphical slider to set this value & then watch the raw Rx signal.
* rx data amplification: You generally want this "high", but you can
  play with this value to see what works best. This value generally
  isn't as critical as the Tx data amp value.
* Since OFDM sends data in packets, you really care about the Packet
  Error Rate (PER). Lose 1 packet, and you've lost a bunch of bits. The
  OFDM Rx uses the tag "packet_num" to show successful packet receipt,
  and increments this value by 1 for each packet detected but invalid
  (whether in the meta-data header or in the payload). So you should be
  able to create a PER block that just watches for skips in the Rx
  "packet_num" tag.
* The meta-data you mention is the header, which is indeed inserted into
  the OFDM signal. It is removed on Rx, so it should not be the cause of
  your issues.
* It sounds almost as if the OFDM Rx is losing sync after 20% of the
  data is received, for some reason. Usually Rx sync is lost because the
  USRP's Tx gain isn't high enough, and so the Rx signal's "SNR" isn't
  high enough to always meet the sync's criteria. Maybe try playing with
  the USRP Tx gain & see if that helps.
I';m sure there are other things relevant here, but these are the ones
that come to mind. Hope this helps! - MLD
On Tue, Mar 6, 2018, at 3:53 PM, Sarah Tran via USRP-users wrote:
> I am trying to use the ofdm_tx.grc and ofdm_rx.grc to transmit data
> from one N210 controlled by a host to another N210 controlled by a
> separate host. Eventually I want to build an 8x8 MIMO system using
> OFDMA. I want to verify that the correct data is being received so I
> sent all of the decoded payload data into a file sink. The file I sent
> has 10e6 random samples from 0-255 being stored into bytes. I received
> at least 5x that amount to ensure that I got all the data. I imported
> the received data and the known sent data into Matlab and performed
> the cross-correlation. The figure looks kind of okay as it showed
> multiple peaks (see figure below). However when I went to actually
> calculate the BER, I never got more than 20% of the correct bits. It
> was behaving strangely as 20% of the bits would be correct in a row,
> and then after that it would just be completely wrong. I know the
> ofdm_tx.grc graphs inserts metadata into the signal, and my theory is
> that the meta data is also being decoded and it won’t match exactly
> what was sent in the file because of the extra information. My
> understanding might be completely off, so if anyone can clarify it
> would be greatly appreciated! I just want to be able to have a way
> that calculates the BER between what is transmitted and what is
> received. Thank you for your time!!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Synchronisation of 2 X310s with TwinRXs

[Goh Liang Zhen via USRP-users]

Dear fellow users,

I intend to put together a 8 channel data collection system using 2 X310s, each 
mounted with 2 TwinRXs.  With the guidance from the past experience in this 
forum, I have installed the hardware and started data collection on a computer 
running on Ubuntu 16.04 LTS and UHD 3.10.3.0.  Time and frequency 
synchronisation were obtained by using the clock and PPS from external 
Octoclock-G, and also timed command for the two X310s as source0 and source1.

However, I realised that as the TwinRXs in different X310s did not share LOs, 
the data collected was not phase synchronised.  I am currently trying to take 
LO1 and LO2 from one of the boxes and sharing it with the other TwinRXs via an 
RF splitter.  The first TwinRX LOs are set to "Internal, True (for export)" and 
"Companion, True", while the rest are set to "External, False".  I shall refer 
to the former TwinRX as "Master", and the remaining as "Slave".  The Master is 
in RX A slot of the first X310.

With this setup, I am able to achieve phase synchronisation repeatedly for the 
Master, and Slaves placed in RX B slot of X310.  The Slave place in RX A slot 
of the second X310 has a phase which starts independently of the Master.

Any kind advice of what I am missing to achieve phase synchronisation of the 
last Slave?


Regards,
GOH Liang Zhen

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

[USRP-users] Hot Debug on E310

[Juan Pablo Leal Licudis via USRP-users]

Hello, I'm trying to "HOT" debug on E310 with the JTAG, what I'm trying to
say with HOT is burning the image but maintaining the OS functional for
open the GnuRadio and test my RFNoc Module whit all the system running, is
it possible ? because I'm experiencing some issues with it. To start whit
this task I followed the Tutorial of the X310 and try to debug the SIGGEN
block I can debug my image correctly if I umount the MicroSDcard and burn
the image directly into the FPGA, but when the SDCard is mounted I can't
even start ILA.

This is the Vivado's information of the same image that works without the
sdcard mounted

WARNING: [Labtools 27-3123] The debug hub core was not detected at User
Scan Chain 1 or 3.
Resolution:
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free
running clock and is active OR
2. Manually launch hw_server with -e "set xsdb-user-bscan
" to detect the debug hub at User Scan
Chain of 2 or 4. To determine the user scan chain setting, open the
implemented design and use: get_property C_USER_SCAN_CHAIN [get_debug_cores
dbg_hub].
WARNING: [Labtools 27-1974] Mismatch between the design programmed into the
device xc7z020_1 and the probes file
/home/jlicudis/Ettus/fpga/usrp3/top/e300/build-E310_RFNOC/SiggenJTAG/SiggenJTAG.runs/impl_1/debug_nets.ltx.
The device design has 0 ILA core(s) and 0 VIO core(s). The probes file has
1 ILA core(s) and 0 VIO core(s).
Resolution:
1. Reprogram device with the correct programming file and associated probes
file OR
2. Goto device properties and associate the correct probes file with the
programming file already programmed in the device.


I saw that the E310 reboot when the Vivado burn the image into the FPGA
with the microSD mounted, so I put the SIGGEN image with the name
of usrp_e310_fpga.bit and check the image loaded with the uhd_usrp_probe
without burning from VIVADO but hit refresh, and again no luck.

Please, can somebody give me some ideas about it, is it possible to
do?. Thank you in advance.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Product Announcement: Simplifying Deployment of Software Defined Radios with USRP N310

[Wan Liu via USRP-users]

Ettus Research is proud to announce the USRP N310 software defined radio
(SDR). This SDR delivers reliability and fault-tolerance for deployment in
large-scale and distributed wireless systems. The USRP N310 simplifies
control and management of a network of radios by introducing the unique
capability to remotely perform tasks such as updating software, rebooting,
factory resetting, self-testing, host PC/ARM debugging, and monitoring
system health.

The USRP N310 is one of the highest channel density devices on the SDR
market, offering four RX and four TX channels in a half-wide RU form
factor. The RF front end uses two AD9371 transceivers, the latest RFIC
technology from Analog Devices. Each channel provides up to 100 MHz of
instantaneous bandwidth, and covers an extended frequency range from 10 MHz
to 6 GHz.

The baseband processor uses the Xilinx Zynq-7100 SoC to deliver a large
user programmable FPGA for real-time and low-latency processing and a
dual-core ARM CPU for stand-alone operation. Users can deploy applications
directly onto the pre-installed embedded Linux operating system or stream
samples to a host computer using high-speed interfaces such as 1 Gigabit
Ethernet, 10 Gigabit Ethernet, and Aurora over dual SFP+ ports.

The open source USRP Hardware Driver™ (UHD) API and RF Network-on-Chip
(RFNoC™) FPGA development framework reduce software development effort and
integrate with a variety of industry-standard tools such as GNU Radio.
Users can rapidly prototype and reliably deploy designs for a variety of
SDR applications such as wireless testbed, remote radio head, spectrum
monitoring, and more.
For more information, visit the USRP N310
 product page or contact
sa...@ettus.com.

Product Page:
https://www.ettus.com/product/details/USRP-N310

Regards,

Wan Liu
Product Manager, Software Defined Radio
Ettus Research
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com