Re: [USRP-users] RFNoC TX Examples

[Ryan Marlow via USRP-users]

Hey Leo,
I haven't seen anyone respond yet and I recently needed to develop a TX
RFNoC example of my own. I worked off the rfnoc_rx_to_file.cpp example. Far
from perfect, but it gets the job done (transmits data). The main changes
are:
- copied send_from_file function from tx_samples_from_file.cpp example to
handle the streaming of data from the input file
- reversed the order that blocks are connected in the graph->connect()
function. Now connects optional arg block -> radio. Was radio -> optional
arg block.
- uses tx_stream instead of rx_stream.
Just add this cpp file to the CMake file in the host/examples dir to build
it then try it out.
I ran it with:
build/examples$ ./rfnoc_tx_from_file --block-id DUC_0 --block-args
output_rate=200e6,input_rate=5e6 --duration 5 --file usrp_samples.dat

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

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

namespace po = boost::program_options;

static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}


typedef boost::function get_sensor_fn_t;

bool check_locked_sensor(std::vector sensor_names, const char* sensor_name, get_sensor_fn_t get_sensor_fn, double setup_time){
if (std::find(sensor_names.begin(), sensor_names.end(), sensor_name) == sensor_names.end())
return false;

boost::system_time start = boost::get_system_time();
boost::system_time first_lock_time;

std::cout << boost::format("Waiting for \"%s\": ") % sensor_name;
std::cout.flush();

while (true) {
if ((not first_lock_time.is_not_a_date_time()) and
(boost::get_system_time() > (first_lock_time + boost::posix_time::seconds(setup_time
{
std::cout << " locked." << std::endl;
break;
}
if (get_sensor_fn(sensor_name).to_bool()){
if (first_lock_time.is_not_a_date_time())
first_lock_time = boost::get_system_time();
std::cout << "+";
std::cout.flush();
}
else {
first_lock_time = boost::system_time();	//reset to 'not a date time'

if (boost::get_system_time() > (start + boost::posix_time::seconds(setup_time))){
std::cout << std::endl;
throw std::runtime_error(str(boost::format("timed out waiting for consecutive locks on sensor \"%s\"") % sensor_name));
}
std::cout << "_";
std::cout.flush();
}
boost::this_thread::sleep(boost::posix_time::milliseconds(100));
}
std::cout << std::endl;
return true;
}

template void send_from_file(
uhd::tx_streamer::sptr tx_stream,
const std::string ,
size_t samps_per_buff
){

uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst = false;
std::vector buff(samps_per_buff);
std::ifstream infile(file.c_str(), std::ifstream::binary);

//loop until the entire file has been read

while(not md.end_of_burst and not stop_signal_called){

infile.read((char*)(), buff.size()*sizeof(samp_type));
size_t num_tx_samps = size_t(infile.gcount()/sizeof(samp_type));

md.end_of_burst = infile.eof();

tx_stream->send((), num_tx_samps, md);
}

infile.close();
}

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

//variables to be set by po
std::string args, file, format, ant, subdev, ref, wirefmt, streamargs, radio_args, block_id, block_args;
size_t total_num_samps, spb, radio_id, radio_chan;
double rate, freq, gain, bw, total_time, setup_time;

//setup the program options
po::options_description desc("Allowed options");
desc.add_options()
("help", "help message")
("file", po::value()->default_value("usrp_samples.dat"), "name of the file to write binary samples to")
("format", po::value()->default_value("sc16"), "File sample format: sc16, fc32, or fc64")
("duration", po::value(_time)->default_value(0), "total number of seconds to receive")
("nsamps", po::value(_num_samps)->default_value(0), "total number of samples to receive")

Re: [USRP-users] N310 timeout before streaming complete

[Michael West via USRP-users]

Hi Rob,

Thanks again for the feedback.  I'm glad to hear the issue is resolved on
the N310.  We will dig in further on the X310 and let you know what we
find.  I did notice the error seems to occur when the number of total
samples received (including those flushed) is aligned to 1996.  A possible
workaround in the meantime may be to use STREAM_MODE_NUM_SAMPS_AND_DONE
with a number of samples not aligned to 1996 or to time the stop command
such that it does not land on a multiple of 1996 samples.

Regards,
Michael

On Tue, Sep 18, 2018 at 8:22 AM, Rob Kossler  wrote:

> Michael,
> I got a chance to test the latest 3.13 changes with regard to the Rx
> timeouts discussed in this thread.  On my N310, the timeouts seem to be
> fixed - I did not experience any in my testing.  However, on the X310, I
> still occasionally get a timeout using the same
> "txrx_loopback_to_file_repeat" program I attached earlier in this thread.
>
> Rob
>
> A few remarks
>
>- Below you will find the console output for
>txrx_loopback_to_file_repeat followed by the output for uhd_usrp_probe
>- Note below the error (timeout) on iterations 8 and 14
>- Previously, after an error occurred, all subsequent iterations would
>fail, but this is not the case anymore.  In fact, for all iterations, the
>desired data capture completed successfully - the timeout happened during
>the "flush" operation.
>- The error does not always occur in this program which is hardcoded
>for 50 iterations.  So, if no error occurs, simply run again and likely
>there will be at least one error.
>- Note that I changed some of the command line parameters (such as
>tx-rate and rx-rate) in an attempt to make the error occur more often, but
>I really don't know if it matters
>
>
> $ txrx_loopback_to_file_repeat --tx-args="addr=192.168.46.2"
> --rx-args="addr=192.168.46.2" --nsamps=100 --tx-rate=50e6
> --rx-rate=100e6 --tx-channels=0,1 --rx-channels=0,1 --tx-freq=2500e6
> --rx-freq=2500e6 --file=/media/ramfolder/usrp_samples
>
> Creating the transmit usrp device with: addr=192.168.46.2...
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.0.3-0-g85347b89
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1296 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>
> Creating the receive usrp device with: addr=192.168.46.2...
> Using TX Device: Single USRP:
>   Device: X-Series Device
>   Mboard 0: X310
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
>   RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: UBX RX
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>   TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: UBX TX
>
> Using RX Device: Single USRP:
>   Device: X-Series Device
>   Mboard 0: X310
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
>   RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: UBX RX
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>   TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: UBX TX
>
> Setting TX Rate: 50.00 Msps...
> Actual TX Rate: 50.00 Msps...
>
> Setting RX Rate: 100.00 Msps...
> Actual RX Rate: 100.00 Msps...
>
> Configuring TX Channel 0
> Setting TX Freq: 2500.00 MHz...
> Actual TX Freq: 2500.00 MHz...
>
> Configuring TX Channel 1
> Setting TX Freq: 2500.00 MHz...
> Actual TX Freq: 2500.00 MHz...
>
> Configuring RX Channel 0
> Setting RX Freq: 2500.00 MHz...
> Actual RX Freq: 2500.00 MHz...
>
> Configuring RX Channel 1
> Setting RX Freq: 2500.00 MHz...
> Actual RX Freq: 2500.00 MHz...
>
> Checking TX: TXLO: locked ...
> Checking RX: RXLO: locked ...
> Setting device timestamp to 0...
> Iteration 0 at time 0.212949
>   Num samples received: 1017960
>   Flush samps received: 19393; EOB: 1; ERR: 0
> Iteration 1 at time 0.434254
>   Num samples received: 1017960
>   Flush samps received: 11682; EOB: 1; ERR: 0
> Iteration 2 at time 0.655387
>   Num samples received: 1017960
>   Flush samps received: 15294; EOB: 1; ERR: 0
> Iteration 3 at time 0.87674
>   Num samples received: 1017960
>   Flush samps received: 12270; EOB: 1; ERR: 0
> Iteration 4 at time 1.09799
>   Num 

Re: [USRP-users] PCI-e bandwidth on X310

[Dave NotTelling via USRP-users]

Chintan,

I have tried both about 1.5 years ago and found that (at least in my use
case) the NI drivers for the PCIe card in Linux were effectively single
threaded.  This is a major issue if you are working on a many core system
with a lower clock rate while trying to receive really high rates (> 100
MSPS).  I can stream at higher rates using 10 Gb/s copper than I can with
the PCIe interface with the same processor.  This is on an approx 3.2 GHz
Intel Xeon processor.  I'd probably be better off with something with fewer
cores and a higher clock, but I need the cores.

If you don't need the latency of PCIe, then (at least in my opinion) it's
better to buy something like the Intel X710 dual port 10 Gb/s NIC.  It's
usable in more scenarios (it's just a normal NIC after all), and has
drivers that are incredibly mature for almost any system.


One assumption I have made that could very well be wrong: I feel like the
drivers for NICs (especially from a vendor like Intel) are going to be more
mature and bullet proof than the NI PCIe driver.  They are massively more
common and tested in the field and are (AFAIK) more configurable.


On Wed, Sep 19, 2018 at 11:56 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 09/19/2018 09:45 AM, Chintan Patel via USRP-users wrote:
> > Hi,
> >
> > What is a realistic achievable capacity on the PCI-e(x4) link on the
> > X310? The NI PXI brochure claims a 832MBytes/s rate, but not sure what
> > has been achieved in practice. Trying to figure out how what sample
> > rate will be supported for a 4-channel RX radio configuration.
> >
> > Thanks
> > Chintan
> >
> >
> It depends, as always, on exactly what you're doing with the samples
> once you get them, and the capabilities of the CPU.
>
> The PCI-e doesn't necessarily offer higher bandwidth than the 1GiGe
> interface, just lower latency.
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 schematic

[Robin Coxe via USRP-users]

Hi Chintan.  Yes, it is an intentional omission.  The PCIe circuitry uses an NI 
proprietary ASIC and that portion of the schematic cannot be released.
-Robin

Robin Coxe | Chief R Program Manager, SDR | Santa Clara, CA | 408.610.6363


From: 32042062500n behalf of
Sent: Wednesday, September 19, 2018 9:55 AM
To: usrp-users
Subject: [USRP-users] X310 schematic

I was looking at the X310 schematic to understand the PCIe circuitry, and it 
seems that the schematic is missing pages which presumably had the PCIe 
circuitry. Is this intentionall?

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

[USRP-users] X310 schematic

[Chintan Patel via USRP-users]

I was looking at the X310 schematic to understand the PCIe circuitry, and
it seems that the schematic is missing pages which presumably had the PCIe
circuitry. Is this intentionall?

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

Re: [USRP-users] PCI-e bandwidth on X310

[Marcus D. Leech via USRP-users]

On 09/19/2018 09:45 AM, Chintan Patel via USRP-users wrote:

Hi,

What is a realistic achievable capacity on the PCI-e(x4) link on the 
X310? The NI PXI brochure claims a 832MBytes/s rate, but not sure what 
has been achieved in practice. Trying to figure out how what sample 
rate will be supported for a 4-channel RX radio configuration.


Thanks
Chintan


It depends, as always, on exactly what you're doing with the samples 
once you get them, and the capabilities of the CPU.


The PCI-e doesn't necessarily offer higher bandwidth than the 1GiGe 
interface, just lower latency.





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

[USRP-users] PCI-e bandwidth on X310

[Chintan Patel via USRP-users]

Hi,

What is a realistic achievable capacity on the PCI-e(x4) link on the X310?
The NI PXI brochure claims a 832MBytes/s rate, but not sure what has been
achieved in practice. Trying to figure out how what sample rate will be
supported for a 4-channel RX radio configuration.

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

Re: [USRP-users] GPS and frequency drift problems on TDMA receiver (E310)

[David Zamorano Fernández via USRP-users]

Hi all!

Does anyone have any idea or experience regarding this problem?

Best regards,
David

--


[image: logo_170x100px.png] 



David Zamorano Fernández
Investigador - Desarrollador | Área de Comunicaciones Avanzadas
Researcher - Developer | Advanced Communications Department



Ph. (+34) 986 120 430  Ext. 3012
dzamor...@gradiant.org   |  www.gradiant.org

[image: Iconos Redes Sociales GRD Firma email-01]
  [image: Iconos Redes Sociales GRD
Firma email-02]   [image: Iconos Redes
Sociales GRD Firma email-03] 
 [image: Iconos Redes Sociales GRD Firma email-04]

Take care of the environment. Try not to print this email.
The information contained in this email message may be confidential
information, and may also be the subject of legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorized and prohibited.
Please inform us immediately and destroy the email. Thank you for your
cooperation.


El mar., 4 sept. 2018 a las 17:31, David Zamorano Fernández (<
dzamor...@gradiant.org>) escribió:

> Hi all!
>
> We have implemented a TDMA receiver using the GPS signal to discipline the
> internal clock of the E310 and thus reduce frequency deviations. The
> system works fine, but in some cases, frequency drifts appear and the slots
> start to be erroneous (wrong CRC). The number of visible satellites has
> also been controlled and abruptly goes from a high number (12-13) to a few
> (1-2) or even none.
>
> The GPS antenna is outside. The system has been tested with different
> antennas and the behavior has been the same.
>
> Is there any kind of known bug in the gps daemon related to this? Is
> there any other reason why this may be happening?
>
> I attached an image of a large message capture. You can see how there are
> three zones where the frequency drift starts to appear and the slots start
> to be erroneous (green circle = ok and red circle = error).
>
> --
>
>
> [image: logo_170x100px.png] 
>
>
>
> David Zamorano Fernández
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430  Ext. 3012
> dzamor...@gradiant.org   |  www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales
> GRD Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03]
>   [image: Iconos Redes
> Sociales GRD Firma email-04]
> 
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com