from:"Nate Temple via USRP\-users"

Re: [USRP-users] B210 on VirtualBox VM - USB settings

2017-07-06 Thread Nate Temple via USRP-users

Hi Saeid,

For the filter rule use  VID: 2500 PID: 0020

Also you may need to install the VirtualBox Extension pack.

Regards,
Nate Temple

> On Jul 6, 2017, at 11:53 AM, Neel Pandeya via USRP-users 
>  wrote:
> 
> I meant to add that you will also still need to set the udev rules in the VM 
> too (I'm assuming that you're using Ubuntu 16.04 as the guest OS).
> 
> https://files.ettus.com/manual/page_transport.html#transport_usb_udev
> 
> --Neel Pandeya
> 
> 
> 
> On 6 July 2017 at 11:51, Neel Pandeya  wrote:
> Just be sure that you're using the latest version of VirtualBox, 5.1.22, and 
> enable USB 3.0 support.
> 
> For running UHD and/or GNU Radio, your VM should have 2 GB memory, and 4 GB 
> would be ideal.
> 
> --Neel Pandeya
> 
> 
> 
> On 6 July 2017 at 11:47, Saeid Hashemi via USRP-users 
>  wrote:
> Hello all,
> 
> Is anyone using the B210 on a VirtualBox VM? What would the USB filter 
> settings be for that setup?
> 
> Thanks and regards,
> Saeid
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] ADC self-test failed

2017-07-07 Thread Nate Temple via USRP-users

Hi Sam,

Can you please email into supp...@ettus.com. We can debug further off the 
mailing list.

Regards,
Nate


> On Jul 6, 2017, at 8:39 AM, Sam Vogel  wrote:
> 
> Hi Nate,
> 
> Sure, our company is using a custom UHD and I will have to redact part of the 
> text. When I run the command it outputs:
> 003.009.001
> This x300 has always been problematic. We have a different X300 that works 
> fine with this setup. The problem occurs when I duplicate the setup for use 
> with our second X300. We need the second setup running also. I have never 
> updated the UHD.
> Hopefully this is helpful, I assume our custom UHD is built from 003.009.001. 
> 
> Thanks so much,
> Sam
> 
> On Thu, Jul 6, 2017 at 1:12 AM, Nate Temple  wrote:
> Hi Sam,
> 
> Can you run the following command send what it's output is? This will print 
> out the exact version of UHD you're using: uhd_usrp_probe --version
> 
> My second question was if you have changed any thing with your setup since 
> the X300 has became problematic ? Have you updated the UHD version at all 
> recently?
> 
> Regards,
> Nate Temple
> 
> 
> > On Jul 5, 2017, at 9:10 PM, Sam Vogel  wrote:
> >
> > Hi Nate,
> >
> > Yes, there is a uhd_usrp_probe program in /examples/utils, perhaps this 
> > means I'm using the 'uhd_usrp_probe' version? I can get more info on this 
> > tomorrow when I'm in the office. We have two different X300 boards, let's 
> > call them X300A and X300B. Each are a different H/W revision. We have been 
> > using X300A for a while and the problem now occurs when I try to use X300B 
> > with the same code base we use for X300A. The main difference in the setups 
> > is the X300 board itself.  A lot of the code we use is custom and I don't 
> > know if starting from a fresh copy of the Ettus repository is feasible.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jul 5, 2017 at 8:29 PM, Nate Temple  wrote:
> > Hi Sam,
> >
> > Which version of UHD are you using? (uhd_usrp_probe --version)
> >
> > Have you recently updated UHD, or has anything changed in your setup from 
> > when it was previously work to now?
> >
> > Regards,
> > Nate Temple
> >
> > On Wed, Jul 5, 2017 at 3:08 PM, Sam Vogel via USRP-users 
> >  wrote:
> > Hi,
> >
> > This happens every time.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jul 5, 2017 at 6:01 PM, Martin Braun via USRP-users 
> >  wrote:
> > Does this happen intermittently? Or every time?
> >
> > -- M
> >
> > On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
> > > Hi All, I’m running into an issue with our x300 revision E.  Any help
> > > resolving this is greatly appreciated.
> > >
> > > Following the procedure to recover the EEPROM yields a problem.
> > >
> > > [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
> > > --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
> > >
> > > Creating USRP device from address: recover_mb_eeprom,addr=192.167.10.111
> > >
> > > -- X300 initialization sequence...
> > >
> > > -- Determining maximum frame size... 8000 bytes.
> > >
> > > -- Setup basic communication...
> > >
> > > -- Loading values from EEPROM...
> > >
> > >
> > >
> > > UHD Warning:
> > >
> > > UHD is operating in EEPROM Recovery Mode which disables hardware
> > > version checks.
> > >
> > > Operating in this mode may cause hardware damage and unstable radio
> > > performance!
> > >
> > > -- Setup RF frontend clocking...
> > >
> > >
> > >
> > > UHD Warning:
> > >
> > > Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not found,
> > > defaulting to reference clock rate of 1000.00 Hz
> > >
> > > -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
> > >
> > > -- Radio 1x clock:200
> > >
> > > -- Initialize Radio0 control...
> > >
> > > -- Performing register loopback test... pass
> > >
> > > -- Initialize Radio1 control...
> > >
> > > -- Performing register loopback test... pass
> > >
> > > Error: RuntimeError: ADC self-test failed! Ramp checker status:
> > > {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
> > >
> > >
> > >
> > > Thanks !
> > >
> > > -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
> >
> >
> > ___
> > 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] Very Close - Trying to Connect B210 Using VMware

2017-07-14 Thread Nate Temple via USRP-users

Hi Konstanitn,

I assume you mean you are using VirtualBox, not VMWare.

You will need to add a USB Filtering rule for the USRP within the settings for 
the virtual machine (within VirtualBox settings). 

You will need to add a rule for VID: 2500 PID: 0020 for the B210.

Also, you need replace the value "" with the path to which UHD is 
installed, commonly this is /usr/local/. uhd_images_downloader will be located 
/usr/local/lib/uhd/utils/uhd_image_downloader.py

Regards,
Nate Temple


> On Jul 14, 2017, at 9:28 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC] via USRP-users  wrote:
> 
>  
> Hello to everyone.  I am a novice to the B210.  My main first task is to 
> hookup the B210 to the laptop via  Oracle VMware (Virtual machine).
>  
> I realize this may not be the most admired approach, but I think i am very 
> close in getting the B210 connected.  btw, after many hours of hurdles that i 
> found out already.
>  
> I hope you can review the screen shot first.
> Comments/Facts
>  
> 1) the B210 is USB 3.0
> 2) I already installed Windows host.guest USB 3.0 driver and Oracle VMware 
> extensions pack to allow the USB 3.0 to pass from the Windows 7 OS to the 
> virtual Ubuntu 16.04 OS.  I hear the beep noise when I open the Vmware 
> software.  Thus, giving a good sign that the Linux OS as detected the USB 3.0 
> port of the B210.
> 3)  When running the 'uhd_find_devices' at the terminal prompt, a message 
> come up stating that I needed to update the B210 image by running the folling 
> python code -/usr/lib/uhd/utils/uhd_images_downloader.py - This seemed to 
> update a driver.
> 4) I then unplugged the B210 and reset the Linux software.
> 5) But then when I ran the 'uhd_find_devices' command in the terminal, i 
> received No UHD Devices Found.
>  
> At this time, I am out of ideas, thus if anyone can help out in assisting me 
> in getting tthings connected with the current approach.
>  
> Thanks
>  
> Konstanitn
>  
>  
>  
> Have a little more info that might help.  Look at the screenshot.  i have a 
> B210, but it shows it is trying to load a b200 hex file to firmware.  This 
> happens when I unplug and plug the USB port in.  May this be the issue?
> 
> Thanks
>  
>  
>  
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] Error when burn fpga image file into USRP X310

2017-07-14 Thread Nate Temple via USRP-users

Hi Luis,

I will follow up with you on this issue off the list, within the thread that 
has been sent to supp...@ettus.com.


Regards,
Nate Temple


> On Jul 14, 2017, at 6:51 AM, Torres Figueroa, Luis Angel via USRP-users 
>  wrote:
> 
> Hi Nate,
>  
> I have exactly the same problem that was reported in previous threads: I 
> loaded a custom FPGA image, got the USRP 2953R (x310) bricked  and then used 
> the JTAG connection with Vivado 2015.4’s Hardware Manager to program the 
> device, however when trying to load an image to flash using the 
> uhd_image_loader command, I get the error: “RuntimeError: Device reported an 
> error during initialization.”
>  
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-December/023092.html
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-October/022064.html
>  
> Could you please let me know which steps must be followed in this case? I 
> attach some logs.
>  
> Best,
> Luis
>  
> ltorresf@pc1:~$ uhd_usrp_probe 
> [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; 
> UHD_4.0.0.rfnoc-devel-348-g2c2e1a99
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size... 
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [X300] Detecting internal GPSDO 
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0... 
> [INFO] [RFNOC] pass (Throughput: 1304.0MB/s)
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1... 
> [INFO] [RFNOC] pass (Throughput: 1305.1MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input 
> ports
> [INFO] [CORES] Performing timer loopback test... 
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test... 
> [INFO] [CORES] Timer loopback test passed
>   _
>  /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 6
> |   |   product: 30513
> |   |   mac-addr0: 00:80:2f:0a:ff:b0
> |   |   mac-addr1: 00:80:2f:0a:ff:b1
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.3
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: F5BE96
> |   |   FW Version: 5.1
> |   |   FPGA Version: 33.0
> |   |   FPGA git hash: f764326-dirty
> |   |   RFNoC capable: Yes
> |   |   
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, 
> ref_locked
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: CBX (0x0067)
> |   |   |   Serial: F58458
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: CBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 1200.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: CBX (0x0067)
> |   |   |   Serial: F583B9
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: CBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 1200.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: B
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _

Re: [USRP-users] I want to build my custom FPGA image but failed to get the license

2017-07-25 Thread Nate Temple via USRP-users

Hi,

Which OS and OS Version are you using?

Regards,
Nate


> On Jul 25, 2017, at 5:55 PM, 이진세 via USRP-users  
> wrote:
> 
>  hello
>  
> I use e310 and try to build custom fpga image.
>  
> and i entered a trial license, including webPack, from Vivado License manager.
>  
> In the View License Status tab, the license named Synthesis and XC7Z020 is 
> displayed.
>  
> However, i received error message saying that the license is not available.
>  
> this is error log about command 'sudo ./uhd_image_builder.py window fft -d 
> e310 -t E310_RFNOC_sg3 -m 5 --fill-with-fifos'.
>  
> please tell me what is wrong.
> 
> thanks.
>  
>  
> spade@spade-DREAMPRO:~/rfnoc/src/uhd-fpga/usrp3/tools/scripts$ sudo 
> ./uhd_image_builder.py window fft -d e310 -t E310_RFNOC_sg3 -m 5 
> --fill-with-fifos
> [sudo] password for spade: 
> --Using the following blocks to generate image:
> * window
> * fft
> Adding CE instantiation file for 'E310_RFNOC_sg3'
> changing temporarily working directory to 
> /home/spade/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/e300
> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
> - Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
> - Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
> 
> Environment successfully initialized.
> make -f Makefile.e300.inc bin NAME=E310_RFNOC_sg3 ARCH=zynq 
> PART_ID=xc7z020/clg484/-3 RFNOC=1 E310=1 EXTRA_DEFS="RFNOC=1 E310=1"
> make[1]: Entering directory '/home/spade/rfnoc/src/uhd-fpga/usrp3/top/e300'
> BUILDER: Checking tools...
> * GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
> * Python 2.7.12
> * Vivado v2015.4 (64-bit)
> 
> BUILDER: Building IP axi_fft
> 
> BUILDER: Staging IP in build directory...
> BUILDER: Reserving IP location: 
> /home/spade/rfnoc/src/uhd-fpga/usrp3/top/e300/build-ip/xc7z020clg484-3/axi_fft
> BUILDER: Retargeting IP to part zynq/xc7z020/clg484/-3...
> BUILDER: Building IP...
> 
> ** Vivado v2015.4 (64-bit)
>    SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
>    IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
> 
> source /home/spade/rfnoc/src/uhd-fpga/usrp3/tools/scripts/viv_generate_ip.tcl
> # set xci_file $::env(XCI_FILE)   ;
> # set part_name$::env(PART_NAME)  ;
> # set gen_example_proj $::env(GEN_EXAMPLE);
> # set synth_ip $::env(SYNTH_IP)   ;
> # set ip_name [file rootname [file tail $xci_file]]   ;
> # file delete -force "$xci_file.out"
> # create_project -part $part_name -in_memory -ip
> # set_property target_simulator XSim [current_project]
> # add_files -norecurse -force $xci_file
> INFO: [IP_Flow 19-234] Refreshing IP repositories
> INFO: [IP_Flow 19-1704] No user IP repositories specified
> INFO: [IP_Flow 19-2313] Loaded Vivado IP repository 
> '/opt/Xilinx/Vivado/2015.4/data/ip'.
> # reset_target all [get_files $xci_file]
> # puts "BUILDER: Generating IP Target..."
> BUILDER: Generating IP Target...
> # generate_target all [get_files $xci_file]
> INFO: [IP_Flow 19-1686] Generating 'Instantiation Template' target for IP 
> 'axi_fft'...
> INFO: [IP_Flow 19-1686] Generating 'Synthesis' target for IP 'axi_fft'...
> INFO: [Device 21-403] Loading part xc7z020clg484-3
> INFO: [IP_Flow 19-1686] Generating 'Simulation' target for IP 'axi_fft'...
> INFO: [IP_Flow 19-1686] Generating 'C Simulation' target for IP 'axi_fft'...
> INFO: [IP_Flow 19-1686] Generating 'Test Bench' target for IP 'axi_fft'...
> INFO: [IP_Flow 19-1686] Generating 'Change Log' target for IP 'axi_fft'...
> generate_target: Time (s): cpu = 00:00:06 ; elapsed = 00:00:08 . Memory (MB): 
> peak = 1134.184 ; gain = 162.906 ; free physical = 1258 ; free virtual = 6661
> # if [string match $synth_ip "1"] {
> # puts "BUILDER: Synthesizing IP Target..."
> # synth_ip [get_ips $ip_name]
> # }
> BUILDER: Synthesizing IP Target...
> INFO: [IP_Flow 19-234] Refreshing IP repositories
> INFO: [IP_Flow 19-1704] No user IP repositories specified
> INFO: [IP_Flow 19-2313] Loaded Vivado IP repository 
> '/opt/Xilinx/Vivado/2015.4/data/ip'.
> Command: synth_design -top axi_fft -part xc7z020clg484-3 -mode out_of_context
> Starting synth_design
> Attempting to get a license for feature 'Synthesis' and/or device 'xc7z020'
> WARNING: [Common 17-348] Failed to get the license for feature 'Synthesis' 
> and/or device 'xc7z020'
> 1 Infos, 1 Warnings, 0 Critical Warnings and 1 Errors encountered.
> synth_design failed
> ERROR: [Common 17-345] A valid license was not found for feature 'Synthesis' 
> and/or device 'xc7z020'. Please run the Vivado License Manager for assistance 
> in determining
> which features and devices are licensed for your system.
> Resolution: Check the status of your licenses in the Vivado License Manager. 
> For debug help search Xilinx Support for "Licensing FAQ".

Re: [USRP-users] Brench Maint and Master of UHD

2017-08-02 Thread Nate Temple via USRP-users

Hi Daniele,

Generally speaking, 'maint' should be stable. 

If you need an absolutely stable version, it is recommended to use a tagged 
release, such as 'release_003_010_002_000' (UHD 3.10.2.0) or 
'release_003_009_007' (UHD 3.9.7). We perform release testing on every tagged 
version of UHD. Unless you need a specific fix or feature that may be on 
'maint' or 'master', it's generally best to use to most recent tagged release 
of UHD. 

Which warnings did you get during your build?

Regards,
Nate Temple


> On Jul 26, 2017, at 3:02 PM, Disco Daniele via USRP-users 
>  wrote:
> 
> HI!
> Building from source the library UHD, for the branch maint (that is reported 
> is a stable version) I obtained some warnings (during the compilation) for 
> the master no.
> (I have verified this in a virtual machine that i've rebuilt for "snapshot" 
> trouble but I can rebuilt again the maint version  if it is necessary).
> The question is "it is always true the the stable version in the Maint 
> branch?"
> Thank you
> Daniele   
>  
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
> abbiate ricevuto questo documento per errore siete cortesemente pregati di 
> darne immediata comunicazione al mittente e di provvedere alla sua 
> distruzione, Grazie. 
> 
> This e-mail and any attachments is confidential and may contain privileged 
> information intended for the addressee(s) only. Dissemination, copying, 
> printing or use by anybody else is unauthorised. If you are not the intended 
> recipient, please delete this message and any attachments and advise the 
> sender by return e-mail, Thanks. 
> 
> Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] Using both TX/RX and RX2 ports on the same daughter board to receive signal simultaneously

2017-08-02 Thread Nate Temple via USRP-users

Hi Yue,

There is only one RX path, and it is only possible to RX via TX/RX or RX2 at 
any given time with the CBX/UBX/SBX/WBX daughterboards. The only exception is 
the TwinRX, which has two RX channels (and no TX), that run at 100e6 each.

Regards,
Nate Temple


> On Aug 2, 2017, at 9:04 PM, Karan Suri via USRP-users 
>  wrote:
> 
> Hi,
> I'm trying to using both TX/RX and RX2 ports on the same daughter board of 
> X310 to receive signal at the same time. 
> On the host side, I tried to create a new recv_to_file thread inside the main 
> thread(which will execute another recv_to_file). However, the terminal will 
> show the error "0/Radio_0 output port 0 is already connected".
> What should I do if I want to set both antennas to be receiving antennas on 
> the host side?
> 
> Thanks,
> Yue
> ___
> 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] When ssh'ing Getting prompt for Password Issue

2017-08-03 Thread Nate Temple via USRP-users

Hi Konstantin,

You may want to try putting your VM into a Bridge Network mode. There may be an 
issue with the NAT routing. If operating in Bridged mode, ensure your Host, VM 
and E3xx all have different IP addresses.

Regards,
Nate Temple



> On Aug 3, 2017, at 9:39 AM, Philip Balister via USRP-users 
>  wrote:
> 
> On 08/03/2017 11:07 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
> TECHNOLOGIES INC] via USRP-users wrote:
>> Hello All,
>> 
>> I have the E310 hooked up with an Ethernet wire, and I can ping from my 
>> Linux Ubuntu Virtual machine (created by Oracle VirtualBox software).
>> 
>> But when I try to SSH, I did get access denied.. until I added a  VM rule 
>> for port 22 in Network Settings of the VM.
>> 
>> But now I get the password message in the Linux terminal to place a 
>> password.  As we know, the password is empty per the instructions on the 
>> website.
> 
> Did you hit return to see if it gave you a prompt?
> 
> Philip
> 
>> 
>> So I went into ssh_config file in Linux at ect/ssh and altered a line that 
>> allows for no passwords... This is the site.. 
>> http://developer.toradex.com/knowledge-base/ssh
>> 
>> But I am still not getting past the password login.
>> 
>> Is there any other advice you can give me?
>> 
>> Thanks,
>> 
>> Konstantin
>> 
>> 
>> 
>> 
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-03 Thread Nate Temple via USRP-users

Hi Konstantin,

When operating in bridged mode, did you manually set the (static) IP address 
within your VM? 

Regards,
Nate Temple

> On Aug 3, 2017, at 11:27 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
> 
> As soon I put it into bridged mode, nothing works..  What I mean is that I am 
> not able to communicate/ping to the E310 that way.
> 
> It may work maybe for other VM software, but again, I am using Oracle 
> VirtualBox.
> 
> Thanks
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Thursday, August 03, 2017 1:37 PM
> To: Philip Balister 
> Cc: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> You may want to try putting your VM into a Bridge Network mode. There may be 
> an issue with the NAT routing. If operating in Bridged mode, ensure your 
> Host, VM and E3xx all have different IP addresses.
> 
> Regards,
> Nate Temple
> 
> 
> 
>> On Aug 3, 2017, at 9:39 AM, Philip Balister via USRP-users 
>>  wrote:
>> 
>> On 08/03/2017 11:07 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC] via USRP-users wrote:
>>> Hello All,
>>> 
>>> I have the E310 hooked up with an Ethernet wire, and I can ping from my 
>>> Linux Ubuntu Virtual machine (created by Oracle VirtualBox software).
>>> 
>>> But when I try to SSH, I did get access denied.. until I added a  VM rule 
>>> for port 22 in Network Settings of the VM.
>>> 
>>> But now I get the password message in the Linux terminal to place a 
>>> password.  As we know, the password is empty per the instructions on the 
>>> website.
>> 
>> Did you hit return to see if it gave you a prompt?
>> 
>> Philip
>> 
>>> 
>>> So I went into ssh_config file in Linux at ect/ssh and altered a line 
>>> that allows for no passwords... This is the site.. 
>>> http://developer.toradex.com/knowledge-base/ssh
>>> 
>>> But I am still not getting past the password login.
>>> 
>>> Is there any other advice you can give me?
>>> 
>>> Thanks,
>>> 
>>> Konstantin
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> 
>> 
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 


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

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-03 Thread Nate Temple via USRP-users

Hi Konstantin,

After setting the NIC to be Bridged for the VM from VirtualBox, you need to 
start the VM, then within the System Settings -> Network of the VM, manually 
set the NIC to have a static IP address. 

Regards,
Nate Temple


> On Aug 3, 2017, at 11:50 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> The Software does not allow me to do that.. Here is a screen shot..  This is 
> all that it offers…
>  
> 
>  
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Thursday, August 03, 2017 2:48 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> Hi Konstantin,
>  
> When operating in bridged mode, did you manually set the (static) IP address 
> within your VM?
>  
> Regards,
> Nate Temple
>  
> > On Aug 3, 2017, at 11:27 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> > TECHNOLOGIES INC]  wrote:
> > 
> > Nate,
> > 
> > As soon I put it into bridged mode, nothing works..  What I mean is that I 
> > am not able to communicate/ping to the E310 that way.
> > 
> > It may work maybe for other VM software, but again, I am using Oracle 
> > VirtualBox.
> > 
> > Thanks
> > 
> > -Original Message-
> > From: Nate Temple [mailto:nate.tem...@ettus.com]
> > Sent: Thursday, August 03, 2017 1:37 PM
> > To: Philip Balister 
> > Cc: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
> > ; usrp-users@lists.ettus.com
> > Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password
> > Issue
> > 
> > Hi Konstantin,
> > 
> > You may want to try putting your VM into a Bridge Network mode. There may 
> > be an issue with the NAT routing. If operating in Bridged mode, ensure your 
> > Host, VM and E3xx all have different IP addresses.
> > 
> > Regards,
> > Nate Temple
> > 
> > 
> > 
> >> On Aug 3, 2017, at 9:39 AM, Philip Balister via USRP-users 
> >>  wrote:
> >> 
> >> On 08/03/2017 11:07 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
> >> TECHNOLOGIES INC] via USRP-users wrote:
> >>> Hello All,
> >>> 
> >>> I have the E310 hooked up with an Ethernet wire, and I can ping from my 
> >>> Linux Ubuntu Virtual machine (created by Oracle VirtualBox software).
> >>> 
> >>> But when I try to SSH, I did get access denied.. until I added a  VM rule 
> >>> for port 22 in Network Settings of the VM.
> >>> 
> >>> But now I get the password message in the Linux terminal to place a 
> >>> password.  As we know, the password is empty per the instructions on the 
> >>> website.
> >> 
> >> Did you hit return to see if it gave you a prompt?
> >> 
> >> Philip
> >> 
> >>> 
> >>> So I went into ssh_config file in Linux at ect/ssh and altered a
> >>> line that allows for no passwords... This is the site..
> >>> http://developer.toradex.com/knowledge-base/ssh
> >>> 
> >>> But I am still not getting past the password login.
> >>> 
> >>> Is there any other advice you can give me?
> >>> 
> >>> Thanks,
> >>> 
> >>> Konstantin
> >>> 
> >>> 
> >>> 
> >>> 
> >>> ___
> >>> USRP-users mailing list
> >>> USRP-users@lists.ettus.com
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>> 
> >> 
> >> ___
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > 


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

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-03 Thread Nate Temple via USRP-users

Hi Konstantin,

You can try connecting via the Serial port [1]. I would suggest to first try 
undoing any changes you have made to the ssh_config. By default it will not 
require any passwords.

If that is not successful, I would suggest downloading a fresh release-4 image 
from [2] and writing it to the SD Card. The SD Card section [3] of the Ettus KB 
will detail which image you need based on your device serial number.

[1] - 
https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Getting_Started_Guides#Serial_Console_Connectivity
[2] - http://files.ettus.com/e3xx_images/
[3] - 
https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources#SD_Card_Images

Regards,
Nate Temple


> On Aug 3, 2017, at 12:06 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> OK.. I did it your way and I am connecting via ping your way now too
> 
> Bu again, when I do the ssh command, it is asking for a password.
> 
> So, I am getting the samething as I was before...
> 
> Does ssh have to be setup on the E310???
> 
> Is there a way to check/reset the password on the E310?
> 
> Thanks
> 
> 
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Thursday, August 03, 2017 2:54 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> After setting the NIC to be Bridged for the VM from VirtualBox, you need to 
> start the VM, then within the System Settings -> Network of the VM, manually 
> set the NIC to have a static IP address. 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 3, 2017, at 11:50 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> The Software does not allow me to do that.. Here is a screen shot..  
>> This is all that it offers…
>> 
>> 
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>> Sent: Thursday, August 03, 2017 2:48 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Philip Balister ; usrp-users@lists.ettus.com
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password 
>> Issue
>> 
>> Hi Konstantin,
>> 
>> When operating in bridged mode, did you manually set the (static) IP address 
>> within your VM?
>> 
>> Regards,
>> Nate Temple
>> 
>>> On Aug 3, 2017, at 11:27 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Nate,
>>> 
>>> As soon I put it into bridged mode, nothing works..  What I mean is that I 
>>> am not able to communicate/ping to the E310 that way.
>>> 
>>> It may work maybe for other VM software, but again, I am using Oracle 
>>> VirtualBox.
>>> 
>>> Thanks
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>>> Sent: Thursday, August 03, 2017 1:37 PM
>>> To: Philip Balister 
>>> Cc: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> ; usrp-users@lists.ettus.com
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password 
>>> Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> You may want to try putting your VM into a Bridge Network mode. There may 
>>> be an issue with the NAT routing. If operating in Bridged mode, ensure your 
>>> Host, VM and E3xx all have different IP addresses.
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
>>> 
 On Aug 3, 2017, at 9:39 AM, Philip Balister via USRP-users 
  wrote:
 
 On 08/03/2017 11:07 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC] via USRP-users wrote:
> Hello All,
> 
> I have the E310 hooked up with an Ethernet wire, and I can ping from my 
> Linux Ubuntu Virtual machine (created by Oracle VirtualBox software).
> 
> But when I try to SSH, I did get access denied.. until I added a  VM rule 
> for port 22 in Network Settings of the VM.
> 
> But now I get the password message in the Linux terminal to place a 
> password.  As we know, the password is empty per the instructions on the 
> website.
 
 Did you hit return to see if it gave you a prompt?
 
 Philip
 
> 
> So I went into ssh_config file in Linux at ect/ssh and altered a 
> line that allows for no passwords... This is the site..
> http://developer.toradex.com/knowledge-base/ssh
> 
> But I am still not getting past the password login.
> 
> Is there any other advice you can give me?
> 
> Thanks,
> 
> Konstantin
> 
> 
> 
> 
> ___
> 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] When ssh'ing Getting prompt for Password Issue

2017-08-03 Thread Nate Temple via USRP-users

Hi Konstantin,

Yes, I suspect there may be an issue with a configuration or change to the SSH 
configs on your current image. Starting with a fresh release-4 image should 
resolve the issue.


Regards,
Nate Temple


> On Aug 3, 2017, at 12:17 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,  Thanks for all the info..
> 
> I just want to refresh your memory that I was able to connect via serial 
> port...  Only root was needed and no password was needed... so that worked 
> fine.. because this is how I altered the IP address of the E310.
> 
> So with that stated, should I just jump t refreshing the SD card - step 2?
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Thursday, August 03, 2017 3:14 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> You can try connecting via the Serial port [1]. I would suggest to first try 
> undoing any changes you have made to the ssh_config. By default it will not 
> require any passwords.
> 
> If that is not successful, I would suggest downloading a fresh release-4 
> image from [2] and writing it to the SD Card. The SD Card section [3] of the 
> Ettus KB will detail which image you need based on your device serial number.
> 
> [1] - 
> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Getting_Started_Guides#Serial_Console_Connectivity
> [2] - http://files.ettus.com/e3xx_images/
> [3] - 
> https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources#SD_Card_Images
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 3, 2017, at 12:06 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> OK.. I did it your way and I am connecting via ping your way now too
>> 
>> Bu again, when I do the ssh command, it is asking for a password.
>> 
>> So, I am getting the samething as I was before...
>> 
>> Does ssh have to be setup on the E310???
>> 
>> Is there a way to check/reset the password on the E310?
>> 
>> Thanks
>> 
>> 
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>> Sent: Thursday, August 03, 2017 2:54 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Philip Balister ; usrp-users@lists.ettus.com
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password 
>> Issue
>> 
>> Hi Konstantin,
>> 
>> After setting the NIC to be Bridged for the VM from VirtualBox, you need to 
>> start the VM, then within the System Settings -> Network of the VM, manually 
>> set the NIC to have a static IP address. 
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 3, 2017, at 11:50 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> The Software does not allow me to do that.. Here is a screen shot..  
>>> This is all that it offers…
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>>> Sent: Thursday, August 03, 2017 2:48 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Philip Balister ; usrp-users@lists.ettus.com
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password 
>>> Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> When operating in bridged mode, did you manually set the (static) IP 
>>> address within your VM?
>>> 
>>> Regards,
>>> Nate Temple
>>> 
 On Aug 3, 2017, at 11:27 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Nate,
 
 As soon I put it into bridged mode, nothing works..  What I mean is that I 
 am not able to communicate/ping to the E310 that way.
 
 It may work maybe for other VM software, but again, I am using Oracle 
 VirtualBox.
 
 Thanks
 
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com]
 Sent: Thursday, August 03, 2017 1:37 PM
 To: Philip Balister 
 Cc: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 ; usrp-users@lists.ettus.com
 Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password 
 Issue
 
 Hi Konstantin,
 
 You may want to try putting your VM into a Bridge Network mode. There may 
 be an issue with the NAT routing. If operating in Bridged mode, ensure 
 your Host, VM and E3xx all have different IP addresses.
 
 Regards,
 Nate Temple
 
 
 
> On Aug 3, 2017, at 9:39 AM, Philip Balister via USRP-users 
>  wrote:
> 
> On 08/03/2017 11:07 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC] via USRP-users wrote:
>> Hello All,
>> 
>> I have the E310 hooked up with an Ethernet wire, and I can ping from my 
>> Linux Ubuntu Virtual machine (created by Oracle VirtualBox software).
>> 
>> But when I try to SSH, I did get access denied.. until I added a  VM

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-04 Thread Nate Temple via USRP-users

Hi Konstantin,

In regards to the page not showing instructions, please copy and paste the full 
links listed below. If you note within the screenshot you posted, you have the 
URL of:

"https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resource";

The full address is:

"https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources#SD_Card_Images";

In regards to the permission denied prompt that is being given in your terminal 
screenshot -- This is because the command that you are issuing 
"/etc/network/interfaces" is not valid. When you issue a command that is the 
path to a file such as that, the system is attempting to pass the file and 
execute it via the default shell (/bin/sh). I suspect you're attempting to edit 
the file, which can be done with the utility "vi", such as "vi 
/etc/network/interfaces". 

I would suggest starting with a fresh "release-4" image for the E310 at this 
point. 

You will need to download the .xz file of the release image for the speed grade 
of your device (details are in the link below for which SG you need based on 
the serial number), and then decompress it with a 7z (7zip) or other similar 
tool. You will then need to burn the image to the SD card, which can be done 
with WinDisk32Imager or the Linux utility "dd", or "bmaptool". 

The default setting for the "release-4" image will give the E310 a static IP 
address of 192.168.10.2. If you then put your VM NIC Settings into a Bridged 
Mode, and set a static IP Address within the VM to "192.168.1.3", you should be 
able to connect to the E310 with the root account and no password via SSH. 


https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Getting_Started_Guides#Serial_Console_Connectivity
http://files.ettus.com/e3xx_images/
https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources#SD_Card_Images



Regards,
Nate Temple



> On Aug 4, 2017, at 9:29 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
>  
> I am close to returning this unit.
>  
> I feel that I am doing everything correctly…
>  
> 1)  I setup the IP static address correctly in the interfaces via the 
> serial cable – proof that I can ping to it from both Linux and Windows
> 2)  I double checked both sshd_config files in E310 and Linux VM OS – 
> both have the permission parameter to have no password for login.
> 3)  VM is in network bridged mode too, as you suggested.
>  
> When I hookup the Ethernet, I am able to ping, but when I do the ssh command 
> to login, I am still getting the permission denied.
>  
> Please tell me any last items to double check before I return the unit, or if 
> I can get someone on the phone to assist me with this issue.
>  
> Thanks,
>  
> Konstantin 
>  
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Sent: Friday, August 04, 2017 10:11 AM
> To: 'Nate Temple' 
> Cc: 'Philip Balister' ; 'usrp-users@lists.ettus.com' 
> 
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> I did the following instructions on the Linux VM, not the E310….  Or did I 
> need to do it to both of them…
>  
> Right now, I going to retract the VM interfaces alteration I did.
>  
> These are the instructions I am referring to…
>  
> https://files.ettus.com/manual/page_usrp_e3x0.html#e3xx_network_configuration
>  
>  
>  
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Sent: Friday, August 04, 2017 10:07 AM
> To: 'Nate Temple' 
> Cc: 'Philip Balister' ; 'usrp-users@lists.ettus.com' 
> 
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> Nate,
>  
> I think I know what the issue is…
>  
> Unfortunately, I have tried so many permutations of fixes, I think I never 
> updated the E310’s IP address..
>  
> I hooked up the serial way and wanted to double check if I updated the E310’s 
> IP address…
>  
> When I tried to get to the following directory, as directed by the website 
> page,  I received permission denied…
>  
> What is the issue?
>  
> Thanks
>  
> 
>  
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Sent: Friday, August 04, 2017 9:07 AM
> To: 'Nate Temple' 
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> Nate,
>  
> I went to start to redo the SD card and the 3rd link gave no instructions.  
> Here is the screen shot.
>  
> Btw,  I received a second SD card with the purchase of the E310.  I plugged 
> that in and it did not work. 
>  
> Are you sure I need to redo the card?  Or is there an SSH setup on the E310 I 
> may need to do?
>  
> Thanks
>  
>  
> 
>  
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Thursday, August 03, 2017 3:24 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Philip Balister ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

Can you please send the full part number and serial number for your device. It 
is located on the label on the bottom side of the E3xx. ( "P/N: XX", "S/N: 
XXX" )

Regards,
Nate Temple


> On Aug 8, 2017, at 8:33 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> OK…  Used the backup microSD we ordered.  Reprogrammed it with the same 
> .direct file…  Same error as below…
>  
> “Unable to read file uImage-zynq-e31x-3.dtb”
>  
> Now, either I am loading a incorrect image, or something is not working 
> correctly with the unit.
>  
> Please tell me your thoughts…
>  
> Thanks…
>  
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Sent: Tuesday, August 08, 2017 11:29 AM
> To: 'Nate Temple' ; 'Marcus Müller' 
> 
> Cc: 'usrp-users' 
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> Btw.. just to validate what image I used…
>  
> I have the E310 E version…
>  
> The instructions I think may not be correct…  Here they are cut and paste…  
> Please validate….
>  
> For the E310, the product number will be 156333X-01L, where X is a letter 
> from A to Z. For devices where X is A, B, C, D, the images under the 
> "ettus-e3xx-sg1" folder should be used. For devices where X is E or later, 
> the images under the "ettus-e3xx-sg3" folder should be used. (WHAT I USED) 
> You must use the appropriate image for your specific device. The incorrect 
> image will not work, and will only boot as far as the U-Boot boot loader 
> before stopping.
> 
>  
> 
> BUT this is what is written also…
> 
>  
> 
> For the E312, the product number will be 140605X-01L, where X is a letter 
> from A to Z. The images under the "ettus-e3xx-sg3" folder should be used for 
> all E312 devices.
> 
>  
> So you told me to go to release 4 (also the directions did)…  and then I 
> chose the sg3 directory – Is this correct???  Thus, both the E310 E and E312 
> devices use the sg3 directory
>  
> I used the Ettus-3xx-sg3 directory and downloaded those versions.  I am 
> assuming they are the correct versions.
>  
> Thanks…
>  
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Sent: Tuesday, August 08, 2017 11:15 AM
> To: 'Nate Temple' ; Marcus Müller 
> 
> Cc: usrp-users 
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> Nate,
>  
> The instructions are very well written and detailed.. Thanks…
>  
> Actually, most of the steps I was doing correctly from all the various 
> portions of documents.  But it is good you placed all in one document.  
> Thanks…
>  
> Everything worked well up until I burned the image. 
>  
> When I did the terminal  command - sudo screen /dev/ttyUSB0 115200 – and then 
> turned on the E310, I received “Unable to read file uImage-zynq-e31x-3.dtb”
>  
> I tried both tx version – demo and dev…  Both did the same thing…
>  
> I have another SD card that we ordered with the unit.  I will try to re-image 
> that card and see hwat happens…  Of course, I will let you know.
>  
> Thanks,
>  
> Konstantin
>  
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Monday, August 07, 2017 9:29 PM
> To: Marcus Müller 
> Cc: usrp-users ; Matheou, Konstantin J. 
> (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> Hi Konstantin,
> 
> Please see the updated version of the PDF, attached to this email. One of the 
> screen captures needed to be updated.
> 
> Regards,
> Nate Temple
> 
> 
> 
> 
> Previous message
> ---
> Hi Konstantin,
> 
> I had an error in my previous email. The default setting for the release-4 
> image is to have a DHCP address. You'll need to edit /etc/network/interfaces 
> and update it to operate with a static IP.
> 
> Please see the attached PDF that will walk through the process of burning the 
> release-4 SD Card image to a blank SD Card, and then the required steps to 
> configure the Ubuntu VM within the Windows host to connect via the Serial 
> interface to update the /etc/network/interfaces file, and then connect via 
> SSH.
> 
> Also, with 1GbE connections, you do not need to use a cross over cable. 1GbE 
> has auto-MDIX which will allow a normal straight through ethernet cable to be 
> used when directly connecting devices. 
> 
> Regards,
> Nate Temple
> ---


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

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

I don't suspect that there is any issue at all with the hardware. It is most 
likely due to the image or partition table on the SD card not being setup 
correctly. 

Can you please open the Disk Management program within Windows and with the SD 
card inserted, take a screen capture of the partition layout for the SD Card?

Regards,
Nate Temple

> On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
> 
> I also tried release 4 sg1 directory dev.direct file...  same error as 
> below...
> 
> I also tried release 3 dev.direct...  Was able to log in through root... made 
> the vi alterations to the interfaces file...  but was unable to ping...
> 
> Here is the E310 info:
> 
> P/N 156333E-01L
> 
> S/N 8117FF1
> 
> How soon can I get another E310 shipped to me???  Unfortunately, I need to 
> have a design ready for my project by early September.  I really need a 
> replacement pretty fast, if possible?
> 
> Thanks,
> 
> Konstantin
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 1:21 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Can you please send the full part number and serial number for your device. 
> It is located on the label on the bottom side of the E3xx. ( "P/N: XX", 
> "S/N: XXX" )
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 8:33 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> OK…  Used the backup microSD we ordered.  Reprogrammed it with the same 
>> .direct file…  Same error as below…
>> 
>> “Unable to read file uImage-zynq-e31x-3.dtb”
>> 
>> Now, either I am loading a incorrect image, or something is not working 
>> correctly with the unit.
>> 
>> Please tell me your thoughts…
>> 
>> Thanks…
>> 
>> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> Sent: Tuesday, August 08, 2017 11:29 AM
>> To: 'Nate Temple' ; 'Marcus Müller' 
>> 
>> Cc: 'usrp-users' 
>> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Btw.. just to validate what image I used…
>> 
>> I have the E310 E version…
>> 
>> The instructions I think may not be correct…  Here they are cut and paste…  
>> Please validate….
>> 
>> For the E310, the product number will be 156333X-01L, where X is a letter 
>> from A to Z. For devices where X is A, B, C, D, the images under the 
>> "ettus-e3xx-sg1" folder should be used. For devices where X is E or later, 
>> the images under the "ettus-e3xx-sg3" folder should be used. (WHAT I USED) 
>> You must use the appropriate image for your specific device. The incorrect 
>> image will not work, and will only boot as far as the U-Boot boot loader 
>> before stopping.
>> 
>> 
>> 
>> BUT this is what is written also…
>> 
>> 
>> 
>> For the E312, the product number will be 140605X-01L, where X is a letter 
>> from A to Z. The images under the "ettus-e3xx-sg3" folder should be used for 
>> all E312 devices.
>> 
>> 
>> So you told me to go to release 4 (also the directions did)…  and then I 
>> chose the sg3 directory – Is this correct???  Thus, both the E310 E and E312 
>> devices use the sg3 directory
>> 
>> I used the Ettus-3xx-sg3 directory and downloaded those versions.  I am 
>> assuming they are the correct versions.
>> 
>> Thanks…
>> 
>> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> Sent: Tuesday, August 08, 2017 11:15 AM
>> To: 'Nate Temple' ; Marcus Müller 
>> 
>> Cc: usrp-users 
>> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Nate,
>> 
>> The instructions are very well written and detailed.. Thanks…
>> 
>> Actually, most of the steps I was doing correctly from all the various 
>> portions of documents.  But it is good you placed all in one document.  
>> Thanks…
>> 
>> Everything worked well up until I burned the image. 
>> 
>> When I did the terminal  command - sudo screen /dev/ttyUSB0 115200 – and 
>> then turned on the E310, I received “Unable to read file 
>> uImage-zynq-e31x-3.dtb”
>> 
>> I tried both tx version – demo and dev…  Both did the same thing…
>> 
>> I have another SD card that we ordered with the unit.  I will try to 
>> re-image that card and see hwat happens…  Of course, I will let you know.
>> 
>> Thanks,
>> 
>> Konstantin
>> 
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Monday, August 07, 2017 9:29 PM
>> To: Marcus Müller 
>> Cc: usrp-users ; Matheou, Konstantin J. 
>> (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> Please see the updated version of the PDF, attached to this email. One of 
>> the screen captures needed to be updated.
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>> 
>> 
>> Previous message
>> ---

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

The partition table looks like it is OK.

I would suggest trying to redownload the release-4 / SpeedGrade3 images again 
and try burning them to the SD Card again. Verify that the md5sums match what 
is posted in the SG3/ folder. 

The error you're seeing has only came up when the incorrect SpeedGrade image is 
used.

Regards,
Nate Temple




> On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
>  
> I hope there is no issue with the hardware... OK.. we are now in debug mode I 
> guess...  I hope you can hang out a little quicker with me to get this 
> resolved...  I appreciate it...
>  
> Below is the Disk Management program screen shot and I placed the files that 
> got placed on the micro SD card  Again it was the file from 
> release4/...sg3/ - again I have the E310 E.
>  
> This is the backup micro SD card….  And the micro SD card that came with the 
> unit (visually checked) looked exactly the same….
>  
> 
>  
>  
>  
>  
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 2:35 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>  
> Hi Konstantin,
>  
> I don't suspect that there is any issue at all with the hardware. It is most 
> likely due to the image or partition table on the SD card not being setup 
> correctly.
>  
> Can you please open the Disk Management program within Windows and with the 
> SD card inserted, take a screen capture of the partition layout for the SD 
> Card?
>  
> Regards,
> Nate Temple
>  
> > On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> > TECHNOLOGIES INC]  wrote:
> > 
> > Nate,
> > 
> > I also tried release 4 sg1 directory dev.direct file...  same error as 
> > below...
> > 
> > I also tried release 3 dev.direct...  Was able to log in through root... 
> > made the vi alterations to the interfaces file...  but was unable to ping...
> > 
> > Here is the E310 info:
> > 
> > P/N 156333E-01L
> > 
> > S/N 8117FF1
> > 
> > How soon can I get another E310 shipped to me???  Unfortunately, I need to 
> > have a design ready for my project by early September.  I really need a 
> > replacement pretty fast, if possible?
> > 
> > Thanks,
> > 
> > Konstantin
> > 
> > -Original Message-
> > From: Nate Temple [mailto:nate.tem...@ettus.com]
> > Sent: Tuesday, August 08, 2017 1:21 PM
> > To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> > 
> > Cc: Marcus Müller ; usrp-users 
> > 
> > Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> > 
> > Hi Konstantin,
> > 
> > Can you please send the full part number and serial number for your device. 
> > It is located on the label on the bottom side of the E3xx. ( "P/N: XX", 
> > "S/N: XXX" )
> > 
> > Regards,
> > Nate Temple
> > 
> > 
> >> On Aug 8, 2017, at 8:33 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> >> TECHNOLOGIES INC]  wrote:
> >> 
> >> OK…  Used the backup microSD we ordered.  Reprogrammed it with the same 
> >> .direct file…  Same error as below…
> >> 
> >> “Unable to read file uImage-zynq-e31x-3.dtb”
> >> 
> >> Now, either I am loading a incorrect image, or something is not working 
> >> correctly with the unit.
> >> 
> >> Please tell me your thoughts…
> >> 
> >> Thanks…
> >> 
> >> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
> >> Sent: Tuesday, August 08, 2017 11:29 AM
> >> To: 'Nate Temple' ; 'Marcus Müller' 
> >> 
> >> Cc: 'usrp-users' 
> >> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
> >> 
> >> Btw.. just to validate what image I used…
> >> 
> >> I have the E310 E version…
> >> 
> >> The instructions I think may not be correct…  Here they are cut and paste… 
> >>  Please validate….
> >> 
> >> For the E310, the product number will be 156333X-01L, where X is a letter 
> >> from A to Z. For devices where X is A, B, C, D, the images under the 
> >> "ettus-e3xx-sg1" folder should be used. For devices where X is E or later, 
> >> the images under the "ettus-e3xx-sg3" folder should be used. (WHAT I USED) 
> >> You must use the appropriate image for your specific device. The incorrect 
> >> image will not work, and will only boot as far as the U-Boot boot loader 
> >> before stopping.
> >> 
> >> 
> >> 
> >> BUT this is what is written also…
> >> 
> >> 
> >> 
> >> For the E312, the product number will be 140605X-01L, where X is a letter 
> >> from A to Z. The images under the "ettus-e3xx-sg3" folder should be used 
> >> for all E312 devices.
> >> 
> >> 
> >> So you told me to go to release 4 (also the directions did)…  and then I 
> >> chose the sg3 directory – Is this correct???  Thus, both the E310 E and 
> >> E312 devices use the sg3 directory
> >> 
> >> I used the Ettus-3xx-sg3 directory and downloaded those versions.  I am 
> >> assuming they are

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

Also, looking up the serial number 8117FF1 didn't not result in any matches.

Can you please send a picture of the back label so we can clearly see the 
numbers on the label?


Regards,
Nate Temple




> On Aug 8, 2017, at 12:23 PM, Nate Temple  wrote:
> 
> Hi Konstantin,
> 
> The partition table looks like it is OK.
> 
> I would suggest trying to redownload the release-4 / SpeedGrade3 images again 
> and try burning them to the SD Card again. Verify that the md5sums match what 
> is posted in the SG3/ folder. 
> 
> The error you're seeing has only came up when the incorrect SpeedGrade image 
> is used.
> 
> Regards,
> Nate Temple
> 
> 
> 
> 
>> On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> Nate,
>> 
>> I hope there is no issue with the hardware... OK.. we are now in debug mode 
>> I guess...  I hope you can hang out a little quicker with me to get this 
>> resolved...  I appreciate it...
>> 
>> Below is the Disk Management program screen shot and I placed the files that 
>> got placed on the micro SD card  Again it was the file from 
>> release4/...sg3/ - again I have the E310 E.
>> 
>> This is the backup micro SD card….  And the micro SD card that came with the 
>> unit (visually checked) looked exactly the same….
>> 
>> 
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 2:35 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> I don't suspect that there is any issue at all with the hardware. It is most 
>> likely due to the image or partition table on the SD card not being setup 
>> correctly.
>> 
>> Can you please open the Disk Management program within Windows and with the 
>> SD card inserted, take a screen capture of the partition layout for the SD 
>> Card?
>> 
>> Regards,
>> Nate Temple
>> 
>>> On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Nate,
>>> 
>>> I also tried release 4 sg1 directory dev.direct file...  same error as 
>>> below...
>>> 
>>> I also tried release 3 dev.direct...  Was able to log in through root... 
>>> made the vi alterations to the interfaces file...  but was unable to ping...
>>> 
>>> Here is the E310 info:
>>> 
>>> P/N 156333E-01L
>>> 
>>> S/N 8117FF1
>>> 
>>> How soon can I get another E310 shipped to me???  Unfortunately, I need to 
>>> have a design ready for my project by early September.  I really need a 
>>> replacement pretty fast, if possible?
>>> 
>>> Thanks,
>>> 
>>> Konstantin
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>>> Sent: Tuesday, August 08, 2017 1:21 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> Can you please send the full part number and serial number for your device. 
>>> It is located on the label on the bottom side of the E3xx. ( "P/N: XX", 
>>> "S/N: XXX" )
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
 On Aug 8, 2017, at 8:33 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 OK…  Used the backup microSD we ordered.  Reprogrammed it with the same 
 .direct file…  Same error as below…
 
 “Unable to read file uImage-zynq-e31x-3.dtb”
 
 Now, either I am loading a incorrect image, or something is not working 
 correctly with the unit.
 
 Please tell me your thoughts…
 
 Thanks…
 
 From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
 Sent: Tuesday, August 08, 2017 11:29 AM
 To: 'Nate Temple' ; 'Marcus Müller' 
 
 Cc: 'usrp-users' 
 Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Btw.. just to validate what image I used…
 
 I have the E310 E version…
 
 The instructions I think may not be correct…  Here they are cut and paste… 
  Please validate….
 
 For the E310, the product number will be 156333X-01L, where X is a letter 
 from A to Z. For devices where X is A, B, C, D, the images under the 
 "ettus-e3xx-sg1" folder should be used. For devices where X is E or later, 
 the images under the "ettus-e3xx-sg3" folder should be used. (WHAT I USED) 
 You must use the appropriate image for your specific device. The incorrect 
 image will not work, and will only boot as far as the U-Boot boot loader 
 before stopping.
 
 
 
 BUT this is what is written also…
 
 
 
 For the E312, the product number will be 140605X-01L, where X is a letter 
 from A to Z. The images under the "ettus-e3xx-sg3" folder should be used 
 for al

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

Can you please attach the picture of the back label?

Regards,
Nate Temple


> On Aug 8, 2017, at 12:29 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> I am wearing my reading glasses and the letters were very small too...
> 
> I took the picture and zoomed in on it with my phone..
> 
> It is 3117FF1
> 
> 
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 3:25 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Also, looking up the serial number 8117FF1 didn't not result in any matches.
> 
> Can you please send a picture of the back label so we can clearly see the 
> numbers on the label?
> 
> 
> Regards,
> Nate Temple
> 
> 
> 
> 
>> On Aug 8, 2017, at 12:23 PM, Nate Temple  wrote:
>> 
>> Hi Konstantin,
>> 
>> The partition table looks like it is OK.
>> 
>> I would suggest trying to redownload the release-4 / SpeedGrade3 images 
>> again and try burning them to the SD Card again. Verify that the md5sums 
>> match what is posted in the SG3/ folder. 
>> 
>> The error you're seeing has only came up when the incorrect SpeedGrade image 
>> is used.
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>> 
>> 
>>> On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Nate,
>>> 
>>> I hope there is no issue with the hardware... OK.. we are now in debug mode 
>>> I guess...  I hope you can hang out a little quicker with me to get this 
>>> resolved...  I appreciate it...
>>> 
>>> Below is the Disk Management program screen shot and I placed the files 
>>> that got placed on the micro SD card  Again it was the file from 
>>> release4/...sg3/ - again I have the E310 E.
>>> 
>>> This is the backup micro SD card….  And the micro SD card that came with 
>>> the unit (visually checked) looked exactly the same….
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 2:35 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> I don't suspect that there is any issue at all with the hardware. It is 
>>> most likely due to the image or partition table on the SD card not being 
>>> setup correctly.
>>> 
>>> Can you please open the Disk Management program within Windows and with the 
>>> SD card inserted, take a screen capture of the partition layout for the SD 
>>> Card?
>>> 
>>> Regards,
>>> Nate Temple
>>> 
 On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Nate,
 
 I also tried release 4 sg1 directory dev.direct file...  same error as 
 below...
 
 I also tried release 3 dev.direct...  Was able to log in through root... 
 made the vi alterations to the interfaces file...  but was unable to 
 ping...
 
 Here is the E310 info:
 
 P/N 156333E-01L
 
 S/N 8117FF1
 
 How soon can I get another E310 shipped to me???  Unfortunately, I need to 
 have a design ready for my project by early September.  I really need a 
 replacement pretty fast, if possible?
 
 Thanks,
 
 Konstantin
 
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com]
 Sent: Tuesday, August 08, 2017 1:21 PM
 To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 
 Cc: Marcus Müller ; usrp-users 
 
 Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Hi Konstantin,
 
 Can you please send the full part number and serial number for your 
 device. It is located on the label on the bottom side of the E3xx. ( "P/N: 
 XX", "S/N: XXX" )
 
 Regards,
 Nate Temple
 
 
> On Aug 8, 2017, at 8:33 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> OK…  Used the backup microSD we ordered.  Reprogrammed it with the same 
> .direct file…  Same error as below…
> 
> “Unable to read file uImage-zynq-e31x-3.dtb”
> 
> Now, either I am loading a incorrect image, or something is not working 
> correctly with the unit.
> 
> Please tell me your thoughts…
> 
> Thanks…
> 
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
> Sent: Tuesday, August 08, 2017 11:29 AM
> To: 'Nate Temple' ; 'Marcus Müller' 
> 
> Cc: 'usrp-users' 
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Btw.. just to validate what image I used…
> 
> I have the E310 E version…
> 
> The instructions I th

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

Thank you for sending the image. It is indeed a SG3 E310. Please try 
downloading the release-4 / SG3 images again, verify the md5sum against the 
hashes provided in the same folder and try writing them again.


Regards,
Nate Temple


> On Aug 8, 2017, at 12:41 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Just sent it to you via my phone... Please tell me if you received it...
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 3:39 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Can you please attach the picture of the back label?
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 12:29 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> I am wearing my reading glasses and the letters were very small too...
>> 
>> I took the picture and zoomed in on it with my phone..
>> 
>> It is 3117FF1
>> 
>> 
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 3:25 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> Also, looking up the serial number 8117FF1 didn't not result in any matches.
>> 
>> Can you please send a picture of the back label so we can clearly see the 
>> numbers on the label?
>> 
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>> 
>> 
>>> On Aug 8, 2017, at 12:23 PM, Nate Temple  wrote:
>>> 
>>> Hi Konstantin,
>>> 
>>> The partition table looks like it is OK.
>>> 
>>> I would suggest trying to redownload the release-4 / SpeedGrade3 images 
>>> again and try burning them to the SD Card again. Verify that the md5sums 
>>> match what is posted in the SG3/ folder. 
>>> 
>>> The error you're seeing has only came up when the incorrect SpeedGrade 
>>> image is used.
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
>>> 
>>> 
 On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Nate,
 
 I hope there is no issue with the hardware... OK.. we are now in debug 
 mode I guess...  I hope you can hang out a little quicker with me to get 
 this resolved...  I appreciate it...
 
 Below is the Disk Management program screen shot and I placed the files 
 that got placed on the micro SD card  Again it was the file from 
 release4/...sg3/ - again I have the E310 E.
 
 This is the backup micro SD card….  And the micro SD card that came with 
 the unit (visually checked) looked exactly the same….
 
 
 
 
 
 
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com] 
 Sent: Tuesday, August 08, 2017 2:35 PM
 To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 
 Cc: Marcus Müller ; usrp-users 
 
 Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Hi Konstantin,
 
 I don't suspect that there is any issue at all with the hardware. It is 
 most likely due to the image or partition table on the SD card not being 
 setup correctly.
 
 Can you please open the Disk Management program within Windows and with 
 the SD card inserted, take a screen capture of the partition layout for 
 the SD Card?
 
 Regards,
 Nate Temple
 
> On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
> 
> I also tried release 4 sg1 directory dev.direct file...  same error as 
> below...
> 
> I also tried release 3 dev.direct...  Was able to log in through root... 
> made the vi alterations to the interfaces file...  but was unable to 
> ping...
> 
> Here is the E310 info:
> 
> P/N 156333E-01L
> 
> S/N 8117FF1
> 
> How soon can I get another E310 shipped to me???  Unfortunately, I need 
> to have a design ready for my project by early September.  I really need 
> a replacement pretty fast, if possible?
> 
> Thanks,
> 
> Konstantin
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com]
> Sent: Tuesday, August 08, 2017 1:21 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Can you please send the full part number and serial number for your 
> device. It is located on the label on the bottom side of the E3xx. ( 
> "P/N: XX", "S/N: XXX" )
> 
> Regards,
> Nate Temple

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

Please use 7zip to decompress the file. 

Details on calculating a md5sum via Windows can be found here: 
https://support.microsoft.com/en-us/help/889768/how-to-compute-the-md5-or-sha-1-cryptographic-hash-values-for-a-file

Regards,
Nate Temple


> On Aug 8, 2017, at 12:45 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Via WinZip7 I tested the newly downloaded file...  It stated no errors...  I 
> am using Windows to burn things  md5sums I think is only in Linux?
> 
> I am reburning as we speak...
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 3:24 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> The partition table looks like it is OK.
> 
> I would suggest trying to redownload the release-4 / SpeedGrade3 images again 
> and try burning them to the SD Card again. Verify that the md5sums match what 
> is posted in the SG3/ folder. 
> 
> The error you're seeing has only came up when the incorrect SpeedGrade image 
> is used.
> 
> Regards,
> Nate Temple
> 
> 
> 
> 
>> On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> Nate,
>> 
>> I hope there is no issue with the hardware... OK.. we are now in debug mode 
>> I guess...  I hope you can hang out a little quicker with me to get this 
>> resolved...  I appreciate it...
>> 
>> Below is the Disk Management program screen shot and I placed the files that 
>> got placed on the micro SD card  Again it was the file from 
>> release4/...sg3/ - again I have the E310 E.
>> 
>> This is the backup micro SD card….  And the micro SD card that came with the 
>> unit (visually checked) looked exactly the same….
>> 
>> 
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 2:35 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> I don't suspect that there is any issue at all with the hardware. It is most 
>> likely due to the image or partition table on the SD card not being setup 
>> correctly.
>> 
>> Can you please open the Disk Management program within Windows and with the 
>> SD card inserted, take a screen capture of the partition layout for the SD 
>> Card?
>> 
>> Regards,
>> Nate Temple
>> 
>>> On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Nate,
>>> 
>>> I also tried release 4 sg1 directory dev.direct file...  same error as 
>>> below...
>>> 
>>> I also tried release 3 dev.direct...  Was able to log in through root... 
>>> made the vi alterations to the interfaces file...  but was unable to ping...
>>> 
>>> Here is the E310 info:
>>> 
>>> P/N 156333E-01L
>>> 
>>> S/N 8117FF1
>>> 
>>> How soon can I get another E310 shipped to me???  Unfortunately, I need to 
>>> have a design ready for my project by early September.  I really need a 
>>> replacement pretty fast, if possible?
>>> 
>>> Thanks,
>>> 
>>> Konstantin
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>>> Sent: Tuesday, August 08, 2017 1:21 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> Can you please send the full part number and serial number for your device. 
>>> It is located on the label on the bottom side of the E3xx. ( "P/N: XX", 
>>> "S/N: XXX" )
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
 On Aug 8, 2017, at 8:33 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 OK…  Used the backup microSD we ordered.  Reprogrammed it with the same 
 .direct file…  Same error as below…
 
 “Unable to read file uImage-zynq-e31x-3.dtb”
 
 Now, either I am loading a incorrect image, or something is not working 
 correctly with the unit.
 
 Please tell me your thoughts…
 
 Thanks…
 
 From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
 Sent: Tuesday, August 08, 2017 11:29 AM
 To: 'Nate Temple' ; 'Marcus Müller' 
 
 Cc: 'usrp-users' 
 Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Btw.. just to validate what image I used…
 
 I have the E310 E version…
 
 The instructions I think may not be correct…  Here they are cut and paste… 
  Please validate….
 
 For the E310, the product number will be 156333X-01L, where X is a letter 
 from A to Z. For devices where X is A, B, C, D, the images under the 
 "

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

Thats good news.

Now you need to update the host identification for E31x, as it's fingerprint 
has changed.

Within the Linux VM, remove the file /home/user/.ssh/known_hosts with the 
commnad:

rm -v ~/.ssh/known_hosts

Then attempt to login again, you'll be prompted to verify the fingerprint, type 
"yes"., and you should then be logged into the E3xx.


Regards,
Nate Temple


> On Aug 8, 2017, at 1:15 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> OK  Good News...
> 
> Got all the way to the ping of the unit...
> 
> When I tried ssh'iing, I received a message stating - warning remote host 
> identification has changed...
> 
> Add correct host key
> 
> ECDSA host key fopr 192.168.10.2 has changed and you have requested strict 
> checking.
> 
> Host verification failed
> 
> What should I do now???
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 3:49 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Please use 7zip to decompress the file. 
> 
> Details on calculating a md5sum via Windows can be found here: 
> https://support.microsoft.com/en-us/help/889768/how-to-compute-the-md5-or-sha-1-cryptographic-hash-values-for-a-file
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 12:45 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> Via WinZip7 I tested the newly downloaded file...  It stated no errors...  I 
>> am using Windows to burn things  md5sums I think is only in Linux?
>> 
>> I am reburning as we speak...
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 3:24 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> The partition table looks like it is OK.
>> 
>> I would suggest trying to redownload the release-4 / SpeedGrade3 images 
>> again and try burning them to the SD Card again. Verify that the md5sums 
>> match what is posted in the SG3/ folder. 
>> 
>> The error you're seeing has only came up when the incorrect SpeedGrade image 
>> is used.
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>> 
>> 
>>> On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Nate,
>>> 
>>> I hope there is no issue with the hardware... OK.. we are now in debug mode 
>>> I guess...  I hope you can hang out a little quicker with me to get this 
>>> resolved...  I appreciate it...
>>> 
>>> Below is the Disk Management program screen shot and I placed the files 
>>> that got placed on the micro SD card  Again it was the file from 
>>> release4/...sg3/ - again I have the E310 E.
>>> 
>>> This is the backup micro SD card….  And the micro SD card that came with 
>>> the unit (visually checked) looked exactly the same….
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 2:35 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> I don't suspect that there is any issue at all with the hardware. It is 
>>> most likely due to the image or partition table on the SD card not being 
>>> setup correctly.
>>> 
>>> Can you please open the Disk Management program within Windows and with the 
>>> SD card inserted, take a screen capture of the partition layout for the SD 
>>> Card?
>>> 
>>> Regards,
>>> Nate Temple
>>> 
 On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Nate,
 
 I also tried release 4 sg1 directory dev.direct file...  same error as 
 below...
 
 I also tried release 3 dev.direct...  Was able to log in through root... 
 made the vi alterations to the interfaces file...  but was unable to 
 ping...
 
 Here is the E310 info:
 
 P/N 156333E-01L
 
 S/N 8117FF1
 
 How soon can I get another E310 shipped to me???  Unfortunately, I need to 
 have a design ready for my project by early September.  I really need a 
 replacement pretty fast, if possible?
 
 Thanks,
 
 Konstantin
 
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com]
 Sent: Tuesday, August 08, 2017 1:21 PM
 To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 
 Cc: Marcus Müller ; usrp-users 
 
 Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Hi Konstantin,
 
 Can you pleas

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

I would suggest trying to attach to the E310 via the serial connection and then 
issue a reboot command for it.

Verify all your settings are as they should be.


Regards,
Nate Temple


> On Aug 8, 2017, at 1:30 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> I will do this.. But I closed the VM and went back in and no the ping command 
> states the host is unreachable...
> 
> Confusing...
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 4:24 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Thats good news.
> 
> Now you need to update the host identification for E31x, as it's fingerprint 
> has changed.
> 
> Within the Linux VM, remove the file /home/user/.ssh/known_hosts with the 
> commnad:
> 
> rm -v ~/.ssh/known_hosts
> 
> Then attempt to login again, you'll be prompted to verify the fingerprint, 
> type "yes"., and you should then be logged into the E3xx.
> 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 1:15 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> OK  Good News...
>> 
>> Got all the way to the ping of the unit...
>> 
>> When I tried ssh'iing, I received a message stating - warning remote host 
>> identification has changed...
>> 
>> Add correct host key
>> 
>> ECDSA host key fopr 192.168.10.2 has changed and you have requested strict 
>> checking.
>> 
>> Host verification failed
>> 
>> What should I do now???
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 3:49 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> Please use 7zip to decompress the file. 
>> 
>> Details on calculating a md5sum via Windows can be found here: 
>> https://support.microsoft.com/en-us/help/889768/how-to-compute-the-md5-or-sha-1-cryptographic-hash-values-for-a-file
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 8, 2017, at 12:45 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Via WinZip7 I tested the newly downloaded file...  It stated no errors...  
>>> I am using Windows to burn things  md5sums I think is only in Linux?
>>> 
>>> I am reburning as we speak...
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 3:24 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> The partition table looks like it is OK.
>>> 
>>> I would suggest trying to redownload the release-4 / SpeedGrade3 images 
>>> again and try burning them to the SD Card again. Verify that the md5sums 
>>> match what is posted in the SG3/ folder. 
>>> 
>>> The error you're seeing has only came up when the incorrect SpeedGrade 
>>> image is used.
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
>>> 
>>> 
 On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Nate,
 
 I hope there is no issue with the hardware... OK.. we are now in debug 
 mode I guess...  I hope you can hang out a little quicker with me to get 
 this resolved...  I appreciate it...
 
 Below is the Disk Management program screen shot and I placed the files 
 that got placed on the micro SD card  Again it was the file from 
 release4/...sg3/ - again I have the E310 E.
 
 This is the backup micro SD card….  And the micro SD card that came with 
 the unit (visually checked) looked exactly the same….
 
 
 
 
 
 
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com] 
 Sent: Tuesday, August 08, 2017 2:35 PM
 To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 
 Cc: Marcus Müller ; usrp-users 
 
 Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Hi Konstantin,
 
 I don't suspect that there is any issue at all with the hardware. It is 
 most likely due to the image or partition table on the SD card not being 
 setup correctly.
 
 Can you please open the Disk Management program within Windows and with 
 the SD card inserted, take a screen capture of the partition layout for 
 the SD Card?
 
 Regards,
 Nate Temple
 
> On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
> 
> I also tried release 4 sg1 directory dev.direct file...  same error

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

It is fine to have the serial and ethernet connected at the same time. 

By manually power cycling the device, without a proper shutdown, it may have 
corrupted the SD card. 

I would suggest trying to re-image the SD card again, and go through the 
process as it had previously worked.

Regards,
Nate Temple


> On Aug 8, 2017, at 1:40 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> First off, per the instructions, I have both cables hooked up at the same 
> time  Should I remove the serial cable when ssh'ing?
> 
> I have been rebooting the hardware via the button, and once I get to the 
> login prompt, things are locking
> 
> And of course, I have been verifying the settings
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 4:35 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> I would suggest trying to attach to the E310 via the serial connection and 
> then issue a reboot command for it.
> 
> Verify all your settings are as they should be.
> 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 1:30 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> I will do this.. But I closed the VM and went back in and no the ping 
>> command states the host is unreachable...
>> 
>> Confusing...
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 4:24 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> Thats good news.
>> 
>> Now you need to update the host identification for E31x, as it's fingerprint 
>> has changed.
>> 
>> Within the Linux VM, remove the file /home/user/.ssh/known_hosts with the 
>> commnad:
>> 
>> rm -v ~/.ssh/known_hosts
>> 
>> Then attempt to login again, you'll be prompted to verify the fingerprint, 
>> type "yes"., and you should then be logged into the E3xx.
>> 
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 8, 2017, at 1:15 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> OK  Good News...
>>> 
>>> Got all the way to the ping of the unit...
>>> 
>>> When I tried ssh'iing, I received a message stating - warning remote host 
>>> identification has changed...
>>> 
>>> Add correct host key
>>> 
>>> ECDSA host key fopr 192.168.10.2 has changed and you have requested strict 
>>> checking.
>>> 
>>> Host verification failed
>>> 
>>> What should I do now???
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 3:49 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> Please use 7zip to decompress the file. 
>>> 
>>> Details on calculating a md5sum via Windows can be found here: 
>>> https://support.microsoft.com/en-us/help/889768/how-to-compute-the-md5-or-sha-1-cryptographic-hash-values-for-a-file
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
 On Aug 8, 2017, at 12:45 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Via WinZip7 I tested the newly downloaded file...  It stated no errors...  
 I am using Windows to burn things  md5sums I think is only in Linux?
 
 I am reburning as we speak...
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com] 
 Sent: Tuesday, August 08, 2017 3:24 PM
 To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 
 Cc: Marcus Müller ; usrp-users 
 
 Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Hi Konstantin,
 
 The partition table looks like it is OK.
 
 I would suggest trying to redownload the release-4 / SpeedGrade3 images 
 again and try burning them to the SD Card again. Verify that the md5sums 
 match what is posted in the SG3/ folder. 
 
 The error you're seeing has only came up when the incorrect SpeedGrade 
 image is used.
 
 Regards,
 Nate Temple
 
 
 
 
> On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
> 
> I hope there is no issue with the hardware... OK.. we are now in debug 
> mode I guess...  I hope you can hang out a little quicker with me to get 
> this resolved...  I appreciate it...
> 
> Below is the Disk Management program screen shot and I placed the files 
> that got placed on the micro SD card  Again it was the file from 
>>

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

You should not need to edit the ssh_config at all.

If you attempt to SSH to the E310 from the Linux VM now, does it work?

What is the full output when you try to SSH to the E310?

Regards,
Nate Temple

> On Aug 8, 2017, at 1:52 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> I cannot find that specific file..  Is it somewhere else???
> 
> But I did find a file within the ssh directory called ssh_config where there 
> is a parameter called HashKnownHosts Yes.. do I have to do anything with that?
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 4:24 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Thats good news.
> 
> Now you need to update the host identification for E31x, as it's fingerprint 
> has changed.
> 
> Within the Linux VM, remove the file /home/user/.ssh/known_hosts with the 
> commnad:
> 
> rm -v ~/.ssh/known_hosts
> 
> Then attempt to login again, you'll be prompted to verify the fingerprint, 
> type "yes"., and you should then be logged into the E3xx.
> 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 1:15 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> OK  Good News...
>> 
>> Got all the way to the ping of the unit...
>> 
>> When I tried ssh'iing, I received a message stating - warning remote host 
>> identification has changed...
>> 
>> Add correct host key
>> 
>> ECDSA host key fopr 192.168.10.2 has changed and you have requested strict 
>> checking.
>> 
>> Host verification failed
>> 
>> What should I do now???
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 3:49 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> Please use 7zip to decompress the file. 
>> 
>> Details on calculating a md5sum via Windows can be found here: 
>> https://support.microsoft.com/en-us/help/889768/how-to-compute-the-md5-or-sha-1-cryptographic-hash-values-for-a-file
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 8, 2017, at 12:45 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Via WinZip7 I tested the newly downloaded file...  It stated no errors...  
>>> I am using Windows to burn things  md5sums I think is only in Linux?
>>> 
>>> I am reburning as we speak...
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 3:24 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> The partition table looks like it is OK.
>>> 
>>> I would suggest trying to redownload the release-4 / SpeedGrade3 images 
>>> again and try burning them to the SD Card again. Verify that the md5sums 
>>> match what is posted in the SG3/ folder. 
>>> 
>>> The error you're seeing has only came up when the incorrect SpeedGrade 
>>> image is used.
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
>>> 
>>> 
 On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Nate,
 
 I hope there is no issue with the hardware... OK.. we are now in debug 
 mode I guess...  I hope you can hang out a little quicker with me to get 
 this resolved...  I appreciate it...
 
 Below is the Disk Management program screen shot and I placed the files 
 that got placed on the micro SD card  Again it was the file from 
 release4/...sg3/ - again I have the E310 E.
 
 This is the backup micro SD card….  And the micro SD card that came with 
 the unit (visually checked) looked exactly the same….
 
 
 
 
 
 
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com] 
 Sent: Tuesday, August 08, 2017 2:35 PM
 To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 
 Cc: Marcus Müller ; usrp-users 
 
 Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
 
 Hi Konstantin,
 
 I don't suspect that there is any issue at all with the hardware. It is 
 most likely due to the image or partition table on the SD card not being 
 setup correctly.
 
 Can you please open the Disk Management program within Windows and with 
 the SD card inserted, take a screen capture of the partition layout for 
 the SD Card?
 
 Regards,
 Nate Temple
 
> On Aug 8, 2017, at 11:16 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

This appears to now be an IP Address / conflict issue.

The user for the E310 is "root".

What is the IP address for your virtual machine? Please send the out of the 
command:

ip a


Regards,
Nate Temple


> On Aug 8, 2017, at 2:01 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> The error I get is - Permission Denied (publickey, password, 
> keyboard-interactive)
> 
> -Original Message-
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Sent: Tuesday, August 08, 2017 4:59 PM
> To: 'Nate Temple' 
> Cc: 'Marcus Müller' ; 'usrp-users' 
> 
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Sorry Nate... It seems the file was hidden.. I removed it...
> 
> I redid the ssh command and typed yes when asksed..
> 
> Then it asked for a password, and just hit enter... but it did not let me 
> in.
> 
> Actually, the name on the command is kmatheou@192.168.10.2 not 
> root@192.168.10.2  kmatheou is the name of my VM...
> 
> 
> 
> -Original Message-
> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> Sent: Tuesday, August 08, 2017 4:52 PM
> To: 'Nate Temple' 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> I cannot find that specific file..  Is it somewhere else???
> 
> But I did find a file within the ssh directory called ssh_config where there 
> is a parameter called HashKnownHosts Yes.. do I have to do anything with that?
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 4:24 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> Thats good news.
> 
> Now you need to update the host identification for E31x, as it's fingerprint 
> has changed.
> 
> Within the Linux VM, remove the file /home/user/.ssh/known_hosts with the 
> commnad:
> 
> rm -v ~/.ssh/known_hosts
> 
> Then attempt to login again, you'll be prompted to verify the fingerprint, 
> type "yes"., and you should then be logged into the E3xx.
> 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 1:15 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> OK  Good News...
>> 
>> Got all the way to the ping of the unit...
>> 
>> When I tried ssh'iing, I received a message stating - warning remote host 
>> identification has changed...
>> 
>> Add correct host key
>> 
>> ECDSA host key fopr 192.168.10.2 has changed and you have requested strict 
>> checking.
>> 
>> Host verification failed
>> 
>> What should I do now???
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 3:49 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> Please use 7zip to decompress the file. 
>> 
>> Details on calculating a md5sum via Windows can be found here: 
>> https://support.microsoft.com/en-us/help/889768/how-to-compute-the-md5-or-sha-1-cryptographic-hash-values-for-a-file
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 8, 2017, at 12:45 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> Via WinZip7 I tested the newly downloaded file...  It stated no errors...  
>>> I am using Windows to burn things  md5sums I think is only in Linux?
>>> 
>>> I am reburning as we speak...
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 3:24 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> The partition table looks like it is OK.
>>> 
>>> I would suggest trying to redownload the release-4 / SpeedGrade3 images 
>>> again and try burning them to the SD Card again. Verify that the md5sums 
>>> match what is posted in the SG3/ folder. 
>>> 
>>> The error you're seeing has only came up when the incorrect SpeedGrade 
>>> image is used.
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
>>> 
>>> 
 On Aug 8, 2017, at 11:59 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Nate,
 
 I hope there is no issue with the hardware... OK.. we are now in debug 
 mode I guess...  I hope you can hang out a little quicker with me to get 
 this resolved...  I appreciate it...
 
 Below is the Disk Management program screen shot and I placed the files 
 that got placed on the micro SD card  Again it was the file from 
 release4/...sg3/ - again I have the E310 E.
 
 This is the backup micro SD card….  And t

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

I don't understand why you're trying to use the username kmatheou when 
connecting to the E310.

The user on the E310 is "root". You need to issue the command *from the Linux 
VM* to the E310, "ssh root@192.168.10.2".




Regards,
Nate Temple


> On Aug 8, 2017, at 2:12 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> I think we are almost there
> 
> The Ip address for the VM is what was stated in the document 192.168.10.1 and 
> 24 for mask
> 
> I did the ip a command and retried the sh command.. still got 
> kmatheou@192.168.10.2
> 
> Do I need to alter the VM to another value and not the host of .1???
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 5:07 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> This appears to now be an IP Address / conflict issue.
> 
> The user for the E310 is "root".
> 
> What is the IP address for your virtual machine? Please send the out of the 
> command:
> 
> ip a
> 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 2:01 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> The error I get is - Permission Denied (publickey, password, 
>> keyboard-interactive)
>> 
>> -Original Message-
>> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> Sent: Tuesday, August 08, 2017 4:59 PM
>> To: 'Nate Temple' 
>> Cc: 'Marcus Müller' ; 'usrp-users' 
>> 
>> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Sorry Nate... It seems the file was hidden.. I removed it...
>> 
>> I redid the ssh command and typed yes when asksed..
>> 
>> Then it asked for a password, and just hit enter... but it did not let me 
>> in.
>> 
>> Actually, the name on the command is kmatheou@192.168.10.2 not 
>> root@192.168.10.2  kmatheou is the name of my VM...
>> 
>> 
>> 
>> -Original Message-
>> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> Sent: Tuesday, August 08, 2017 4:52 PM
>> To: 'Nate Temple' 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> I cannot find that specific file..  Is it somewhere else???
>> 
>> But I did find a file within the ssh directory called ssh_config where there 
>> is a parameter called HashKnownHosts Yes.. do I have to do anything with 
>> that?
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 4:24 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> Thats good news.
>> 
>> Now you need to update the host identification for E31x, as it's fingerprint 
>> has changed.
>> 
>> Within the Linux VM, remove the file /home/user/.ssh/known_hosts with the 
>> commnad:
>> 
>> rm -v ~/.ssh/known_hosts
>> 
>> Then attempt to login again, you'll be prompted to verify the fingerprint, 
>> type "yes"., and you should then be logged into the E3xx.
>> 
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 8, 2017, at 1:15 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> OK  Good News...
>>> 
>>> Got all the way to the ping of the unit...
>>> 
>>> When I tried ssh'iing, I received a message stating - warning remote host 
>>> identification has changed...
>>> 
>>> Add correct host key
>>> 
>>> ECDSA host key fopr 192.168.10.2 has changed and you have requested strict 
>>> checking.
>>> 
>>> Host verification failed
>>> 
>>> What should I do now???
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 3:49 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> Please use 7zip to decompress the file. 
>>> 
>>> Details on calculating a md5sum via Windows can be found here: 
>>> https://support.microsoft.com/en-us/help/889768/how-to-compute-the-md5-or-sha-1-cryptographic-hash-values-for-a-file
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
 On Aug 8, 2017, at 12:45 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 Via WinZip7 I tested the newly downloaded file...  It stated no errors...  
 I am using Windows to burn things  md5sums I think is only in Linux?
 
 I am reburning as we speak...
 -Original Message-
 From: Nate Temple [mailto:nate.tem...@ettus.com] 
 Sent: Tuesday, August 08, 2017 3:24 PM
 To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
 
 Cc: Marc

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

I think the issue now lays within some routing or networking issue between the 
E310 and the VirtualMachine.

Perhaps try turning off the firewall on your Windows host.

Test pinging the VM from the E310 when connected via serial connection.

Try pinging the E310 from the Windows host. 

This is now a networking issue. We typically don't recommend operating in a 
VirtualMachine, except for advanced users, as it adds another layer of 
complexity. You will need to try debugging what is going on. I suggest looking 
at each interface connected, via Wireshark in the VM, and also running 
Wireshark on the Windows host.



Regards,
Nate Temple


> On Aug 8, 2017, at 2:29 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate...  I rebooted the E310 by shutting it down via the software shutdown -h 
> now command...
> 
> When it came back up and I logged in as root..  When I tried pinging, it 
> stated the host is unreachable...
> 
> I di the ifdown and ifup and ip a and then the ping command again, and still 
> the same issue.
> 
> What do you think?
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 5:23 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> I don't understand why you're trying to use the username kmatheou when 
> connecting to the E310.
> 
> The user on the E310 is "root". You need to issue the command *from the Linux 
> VM* to the E310, "ssh root@192.168.10.2".
> 
> 
> 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 2:12 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> I think we are almost there
>> 
>> The Ip address for the VM is what was stated in the document 192.168.10.1 
>> and 24 for mask
>> 
>> I did the ip a command and retried the sh command.. still got 
>> kmatheou@192.168.10.2
>> 
>> Do I need to alter the VM to another value and not the host of .1???
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>> Sent: Tuesday, August 08, 2017 5:07 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>> 
>> Hi Konstantin,
>> 
>> This appears to now be an IP Address / conflict issue.
>> 
>> The user for the E310 is "root".
>> 
>> What is the IP address for your virtual machine? Please send the out of the 
>> command:
>> 
>> ip a
>> 
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 8, 2017, at 2:01 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> The error I get is - Permission Denied (publickey, password, 
>>> keyboard-interactive)
>>> 
>>> -Original Message-
>>> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> Sent: Tuesday, August 08, 2017 4:59 PM
>>> To: 'Nate Temple' 
>>> Cc: 'Marcus Müller' ; 'usrp-users' 
>>> 
>>> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Sorry Nate... It seems the file was hidden.. I removed it...
>>> 
>>> I redid the ssh command and typed yes when asksed..
>>> 
>>> Then it asked for a password, and just hit enter... but it did not let me 
>>> in.
>>> 
>>> Actually, the name on the command is kmatheou@192.168.10.2 not 
>>> root@192.168.10.2  kmatheou is the name of my VM...
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> Sent: Tuesday, August 08, 2017 4:52 PM
>>> To: 'Nate Temple' 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> I cannot find that specific file..  Is it somewhere else???
>>> 
>>> But I did find a file within the ssh directory called ssh_config where 
>>> there is a parameter called HashKnownHosts Yes.. do I have to do anything 
>>> with that?
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com] 
>>> Sent: Tuesday, August 08, 2017 4:24 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> Thats good news.
>>> 
>>> Now you need to update the host identification for E31x, as it's 
>>> fingerprint has changed.
>>> 
>>> Within the Linux VM, remove the file /home/user/.ssh/known_hosts with the 
>>> commnad:
>>> 
>>> rm -v ~/.ssh/known_hosts
>>> 
>>> Then attempt to login again, you'll be prompted to verify the fingerprint, 
>>> type "yes"., and you should then be logged into the E3xx.
>>> 
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
 On Aug 8, 2017, at 1:15 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
>>>

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

2017-08-08 Thread Nate Temple via USRP-users

Hi Konstantin,

Glad to hear that it is working.

There are several application notes in the Ettus Knowledge Base that cover 
working with the E310.

https://kb.ettus.com/Application_Notes


Regards,
Nate Temple


> On Aug 8, 2017, at 2:47 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
> TECHNOLOGIES INC]  wrote:
> 
> Nate,
> 
> Thanks for all of your help  
> 
> I had to undo and redo the Network Bridged Mode.. at least that is what I 
> think did it  I did so many other things too
> 
> I got the example working...
> 
> So, that means I got in via ssh and now I can start doing work by creating 
> files and sshing them and running them  Now to better learn how to do 
> this...
> 
> If you have any app notes or good examples specific for the E310, ,I would 
> appreciate any links.
> 
> Have a great night...
> 
> Konstantin
> 
> -Original Message-
> From: Nate Temple [mailto:nate.tem...@ettus.com] 
> Sent: Tuesday, August 08, 2017 5:43 PM
> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
> 
> Cc: Marcus Müller ; usrp-users 
> 
> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password Issue
> 
> Hi Konstantin,
> 
> I think the issue now lays within some routing or networking issue between 
> the E310 and the VirtualMachine.
> 
> Perhaps try turning off the firewall on your Windows host.
> 
> Test pinging the VM from the E310 when connected via serial connection.
> 
> Try pinging the E310 from the Windows host. 
> 
> This is now a networking issue. We typically don't recommend operating in a 
> VirtualMachine, except for advanced users, as it adds another layer of 
> complexity. You will need to try debugging what is going on. I suggest 
> looking at each interface connected, via Wireshark in the VM, and also 
> running Wireshark on the Windows host.
> 
> 
> 
> Regards,
> Nate Temple
> 
> 
>> On Aug 8, 2017, at 2:29 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC]  wrote:
>> 
>> Nate...  I rebooted the E310 by shutting it down via the software shutdown 
>> -h now command...
>> 
>> When it came back up and I logged in as root..  When I tried pinging, it 
>> stated the host is unreachable...
>> 
>> I di the ifdown and ifup and ip a and then the ping command again, and still 
>> the same issue.
>> 
>> What do you think?
>> 
>> -Original Message-
>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>> Sent: Tuesday, August 08, 2017 5:23 PM
>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>> 
>> Cc: Marcus Müller ; usrp-users 
>> 
>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password 
>> Issue
>> 
>> Hi Konstantin,
>> 
>> I don't understand why you're trying to use the username kmatheou when 
>> connecting to the E310.
>> 
>> The user on the E310 is "root". You need to issue the command *from the 
>> Linux VM* to the E310, "ssh root@192.168.10.2".
>> 
>> 
>> 
>> 
>> Regards,
>> Nate Temple
>> 
>> 
>>> On Aug 8, 2017, at 2:12 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>>> TECHNOLOGIES INC]  wrote:
>>> 
>>> I think we are almost there
>>> 
>>> The Ip address for the VM is what was stated in the document 192.168.10.1 
>>> and 24 for mask
>>> 
>>> I did the ip a command and retried the sh command.. still got 
>>> kmatheou@192.168.10.2
>>> 
>>> Do I need to alter the VM to another value and not the host of .1???
>>> 
>>> -Original Message-
>>> From: Nate Temple [mailto:nate.tem...@ettus.com]
>>> Sent: Tuesday, August 08, 2017 5:07 PM
>>> To: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] 
>>> 
>>> Cc: Marcus Müller ; usrp-users 
>>> 
>>> Subject: Re: [USRP-users] When ssh'ing Getting prompt for Password 
>>> Issue
>>> 
>>> Hi Konstantin,
>>> 
>>> This appears to now be an IP Address / conflict issue.
>>> 
>>> The user for the E310 is "root".
>>> 
>>> What is the IP address for your virtual machine? Please send the out of the 
>>> command:
>>> 
>>> ip a
>>> 
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
 On Aug 8, 2017, at 2:01 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
 TECHNOLOGIES INC]  wrote:
 
 The error I get is - Permission Denied (publickey, password, 
 keyboard-interactive)
 
 -Original Message-
 From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
 Sent: Tuesday, August 08, 2017 4:59 PM
 To: 'Nate Temple' 
 Cc: 'Marcus Müller' ; 'usrp-users' 
 
 Subject: RE: [USRP-users] When ssh'ing Getting prompt for Password 
 Issue
 
 Sorry Nate... It seems the file was hidden.. I removed it...
 
 I redid the ssh command and typed yes when asksed..
 
 Then it asked for a password, and just hit enter... but it did not let me 
 in.
 
 Actually, the name on the command is kmatheou@192.168.10.2 not 
 root@192.168.10.2  kmatheou is the name of my VM...
 
 
 
 -Original Message-
 From: Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]
 Sent: Tuesday, August 08

Re: [USRP-users] (no subject)

2017-08-09 Thread Nate Temple via USRP-users

Hi Masoud,

Please refrain from creating multiple threads on the same topic. [1][2][3]

Have you tried the suggestion that Marcus Leech suggested in your original 
post? [4] You're still posting with n_channel = 1, when it should be n_channel 
= 2;

[1] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/025991.html
[2] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/026030.html
[3] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/026031.html

[4] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/025898.html



Regards,
Nate Temple


> On Aug 9, 2017, at 12:03 PM, Masoud Naderpour via USRP-users 
>  wrote:
> 
> Hi,
> I have launched B210 USRP MIMO config. I have problem in transmission on both 
> Tx channels. However, there is no problem in receiving on both ones. In 
> transmission on both channels continous Underflows appear in console. It is 
> independent of the Tx sampling rate. How can I fix the problem?
> I have used the following code for initializing the uhd stream. 
> 
> size_t channel[2] = { 0,1 };;
> uhd_stream_args_t stream_args = {
> cpu_format = "fc32",
> otw_format = "sc16",
> args = "",
> channellist = channel,
> n_channel = 1
> };
> How can I fix the problem?
> ___
> 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] Dual Tx Transmission Problem

2017-08-09 Thread Nate Temple via USRP-users

Hi Masoud,

Please refrain from creating multiple threads on the same topic. [1][2][3]

Have you tried the suggestion that Marcus Leech suggested in your original 
post? [4] You're still operating with n_channel = 1, when it should be 
n_channel = 2;


[1] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/025991.html
[2] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/026030.html
[3] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/026031.html

[4] - 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/025898.html


Please use this thread for follow up on this issue.

Regards,
Nate Temple


> On Aug 9, 2017, at 12:04 PM, Masoud Naderpour via USRP-users 
>  wrote:
> 
> Hi,
> I have launched B210 USRP MIMO config. I have problem in transmission on both 
> Tx channels. However, there is no problem in receiving on both ones. In 
> transmission on both channels continous Underflows appear in console. It is 
> independent of the Tx sampling rate. How can I fix the problem?
> I have used the following code for initializing the uhd stream. 
> 
> size_t channel[2] = { 0,1 };;
> uhd_stream_args_t stream_args = {
> cpu_format = "fc32",
> otw_format = "sc16",
> args = "",
> channellist = channel,
> n_channel = 1
> };
> How can I fix the problem?
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] Fwd: B210, MIMO Tx Streaming Problem

2017-08-09 Thread Nate Temple via USRP-users

Duplicate thread - Please see this thread for responses -
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-August/026033.html

On Tue, Aug 8, 2017 at 12:30 PM, Masoud Naderpour via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
>
> Hi,
> I have launched B210 USRP MIMO config. I have problem in transmission on
> both Tx channels. However, there is no problem in receiving on both ones.
> In transmission on both channels continous Underflows appear in console. It
> is independent of the Tx sampling rate. How can I fix the problem?
> I have used the following code for initializing the uhd stream.
>
> size_t channel[2] = { 0,1 };;
> uhd_stream_args_t stream_args = {
> cpu_format = "fc32",
> otw_format = "sc16",
> args = "",
> channellist = channel,
> n_channel = 1
> };
> How can I fix the problem?
>
> ___
> 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] List of compatible parts

2017-08-15 Thread Nate Temple via USRP-users

Hi Daniel, Michael:

Generally there should be no compatibility issues. Where you may run into an 
issue with compatibility is if for example, you build UHD & GNU Radio, then 
switch the major version of UHD without rebuilding GNU Radio. This will cause 
an ABI mismatch, and GNU Radio needs to be rebuilt.  

Generally as long as you follow the order of building UHD -> GNU Radio, there 
should never be a mismatch issue. Keep in mind, unless you're installing to a 
local directory, and have a custom environment setup file, you'll want to 
remove any previous versions of UHD/GR before starting with a new install. 

Another point to note, you should not mix source installs of UHD/GR with 
package installations (apt-get, yum, dnf, etc) of UHD/GR. This will often cause 
headaches and difficult to diagnose problems. 

Now if you have a USRP such as a N2xx or X3xx, where the FPGA image is stored, 
if you switch versions of UHD that require a different FPGA version, you'll 
need to download (with uhd_images_downloader) new FPGA images and write them to 
the USRP EEPROM (with uhd_image_loader) once.

Below is a guide on installing UHD/GR from source on Linux and has been 
throughly tested against the operating systems listed within the app note. 

https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux


+Michael - I've attached a rough outline of instructions that cover installing 
OpenBTS I've put together which should get you started. These have been 
ran/tested on Ubuntu 14.04 and 16.04. If you're running Ubuntu 14.04, you don't 
need to perform the manual service starting at the end as Ubuntu 14.04 uses 
upstart. The manually starting of services is only required if you are using a 
version of Ubuntu which uses systemd.


Regards,
Nate Temple


 Update your system
sudo apt-get update
sudo apt-get upgrade

 Install Deps
sudo apt-get install libboost-all-dev libusb-1.0-0-dev python-mako doxygen 
python-docutils cmake build-essential libncurses5-dev libncurses5 python-dev 
python-requests ncurses-bin libncurses5-dbg libudev-dev git 

 Create working dir
mkdir ~/workarea
cd ~/workarea/

 Install UHD (skip if you already have UHD installed )
git clone https://github.com/EttusResearch/uhd
cd uhd/
git checkout release_003_009_006
cd host/
mkdir build
cd build/
cmake ..  
make -j3
sudo make install
sudo ldconfig

### Install UDEV Rules
cd ../utils/
sudo cp uhd-usrp.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger

### Create usrp group and add user
sudo addgroup usrp
sudo usermod -a -G usrp $USER

### Add rtprio line to limits.conf
sudo sh -c "echo '@usrp\t-\trtprio\t99' >> /etc/security/limits.conf"

### Log out and log back in

### Download UHD Images
sudo uhd_images_downloader 







 Clone OpenBTS build scripts
cd ~/workarea/
git clone https://github.com/RangeNetworks/dev.git
cd dev/

 Update build scripts to skip installing the repo UHD packages
sed -i 's/installIfMissing\ libuhd-dev/#installIfMissing\ libuhd-dev/g' build.sh
sed -i 's/installIfMissing\ libuhd003/#installIfMissing\ libuhd003/g' build.sh
sed -i 's/installIfMissing\ uhd-host/#installIfMissing\ uhd-host/g' build.sh
sed -i '/#installIfMissing\ uhd-host/a \\techo "Skipping UHD Package Install"' 
build.sh

 Clone openbts, and all other repos using build script util
 Switch to master branch
 Build OpenBTS and friends
./clone.sh 
./switchto.sh master
./build.sh B210

 Install built packages, * This command will fail 
 *** Select "Y" to overwrite config files when prompted
 You must change the path of this command to match the folder and replace 
the __TIMESTAMP_OF_BUILD__ 
sudo dpkg -i BUILDS/__TIMESTAMP_OF_BUILD__/*.deb

 Resolve Deps from previous command
sudo apt-get -f install

 Run the install again for packages, this will pass
sudo dpkg -i BUILDS/__TIMESTAMP_OF_BUILD__/*.deb

 Change permissions on asterisk database
sudo chown -R asterisk:asterisk /var/lib/asterisk/sqlite3dir


 Starting OpenBTS & Friends
# In four new terminals run:

# Terminal 1:
sudo /usr/local/sbin/smqueue 

# Terminal 2:
sudo /usr/local/sbin/sipauthserve 

# Terminal 3:
sudo /usr/sbin/asterisk -

# Terminal 4:
# * Note: Run uhd_usrp_probe before starting OpenBTS, so the FPGA image is 
loaded. OpenBTS's startup can timeout waiting on the FPGA to load.
uhd_usrp_probe 
cd /OpenBTS
sudo ./OpenBTS

### OpenBTS should now be running with a prompt:

OpenBTS >

### Adjusting RX Gain:
OpenBTS > rxgain 20

### Config Open Regristration:
OpenBTS> config Control.LUR.OpenRegistration ".*"

# You should now be able to search for the network and connect to it with your 
phones.
# Register with SIP by sending a 7-10 digit phone number to the number: 101
# OR manually add each IMSI with the commands below:

 Notes on adding SIP subscribers manually
# * In new terminal

cd ~/workarea/dev/NodeManager/

# read current subscribers
./nmcli.py sipau

Re: [USRP-users] Gnu radio compatibility

2017-08-21 Thread Nate Temple via USRP-users

Hi Daniel,

There should be no compatibility issues with using GNU Radio with UHD 3.10.x.x. 

Which version of GNU Radio are you using? It is usually suggested to use either 
the 'maint' branch or a tagged release, such as "v3.7.10.2".

What error are you getting?

Regards,
Nate Temple

> On Aug 21, 2017, at 3:51 PM, Cho, Daniel J (332C) via USRP-users 
>  wrote:
> 
> Hello –
>  
> I have a UHD 3.10 installed.  I installed the most up-to-date version of 
> gnuradio and it is only compatible with UHD 3.9.  Is there a gnuradio that is 
> compatible with UHD 3.10?
>  
> Thanks,
> Daniel Cho
> ___
> 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] Virtual machine setup

2017-08-23 Thread Nate Temple via USRP-users

Hi Daniel,

It is generally recommended not to run within a VM, and it is better to operate 
on the bare metal host for SDR applications. You should expect lower 
performance and throughput when operating within a VM vs a bare metal host. 
However it is possible. 

>How much memory (RAM) should we allocate to the VM?

As much as possible. Ubuntu's recommended minimum is 2GB. 4GB would be a good 
starting target.

>How big should the virtual disk size be?
Depends upon your application requirements. Ubuntu's recommended minimum is 
25GB.

>How do we configure the network to connect the USRP to the VM?
The B210 is not a network based USRP. It does however require VID/PID USB rules 
to enable the B210 to be passed through to the VM (For VirtualBox).

Regards,
Nate Temple


> On Aug 23, 2017, at 9:23 AM, Cho, Daniel J (332C) via USRP-users 
>  wrote:
> 
> Hello –
>  
> I tried looking for a guide in setting up an Ubuntu VM to use for a USRP B210 
> that I just bought but was unable to find anything online. 
> How much memory (RAM) should we allocate to the VM?
> How big should the virtual disk size be?
> How do we configure the network to connect the USRP to the VM?
>  
> Thanks,
> Daniel Cho
> ___
> 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] Support with handling data at 200MSPS from NI USRP 2954R

2017-08-28 Thread Nate Temple via USRP-users

Hi Snehasish,

You should not be using a Throttle block when you have any actual hardware 
within the flowgraph.

Note, in order to write 200 MS/s to disk, you'll most likely need a PCIe based 
SSD, or SSD Raid configuration. I've had success with an Intel 750 Series PCIe 
based SSD to write 200 MS/s to disk, until it was full. Another option is to 
use a RAM disk.

Regards,
Nate Temple


> On Aug 27, 2017, at 11:49 PM, Snehasish Kar via USRP-users 
>  wrote:
> 
> Hello 
> 
> I am using UHD source in gnu radio to capture data from usrp. I am then 
> passing this data to throttle and then to file sink. My data sample is 64 bit 
> (complex 32 bit) and I am capturing at the rate of 200 MSps. How to get 
> correct 2 to 3 seconds  of data without any data loss as I am seeing data 
> loss after decoding if I just do as the way I am doing. I am seeing "oo" 
> in the console as well while writing to the file. Please help. I am attaching 
> the grc file to capture data and write to a file.
> 
> Regards,
> Snehasish
> ___
> 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] B200mini & XU4 problem

2017-09-02 Thread Nate Temple via USRP-users

Hi Dave,

This is certainly an interesting issue. I suspect the core of the issue may be 
power draw on the USB interface during boot. One of the common issues with the 
XU4 that I've seen reported is that the USB3 ports do not provide USB3 spec 
power levels. 

Using a powered USB3 hub may resolve the issue. 

Another option would be a Y power cable such as this 
http://www.ebay.com/itm/262045046196 which would allow you to use an external 
power adapter to feed power to the USRP. 

Another test you could try -- Try using the USB2 on the XU4. Does it result in 
the same boot up problems? 

I have a early rev 0.1 20151201 XU4 that I often use paired with a B205mini and 
have not seen any issue such as this. 

Regards,
Nate Temple




> On Sep 2, 2017, at 1:44 AM, David via USRP-users  
> wrote:
> 
> Hi All,
> 
> I'm trying to get XU4 and B200mini to work together, but having a serious 
> issue: the SD card gets trashed!
> 
> I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, and 
> latest GIT clone of UHD (as of two weeks ago). Two uSD cards I had are now 
> totally trashed. I'm on my last card. They seem to get totally trashed after 
> I run uhd-fft a few times.
> 
> The main symptom is that if the B200mini is connected and I reboot, an fsck 
> is done every time, and also has the effect of continually rebooting, and 
> continually corrupting the card.
> 
> Unplug the B200mini and all is fine (after a couple of fscks). I managed to 
> work out that if I remove the udev rule that starts up UHD (uhd-usrp.rules) I 
> am also able to reboot with no issues. So a driver issue?
> 
> Without the udev rule I get the following, which I'm assuming is normal?:
> 
> [   24.555119] usb 3-1.1: device descriptor read/64, error -110
> [   29.995114] usb 3-1.1: device descriptor read/64, error -110
> [   45.675119] usb 3-1.1: device descriptor read/64, error -110
> [   56.685085] usb 3-1.1: device not accepting address 5, error -62
> [   67.565082] usb 3-1.1: device not accepting address 6, error -62
> [   67.569976] usb 3-1-port1: unable to enumerate USB device
> 
> Hope you can help, thanks,
> 
> Dave.
> 
> 
> ___
> 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] B200mini & XU4 problem

2017-09-03 Thread Nate Temple via USRP-users

Hi Dave,

What is the error when uhd_fft fails over the USB2 port?

The routing is different between the USB2 and USB3 ports on the XU4. The USB3 
ports are routed through a USB3 hub (GL3521) and also have a RTL8153 1GbE 
ethernet controller on the #1 channel. They also provide their own bus power 
through the NCP380HM switch. I don't know where the issue is at with the XU4 
power via the USB3 ports, but any of these could be the culprit. I know Odroid 
will recommend a powered hub for USB3 devices that don't have an external power 
option. The schematics will show all the details:

https://dn.odroid.com/5422/ODROID-XU4/Schematics/

Regards,
Nate Temple

> On Sep 3, 2017, at 5:46 AM, David via USRP-users  
> wrote:
> 
> Hey all,
> Thanks for the replies, didn't realise it would work on USB2... so I...
> - plugged into USB2 port
> - no boot up problems with the udev rule enabled
> - get similar device read errors, until the device is unplugged & plugged 
> back in
> - then uhd_usrp_probe works, no corruption of the fs :-)
> - takes much longer to load fw!
> - can't run uhd_fft however (...LIBUSB_ERROR_NO_DEVICE...)
> 
> So using USB2 port seems OK, but need to unplug, plug in the device after 
> each reboot, can do a
> uhd_usrp_probe with no issues, and reboot OK, but uhd_fft fails (is that 
> expected?).
> 
> Why the difference between USB2 and USB3, thought the power (500mA) was the 
> same?
> 
> I've been wondering about power, esp. since reading the odroid forums, I 
> think, as you say Nate, a powered hub, or Y adaptor (I didn't know about 
> that) is the next step...
> 
> Marcus, is there a location for the Arch image please? I saw a previous post 
> from you about using b2x0's with XU4... :-)
> 
> Many Thanks,
> Dave
> 
> On 02/09/17 23:30, Marcus D. Leech via USRP-users wrote:
>> On 09/02/2017 05:02 PM, Nate Temple via USRP-users wrote:
>>> Hi Dave,
>>> 
>>> This is certainly an interesting issue. I suspect the core of the issue may 
>>> be power draw on the USB interface during boot. One of the common issues 
>>> with the XU4 that I've seen reported is that the USB3 ports do not provide 
>>> USB3 spec power levels.
>>> 
>>> Using a powered USB3 hub may resolve the issue.
>>> 
>>> Another option would be a Y power cable such as this 
>>> http://www.ebay.com/itm/262045046196 which would allow you to use an 
>>> external power adapter to feed power to the USRP.
>>> 
>>> Another test you could try -- Try using the USB2 on the XU4. Does it result 
>>> in the same boot up problems?
>>> 
>>> I have a early rev 0.1 20151201 XU4 that I often use paired with a B205mini 
>>> and have not seen any issue such as this.
>>> 
>>> Regards,
>>> Nate Temple
>>> 
>>> 
>>> 
>>> 
>>>> On Sep 2, 2017, at 1:44 AM, David via USRP-users 
>>>>  wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> I'm trying to get XU4 and B200mini to work together, but having a serious 
>>>> issue: the SD card gets trashed!
>>>> 
>>>> I'm using Ubuntu 16.04 image from the Odroid site, kernel 4.9.28-38, and 
>>>> latest GIT clone of UHD (as of two weeks ago). Two uSD cards I had are now 
>>>> totally trashed. I'm on my last card. They seem to get totally trashed 
>>>> after I run uhd-fft a few times.
>>>> 
>>>> The main symptom is that if the B200mini is connected and I reboot, an 
>>>> fsck is done every time, and also has the effect of continually rebooting, 
>>>> and continually corrupting the card.
>>>> 
>>>> Unplug the B200mini and all is fine (after a couple of fscks). I managed 
>>>> to work out that if I remove the udev rule that starts up UHD 
>>>> (uhd-usrp.rules) I am also able to reboot with no issues. So a driver 
>>>> issue?
>>>> 
>>>> Without the udev rule I get the following, which I'm assuming is normal?:
>>>> 
>>>> [   24.555119] usb 3-1.1: device descriptor read/64, error -110
>>>> [   29.995114] usb 3-1.1: device descriptor read/64, error -110
>>>> [   45.675119] usb 3-1.1: device descriptor read/64, error -110
>>>> [   56.685085] usb 3-1.1: device not accepting address 5, error -62
>>>> [   67.565082] usb 3-1.1: device not accepting address 6, error -62
>>>> [   67.569976] usb 3-1-port1: unable to enumerate USB device
>>>> 
>>>> Hope you can help, thanks,
>>>&g

Re: [USRP-users] Verifying MIMO cable integrity

2017-09-21 Thread Nate Temple via USRP-users

Hi John,

I've matched your configuration, with a N210 with GPSDO as master, and a
N210 slave connected via a MIMO cable. I was able to create a pair of
synced streams with the flowgraph attached without issue. Can you give it a
try? Otherwise email us at supp...@ettus.com and we can follow up there.

Regards,
Nate Temple



On Thu, Sep 21, 2017 at 1:21 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> That seems correct to me, but I don't have a useful configuration in my
> lab to test.  (No N2xx, no MIMO cables).
>
>
>
>
>
>
>
>
> On 2017-09-21 16:02, John Shields via USRP-users wrote:
>
> Hi,
> I have been struggling with trying to get two coherent channels from a
> pair of N200 , one with GPSDO and the other with a MIMO cable. I realise
> that, according to the sync_page doc, I need to do some software magic in
> order to attempt to phase-sync but the slave unit reports that it cannot
> detect the PPS in time. While trying various options (e.g. moving the GPSDO
> from one N200r4 to the other) the conclusion appeared to be that each N200
> was OK and that either the MIMO cable was faulty (unlikely) or there is a
> software problem with UHD.
>
>   What I am now attempting to do is to take the GPSDO module out of the
> equation and test purely the MIMO cable/software. I have separated out the
> UHD sources in GRC so I have some control – not all control unfortunately
> because if there is a GPSDO, it appears that it is detected and used no
> matter the settings but that can be easily remedied.
>
>   So, after removing UART connection on GPSDO, I have 2 free-running N200s
> – I want to make one the 'master' so I have set Red:  Sync = Don't Sync,
> Clock Source = Internal, Time source=Default.
>
>   On the other unit, Blue, I have set : Sync= Don't Sync, Clock Source and
> Time Source= MIMO Cable. If I set the sync parameter to "unknown PPS" we
> are back to the situation where there is no PPS detected.
>
> Are these the correct settings to test the integrity of the MIMO cable
> and/or UHD sync software?
>
>   Kind Regards,
>
>John
>
>
>
>
> 
>  Virus-free.
> www.avast.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
>
>


n2xx_mimo.grc
Description: Binary data
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fosphor issue

2017-09-26 Thread Nate Temple via USRP-users

Hi Alex,

You'll need to run uhd_images_downloader on the E3xx, and note the URL for the 
FPGA .zip file it is attempting to fetch within the output. Download that zip 
file on a computer that is connected to the internet, then transfer it to the 
E3xx, and unpack them, and you should then be able to pass the fpga= arg to the 
new FPGA image.

Regards,
Nate Temple


> On Sep 26, 2017, at 6:53 AM, Alex Young via USRP-users 
>  wrote:
> 
> I am trying to build an d run fosphor on my  e310 (sg1)
> 
> I used the getting started guide 
> (https://kb.ettus.com/Getting_Started_with_RFNoC_Development), successfully 
> built the block, and copied it over to the directory ~/rfnoc on the e310. 
> When I run this command:
> 
> $ uhd_usrp_probe --args="fpga=/home/root/rfnoc/usrp_e310_fpga_RFNOC.bit"
> 
> I get: 
> 
> >>>
> linux; GNU C++ version 5.2.0; Boost_105800; UHD_003.010.001.001-release
> 
> -- Loading FPGA image: /home/root/rfnoc/usrp_e310_fpga_RFNOC.bit... done
> -- Detecting internal GPSDO  found
> -- Initializing core control...
> -- Performing register loopback test... pass
> Error: RuntimeError: Expected FPGA compatibility number 16.x, but got 255.0:
> The FPGA build is not compatible with the host code build.
> Please run:
> 
>  "/usr/lib/uhd/utils/uhd_images_downloader.py"
> >>>
> 
> So I run 
> 
> $ /usr/lib/uhd/utils/uhd_images_downloader.py
> 
>  and try it to load the bit file again, with the same results.
> 
> Anyone know what I need to do?
> 
> -Thanks,
> Alex Young
> 
> -- 
> Alexander Young
> Senior Systems Engineer | Echo Ridge, LLC
> alex.yo...@echoridgenet.com | 703.437.0404
> 
> ___
> 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] UBX-160 with X310 communication issue

2017-10-17 Thread Nate Temple via USRP-users

Hi Mark,

The UBX v2 is not supported using UHD 3.9.3. Support for the UBX v2 was
added with UHD 3.9.5 and UHD 3.10.2.0. Can you please try updating to the
newest UHD, such as 3.9.7 or 3.10.2.0 and try probing USRP/DBs again?

Regards,
Nate Temple

On Tue, Oct 17, 2017 at 1:01 PM, Mark Koenig via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> I am looking for some help with respect to the UBX-160.  I have two
> version 2 daughtercards which were purchased a couple of months ago.
>
>
>
> I am running on CentOS 7.2 and CentOS 6.5 with GNU radio version 3.7.4 and
> UHD version 003.009.003.
>
>
>
> I can ping the USRP and also return information on the *uhd_find_devices*
> command, however, when I run the *uhd_usrp_probe *command I do not get a
> return for the daughtercards.  The example output is below.
>
>
>
> Any help would be EXTREMELY appreciated.
>
>
>
> Thank you
>
> Mark
>
>
>
> linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-16); Boost_105300;
> UHD_003.009.004-0-g2b5a88bb
>
>
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 1472 bytes.
>
> -- Setup basic communication...
>
> -- Loading values from EEPROM...
>
> -- Setup RF frontend clocking...
>
> -- Radio 1x clock:200
>
> -- Detecting internal GPSDO Found an internal GPSDO
>
> -- Initialize Radio0 control...
>
> -- Performing register loopback test... pass
>
> -- Initialize Radio1 control...
>
> -- Performing register loopback test... pass
>
>   _
>
> /
>
> |   Device: X-Series Device
>
> | _
>
> |/
>
> |   |   Mboard: X310
>
> |   |   revision: 11
>
> |   |   revision_compat: 7
>
> |   |   product: 30818
>
> |   |   mac-addr0: 00:80:2f:17:43:3f
>
> |   |   mac-addr1: 00:80:2f:17:43:40
>
> |   |   gateway: 192.168.10.1
>
> |   |   ip-addr0: 192.168.10.2
>
> |   |   subnet0: 255.255.255.0
>
> |   |   ip-addr1: 192.168.20.2
>
> |   |   subnet1: 255.255.255.0
>
> |   |   ip-addr2: 192.168.30.2
>
> |   |   subnet2: 255.255.255.0
>
> |   |   ip-addr3: 192.168.40.2
>
> |   |   subnet3: 255.255.255.0
>
> |   |   serial: 311FF4E
>
> |   |   FW Version: 4.0
>
> |   |   FPGA Version: 19.0
>
> |   |
>
> |   |   Time sources: internal, external, gpsdo
>
> |   |   Clock sources: internal, external, gpsdo
>
> |   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo,
> ref_locked
>
> |   | _
>
> |   |/
>
> |   |   |   RX DSP: 0
>
> |   |   |   Freq range: -100.000 to 100.000 MHz
>
> |   | _
>
> |   |/
>
> |   |   |   RX DSP: 1
>
> |   |   |   Freq range: -100.000 to 100.000 MHz
>
> |   | _
>
> |   |/
>
> |   |   |   RX Dboard: A
>
> |   |   |   ID: Unknown (0x007e)
>
> |   |   |   Serial: 3120D56
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   RX Frontend: 0
>
> |   |   |   |   Name: Unknown (0x007e) - 0
>
> |   |   |   |   Antennas:
>
> |   |   |   |   Sensors:
>
> |   |   |   |   Freq range: 0.000 to 0.000 MHz
>
> |   |   |   |   Gain Elements: None
>
> |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>
> |   |   |   |   Connection Type: IQ
>
> |   |   |   |   Uses LO offset: No
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   RX Codec: A
>
> |   |   |   |   Name: ads62p48
>
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
>
> |   | _
>
> |   |/
>
> |   |   |   RX Dboard: B
>
> |   |   |   ID: Unknown (0x007e)
>
> |   |   |   Serial: 3120D4A
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   RX Frontend: 0
>
> |   |   |   |   Name: Unknown (0x007e) - 0
>
> |   |   |   |   Antennas:
>
> |   |   |   |   Sensors:
>
> |   |   |   |   Freq range: 0.000 to 0.000 MHz
>
> |   |   |   |   Gain Elements: None
>
> |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>
> |   |   |   |   Connection Type: IQ
>
> |   |   |   |   Uses LO offset: No
>
> |   |   | _
>
> |   |   |/
>
> |   |   |   |   RX Codec: B
>
> |   |   |   |   Name: ads62p48
>
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
>
> |   | _
>
> |   |/
>
> |   |   |   TX DSP: 0
>
> |   |   |   Freq range: -100.000 to 100.000 MHz
>
> |   | _
>
> |   |/
>
> |   |   |   TX DSP: 1
>
> |   |   |   Freq range: -100.000 to 100.000 MHz
>
> |   | _
>
> |   |/
>
> |   |   |   TX Dboard: A
>
> |   |   |

Re: [USRP-users] Problems with Ettus B210 and Intel Nuk

2017-10-31 Thread Nate Temple via USRP-users

Hi Tathagata,

After you boot, if you run: $UHD_INSTALL_PREFIX/utils/b2xx_fx3_utils 
--reset-device

Are you able to then initialize the USRP by running uhd_usrp_probe?


Regards,
Nate Temple



> On Oct 31, 2017, at 11:11 AM, Neel Pandeya via USRP-users 
>  wrote:
> 
> Hello Tathagata:
> 
> If I recall from a separate conversation, after you upgraded the BIOS on this 
> Intel NUC, the system would no longer recognize the B210, right?
> 
> Before the BIOS upgrade, the B210 would still be recognized, but only after a 
> long 30- or 60-second delay, right?
> 
> --Neel Pandeya
> 
> 
> On 31 October 2017 at 10:52, Humphries, James R. via USRP-users 
>  wrote:
> Hey T,
> 
>  
> 
> I encountered a problem similar to this in the past with a Minnowboard Max. 
> If you press the reset switch (S700 I believe), is the NUC able to see the 
> B210 (instead of unplugging USB)? I had to do this if I had a B200 plugged 
> into the Minnowboard while it booted.
> 
>  
> 
> The solution we came up with was to install a larger capacitor in parallel 
> with C716/S700. I recall installing a 100uF capacitor. This allowed some 
> extra time before the Cypress USB chip on the B200 powered up and it would 
> work normally after a cold boot.
> 
>  
> 
> Obviously, if you want to try I assume it will void your warranty on the 
> B210, so proceed at your own risk.
> 
>  
> 
> I think B200mini alleviated this ‘issue’ as it has a reset supervisor 
> (TPS3801).
> 
>  
> 
> -Trip
> 
>  
> 
>  
> 
>  
> 
> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
> "Tathagata (T)" via USRP-users
> Sent: Tuesday, October 31, 2017 12:09 AM
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] Problems with Ettus B210 and Intel Nuk
> 
>  
> 
> Hi,
> 
>  
> 
> We have a problem with Ettus B210 on an Intel Nuk. Briefly when we plug in 
> the SDR into the USB port of the Intel Nuk, it is not recognized. The Nuk is 
> running Ubuntu 16.04. The attached document details the debugging steps that 
> we have taken and the errors that we are getting.  We never had this problem 
> before and it suddenly started and we have no clue as to what is going wrong. 
> Any help would be highly appreciated.
> 
>  
> 
> Thanks
> 
> T
> 
>  
> 
>  
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] Linux Kernel Modules for X-Series PCIe Connectivity

2017-12-01 Thread Nate Temple via USRP-users

Hi John,

You will need to run Ubuntu <14.04.4 [1] which has the 4.2 kernel, to use the 
NI driver for the PCIe connection. We have the update on our radar, however I 
don't have any estimate on when it will be available at this time. 

[1] - 
https://wiki.ubuntu.com/Kernel/Support?action=AttachFile&do=view&target=Ubuntu+Kernel+Support+Schedule.svg


Regards,
Nate Temple


> On Nov 28, 2017, at 5:08 PM, john liu via USRP-users 
>  wrote:
> 
> Hi all,
> From the manual http://files.ettus.com/manual/page_ni_rio_kernel.html ,we 
> know Currently, the latest supported kernel version is 4.2.x. 
> But the kernel version of ubnutu16.04 is newer than 4.2.x.So  we have a plan 
> to update this? 
> 
> thank you.
> best regards
> John
> ___
> 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] [RFNOC] [E310]: Runtime Error: On node 0/FIFO_0 when attempting to run "rx_samples_to_file" example

2017-12-15 Thread Nate Temple via USRP-users

Hi Adam,

This is a known bug that we are tracking on our internal issue tracker.

Can you please try building with these commits:


https://github.com/EttusResearch/gr-ettus/commit/30302780a44f3f0b146e9b81f88e70c9d983f559

https://github.com/EttusResearch/uhd/commit/12a34d6ef6b9666e29a23039291138f989c7c2ce

Note, using these commits, you'll still get the peak32() errors on the idle 
FPGA image load, however, it will not be fatal due to the FIFO connection error 
as seen with the error you posted..


Regards,
Nate Temple



> On Dec 15, 2017, at 1:36 PM, Adam Kurisko via USRP-users 
>  wrote:
> 
> Hi there,
> 
> I am attempting to set up UHD with RFNOC to cross compile on my E310 sg1, 
> where I ran into a bit of an issue while trying to run the example files. 
> 
> I followed this guide to setup the environment:
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
> 
> There were also errors in uhd_usrp_probe, however they were identical to 
> those talked about here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/023950.html
> 
> Jonathon's response in that thread reassured me that UHD would still work 
> despite the error messages in uhd_usrp_probe and tested out the example file 
> stated in the guide.
> 
> So my question is: Is there something I need to correct with my build? Or is 
> this just a result of the assertion errors from uhd_usrp_probe?
> 
> I pasted the output I received below: 
> 
> root@ettus-e3xx-sg1:~/newinstall/usr/lib/uhd/examples# ./rx_samples_to_file 
> --freq 100e6 --gain 0 --ant TX/RX --rate 1e6 --null
> 
> Creating the usrp device with: ...
> [INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700; 
> UHD_4.0.0.rfnoc-devel-409-gec9138eb] 
> [INFO] [E300] Loading FPGA image: 
> /home/root/newinstall/usr/share/uhd/images/usrp_e310_fpga.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
> 
> [INFO] [E300] Performing register loopback test... 
> [INFO] [E300] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input 
> ports
> [INFO] [AD936X] Performing CODEC loopback test... 
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [AD936X] Performing CODEC loopback test... 
> [INFO] [AD936X] CODEC loopback test passed
> [INFO] [CORES] Performing timer loopback test... 
> [INFO] [CORES] Timer loopback test passed
> [INFO] [E300] Loading FPGA image: 
> /home/root/newinstall/usr/share/uhd/images/usrp_e3xx_fpga_idle.bit...
> [INFO] [E300] FPGA image loaded
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/Adam/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
>   in typename T::sptr e300_transport::get_buff(double) [with T = 
> uhd::transport::managed_send_buffer; typename T::sptr = 
> boost::intrusive_ptr]
>   at /home/Adam/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> 
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/Adam/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
>   in typename T::sptr e300_transport::get_buff(double) [with T = 
> uhd::transport::managed_send_buffer; typename T::sptr = 
> boost::intrusive_ptr]
>   at /home/Adam/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> 
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/Adam/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
>   in typename T::sptr e300_transport::get_buff(double) [with T = 
> uhd::transport::managed_send_buffer; typename T::sptr = 
> boost::intrusive_ptr]
>   at /home/Adam/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> 
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/Adam/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
>   in typename T::sptr e300_transport::get_buff(double) [with T = 
> uhd::transport::managed_send_buffer; typename T::sptr = 
> boost::intrusive_ptr]
>   at /home/Adam/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> 
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/Adam/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
>   in typename T::sptr e300_transport::get_buff(double) [with T = 
> uhd::transport::managed_send_buffer; typename T::sptr = 
> boost::intrusive_ptr]
>   at /home/Adam/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> 
> [ERROR] [UHD] Exception caught in safe-call.
>   in v

Re: [USRP-users] USRP TwinRX Error UHD

2017-12-28 Thread Nate Temple via USRP-users

Hi Alejandro,

The TwinRX does not support a 184.32e6 Master Clock Rate which is required for 
srsLTE. The TwinRX DBs also will not work with srsLTE as they do not have any 
TX channels.

Regards,
Nate Temple



> On Dec 28, 2017, at 8:52 AM, ALEJANDRO BLANCO PIZARRO via USRP-users 
>  wrote:
> 
> Yeah, sure, The output is:
> 
> sudo uhd_usrp_probe --args "type=x310"
> linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> UHD_003.010.002.000-release
> 
> Error: LookupError: KeyError: No devices found for ->
> Device Address:
> type: x310
> 
> 
> I am not pretty sure that the command is correct. So, I am going to show you 
> the output of sudo uhd_usrp_probe too: 
> 
> linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> UHD_003.010.002.000-release
> 
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware Rev 
> 0.929a
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.7MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.5MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
>   _
>  /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 7
> |   |   revision_compat: 7
> |   |   product: 30818
> |   |   mac-addr0: 00:80:2f:21:e4:65
> |   |   mac-addr1: 00:80:2f:21:e4:66
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.50.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 30AAD25
> |   |   FW Version: 5.1
> |   |   FPGA Version: 33.0
> |   |   RFNoC capable: Yes
> |   |   
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, 
> ref_locked
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: TwinRX v1.1 (0x0093)
> |   |   |   Serial: 3129E7C
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: TwinRX RX0
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connection Type: II
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 1
> |   |   |   |   Name: TwinRX RX1
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connection Type: QQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: TwinRX v1.1 (0x0093)
> |   |   |   Serial: 31293DD
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: TwinRX RX0
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connection Type: II
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 1
> |   |   |   |   Name: TwinRX RX1
> |   |   |   |   Antennas: RX1, RX2
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range all: 0.0 to 95.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 8000.0 to 8000.0 step 0.0 Hz
> |   |   |   |   Connec

Re: [USRP-users] TwinRX dead on arrival?

2018-01-15 Thread Nate Temple via USRP-users

Hi Anon, 

Please disregard my comment before about the Osmocom blocks, I had switched to 
the wrong flowgraph. 

A normalized gain of .5 on the TwinRX is bit low. The TwinRX has 95dB of 
adjustable gain. Around 60-70 dB will usually provide a good SNR with a common 
antenna attached. 

Regards,
Nate Temple


> On Jan 15, 2018, at 10:32 AM, Nate Temple  wrote:
> 
> Hi Anon,
> 
> The TwinRX will work fine with the Osmocom Source, however, there is more 
> functionality exposed via the UHD Source/Sinks, especially for the TwinRX (LO 
> Controls for example).
> 
> Can you try using the GNU Radio application uhd_fft to test the TwinRX? A 
> command such as below should display your local WBFM.
> 
> uhd_fft -f 100e6 -s 10e6 -g 60 -A RX1
> 
> One important note with the TwinRX is the antenna names, “RX1” and “RX2”. 
> Also subdev specs need to be set to use multiple channels, “A:0 A:1” for a 
> single card. “A:0 A:1 B:0 B:1” for a pair of TwinRXs.
> 
> Attached is a example flowgraph for a 4 channel configuration with a X3xx 
> over 10Gb + two TwinRXs. You can use this as a reference and disable the 
> blocks for channels 2-4 if you would like to only use a single channel. 
> 
> 
> Regards,
> Nate Temple
> 
> 
> 
>> On Jan 15, 2018, at 10:13 AM, Anon Lister via USRP-users 
>>  wrote:
>> 
>> Hey all,
>> 
>> We recently purchased an X300 with a pair of UBX boards and a TwinRX
>> board. The UBX works great, but the TwinRX is completely deaf. It acts
>> as if something in the RF path is broken. Command and control side
>> seem to work fine. I have attached two screenshots of the FM band with
>> both TwinRX and UBX, same flowgraph, same X300, same antenna cable.
>> 
>> I tried:
>> swapping daughterboard slot on x300. no change
>> swapping RX port on TwinRX. no change
>> swapping out SMA-mcx cable on TwinRX. no change
>> tuning to different areas. get basically nothing anywhere except
>> slight changes in noise floor amplitude.
>> 
>> 
>> UHD:
>> UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_3.11.0.git-230-gfc8cd827
>> Only one daughterboard was in X300 at at time.
>> 
>> Is there something special you have to do with the configuration of
>> the TwinRX(See attached flowgraph)? Or do we need to RMA this
>> daughterboard?
>> 
>> Thanks!
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 


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

Re: [USRP-users] TwinRX dead on arrival?

2018-01-15 Thread Nate Temple via USRP-users

Hi Anon,

Can you try running these tests with a tagged release of UHD, such as
"release_003_010_002_000" instead of the master branch? You may need to
recompiled GNU Radio against this version of UHD. It is important to
download and flash the 3.10.2.0 FPGA image before running the tests.

If 3.10.2.0 shows the same results, please email supp...@ettus.com and we
can start a RMA.

Regards,
Nate Temple

On Mon, Jan 15, 2018 at 11:36 AM, Anon Lister  wrote:

> Nate,
>
> Roger. I set gain to absolute 70dB with no change. Also plotted RX1
> and RX2(twinrx_ubx_text2.grc). Antenna attached to RX1. Same deal.
> (test_flowgraph2.png).
>
> Also swapped to different X300 chassis as a longshot, but no change.
>
> Looks pretty dead with your attached flowgraph too. (after editing to
> disable the blocks for channel 3/4 since we only have 1 TwinRX)
> (twinrx_front_panel.png)
>
> Same for uhd_fft See attached, also did same command with UBX for
> comparison of spectrum. For the ubx comparison i modified the command
> to reference the TX/RX antenna. (uhd_fft_*.png)
>
> Also attached uhd_usrp_probe incase that is of any use.
>
> Anything else to try, or should I contact Ettus directly for RMA?
>
> Thanks!.
>
> On Mon, Jan 15, 2018 at 1:32 PM, Nate Temple 
> wrote:
> > Hi Anon,
> >
> > The TwinRX will work fine with the Osmocom Source, however, there is
> more functionality exposed via the UHD Source/Sinks, especially for the
> TwinRX (LO Controls for example).
> >
> > Can you try using the GNU Radio application uhd_fft to test the TwinRX?
> A command such as below should display your local WBFM.
> >
> > uhd_fft -f 100e6 -s 10e6 -g 60 -A RX1
> >
> > One important note with the TwinRX is the antenna names, “RX1” and
> “RX2”. Also subdev specs need to be set to use multiple channels, “A:0 A:1”
> for a single card. “A:0 A:1 B:0 B:1” for a pair of TwinRXs.
> >
> > Attached is a example flowgraph for a 4 channel configuration with a
> X3xx over 10Gb + two TwinRXs. You can use this as a reference and disable
> the blocks for channels 2-4 if you would like to only use a single channel.
> >
> >
> > Regards,
> > Nate Temple
> >
> >
> >
> >
> >> On Jan 15, 2018, at 10:13 AM, Anon Lister via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >>
> >> Hey all,
> >>
> >> We recently purchased an X300 with a pair of UBX boards and a TwinRX
> >> board. The UBX works great, but the TwinRX is completely deaf. It acts
> >> as if something in the RF path is broken. Command and control side
> >> seem to work fine. I have attached two screenshots of the FM band with
> >> both TwinRX and UBX, same flowgraph, same X300, same antenna cable.
> >>
> >> I tried:
> >> swapping daughterboard slot on x300. no change
> >> swapping RX port on TwinRX. no change
> >> swapping out SMA-mcx cable on TwinRX. no change
> >> tuning to different areas. get basically nothing anywhere except
> >> slight changes in noise floor amplitude.
> >>
> >>
> >> UHD:
> >> UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> >> UHD_3.11.0.git-230-gfc8cd827
> >> Only one daughterboard was in X300 at at time.
> >>
> >> Is there something special you have to do with the configuration of
> >> the TwinRX(See attached flowgraph)? Or do we need to RMA this
> >> daughterboard?
> >>
> >> Thanks!
> >> __
> _
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 Environment (IO) error

2018-02-01 Thread Nate Temple via USRP-users

Hi Jacob,

Can you try upgrading to UHD 3.10.3.0 to see if it resolves this error?

Regards,
Nate Temple

On Thu, Feb 1, 2018 at 5:09 PM, Jacob Knoles via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
> I have an application that utilizes an X300 radio to play a short burst of
> pulses. This burst style transmission will be repeated hundreds of times
> during the lifetime of the application along with several other types of
> bursts and a brief capture activity.
>
> Some of these functions are being done using GNURadio while some are done
> using the UHD api directly, but the common point is that a usrp_source
> block and usrp_sink are created at the applications start and held through
> the life of the app.
>
> Now, the issue I am having is this, everything works fine until I try a
> second function, meaning, I play a short burst of signal and when playing a
> second burst I get this error:
>
> EnvironmentError: IOError: [0/Radio_0] user_reg_read32() failed:
> EnvironmentError: IOError: [0/Radio_0] sr_read32() failed:
> EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet -
> AssertionError: buff->size() > 0
>   in unsigned __int64 __cdecl ctrl_iface_impl::wait_for_ack(const bool)
>   at Z:\gr-build\src-stage1-dependencies\uhd-release_003_
> 010_001_001\host\lib\rfnoc\ctrl_iface.cpp:206
>
> I have no idea what is causing this error and I need advice on how to
> correct it. Any ideas?
>
> Thanks.
> -
> Jacob Knoles
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] MIMO Cable for USRPN200 and USRP2

2018-02-07 Thread Nate Temple via USRP-users

Hi Wahhab,

The MIMO Cable will work with the USRP2. Please see this section of the UHD
Manual: http://files.ettus.com/manual/page_usrp2.html#usrp2_mimocable

Regards,
Nate Temple

On Tue, Feb 6, 2018 at 1:34 PM, Wahhab Albazrqaoe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I would like to use MIMO cable to connect (synchronize) USRPN200 and USRP2.
>
> Is it possible to do so? Is it safe to do so?
>
> I appreciate your comments.
>
> Wahhab Albazrqaoe
>
>
> ___
> 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 underflow in transmit-only configuration

2018-02-08 Thread Nate Temple via USRP-users

Hi Steven,

If you are able, can you please post an application/code that demonstrates
this ? Without seeing the code, its nearly impossible to debug the issue.

What version of UHD are you using?

Regards,
Nate Temple



On Thu, Feb 8, 2018 at 1:33 PM, Steven Knudsen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I have been scratching my head for a while on this one…
>
> I have made a TDMA radio that has a simple 4 slot cycle with a relatively
> low duty cycle (slots are 40% and the remaining 60% of the cycle the USRP
> is idle).
>
> A radio transmits in it’s “owned” slot and receives in all others (3 of
> them). The transmit is timed as are the receptions in each slot. Transmit
> is schedule 10 ms in advance (at the start of a cycle) and the receives are
> scheduled at least 6 ms in advance (at the end of the last receive slot).
>
> When I test with a B200mini connected to an Octoclock G for 1 PPS
> reference, it runs flawlessly for hours (5 is the longest). When, on the
> exact same Linux host I run with an X310 connected to the same Octoclock G
> for 1 PPS and 10 MHz, it stops working after not too long with a slew of
> ’U’s and ’L’s
>
> Trying to narrow things down, I created a version fo the radio that only
> transmits. Reception is completely disabled and I confirm that no receive
> commands are ever scheduled and rxStreamer->recv() is never called.
>
> So, imagine my surprise when after a fairly long time of transmitting
> successfully (evidenced by using an oscilloscope to view packets), the
> transmit-only version fails!?! Below is a copy o the log showing the first
> evidence of failure, namely ’L’s indicating transmits were too late. But,
> what is the ‘U’ doing there? As I mentioned, no reception functionality is
> in the program, so what is going on?
>
> Anyone else see this kind of thing? I never see it with the B200mini, but
> see it consistently with the X310.
>
> thanks very much for your time and consideration,
>
> steven
>
> ULLsendFrame() MPDU #719935  mpdu size = 488 bytes at 1518123481s 89 us
> ULLLsendFrame() MPDU #719936  mpdu size = 488 bytes at 1518123481s 90 us
> UsendFrame() MPDU #719937  mpdu size = 488 bytes at 1518123481s 91 us
> ULsendFrame() MPDU #719938  mpdu size = 488 bytes at 1518123481s 92 us
> ULLsendFrame() MPDU #719939  mpdu size = 488 bytes at 1518123481s 93 
> us
> ULLLsendFrame() MPDU #719940  mpdu size = 488 bytes at 1518123481s 94 
> us
> UsendFrame() MPDU #719941  mpdu size = 488 bytes at 1518123481s 
> 95 us
> ULsendFrame() MPDU #719942  mpdu size = 488 bytes at 1518123481s 
> 96 us
> ULLsendFrame() MPDU #719943  mpdu size = 488 bytes at 1518123481s 
> 97 us
> ULLLsendFrame() MPDU #719944  mpdu size = 488 bytes at 1518123481s 
> 98 us
> UsendFrame() MPDU #719945  mpdu size = 488 bytes at 1518123481s 
> 99 us
> ULsendFrame() MPDU #719946  mpdu size = 488 bytes at 1518123482s 
> 0 us
> ULsendFrame() MPDU #719947  mpdu size = 488 bytes at 1518123482s 
> 1 us
> ULLsendFrame() MPDU #719948  mpdu size = 488 bytes at 1518123482s 
> 2 us
> ULLLsendFrame() MPDU #719949  mpdu size = 488 bytes at 
> 1518123482s 3 us
> UsendFrame() MPDU #719950  mpdu size = 488 bytes at 
> 1518123482s 4 us
> ULsendFrame() MPDU #719951  mpdu size = 488 bytes at 
> 1518123482s 5 us
> ULLsendFrame() MPDU #719952  mpdu size = 488 bytes at 
> 1518123482s 6 us
> ULLLsendFrame() MPDU #719953  mpdu size = 488 bytes at 
> 1518123482s 7 us
>
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
>
> www.linkedin.com/in/knudstevenknudsen
>
>
>
> *All the wires are cut, my friendsLive beyond the severed ends.  Louis
> MacNeice*
>
>
> ___
> 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] B200 USB high CPU usage

2018-02-13 Thread Nate Temple via USRP-users

Hi Kasper,

There are several caveats/issues/topics to consider with regards to running
at higher sample rates with the B2xx. Generally speaking, Linux will offer
better performance than Windows.

What version of UHD are you using? If you're not using UHD 3.10.3.0, can
you please try upgrading? UHD 3.10.3.0 includes a commit [1] and updated
firmware, which optimizes the FX3 performance.

The i5-3210M may be slightly under-powered for the task, however you can
try all the following performance tuning adjustments, and it may be able to
support 56 MS/s.

It is worth noting that the recent KPTI patches and other related
workarounds [2] for Intel CPUs to protect against Meltdown/Spectre attacks
[3], may cause a considerable overhead. Here [4] are instructions on how to
check to see if KPTI is enabled for Ubuntu. You may want to disable KPTI,
if it is enabled on your system, then test to see how much additional
overhead it creates, running your application.

Adjust your CPU Governor to "performance". This can be done with the
cpu-frequtils utility [5]. ( sudo cpufreq-set -g performance )

Ensure your CPU is not throttling due to overheating ( sudo cat
/var/log/syslog | grep throttled ). This is very common in laptops,
especially older devices where the thermal grease is in need of replacement.

You can test using sc8 and sc12 OTW (over the wire) [6] sample sizes with
the benchmark_rate [7] utility. Using sc12 will not drop any information as
the ADC/DAC on the B2xx is 12bits.

./benchmark_rate --rx_otw sc12 --rx_rate 40e6
./benchmark_rate --tx_otw sc8 --tx_rate 40e6

Some USB controllers can be problematic. Intel Series 7/8/9 USB controllers
usually offer the best performance.

Using Thinkpads (T430s, T470p) I've found that a recv/send frame size of
8192 tends to work the best at higher sample rates.

As Marcus mentioned, the UHD examples are provided as an API reference and
not tuned for performance. Case in point is rx_samples_to_file being single
threaded. GNU Radio will by default offer a multi-threaded architecture,
which can be useful to test. You may need to adjust the min buffer sizes to
handle the higher sample rates however within the GR Blocks.

I've attached an example of rx_samples_to_file.cpp which is multi-thread
and has additional buffering.

Without a SSD or NVMe hard drive, sustaining a high sample rate to disk can
be difficult. Depending upon your system configuration, you may want to
consider using a ram disk. I would recommend leaving at least 2-8 GB of ram
for your host OS (this is dependent upon your application etc). This will
however limit the length of time you can save to disk (as limited by the
ram in the machine). Below is an example to create a 24GB ramdisk:

mkdir -p ~/ramfs
mount -t tmpfs -o size=24G tmpfs ~/ramfs

[1] -
https://github.com/EttusResearch/uhd/commit/d95613152da3e7c7f41c71acca65101ed0896893
[2] - https://en.wikipedia.org/wiki/Kernel_page-table_isolation
[3] - https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
[4] -
https://askubuntu.com/questions/992137/how-to-check-that-kpti-is-enabled-on-my-ubuntu
[5] - http://www.thinkwiki.org/wiki/How_to_use_cpufrequtils
[6] - https://files.ettus.com/manual/page_stream.html#stream_datatypes_otw
[7] -
https://github.com/EttusResearch/uhd/blob/maint/host/examples/benchmark_rate.cpp

Regards,
Nate Temple

On Tue, Feb 13, 2018 at 11:59 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/13/2018 04:52 AM, Kasper Føns via USRP-users wrote:
>
>> Hi.
>>
>> We have bought a B200 board and are having issues simply receiving the
>> samples and would like some support in the matter.
>>
>> Running the command
>>./rx_samples_to_file --null --rate 5600
>> on a Sony Vaio Z with an I5-3210M running Ubuntu Server 17.10 shows a
>> high CPU usage of ~78%.
>>
>> Is such a high CPU usage expected?
>> Switching terminal windows (ALT + F1 or ALT + F2) is enough to cause an
>> overflow on the Linux host.
>>
>>
>> There is also a high CPU usage on a Windows 10 machine (ThinkPad,
>> i7-4810MQ).
>> Running
>>./rx_samples_to_file --null --rate 5600
>> results in a infinite stream of overflows.
>>
>> Running
>>./rx_samples_to_file --null --rate 3200
>> utilizes 22% CPU and still overflows once in a while. Moving a
>> calculator window around the screen results in overflows.
>>
>> We have tried increasing buffers using --args="recv_frame_size=X,
>> num_recv_frames=Y"
>> However, we haven't been able to increase X to higher values than ~16000
>> (16384 fails with lots of overflows).
>> The same applies to Y, where 300 fails with an error.
>>
>> The software was compiled in release mode an ran over a USB 3 connection.
>>
>> Thus, for USB transfers using the B200:
>>   - On Vaio: Is ~78% CPU usage expected for 56 Msps ?
>>   - On Win10: Is it not possible to receive 56 Msps?
>>   - On Win10: Is 22% CPU usage expected for 32 Msps?
>>   - Is there some limit to recv_frame_size? A value of 16384 fail

Re: [USRP-users] B210 - How much input power can its TX chains endure?

2018-03-07 Thread Nate Temple via USRP-users

Hi Brais,

You'll want to have an isolator/ciculator inline.


Regards,
Nate Temple

On Wed, Mar 7, 2018 at 3:29 PM, Brais Ares via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We are planning to use a B210 device in a project where there may be high
> power interferences.
>
> What would be the *maximum input power through a B210 RF output* to
> prevent damaging the device?
> (The AD9361 datasheet indicates an absolute maximum of 2.5 dBm for an RF
> input, but it does not specify a similar value for RF outputs)
>
> Regards,
> Brais
>
>
> ___
> 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] Multi N200 issues

2018-03-08 Thread Nate Temple via USRP-users

Hi Keith,

Can you please give UHD 3.9.7 or the 3.9-LTS branch of a try with your
setup?

What kind of CPU does your host have? What is the load profile while your
application is running?

Regards,
Nate Temple

On Thu, Mar 8, 2018 at 1:55 PM, Keith k via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey all
>
> Just wondering if anyone had a chance to look at this for me. I'd
> appreciate it immensely! Thank you.
>
> On Fri, Mar 2, 2018 at 3:37 PM, Keith k  wrote:
>
>> Hello all
>>
>> I'm working on a project to use 16 N200s in a multi USRP configuration
>> for a radar project. They are synchronized using 3 Octoclocks (one master
>> with a GPSDO, and two slaves that drive the 16 N200s). I've been getting
>> many errors that I was hoping someone could help with. I have attached a
>> sample program that mimics how the USRPs are used. The basic goal here is
>> to sample a determined number of samples while transmitting some spaced
>> pulses (a "pulse sequence") and then repeat. It would be beneficial to have
>> as little delay as possible in between loops. I've been running into some
>> problems however.
>>
>> BASIC INFO
>>   We have 16 N200s + 1 spare
>>   3 Octoclocks (1 has gps and it drives the other two)
>>   LFTX and LFRX daughterboards in each N200
>>   linux; GNU C++ version 4.8.5; Boost_105400;
>> UHD_003.010.002.000-0-gbd6e21dc
>>   Intel Corporation Ethernet Controller 10-Gigabit X540-AT2
>>   Devices are all connected via 3 daisy chained Netgear XS708E switches
>>   Ideal sampling rates: 5-10MHz TX, 5-10MHz RX depending on
>> hardware/software limitations.
>>
>> One of the issues I sometimes get after several minutes of runtime (or
>> several thousand pulse sequences) is the overflow(O) with the out of
>> sequence flag set in the rx metadata. I also get sequence errors(S) on the
>> tx side too. It seems to happen more often and faster with higher sampling
>> rate. I've gathered from other mailing list posts that this is likely a
>> network configuration issue. Can someone recommend a known working computer
>> build and network configuration that can handle the amount of USRPs and
>> data we are attempting to use?
>>
>> Another major issue I eventually get during runtime is a slurry of
>> lates(L) on TX and then a LATE in the RX metadata. I've tried increasing
>> the time in the future that the TX/RX should start (from when the stream
>> commands are called) and I've tried to minimize the number of operations
>> happening between that calculation and when TX/RX start, but the lates
>> still eventually happen. I've tried to time profile what I can in my code
>> and it seems I should really only need about ~0.5ms of delay, but even at
>> 3-10ms of delay I have issues. I feel like 10ms of time should be more that
>> plenty of time for the host to issue stream commands. I don't seem to get
>> lates if I have test applications that individually test TX or RX, but when
>> I put them together using threads, I can't seem to find a way to eliminate
>> the lates. Any ideas on how I should set up what I'm trying to do here?
>>
>> Here is the compiler line to make the test program:
>> g++ -o test_rx_tx -std=c++11 -Wall test_rx_tx.cpp -lboost_system -luhd
>>
>> If I can explain anything in further detail please let me know.
>>
>> Thank you for your time.
>>
>> --
>> -Keith Kotyk
>>
>
>
>
> --
> -Keith Kotyk
>
> ___
> 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] RF_NoC fosphor issue (Source IO size "8" does not match sink IO size "8192".)

2018-03-19 Thread Nate Temple via USRP-users

Hi Tarik,

If you press "F6" instead of the "Run" button, it will bypass this warning
and run the flowgraph.

Regards,
Nate Temple

On Mon, Mar 19, 2018 at 8:59 AM, Tarik Kazaz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
>
> I am using USRP X310 with UBX-160MHz. I tried to run RFNoC fosphor demo,
> however I am getting errors related to connection of RFNoC:Radio to RFNoC:
> DDC and to RFNoC:Window (Source IO size "8" does not match sink IO size
> "8192"). I found this discussion on mailing list (from 2016)
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00366.html.
> However, I did not manage to make it work.
>
>
> Could you please provide me more information which modifications I should
> do in order to make it work?
>
>
> KInd Regards
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] carrier discontinuities on usrp B200 when using rx_samples_to_file

2018-03-27 Thread Nate Temple via USRP-users

Hi Colin,

The B2xx/AD936x has built in DC offset calibration that may be causing
this, and generally you will want to either offset tune so your signal is
not at the exact center frequency, but still within your passband, or use
the LO offset functionality.

Using the LO offset method is the easiest, by adding the argument
"lo_offset=xxx" to your device string, such as:

./rx_samples_to_file --args
"type=b200,master_clock_rate=50e6,lo_offset=25e6" 


Regards,
Nate Temple

On Tue, Mar 27, 2018 at 9:02 AM, de Vrieze, Colin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
> When using the rx_samples_to_file example script, I'm experiencing weird
> discontinuities in the envelope of the signal, which I cannot get rid of.
>
>
> My intention is to visualize the CFO between transmitter and receiver. TX
> transmits a random BPSK-modulated at 5.75 GHz. I am using a lab-grade
> vector signal generator, and sampling the transmitted signal with a
> spectrum analyzer shows that it is clean.
>
>
> On the receiver side, I use a USRP B200 as RX, connected via USB3. I run
> the rx_samples_to_file script for 100ms with srate=50MHz. I use port RF A
> RX2. I chose the buffer size to match the number of total samples per
> recording to exclude buffering issues. I double checked with print
> statements in the receive script that the whole recording fits in the
> buffer. After receiving all the data, I read the samples from the hard
> disk, square and low-pass filter the values to extract the envelope signal.
>
>
> In any case, the magnitude of the squared signal should be constant. In
> case of no CFO, the I and Q signal should both be constant, too. In case of
> CFO, the I and Q signals should be sinusoids with a frequency equal to
> twice the CFO. Again, sampling with a spectrum analyzer shows just that.
>
>
> However, the signal recorded by the B200 shows strange discontinuities.
> They tend to have a somewhat regular structure, but the shape changes. The
> stream indicates no under-/overflows.
>
>
> I get the same effect with different sample rates, too. For example, I
> tried srate=master_clock_rate=40e6 or srate=0.5*master_clock_rate=50e6. I
> already chose a super long set-up time to make sure the CFO has settled and
> I printed out the metadata of recv_stream to make sure there are no issues.
> The same effect happens if I only record for 10ms. Please find the output
> of the rx_samples_to_file script below.
>
>
> Has anyone seen this before or does anyone have an idea how to solve it?
>
>
> Cheers,
>
> Colin
>
>
> ---
>
>
> Creating the usrp device with: serial=EAR04Z7B2,master_clock_rate=50e6...
> Detected Device: B200
> Operating over USB 3.
> Initialize CODEC control...
> Initialize Radio control...
> Performing register loopback test...
> pass
> Performing CODEC loopback test...
> CODEC loopback test passed
> Asking for clock rate 50.00 MHz...
> Actually got clock rate 50.00 MHz.
> Performing timer loopback test...
> Timer loopback test passed
> Using Device: Single USRP:
>   Device: B-Series Device
>   Mboard 0: B200
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
> Setting RX Rate: 50.00 Msps...
> Actual RX Rate: 50.00 Msps...
> Setting RX Freq: 5750.00 MHz...
> Actual RX Freq: 5750.00 MHz...
> Setting RX Gain: 55.00 dB...
> Actual RX Gain: 55.00 dB...
> Waiting for "lo_locked": ++
> locked.
> Number of requested samples: 525000
> Buffer size: 525000
> Tick
> Number of received samples: 525000
> Has timespec: YesTime of first sample: 10.2594
> Fragmented: No  Fragmentation offset: 0
> Start of burst: NoEnd of burst: No
> Error Code: ERROR_CODE_NONEOut of sequence: No
> Done!
>
>
>
>
>
> ___
> 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] Spurious emissions using B200

2018-04-19 Thread Nate Temple via USRP-users

Hi Carmine,

Can you please post a plot showing the spurious emissions you're seeing?

If possible, if you can include how you're generating the plots (the
script) would be useful as well.

What version of UHD are you using?

What color is the PCB of your B200?

What USRP are you using as a receiver ?

Regards,
Nate Temple

On Tue, Apr 10, 2018 at 1:09 AM, carmine via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear community,
>
> I implemented C++ codes of the transmitter and receiver using UHD API,
> starting from example provided by Ettus.
>
> Until now, I'm testing my codes using a coax cable for connecting the
> USRPs (a USRP used as transmitter and a USRP used as receiver).
>
> In this setup, just before the beginning of data transmission, I found two
> spurious emissions (around correlated 1 samples per times), which
> precede the data. I need to synchronize Tx and Rx, so this spurious
> emissions became a nightmare for me.
>
> My transmitter code is very easy:
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make("");
>
> //Lock mboard clocks
> usrp->set_clock_source("internal");
> //set the sample rate
> usrp->set_tx_rate(1000);
> //set the center frequency
> uhd::tune_request_t tune_request;
> tune_request = uhd::tune_request_t(24.0, 10.0);
> usrp->set_tx_freq(tune_request);
> //set the rf gain
> usrp->set_tx_gain(40);
> usrp->set_tx_bandwidth(1000);
> //set the antenna
> usrp->set_tx_antenna("TX/RX");
>
> boost::this_thread::sleep(boost::posix_time::seconds(1)); //allow for
> some setup time
>
> //Check Ref and LO Lock detect
> std::vector sensor_names;
> sensor_names = usrp->get_tx_sensor_names(0);
> if (std::find(sensor_names.begin(), sensor_names.end(), "lo_locked") !=
> sensor_names.end()) {
> uhd::sensor_value_t lo_locked = usrp->get_tx_sensor("lo_locked",0);
> std::cout << boost::format("Checking TX: %s ...") %
> lo_locked.to_pp_string() << std::endl;
> UHD_ASSERT_THROW(lo_locked.to_bool());
> }
> sensor_names = usrp->get_mboard_sensor_names(0);
>
> //create a transmit streamer
> uhd::stream_args_t stream_args("fc32", "sc16");
> uhd::tx_streamer::sptr tx_stream = usrp->get_tx_stream(stream_args);
>
> uhd::tx_metadata_t md;
> md.start_of_burst = true;
> md.end_of_burst = false;
>
> // Some operations for creating IQ samples stored in float tx_vec
>
> for(n_real=0;n_real<1000;n_real++) tx_stream->send((const
> void**)&tx_vec[0], 80, md);
>
> I'm receiving the dump using the executable script rx_samples_to_file.
>
> Can anyone help me, please?
>
> Thanks in advance,
>
> Carmine
>
>
> ___
> 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 Subdevice Specification

2018-04-23 Thread Nate Temple via USRP-users

Hi Sarah,

For four channels on the N310 and UHD 3.11.0.1, the subdev spec will be
"A:0 B:0 C:0 D:0".

What sample rate are you running at ?

Regards,
Nate Temple



On Mon, Apr 23, 2018 at 6:50 PM, Sarah Tran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> I recently got the N310, and I got one of the example programs from
> gr-digital to run on it. However because I didn’t specify a subdevice, it
> only uses one channel. I want to be able to TX on all 4 channels but I
> couldn’t get the right subdevice specification syntax correct. I tried “A:0
> B:0” just to get maybe two channels transmitting, but it just printed out a
> lot of ‘S’ and ‘L’s. I also tried the syntax for the E310 “A:A A:B” which
> didn’t work either. I know this is just my error, but I can’t find much
> documentation on the correct syntax to use! I am using UHD version 3.11 and
> GNU Radio 3.7.11.1. Any help is greatly appreciated!
>
>
>
>
>
> -Sarah Leony
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 underflows with tx_rate 100Msps

2019-11-25 Thread Nate Temple via USRP-users

Hi Voonna,

What is your CPU frequency?

What kind of NIC are you using?

If your NIC supports DPDK, I would recommend trying to use the DPDK
transport, but you will need to update to UHD 3.14.1.1 to support DPDK with
the X310.


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

Regards,
Nate Temple

On Thu, Nov 21, 2019 at 9:35 AM voonna santosh via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Michael,
> I am experiencing lots of underflows when I use benchmark_rate example
> app. Following is the configuration:
>
> Host processor: Intel® Xeon® Processor D-1500 System on Chip (SoC)
> Host OS: Centos 7
> UHD: release_003_010_001_000
> SDR HW: X300 with UBX-160 (Calibration done as documented)
> Eth link: SFP
>  - Maximum socket buffer sizes (wmem_max, rmem_max)
>  - MTU 9000
>  - Tx/Rx descriptors (sudo ethtool -G  tx 4096 rx 4096)
>  - thread priority set to 1
> CPU usage: Only two CPUs are being used, but rest of the cores are free
> and the host is headless(No CPU consuming apps).
>
>   If I test rx_rate with 200Msps, it works well. But when I use tx_rate
> with 100Msps, I could see lots of underflows (Us).
>
> ./benchmark_rate --args="addr=192.168.40.2" --tx_rate=100e6
> --channels="0" --duration 200
> linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39); Boost_105800;
> UHD_003.010.001.HEAD-0-g929e3b32
>
>
> Creating the usrp device with: addr=192.168.40.2...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
> Rev 0.929b
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1179.5MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1184.4MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> Using Device: Single USRP:
>   Device: X-Series Device
>   Mboard 0: X300
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
>   RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: Unknown (0x) - 0
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>   TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: Unknown (0x) - 0
>
> Setting device timestamp to 0...
> Testing transmit rate 100.00 Msps on 1 channels
> U ... Lots of
> underflows
>
> Thanks in advance.
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD and FPGA Image mismatch error

2019-12-02 Thread Nate Temple via USRP-users

Hi Bisma,

You should download the FPGA images for your installed version of UHD (with
uhd_images_downloader) and then write a new FPGA image to the E320 using
the uhd_image_loader utility.

UHD will work on Ubuntu 19.x.

Regards,
Nate Temple

On Wed, Nov 6, 2019 at 2:38 AM Bisma Amjad via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi there,
>
>
> · I have installed GNU Radio using PyBombs from
> http://ecee.colorado.edu/~mathys/ecen4652/SDRsoftware/GNURadioInstall.html
>
>
>
> · UHD was installed from
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>
>
>
> · GNU Radio works fine. I’ve created an FM Radio application on
> it.  USRP E320 is also detected on the system. However, when the flowgraph
> is executed on GNU Radio, following error shows up:
>
>
>
> *RuntimeError: FPGA component ‘noc_shell’ is revision 2 and UHD supports
> revision 3. Please either upgrade the FPGA image (Recommended) or downgrade
> UHD.*
>
> *Troubleshooting:*
>
> ·As indicated by few web sources, Pybombs could’ve created issues during
> GNU Radio installation. So, I re-installed GNU radio and UHD without using
> pybombs (from
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux)
> .
>
>  But the error still persists.
>
>
>
> *RuntimeError: FPGA component ‘noc_shell’ is revision 2 and UHD supports
> revision 6. Please either upgrade the FPGA image (Recommended) or downgrade
> UHD.*
>
>
>
>
>
> ·Moreover, the required installation libraries for UHD are supported for
> Ubuntu version 18.10 or less. Whereas, our system has Ubuntu version 19.0.
> Could this be the possible reason for this issue? Should I downgrade Ubuntu
> to 18.10?
> ___
> 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] Problems running uhd/examples/tx_samples_from_files on E310

2019-12-02 Thread Nate Temple via USRP-users

Hi Z. Cao,

What version of UHD are you running on your old E310?

Generally the max sample rate supported by the ARM is ~10 MS/s.

With regards to the sample rate error you saw when trying to run at 40
MS/s, try adding the device args: "master_clock_rate=40e6".

>Does RFNoC included in the default image in E310 now? If so, UHD 3.14.1
branch and all its examples supports RFNoC? Which E310 image doesn’t
include RFNoC?

With UHD 3.15 RFNoC will be enabled by default, on 3.14.x, it must be
enabled with the cmake arg -DENABLE_RFNOC=ON.

Regards,
Nate Temple

On Thu, Oct 31, 2019 at 12:09 PM zcao--- via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> We are testing a newly acquired E310 by running UHD example
> tx_samples_from_files.cpp. The data file we use was used in testing other
> USRP E310 devices so we know it is correct. For this particular E310, we
> ran into underrun problem. The screen output looks like the following:
>
> root@ettus-e3xx-sg3:~/localinstall#
> usr/lib/uhd/examples/tx_samples_from_file --rate 400 --freq 251200
> --ant TX/RX --gain 30 --bw 100 --file ./pkt_0238_2.dat --repeat --spb
> 5000
>
> Creating the usrp device with: ...
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_3.14.1.HEAD-0-gbfb9c1c7
> [INFO] [E300] Loading FPGA image:
> /home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_sg3.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Detecting internal GPS
>  [INFO] [E300] GPSDO found
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [WARNING] [RFNOC] [legacy_compat] No FIFO detected. Higher transmit rates
> may encounter errors.
> Using Device: Single USRP:
>   Device: E-Series Device
>   Mboard 0: E3XX SG3
>   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
>   RX Channel: 2
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   RX Channel: 3
> 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
>   TX Channel: 2
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
>   TX Channel: 3
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting TX Rate: 4.00 Msps...
> Actual TX Rate: 4.00 Msps...
>
> Setting TX Freq: 2512.00 MHz...
> Setting TX LO Offset: 0.00 MHz...
> Actual TX Freq: 2512.00 MHz...
>
> Setting TX Gain: 30.00 dB...
> Actual TX Gain: 30.00 dB...
>
> Setting TX Bandwidth: 1.00 MHz...
> Actual TX Bandwidth: 1.00 MHz...
>
> Checking TX: LO: locked ...
> Press Ctrl + C to stop streaming...
>
> ^C
> Done!
> U
> UU[INFO] [E300] Loading FPGA image:
> /home/root/localinstall/usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit...
> [INFO] [E300] FPGA image loaded
>
> Any suggestions on where we should go from here are appreciated. We have a
> few questions.
>
> 1. Does RFNoC included in the default image in E310 now? If so, UHD 3.14.1
> branch and all its examples supports RFNoC? Which E310 image doesn’t
> include RFNoC?
>
> 2. On our old E310 platforms acquired 3 years ago, we can run TX rate
> @40MSPS. However, for this E310, there is a warning sign above says :
> [WARNING] [RFNOC] [legacy_compat] No FIFO detected. Higher transmit rates
> may encounter errors.
>
> In fact, we tried to set rate high @40MSPS, we got the following messages:
>
> [WARNING] [MULTI_USRP] The hardware does not support the requested TX
> sample rate:
> Target sample rate: 40.00 MSps
> Actual sample rate: 16.00 MSps
>
>
> Are we using the right FPGA images?
>
>
> Thanks,
> Z. Cao
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [USRP-users] Custom OOT C++ on USRP

2019-12-02 Thread Nate Temple via USRP-users

Hi Michael,

Please see this app note which covers cross compiling UHD/GR/gr-ettus.

You can treat your OOT the same as gr-ettus.

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

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

Regards,
Nate Temple

On Mon, Nov 25, 2019 at 3:09 PM Michael Bassi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
> I have created my first GNU Radio Out of Tree (OOT) module in C++
> I have tested it in GNU Radio Companion (GRC) and it works as expected.
> I would now like to run it from my USRP device (E312).
> Currently my USRP does not recognize my custom module. Which makes sense!
> It is not a part of the GNU library
> I have tried copying my gr-custom_module across to the device root
> directory, but obviously the dependencies are not setup.
> I have then tried running the standard cmake commands from the build
> directory (on the USRP), but these don't work.
>
> I got some tips on stack-overflow:
>
> https://stackoverflow.com/questions/58794210/running-a-gnu-radio-custom-out-of-tree-oot-module-on-a-usrp-device/58808077?noredirect=1#comment103906511_58808077
>
> I was told to:
>
>- Set up a cross-compilation tool-chain on my PC,
>- Cross-compile my module, and
>- install it to the correct directory structure, finally
>- copying over the thus generated filesystem tree to your device
>
> How do I do this?
>
> I'm currently reading this wiki
> https://wiki.gnuradio.org/index.php/Cross_compile_GNU_Radio_and_install_on_target.
> It says:
> We have our environment set up such that we've run the environment script
> provided by the SDK and we can talk to the device. To build the program, we
> just need to follow standard instructions for our build system to make sure
> it uses the right tools from the SDK. The environmental variables take care
> of a great many of these issues. For CMake-based projects like GNU Radio
> and GNU Radio out-of-tree modules, we also provide a toolchain file.
> Setting up the project is then as simple as: (and then some special cmake
> commands)
>
> What is this "environment script provided by the SDK"?
> I can currently connect to my device via ssh. Though I'm assuming this is
> something different?
> "we just need to follow standard instructions..." - what standard
> instructions"
> what toolchain file?
>
> Thanks again for any help!
> Mike
>
>
> ___
> 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] Phase relation between RX/TX LO

2019-12-07 Thread Nate Temple via USRP-users

Hi Luke,

What version of UHD are you using?

There was an issue with the DUC/DDC phase accumulator's resolution, but it
was fixed with UHD 3.14.1.0.

The threads below are were this was identified:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059914.html
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-April/059465.html

As recommended from the thread:

Phase may change each time streamers are created, but the phase between TX
and RX should remain consistent during streaming.  Tuning must be done with
timed commands and a consistent time delta between the tune time of TX and
RX must be maintained that is greater than 500us to maintain the coherence
across re-tunes.



If you're using the QT widget without any modifications, it will not be
using timed commands, you'll need to generate the python file and manually
add in the timed commands to the set_freq calls.

Also, if I remember correctly, even with the phase accumulator fix, there
was some caveats to which frequencies would stay coherent. I need to go
back and look at some notes on it.

Regards,
Nate Temple

On Fri, Dec 6, 2019 at 11:11 PM Lukas Haase via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Marcus,
>
> Marcus wrote:> On 12/06/2019 09:33 PM, Lukas Haase via USRP-users wrote:
> >> Hi,
> >>
> >> I am using the USRP X310+UBX160 with gnuradio to perform very
> >> precicse phase measurements: The TX transmits a CW which is
> >> reflected by an object and received by the RX.
> >>
> >> The received phase provides an accurate estimate of the distance
> >> to>> the reflected object, once the fixed phase relation (between
> >> TX/RX- LO, filters, cables etc.) has been subtracted out.
> >>
> >> This works nicely so far.
> >>
> >> However, I need my system to work across power cycles, and more
> >> importantly, across different frequencies: The goal is to perform
> >> fast frequency hopping and obtain the phase for each frequency.
> >>
> >> Unfortunately it seems that the phase relationship between TX/RX
> >> is>> lost when I tune the USRP to a different center frequency and
> >> back. For example, I have the center frequency set to 900 MHz and
> >> the phase. I measure (by computing the angle of the I/Q samples)
> >> stays constant. But when I set the center frequency to 950 MHz and
> >> then back to 900 MHz, the phase has a random value again.
> >>
> >> Is there any way to avoid this? Or is there any way to lock the LO
> >> phase to a particular phase when>> tuning back to the original
> >> frequency?
> >
> > It *might* be possible to phase-synchroniez the RX and TX LOs using
> > timed commands combined, possibly with INTEGER_N tuning.
> >
> > There's an APP Note on phase-synchronization here:
> >
> >
> https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices
>
> Thank you, I'm studying this right now.
>
> > My gut tells me this is going to be hard, though, since the
> > requirement is to bring a synthesizer back to the same relative phase
> > it had when it was previously tuned to the same frequency.
>
> Yes, this is about multiple devices, certainly hard.
>
> Let's take a step back and I am happy when just the TX/RX LO on a single
> device is synchronized.
>
> This is what I do right now: In gnuradio, I generate a sinudoid (fif=1MHz)
> at baseband and transmit (UHD: USRP Sink) it with fcenter=900MHz.
> Then I receive (UHD: USRP Source) it and multiply it with "-fif" again.
> This gives me a constant signal in I and Q.
>
> The center frequency is configured via "QT GUI Entry". I enter 900e6 and
> press enter. Then I plot "Complex to Arg". As long as I do nothing this
> value is fairly constant (somewhere between -pi and pi).
>
> Now I hit enter again in the QT GUI Entry. Although it's the same center
> frequency, the USRP retunes and the phase jumps to another value.
>
> Now let's look at the USRP block diagram:
>
> https://kb.ettus.com/images/1/16/2920_simplified_system_diagram.gif
>
> Yes, both TX and RX path have a separate PLL and VCO.
> However, the *reference* for this PLL is the same. Hence the PLL should
> lock to the phase of this reference (after all, it's a *phase* locked
> loop). And this implies that the *relative* phase between TX and RX, for a
> given frequency, should be fixed -- at least as long as the USRP is powered.
>
> So, how can it be that this is not the case?!
>
>
> There is just a single suspicion that I have: DSP on gnuradio (host
> computer runs a different clock) versus USRP clock. What do I mean by that?
> Initially I was transmitting a pure CW (in gnuradio, connecting a "Constant
> Source" to USRP Sink and setting the frequency to fcenter+fif). However,
> downconversion was performed with fcenter only and multiplying with fif in
> gnuradio. I could see a slow phase drift. It took me hours to figure out
> that this is caused by the different clocks. The effect was gone once I
> also generated the transmitted waveform in gnuradio.
> In order to fix this, I w

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-07 Thread Nate Temple via USRP-users

Hi Luke,

There is an example of setting timed commands in a custom block for the
TwinRX in gr-doa here:

https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L101-L121

You can do this with the standard UHD source/sink blocks, by first making
your flowgraph, then generate the .py in GRC, then open up that .py file
and modify it to add the timed command calls.

If you modify the GRC and regenerate the .py, it'll overwrite your changes.

Regards,
Nate Temple

On Sat, Dec 7, 2019 at 11:35 AM Lukas Haase  wrote:

> Hi Nate,
>
> Thank you so much, this is very useful.
>
> I am using Gnuradio 3.7 on Windows and according to
> uhd_cal_rx_iq_balance.exe for example, UHD version is
> UHD_3.14.1.HEAD-0-g5491b80e. That should have the issue fixed, right?
>
>
> Would you mind to elaborate briefly how to get the "timed command"? (I am
> working with grc for a few weeks and I am fairly new to it)
>
> Just conceptually how to do it would be amazing or a pointer to an example
> that I could modify even better!
>
> For example, I went through the example at
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.1._Intro_to_Using_GNU_Radio_with_Python
> but I do not know if this really creates these "timed commands".
> Yes, I can store the frequency value in a variable but how do I ensure
> that it's updated exactly at a rate of say, 1/100ms?
>
> Also: Why wouldn't such an approach cause issues due to the clock
> differences between the host computer and the USRP?
>
> And if you are able to dig up any more information about the additional
> caveats you were mentioning, that would be truly amazing.
>
> Thanks a lot,
> Luke
>
>
>
>
>
> Gesendet: Samstag, 07. Dezember 2019 um 12:05 Uhr
> Von: "Nate Temple" 
> An: "Lukas Haase" 
> Cc: "USRP-users@lists.ettus.com" 
> Betreff: Re: [USRP-users] Phase relation between RX/TX LO
>
> Hi Luke,
>
> What version of UHD are you using?
>
> There was an issue with the DUC/DDC phase accumulator's resolution, but it
> was fixed with UHD 3.14.1.0.
>
> The threads below are were this was identified:
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059914.html
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-April/059465.html
>
> As recommended from the thread:
>
> Phase may change each time streamers are created, but the phase between TX
> and RX should remain consistent during streaming.  Tuning must be done with
> timed commands and a consistent time delta between the tune time of TX and
> RX must be maintained that is greater than 500us to maintain the coherence
> across re-tunes.
>
>
>
> If you're using the QT widget without any modifications, it will not be
> using timed commands, you'll need to generate the python file and manually
> add in the timed commands to the set_freq calls.
>
> Also, if I remember correctly, even with the phase accumulator fix, there
> was some caveats to which frequencies would stay coherent. I need to go
> back and look at some notes on it.
> Regards,
> Nate Temple
>
> On Fri, Dec 6, 2019 at 11:11 PM Lukas Haase via USRP-users <
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:Hi
> Marcus,
>
> Marcus wrote:> On 12/06/2019 09:33 PM, Lukas Haase via USRP-users wrote:
> >> Hi,
> >>
> >> I am using the USRP X310+UBX160 with gnuradio to perform very
> >> precicse phase measurements: The TX transmits a CW which is
> >> reflected by an object and received by the RX.
> >>
> >> The received phase provides an accurate estimate of the distance
> >> to>> the reflected object, once the fixed phase relation (between
> >> TX/RX- LO, filters, cables etc.) has been subtracted out.
> >>
> >> This works nicely so far.
> >>
> >> However, I need my system to work across power cycles, and more
> >> importantly, across different frequencies: The goal is to perform
> >> fast frequency hopping and obtain the phase for each frequency.
> >>
> >> Unfortunately it seems that the phase relationship between TX/RX
> >> is>> lost when I tune the USRP to a different center frequency and
> >> back. For example, I have the center frequency set to 900 MHz and
> >> the phase. I measure (by computing the angle of the I/Q samples)
> >> stays constant. But when I set the center frequency to 950 MHz and
> >> then back to 900 MHz, the phase has a random value again.
> >>
> >> Is there any way to avoid this? Or is there any way to lock the LO
> >> phase to a particular phase when>> tuning back to the original
> >> frequency?
> >
> > It *might* be possible to phase-synchroniez the RX and TX LOs using
> > timed commands combined, possibly with INTEGER_N tuning.
> >
> > There's an APP Note on phase-synchronization here:
> >
> >
> https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices[https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices]
>
> Thank you, I'm studying this right now.
>
> > My gut tells me this is going to be hard, though, since the
> > re

Re: [USRP-users] Default RFNoC image for N310 does not compile

2019-12-09 Thread Nate Temple via USRP-users

Hi Robert,

Thanks for the bug report.

If you're just trying to use RFNoC at this point, I would recommend to
stick with the latest stable release, which at this time is v3.14.1.1.

Note, 3.14.x.x UHD will require Vivado 2017.4.


Regards,
Nate Temple

On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all!
>
> I tried to compile the default RFNoC image for the N310, using UHD on tag
> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>
> Running "make N310_RFNOC_XG", the IP cores are compiled successfully, but
> then Vivado shows the following errors:
>
> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
> 'STR_SINK_FIFOSIZE'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-196] conditional expression could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
> ERROR: [Synth 8-6156] failed synthesizing module
> 'noc_shell__parameterized9'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>
> The full build.log file is attached. I did not modify any files, just
> trying to compile the RFNoC example as provided.
>
>
>
>
> Btw I also tried to build the default image with "make N310_XG", this one
> compiles but failed later during DRC:
>
> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
> For example, the following two ports in this bank have conflicting VCCOs:
> ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15]
> (LVCMOS18, requiring VCCO=1.800)
> [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
>
>
> ___
> 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] Default RFNoC image for N310 does not compile

2019-12-09 Thread Nate Temple via USRP-users

Hi Robert,

So this is a bug related to Vivado, you will need to install this linked
below patch and it should resolve it.

https://www.xilinx.com/support/answers/71898.html

Regards,
Nate Temple

On Mon, Dec 9, 2019 at 10:38 AM Nate Temple  wrote:

> Hi Robert,
>
> Thanks for the bug report.
>
> If you're just trying to use RFNoC at this point, I would recommend to
> stick with the latest stable release, which at this time is v3.14.1.1.
>
> Note, 3.14.x.x UHD will require Vivado 2017.4.
>
>
> Regards,
> Nate Temple
>
> On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all!
>>
>> I tried to compile the default RFNoC image for the N310, using UHD on tag
>> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>>
>> Running "make N310_RFNOC_XG", the IP cores are compiled successfully,
>> but then Vivado shows the following errors:
>>
>> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
>> 'STR_SINK_FIFOSIZE'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
>> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>> ERROR: [Synth 8-196] conditional expression could not be resolved to a
>> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
>> ERROR: [Synth 8-6156] failed synthesizing module
>> 'noc_shell__parameterized9'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
>> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
>> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
>> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
>> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
>> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>>
>> The full build.log file is attached. I did not modify any files, just
>> trying to compile the RFNoC example as provided.
>>
>>
>>
>>
>> Btw I also tried to build the default image with "make N310_XG", this one
>> compiles but failed later during DRC:
>>
>> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
>> For example, the following two ports in this bank have conflicting VCCOs:
>> ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15]
>> (LVCMOS18, requiring VCCO=1.800)
>> [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
>>
>>
>> ___
>> 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] Default RFNoC image for N310 does not compile

2019-12-10 Thread Nate Temple via USRP-users

Hi Robert,

This patch/line change detailed below should resolve that issue and will be
included in the official 3.15.0.0 release:

---
 usrp3/lib/rfnoc/noc_shell.v | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/usrp3/lib/rfnoc/noc_shell.v b/usrp3/lib/rfnoc/noc_shell.v
index 927f40a70..732d41afa 100644
--- a/usrp3/lib/rfnoc/noc_shell.v
+++ b/usrp3/lib/rfnoc/noc_shell.v
@@ -267,7 +267,7 @@ module noc_shell
   .o_tdata({set_addr_bclk[8*k+7:8*k],
set_data_bclk[32*k+31:32*k]}),
   .o_tvalid(set_stb_bclk[k]), .o_tready(set_stb_bclk[k]));

-   localparam [31:0] STR_SINK_FIFO_SIZE_BYTES =
2**(STR_SINK_FIFOSIZE[8*k+7:8*k]+3);
+   localparam [31:0] STR_SINK_FIFO_SIZE_BYTES = (k < INPUT_PORTS) ?
2**(STR_SINK_FIFOSIZE[8*k+7:8*k]+3) : 0;
// "Lines" is the most useful unit for the command FIFO size, since
// commands take either 2 or 3 lines. Software can do the rest of
the
// math to figure out how many actual command packets it can send.



Regards,
Nate Temple

On Tue, Dec 10, 2019 at 8:46 AM  wrote:

> Hi Nate!
>
>
>
> I followed the guide in
> https://files.ettus.com/manual/md_usrp3_build_instructions.html, thus
> ended up with Vivado 2018.3 and then later found out this requires UHD
> 3.15. Thanks for pointing me to the Vivado bug. I thought with 2018.3.1
> this would be fixed, but apparently that is not the case. Now I went back
> to 2018.3 (clean re-install) and installed the patch AR#71898. The standard
> N310 image compiles fine now.
>
>
>
> The other error
>
> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
> 'STR_SINK_FIFOSIZE'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>
> seems to be happening only for few specific RFNoC blocks (fosphor and
> split_stream, specifically). Leaving these out, the RFNoC image does
> compile. Not sure what exactly is the problem, though. The recent commit
> https://github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9
> did not help (tried both versions, neither of them works).
>
>
>
> Regards
>
> Robert
>
>
>
>
>
> *From:* Nate Temple [mailto:nate.tem...@ettus.com]
> *Sent:* Monday, December 09, 2019 8:43 PM
> *To:* Pöhlmann, Robert
> *Cc:* USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Default RFNoC image for N310 does not compile
>
>
>
> Hi Robert,
>
>
>
> So this is a bug related to Vivado, you will need to install this linked
> below patch and it should resolve it.
>
>
>
> https://www.xilinx.com/support/answers/71898.html
>
>
>
> Regards,
>
> Nate Temple
>
>
>
> On Mon, Dec 9, 2019 at 10:38 AM Nate Temple  wrote:
>
> Hi Robert,
>
> Thanks for the bug report.
>
> If you're just trying to use RFNoC at this point, I would recommend to
> stick with the latest stable release, which at this time is v3.14.1.1.
>
> Note, 3.14.x.x UHD will require Vivado 2017.4.
>
>
> Regards,
> Nate Temple
>
>
>
> On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi all!
>
>
>
> I tried to compile the default RFNoC image for the N310, using UHD on tag
> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>
>
>
> Running "make N310_RFNOC_XG", the IP cores are compiled successfully, but
> then Vivado shows the following errors:
>
>
>
> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
> 'STR_SINK_FIFOSIZE'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-196] conditional expression could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
> ERROR: [Synth 8-6156] failed synthesizing module
> 'noc_shell__parameterized9'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>
>
>
> The full build.log file is attached. I did not modify any files, just
> trying to compile the RFNoC example as provided.
>
>
>
>
>
>
>
> Btw I also tried to build the default image with "make N310_XG", this one
> compiles but failed later during DRC:
>
> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
> For example,

Re: [USRP-users] transmitting on two channels with replay block

2019-12-11 Thread Nate Temple via USRP-users

Hi Thomas,

One option instead of using the Replay block could be to stream 2x 200e6
from your host.

On the X310, this requires using a SRAM image and DPDK. DPDK support was
added with UHD 3.14.1.0 for the X310, I'd suggest to use 3.14.1.1 at this
time though.

Some links on DPDK:

https://www.dpdk.org/
http://files.ettus.com/manual/page_dpdk.html

I've been able to run 2x2 @ 200e6 with the X310 with DPDK using a 4 GHz CPU.

./benchmark_rate --rx_rate 200e6 --rx_channels 0,1 --tx_rate 200e6
--tx_channels 0,1 --args
"addr=192.168.10.2,second_addr=192.168.20.2,use_dpdk=1,num_recv_frames=512,enable_tx_dual_eth=1,skip_ddc=1,skip_duc=1"

num_recv_frames=512 can help if you're seeing overflows.

enable_tx_dual_eth=1 is required for 2x TX @ 200e6

skip_ddc=1,skip_duc=1 can help as well since you'd be sending at full rate.



Regards,
Nate Temple

On Wed, Dec 11, 2019 at 7:03 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I do not think it is possible using the stock FPGA image.  However, I can
> think of a couple of possibilities:
>
>- On the N310, Ettus includes 4 FIFO blocks (rather than the DmaFIFO
>which used the off-FPGA RAM for memory), to provide capability for 4x125
>MS/s streaming. Perhaps if you built an X310 FPGA image with 2 such FIFO
>blocks, you could use these rather than the DmaFIFO and achieve the desired
>streaming.  Note that this requires a Vivado license to build your own FPGA
>image, but does not require FPGA experience because you would be building
>an image with "stock" blocks.  One caution though is that streaming at this
>very high rate still requires a high performance host and so it is still
>possible that you would have underruns if your host could not keep up.  If
>you go this route, I believe you will likely need to use the "DPDK"
>capability which is a bit of a pain to configure and get it working
>properly.
>- Another possibility is to create a custom RFNoC block that is
>similar to the replay block but that uses FPGA memory to store a fixed
>duration waveform and then plays it out cyclically like the replay block.
>The Ettus 'window' RFNoC block provides a good example of how to store
>coefficients and play them out repeatedly.  But, making the needed
>modifications is not a trivial task except for someone who is pretty good
>at FPGA programming.
>
> Given that you were trying the replay block, I'm guessing that your Tx
> waveforms are of fixed duration.  What is the duration (in number of
> samples) that you require?
> Rob
>
> On Wed, Dec 11, 2019 at 5:05 AM Thomas Harder 
> wrote:
>
>> Thank you Rob for this comment.
>>
>> But I am not sure if I understand you correctly. Do you want to say, that
>> it is *IMPOSSIBLE* to stream TX two different waveforms synchronized  on
>> the 2 channels of the x310 with the full bandwidth of 200MS/s on each
>> channel?
>>
>> That is what I am trying the last 6 months full time, starting with
>> Labview under windows and then UHD under Linux with a Dell Precision 5820
>> desktop (16GB RAM, Intel Xeon W-2125 CPU@ 4.GHz x8) with MXI connection,
>> dual 10Gbit connection(Intel X520-DA2), the replay block recently: always
>> the same result: continuous underruns.
>>
>> If you can confirm that this is not possible without an important FPGA
>> change (because I have no experience in this field and I have not the time
>> to invest into it), I must search for another solution to create two
>> different synchronized RF waveforms with 160MHz bandwidth (optical,
>> electronical,…) because this will be just a part of my experimental setup
>> but it is crucial to go on .
>>
>> I am thankful for any advise,
>>
>> Thomas
>>
>>
>>
>>
>>
>> *From: *Rob Kossler 
>> *Sent: *Tuesday, December 10, 2019 5:01 AM
>> *To: *Thomas Harder 
>> *Cc: *Sam Reiter ; usrp-users@lists.ettus.com
>> *Subject: *Re: [USRP-users] transmitting on two channels with replay
>> block
>>
>>
>>
>> Apart from solving the underrun issue, there is also an issue with
>> synchronization.  The replay block doesn't presently support timed commands.
>>
>>
>>
>> And, as a side note, the issue with streaming from the host is not just
>> the host.  The DMA FIFO has a maximum bandwidth of something like 600 MS/s
>> (combination of all inputs and outputs) that precludes streaming 400 MS/s
>> in and out of the block simultaneously.  So, even if the host could keep
>> up, the FIFO could not.
>>
>> Rob
>>
>>
>>
>> On Mon, Dec 9, 2019 at 4:34 AM Thomas Harder via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hi Sam,
>>
>> Thank you for your reply.
>>
>> This morning I set the MCR to 184.32 and I am still having continuous
>> underruns using also
>>
>> replay_ctrl->get_record_fullness
>>
>> for both channels.
>>
>>
>>
>> But since I need the full bandwidth of 160MHz I would like implement a
>> second replay block in my fpga image.
>>
>>
>>
>> Could anyone help me with this?
>>
>> I am really new in

Re: [USRP-users] transmitting on two channels with replay block

2019-12-11 Thread Nate Temple via USRP-users

On Wed, Dec 11, 2019 at 9:33 AM Nate Temple  wrote:

> Hi Thomas,
>
> You will need to apply these changes below to the
> fpga-src/usrp3/top/x300/rfnoc_ce_default_inst_x310.v file. This will add
> additional SRAM FIFOs, which is basically what the "XGS" / SRAM image is.
> Make sure to start with the v3.14.1.1 fpga sources. (run git submodule
> init; git submodule update; in your UHD repo after checking out v3.14.1.1).
>
> 
>
> diff --git a/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> b/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> index d20a64962..bcb4c3c32 100644
> --- a/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> +++ b/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> @@ -1,4 +1,4 @@
> -  localparam NUM_CE = 4;  // Must be no more than 10 (6 ports taken by
> transport and IO connected CEs)
> +  localparam NUM_CE = 6;  // Must be no more than 10 (6 ports taken by
> transport and IO connected CEs)
>
>   wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
>   wire [63:0]  ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
> @@ -46,7 +46,9 @@
>   genvar n;
>   generate
> for (n = 4; n < NUM_CE; n = n + 1) begin
> -  noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
> +  noc_block_axi_fifo_loopback #(
> +.STR_SINK_FIFOSIZE(15)
> +  ) inst_noc_block_axi_fifo_loopback (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[n]), .i_tlast(ce_o_tlast[n]),
> .i_tvalid(ce_o_tvalid[n]), .i_tready(ce_o_tready[n]),
>
> 
>
>
> After making these modifications to the FPGA sources, you can build a FPGA
> image with the commands:
>
> cd fpga-src/usrp3/top/x300/
> source setupenv.sh
> make X310_XG
>
> Note: Even though you are calling X310_XG, it is really a "XGS" image
> since it has the additional SRAM fifos.
>
> After that has completed building, you should write that FPGA image to the
> X310 using uhd_image_loader.
>
> uhd_image_lodaer --args "addr=192.168.40.2,type=x300" --fpga-path
> /path/to/x300.bit
>
> After the FPGA image load and restarting the USRP, run uhd_usrp_probe and
> at the end of the output where the RFNoC blocks are listed, you should see
> two additional FIFO blocks:
>
> FIFO_0
> FIFO_1
>
>
>
>
>
> Random performance tuning notes:
>
> * Ensure your CPU governor is set to performance:
>
> sudo apt install cpufrequtils
>
> To set performance for all cores:
>
> for ((i=0;i<$(nproc);i++)); do sudo cpufreq-set -c $i -r -g performance;
> done
>
>
> Verify with:
>
> cpufreq-info
>
> * Set your network buffers
>
> sudo sysctl -w net.core.rmem_max=62500
> sudo sysctl -w net.core.wmem_max=62500
>
> * Set the MTU to 8000 on your 10Gb NICs
>
> * Ensure you have pthreads enabled for your user
>
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling
>
> http://files.ettus.com/manual/page_general.html#general_threading
>
>
> * Disable hyper threading in bios. This will typically give about a 10%
> boost in core performance if you can work without the additional cores.
> You'll need to update your cpu core list in DPDK.
>
> * Disable KPTI for spectra/meltdown. I would recommend to try disabling
> the KPTI protections for your CPU if the machine is offline, you may see a
> 10-15% performance increase.
>
> This can be done by adding the lines below to your /etc/default/grub at
> GRUB_CMDLINE_LINUX_DEFAULT="", then running sudo update-grub and rebooting.
>
> pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
>
> Note, this disables protections against Meltdown/Spectra (links below). So
> if you try to do this, I would recommend disconnecting that host from any
> internet connected network.
>
> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>
> * There are additional recommendations here from Intel on various
> adjustments you can do to improve performance with DPDK:
> http://doc.dpdk.org/guides/linux_gsg/nic_perf_intel_platform.html
>
> Specifically I would recommend to try section 10.1.3 #3 where you isolate
> the CPU cores that are used for DPDK.
>
> * Here is a performance report from Intel on DPDK 17.11:
> https://fast.dpdk.org/doc/perf/DPDK_17_11_Intel_NIC_performance_report.pdf
>
> In the tables of boot and bio's settings the additional CPU options of
> nohz_full="" and rcu_nocbs="" are added to their kernel configs, this may
> help as well.
>
> Additionally they made the changes listed below:
>
> CPU Power and Performance Policy  (you should already be
> doing this)
> CPU C-state Disabled
> CPU P-state Disabled
> Enhanced Intel® Speedstep® Tech Disabled
> Turbo Boost Disabled
>
>
>
>
> Regards,
> Nate Temple
>
> On Wed, Dec 11, 2019 at 9:18 AM Thomas Harder 
> wrote:
>
>> R

Re: [USRP-users] Does USRP B210 support 2x2 30.72Mhz sampling rate?

2019-12-12 Thread Nate Temple via USRP-users

Hi Padorin,

Yes the B210 supports 2x2 @ 30.72e6, but is dependent upon your host system
and USB controllers.

You can try using sc12 OTW format which may help:

./benchmark_rate --rx_otw sc12 --tx_otw sc12 ..

Also ensure you've set your CPU governor to performance, and enabled thread
prioirty scheduling as detailed here
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks

Regards,
Nate Temple

On Thu, Dec 12, 2019 at 7:45 PM Padorin Kurpinsky via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> The USRP B210 spec [1] says it supports  30.72 MHz of instantaneous
> bandwidth. However, If I run benchmark_rate, i.e., sudo ./benchmark_rate
> --rx_rate 30.72e6 --tx_rate 30.72e6 --channels 0,1. Then, it shows a lot of
> U and O. Is this because my host PC is not powerful enough? I'm using
> i7-8750H. Thank you.
>
> [1]
> https://www.ettus.com/wp-content/uploads/2019/01/b200-b210_spec_sheet.pdf
> ___
> 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] UHD Manual Archive now online

2019-12-17 Thread Nate Temple via USRP-users

Hi,

Just wanted to send the list a quick note that we have added an archive of
UHD manuals for all previous UHD versions, which can be found here [0].
These can be useful for reference if you're using an older version of UHD,
as the main manual [1] is built off of the master branch.

[0] - https://files.ettus.com/manual_archive/
[1] - https://files.ettus.com/manual/

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

Re: [USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run

2020-01-03 Thread Nate Temple via USRP-users

There was recently a change to the directory structure for the E300/E310s.

If you're running 3.15.0.0, this should be fixed, see the commits from ~Nov
21 here:

https://github.com/EttusResearch/fpga/commits/v3.15.0.0/usrp3

Regards,
Nate Temple

On Fri, Jan 3, 2020 at 11:17 AM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jerrid,
>
> could you check /home/ck/rfnoc/src/uhd-fpga/usrp3/top/e300/Makefile
> exists?
> My uhd-fpga directory has that; I think yours *should*. Which version
> of the uhd-fpga repo are you using?
>
> Best regards,
> Marcus
>
> On Fri, 2020-01-03 at 15:43 +, Jerrid Plymale via USRP-users wrote:
> > Hey All,
> >
> > So I recently started having issues with the uhd_image_builder_gui
> > after doing a fresh install of UHD and GNU Radio with RFNoC. Below is
> > the output of the terminal when I try to run the gui. Anyone run into
> > this issue and know how to fix it?
> >
> > Traceback (most recent call last):
> >   File "./uhd_image_builder_gui.py", line 656, in 
> > main()
> >   File "./uhd_image_builder_gui.py", line 652, in main
> > _window = MainWindow()
> >   File "./uhd_image_builder_gui.py", line 71, in __init__
> > self.init_gui()
> >   File "./uhd_image_builder_gui.py", line 149, in init_gui
> > self.populate_target('e300')
> >   File "./uhd_image_builder_gui.py", line 608, in populate_target
> > with open(build_targets) as fil:
> > IOError: [Errno 2] No such file or directory:
> > '/home/ck/rfnoc/src/uhd-
> > fpga/usrp3/tools/scripts/../../top/e300/Makefile'
> >
> > Best Regards,
> >
> > Jerrid
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Measuring TDOA for Localization

2020-01-10 Thread Nate Temple via USRP-users

Hi Richard,

To clarify, are you using a common Octoclock, with the 3 X300's in the same
location, or separate locations with 3x Octoclocks? Do you have equal
length cables to the antennas and does the rest of the system match ?

What is your RX frequency ?

What daughterboard are you using?

You may want to try using a decimation factor that will produce an
non-fractional host sample rate, instead of 200e6/22 = 9090909.09090909_
MHz. Does running at 10 MS/s sample rate produce any difference in the
result?

Regards,
Nate Temple

On Thu, Jan 9, 2020 at 4:08 PM Brian Padalino via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On Thu, Jan 9, 2020 at 6:45 PM Richard Bell 
> wrote:
>
>> No I don't need to know phase information. I'm cross correlating the
>> pairs of receivers and the location of the peak gives me the TDOA. If the
>> hardware chains across different radios introduce different delays, that
>> would invalidate the TDOA measurement. So long as the delay is the same
>> through all the hardware chains, the TDOA estimate will be accurate. Can I
>> assume the hardware delay through X300 USRPs with the same FPGA image and
>> set to the same sampling frequency will be the same?
>>
>
> I'd think the group delay should be pretty consistent - at least within
> 10's of nanoseconds of each other if the setup is identical.
>
> What type of variation are you seeing when you perform your cross
> correlations?  How much variation are you able to handle?
>
> Brian
>
>> ___
> 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] Measuring TDOA for Localization

2020-01-10 Thread Nate Temple via USRP-users

I meant to include this link with regards to the same rates in my previous
email:
https://files.ettus.com/manual_archive/v3.15.0.0/html/page_general.html#general_sampleratenotes

On Fri, Jan 10, 2020 at 10:40 AM Nate Temple  wrote:

> Hi Richard,
>
> To clarify, are you using a common Octoclock, with the 3 X300's in the
> same location, or separate locations with 3x Octoclocks? Do you have equal
> length cables to the antennas and does the rest of the system match ?
>
> What is your RX frequency ?
>
> What daughterboard are you using?
>
> You may want to try using a decimation factor that will produce an
> non-fractional host sample rate, instead of 200e6/22 = 9090909.09090909_
> MHz. Does running at 10 MS/s sample rate produce any difference in the
> result?
>
>
> Regards,
> Nate Temple
>
> On Thu, Jan 9, 2020 at 4:08 PM Brian Padalino via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On Thu, Jan 9, 2020 at 6:45 PM Richard Bell 
>> wrote:
>>
>>> No I don't need to know phase information. I'm cross correlating the
>>> pairs of receivers and the location of the peak gives me the TDOA. If the
>>> hardware chains across different radios introduce different delays, that
>>> would invalidate the TDOA measurement. So long as the delay is the same
>>> through all the hardware chains, the TDOA estimate will be accurate. Can I
>>> assume the hardware delay through X300 USRPs with the same FPGA image and
>>> set to the same sampling frequency will be the same?
>>>
>>
>> I'd think the group delay should be pretty consistent - at least within
>> 10's of nanoseconds of each other if the setup is identical.
>>
>> What type of variation are you seeing when you perform your cross
>> correlations?  How much variation are you able to handle?
>>
>> Brian
>>
>>> ___
>> 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] DOA with N310 or X310+TwinRX

2020-01-27 Thread Nate Temple via USRP-users

Hi Rob, Robert, Sammy:

Generally for this type of application we would recommend the X310+TwinRx.
With the TwinRX, you'll be able to have repeatable phase offsets with a
given gain, frequency, sample rate and temperature of a device/system. The
N310 will have a 180 degree phase ambiguity due to the /2 LO architecture.

It is possible to share the LO across multiple motherboards for a X310/Twin
setup, and with the NI branded X310+TwinRX setup (NI-2955) the LO's are
provided out of the back panel. The chassis for currently shipping and Rev
C, F, G X310's back plate has the holes for the LO cables, but the sticker
needs to be removed. This application note covers the process:
https://kb.ettus.com/Modifying_an_X310_Chassis_for_External_LO_Sharing

You'll also need to provide a splitter and most likely an inline amplifier
to overcome splitter losses. A splitter such as the ZFRSC-4-842+ will work.
https://www.minicircuits.com/pdfs/ZFRSC-4-842+.pdf


@Rob: With the current init process of the N310, yes it is required to
first set the external LO to 5 GHz.

With regards to the offsets you're seeing, I believe you should only see a
possible phase difference of 180* within the two channels on the same DB.
Are you issuing a tune request at the start of streaming?

Regards,
Nate Temple

On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Robert, Sammy,
> I am presently running some tests which compare the X310/TwinRx and the
> N310 with regard to channel-to-channel phase.  In my setup, I have a signal
> source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
> TwinRx and 4 channels of my N310. I have seen some strange behavior of the
> N310 that perhaps Robert has experienced?  Take a look:
>
>- For the TwinRx (for which I am a more experienced user with LO
>sharing), I get consistent channel-to-channel phase difference among all
>channels. This is true regardless of power cycles, re-starts of UHD, etc.
>- For the N310 (for which I am a beginner when it comes to external LO
>operation)
>   - it seems more complex to run in this mode (as compared to
>   TwinRx).  In order to get it to work, I have had to disable startup QEC
>   calibration because it seems that the N310 initial cal occurs at 2500 
> MHz
>   RF such that I would need to have my external LO at 5000 MHz for startup
>   (during the UHD deveice 'make') and then later switch my external LO to 
> the
>   desired RF*2. Is this true?
>   - when I run with either external LO or internal LO, I see
>   inconsistent channel-to-channel phase results even between the two 
> channels
>   of a given daughterboard that share the same LO.  I do not understand 
> how
>   this is possible.  My results over 16 captures (with some re-starts of 
> UHD,
>   device reboots, and switching between internal/external LO) show the
>   following channel-to-channel phase difference between channels 0 and 1
>   which share the same LO: (values in degrees) -77, -19, -77, -19, -77, 
> -19,
>   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
> only 3
>   unique values and the delta happens to be 58 deg, but I don't know what
>   that implies...
>
> Rob
>
>
> On Mon, Jan 27, 2020 at 9:57 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> With external LO its 300 MHz – 4 GHz, check footnote [3] from
>> https://www.ettus.com/all-products/usrp-n310/. LO has to be supplied at
>> twice the carrier freq.
>>
>>
>>
>> Currently we use 4 channels. You can find an example how to do the
>> calibration here: https://github.com/EttusResearch/gr-doa
>>
>> gr-doa was written for TwinRX, but can be adapted.
>>
>>
>>
>> Phase noise behavior of N310 and N320/1 could be different, as N310 uses
>> an RFIC and N32/1 use discrete components. This could be important if you
>> want to operate in the small sample regime.
>>
>>
>>
>>
>>
>> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>> Behalf Of *Sammy Welschen via USRP-users
>> *Sent:* Monday, January 27, 2020 3:40 PM
>> *To:* usrp-users@lists.ettus.com
>> *Subject:* Re: [USRP-users] DOA with N310 or X310+TwinRX
>>
>>
>>
>> Thank you for the information Robert! Isn't it 6 GHz? However, 4 GHz
>> would also be sufficient for me.
>>
>>
>>
>> How many channels does your system have?  I suppose you use some
>> algorithm for phase calibration after power cycling? I plan to do the same,
>> so the 180 deg ambiguity should be manageable.
>>
>>
>>
>> I looked at the N32x, however, they cost twice as much and I dont't plan
>> on using 200 MHz of bandwidth. If I have an external LO signal I can feed
>> it to the N310, so the only difference between N310 and N32x in this regard
>> would be that I need to generate the LO externally when using the N310,
>> right?
>>
>>
>>
>>  schrieb am Mo., 27. Jan. 2020, 14:42:
>>
>> We use the N310 for DoA estimation, however:
>>
>> -

Re: [USRP-users] N310 phase jumps with 1 daughterboard

2020-01-27 Thread Nate Temple via USRP-users

Hi Rob,

You should always use a tune request with a timed command when you want to
align channels.

One thing you could test is to try using the internal LO and see if you get
different results.

Also you could try using the integer N tuning mode, but I don't think it
will make any difference for this issue. Checkout this great blog post on
USRP tuning if you haven't seen it before that covers a few more tips on
USRP tuning:
http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html

Regards,
Nate Temple

On Mon, Jan 27, 2020 at 9:33 AM Rob Kossler  wrote:

> Hi Nate,
> I changed the subject as to not further hijack the other thread. Of the 16
> captures I collected, some of them included a tuning command (but using the
> same timed commands I use for other devices such as TwinRx). But, others
> did not.  For example, for the first two data points below (with measured
> phase difference of -77 and -19 respectively).  I simply issued two
> consecutive timed streaming commands.  So, I was very perplexed by the
> results.
>
> In any event, I plan to re-take the data today both with and without a
> DDC.  Hopefully, if I get rid of the DDC, I will see consistent phase
> results, but we'll see.  Let me know if you have other ideas.
> Rob
>
> On Mon, Jan 27, 2020 at 12:04 PM Nate Temple 
> wrote:
>
>>
>> @Rob: With the current init process of the N310, yes it is required to
>> first set the external LO to 5 GHz.
>>
>> With regards to the offsets you're seeing, I believe you should only see
>> a possible phase difference of 180* within the two channels on the same DB.
>> Are you issuing a tune request at the start of streaming?
>>
>> Regards,
>> Nate Temple
>>
>> On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Robert, Sammy,
>>> I am presently running some tests which compare the X310/TwinRx and the
>>> N310 with regard to channel-to-channel phase.  In my setup, I have a signal
>>> source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
>>> TwinRx and 4 channels of my N310. I have seen some strange behavior of the
>>> N310 that perhaps Robert has experienced?  Take a look:
>>>
>>>- For the TwinRx (for which I am a more experienced user with LO
>>>sharing), I get consistent channel-to-channel phase difference among all
>>>channels. This is true regardless of power cycles, re-starts of UHD, etc.
>>>- For the N310 (for which I am a beginner when it comes to external
>>>LO operation)
>>>   - it seems more complex to run in this mode (as compared to
>>>   TwinRx).  In order to get it to work, I have had to disable startup 
>>> QEC
>>>   calibration because it seems that the N310 initial cal occurs at 2500 
>>> MHz
>>>   RF such that I would need to have my external LO at 5000 MHz for 
>>> startup
>>>   (during the UHD deveice 'make') and then later switch my external LO 
>>> to the
>>>   desired RF*2. Is this true?
>>>   - when I run with either external LO or internal LO, I see
>>>   inconsistent channel-to-channel phase results even between the two 
>>> channels
>>>   of a given daughterboard that share the same LO.  I do not understand 
>>> how
>>>   this is possible.  My results over 16 captures (with some re-starts 
>>> of UHD,
>>>   device reboots, and switching between internal/external LO) show the
>>>   following channel-to-channel phase difference between channels 0 and 1
>>>   which share the same LO: (values in degrees) -77, -19, -77, -19, -77, 
>>> -19,
>>>   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
>>> only 3
>>>   unique values and the delta happens to be 58 deg, but I don't know 
>>> what
>>>   that implies...
>>>
>>> Rob
>>>
>>>
>>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 phase jumps with 1 daughterboard

2020-01-27 Thread Nate Temple via USRP-users

Hi Rob,

One other thing, if you're not on UHD v3.15.0.0, I'd recommend to update to
it. There was some phase reset and accumulator fixes with 3.15.0.0.

https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/CHANGELOG#L44


Regards,
Nate Temple

On Mon, Jan 27, 2020 at 11:17 AM Nate Temple  wrote:

> Hi Rob,
>
> You should always use a tune request with a timed command when you want to
> align channels.
>
> One thing you could test is to try using the internal LO and see if you
> get different results.
>
> Also you could try using the integer N tuning mode, but I don't think it
> will make any difference for this issue. Checkout this great blog post on
> USRP tuning if you haven't seen it before that covers a few more tips on
> USRP tuning:
> http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html
>
> Regards,
> Nate Temple
>
> On Mon, Jan 27, 2020 at 9:33 AM Rob Kossler  wrote:
>
>> Hi Nate,
>> I changed the subject as to not further hijack the other thread. Of the
>> 16 captures I collected, some of them included a tuning command (but using
>> the same timed commands I use for other devices such as TwinRx). But,
>> others did not.  For example, for the first two data points below (with
>> measured phase difference of -77 and -19 respectively).  I simply issued
>> two consecutive timed streaming commands.  So, I was very perplexed by the
>> results.
>>
>> In any event, I plan to re-take the data today both with and without a
>> DDC.  Hopefully, if I get rid of the DDC, I will see consistent phase
>> results, but we'll see.  Let me know if you have other ideas.
>> Rob
>>
>> On Mon, Jan 27, 2020 at 12:04 PM Nate Temple 
>> wrote:
>>
>>>
>>> @Rob: With the current init process of the N310, yes it is required to
>>> first set the external LO to 5 GHz.
>>>
>>> With regards to the offsets you're seeing, I believe you should only see
>>> a possible phase difference of 180* within the two channels on the same DB.
>>> Are you issuing a tune request at the start of streaming?
>>>
>>> Regards,
>>> Nate Temple
>>>
>>> On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Robert, Sammy,
 I am presently running some tests which compare the X310/TwinRx and the
 N310 with regard to channel-to-channel phase.  In my setup, I have a signal
 source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
 TwinRx and 4 channels of my N310. I have seen some strange behavior of the
 N310 that perhaps Robert has experienced?  Take a look:

- For the TwinRx (for which I am a more experienced user with LO
sharing), I get consistent channel-to-channel phase difference among all
channels. This is true regardless of power cycles, re-starts of UHD, 
 etc.
- For the N310 (for which I am a beginner when it comes to external
LO operation)
   - it seems more complex to run in this mode (as compared to
   TwinRx).  In order to get it to work, I have had to disable startup 
 QEC
   calibration because it seems that the N310 initial cal occurs at 
 2500 MHz
   RF such that I would need to have my external LO at 5000 MHz for 
 startup
   (during the UHD deveice 'make') and then later switch my external LO 
 to the
   desired RF*2. Is this true?
   - when I run with either external LO or internal LO, I see
   inconsistent channel-to-channel phase results even between the two 
 channels
   of a given daughterboard that share the same LO.  I do not 
 understand how
   this is possible.  My results over 16 captures (with some re-starts 
 of UHD,
   device reboots, and switching between internal/external LO) show the
   following channel-to-channel phase difference between channels 0 and 
 1
   which share the same LO: (values in degrees) -77, -19, -77, -19, 
 -77, -19,
   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
 only 3
   unique values and the delta happens to be 58 deg, but I don't know 
 what
   that implies...

 Rob



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

Re: [USRP-users] N310 phase jumps with 1 daughterboard

2020-01-27 Thread Nate Temple via USRP-users

Hi Rob,

Thanks for trying your setup with 3.15.0.0.

I will see what I can do about getting these fixes backported to 3.14, any
changes will need to be on the UHD-3.14 branch (the maint branch for 3.14),
we won't be able to apply these changes to 3.14.1.1, as it's a tagged
release.

Regards,
Nate Temple

On Mon, Jan 27, 2020 at 2:46 PM Rob Kossler  wrote:

> Nate,
> After switching to 3.15, I now get consistent results such that the
> relative phase between channels is as follows:
> - chan 0 to chan 1: constant
> - chan 1 to chan 2: constant +/- 180 deg
> - chan 2 to chan 3: constant
>
> So, it seems that the problem was in 3.14.
> Rob
>
> On Mon, Jan 27, 2020 at 3:45 PM Rob Kossler  wrote:
>
>> Nate,
>> So, I retested with 3.14.1.1 and got erratic results (same as last
>> week).  Now I am attempting to go to 3.15.0.0.  To make things as painless
>> as possible, I tried to just re-build MPM on the device and then update the
>> other stuff on the host (rather than flashing a new file system).  However,
>> MPM doesn't seem to build (see error below). I'm guessing this error is
>> related to something in the file system that is going to force me to
>> re-flash the file system.  Can you take a look and let me know if there is
>> an easier way.
>> Rob
>>
>> root@ni-n3xx-318F043:~/build_mpm# make -j2
>> [  5%] Built target periphs
>> [ 10%] Built target dboards
>> [ 27%] Built target mykonos
>> [ 32%] Built target spi
>> [ 34%] Building C object lib/i2c/CMakeFiles/i2c.dir/i2cdev.c.o
>> Scanning dependencies of target types
>> [ 36%] Building CXX object lib/types/CMakeFiles/types.dir/lockable.cpp.o
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c: In function 'i2cdev_open':
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c:26:33: error: 'O_LARGEFILE'
>> undeclared (first use in this function); did you mean '__O_LARGEFILE'?
>>  *fd = open(device, O_RDWR | O_LARGEFILE);
>>  ^~~
>>  __O_LARGEFILE
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c:26:33: note: each undeclared
>> identifier is reported only once for each function it appears in
>> make[2]: *** [lib/i2c/CMakeFiles/i2c.dir/build.make:111:
>> lib/i2c/CMakeFiles/i2c.dir/i2cdev.c.o] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:466: lib/i2c/CMakeFiles/i2c.dir/all]
>> Error 2
>> make[1]: *** Waiting for unfinished jobs
>> [ 38%] Building CXX object lib/types/CMakeFiles/types.dir/log_buf.cpp.o
>> [ 40%] Building CXX object
>> lib/types/CMakeFiles/types.dir/mmap_regs_iface.cpp.o
>> [ 40%] Built target types
>> make: *** [Makefile:141: all] Error 2
>> root@ni-n3xx-318F043:~/build_mpm#
>>
>>
>> On Mon, Jan 27, 2020 at 2:21 PM Rob Kossler  wrote:
>>
>>> ok.
>>>
>>> Yes, I always use timed tune commands. If that were not happening
>>> correctly, I don't think I could get consistent results with TwinRx.
>>>
>>> I am presently using 3.14.1.1.  I will complete the testing (using
>>> internal LO) I've already begun with this version and then re-test some/all
>>> using 3.15.  Assuming that the results are different, it would seem that
>>> Ettus should consider applying the fixes to the 3.14 branch.
>>>
>>> Rob
>>>
>>>
>>> On Mon, Jan 27, 2020 at 2:18 PM Nate Temple 
>>> wrote:
>>>
 Hi Rob,

 One other thing, if you're not on UHD v3.15.0.0, I'd recommend to
 update to it. There was some phase reset and accumulator fixes with
 3.15.0.0.

 https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/CHANGELOG#L44


 Regards,
 Nate Temple

 On Mon, Jan 27, 2020 at 11:17 AM Nate Temple 
 wrote:

> Hi Rob,
>
> You should always use a tune request with a timed command when you
> want to align channels.
>
> One thing you could test is to try using the internal LO and see if
> you get different results.
>
> Also you could try using the integer N tuning mode, but I don't think
> it will make any difference for this issue. Checkout this great blog post
> on USRP tuning if you haven't seen it before that covers a few more tips 
> on
> USRP tuning:
> http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html
>
> Regards,
> Nate Temple
>
> On Mon, Jan 27, 2020 at 9:33 AM Rob Kossler  wrote:
>
>> Hi Nate,
>> I changed the subject as to not further hijack the other thread. Of
>> the 16 captures I collected, some of them included a tuning command (but
>> using the same timed commands I use for other devices such as TwinRx). 
>> But,
>> others did not.  For example, for the first two data points below (with
>> measured phase difference of -77 and -19 respectively).  I simply issued
>> two consecutive timed streaming commands.  So, I was very perplexed by 
>> the
>> results.
>>
>> In any event, I plan to re-take the data today both with and without
>> a DDC.  Hopefully, if I get rid of the DDC, I will see consistent phase
>> results,

Re: [USRP-users] DOA with N310 or X310+TwinRX

2020-01-28 Thread Nate Temple via USRP-users

Hi Sammy,

>Can I turn it off and come back the next day and still have the same phase
offset between the channels that I had the day before?

Yes. This assumes that you are running with the same frequency, gain,
sample rate and system temperature that your calibrations were made with.
Also unless you have phase stable cables, if you move your cables at all,
it can cause phase variation.


Regards,
Nate Temple

On Mon, Jan 27, 2020 at 9:29 AM Sammy Welschen 
wrote:

> Hi Nate, thank you for the information.
>
> I'm still a bit unsure what repeatable phase offset means exactly. Suppose
> I have a system with 8 channels with X310+TwinRX and shared LO. Can I turn
> it off and come back the next day and still have the same phase offset
> between the channels that I had the day before?
>
> Sammy
>
> Nate Temple via USRP-users  schrieb am Mo.,
> 27. Jan. 2020, 18:04:
>
>> Hi Rob, Robert, Sammy:
>>
>> Generally for this type of application we would recommend the
>> X310+TwinRx. With the TwinRX, you'll be able to have repeatable phase
>> offsets with a given gain, frequency, sample rate and temperature of a
>> device/system. The N310 will have a 180 degree phase ambiguity due to the
>> /2 LO architecture.
>>
>> It is possible to share the LO across multiple motherboards for a
>> X310/Twin setup, and with the NI branded X310+TwinRX setup (NI-2955) the
>> LO's are provided out of the back panel. The chassis for currently shipping
>> and Rev C, F, G X310's back plate has the holes for the LO cables, but the
>> sticker needs to be removed. This application note covers the process:
>> https://kb.ettus.com/Modifying_an_X310_Chassis_for_External_LO_Sharing
>>
>> You'll also need to provide a splitter and most likely an inline
>> amplifier to overcome splitter losses. A splitter such as the ZFRSC-4-842+
>> will work. https://www.minicircuits.com/pdfs/ZFRSC-4-842+.pdf
>>
>>
>> @Rob: With the current init process of the N310, yes it is required to
>> first set the external LO to 5 GHz.
>>
>> With regards to the offsets you're seeing, I believe you should only see
>> a possible phase difference of 180* within the two channels on the same DB.
>> Are you issuing a tune request at the start of streaming?
>>
>> Regards,
>> Nate Temple
>>
>> On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Robert, Sammy,
>>> I am presently running some tests which compare the X310/TwinRx and the
>>> N310 with regard to channel-to-channel phase.  In my setup, I have a signal
>>> source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
>>> TwinRx and 4 channels of my N310. I have seen some strange behavior of the
>>> N310 that perhaps Robert has experienced?  Take a look:
>>>
>>>- For the TwinRx (for which I am a more experienced user with LO
>>>sharing), I get consistent channel-to-channel phase difference among all
>>>channels. This is true regardless of power cycles, re-starts of UHD, etc.
>>>- For the N310 (for which I am a beginner when it comes to external
>>>LO operation)
>>>   - it seems more complex to run in this mode (as compared to
>>>   TwinRx).  In order to get it to work, I have had to disable startup 
>>> QEC
>>>   calibration because it seems that the N310 initial cal occurs at 2500 
>>> MHz
>>>   RF such that I would need to have my external LO at 5000 MHz for 
>>> startup
>>>   (during the UHD deveice 'make') and then later switch my external LO 
>>> to the
>>>   desired RF*2. Is this true?
>>>   - when I run with either external LO or internal LO, I see
>>>   inconsistent channel-to-channel phase results even between the two 
>>> channels
>>>   of a given daughterboard that share the same LO.  I do not understand 
>>> how
>>>   this is possible.  My results over 16 captures (with some re-starts 
>>> of UHD,
>>>   device reboots, and switching between internal/external LO) show the
>>>   following channel-to-channel phase difference between channels 0 and 1
>>>   which share the same LO: (values in degrees) -77, -19, -77, -19, -77, 
>>> -19,
>>>   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
>>> only 3
>>>   unique values and the delta happens to be 58 deg, but I don't know 
>>> what
>>>   that implies...
>>>
>>> Ro

Re: [USRP-users] USRP N310 Performance Issues

2020-01-28 Thread Nate Temple via USRP-users

Hi Austin,

The MTUs on your host and N310 must match. You should modify the systemd
configuration on the N310 are restart the whole device or restart
systemd-networkd

https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations

It is not recommended to stream over a wireless connection as the
additional delay will cause flow control errors. It is also generally
recommended to not have a switch in line as some switches can reorder
packets. You should directly connect to the USRP for the streaming
interfaces. On the N3xx, it's fine to access the RJ45 management port via a
switch.

Regards,
Nate Temple



On Tue, Jan 28, 2020 at 2:52 PM Austin Adam via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
> I have a very basic GNU script with just a USRP block and a time sink that
> when I run, there are tons of streaming errors with the tx and rx. In GNU,
> the console is being filled with 'D's and the console for the N210 is
> getting filled with 'U's and 'S's.
>
> My setup is just a USRP N210 connected to the RX LO ports of the N310. I
> am sending the following command to the N210:
>
> *"sudo '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms'
> --args "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX"
> --subdev "A:0" --channels 0 --rate 1.25e6 --gain 29.5"*
>
> The USRPs are connected to a router via cat 5e cables, and then my laptop
> is connected to the router via wifi. Something I noticed is that when I
> connect to the router via ethernet to my laptop, I don't get any of the
> performance issues. It seems to only happen over the wifi.
>
> When I run ifconfig on my laptop, my MTU is set to 1500, and on the USRP
> N310 the MTU on the sfp0 port that we are using is 8000. I wasn't able to
> change the MTU on the N310 because it said the device was in use, but those
> values seem to work fine over ethernet so I didn't look too much into it.
>
> The sample rate on my GNU script is set to 5M for now, and lowering it
> does seem to reduce the amount of 'D's that I get, but also negatively
> affects our data.
>
> Lastly, here is some output from the N210 that shows the error:
>
> *austin@Austin-Blade:~$ sudo '/home/*austin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> */workarea-uhd/uhd/host/build/examples/tx_waveforms' --args
> "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX" --subdev
> "A:0" --channels 0 --rate 1.25e6 --gain 29.5Creating the usrp device with:
> addr=192.168.10.15,type=usrp2...[INFO] [UHD] linux; GNU C++ version 8.3.0;
> Boost_106700; UHD_3.14.0.HEAD-0-g6875d061[INFO] [USRP2] Opening a
> USRP2/N-Series device...[INFO] [USRP2] Current recv frame size: 1472
> bytes[INFO] [USRP2] Current send frame size: 1472 bytesUsing Device: Single
> USRP:  Device: USRP2 / N-Series Device  Mboard 0: N210r4  RX Channel: 0
> RX DSP: 0RX Dboard: ARX Subdev: SBXv3 RX  TX Channel: 0TX DSP:
> 0TX Dboard: ATX Subdev: SBXv3 TXSetting TX Rate: 1.25
> Msps...Actual TX Rate: 1.25 Msps...Setting TX Freq: 3900.00
> MHz...Setting TX LO Offset: 0.00 MHz...Actual TX Freq: 3900.00
> MHz...Setting TX Gain: 29.50 dB...Actual TX Gain: 29.50
> dB...Setting device timestamp to 0...Checking TX: LO: locked ...Press Ctrl
> + C to stop streaming...*UUUS[ERROR] [USRP2] Control packet attempt
> 0, sequence number 470:
> RuntimeError: no control response, possible packet loss
> UUUSSUU^C
> *  Done!*
>
> I appreciate any help that anyone has to offer!
>
> Best,
> Austin
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP N310 Performance Issues

2020-01-28 Thread Nate Temple via USRP-users

Hi Austin,

>Is there a way to do it directly via the jtag and using the screen command
to speak with the N310?

You could connect to the ARM via JTAG as detailed in the link below, but
you're better off just SSH'ing into it.

https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Connecting_to_the_ARM_via_SSH

Streaming will be very flakey over any sort of wifi. Two options I'd
suggest exploring:

1) Use fiber to have a direct connection. Aqua multimode fiber is pretty
cheap and you can have long runs.

2) Put a host computer next to the USRP wherever it is installed, and
perform your DSP / streaming to that machine, Then connect to that remote
host via wifi for command and control. You can then stream at lower rate
your processed data off that host to a dashboard or whatever your
application is.

Regards,
Nate Temple



On Tue, Jan 28, 2020 at 3:34 PM Marcus D Leech 
wrote:

> Let’s do some quick math, shall we?
>
> 5msps with 16-bit complex == 160Mbit/second
> 1.25msps with 16-bit complex samples == an additional 40mbit-second
>
> Unless you have super reliable 1Gig wireless infrastructure, this just
> isn’t going to work.
>
> Sent from my iPhone
>
> On Jan 28, 2020, at 6:23 PM, Austin Adam via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hey Nate,
> Thanks for the quick response as always! I tried editing those files in
> the past, but I remember having issues because they were locked or I wasn’t
> able to actually save any changes that I made. Is there a way to do it
> directly via the jtag and using the screen command to speak with the N310?
>
> Also, unfortunately for the current project I am working on, we really
> need to have a wireless connection to the USRPs via the router. I am sure
> there is some way to make it work because we can still get data that looks
> good, it just starts to get clunky after a few seconds of streaming.
>
>
> On Jan 28, 2020, at 3:07 PM, Nate Temple  wrote:
>
> 
> Hi Austin,
>
> The MTUs on your host and N310 must match. You should modify the systemd
> configuration on the N310 are restart the whole device or restart
> systemd-networkd
>
>
> https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations
>
> It is not recommended to stream over a wireless connection as the
> additional delay will cause flow control errors. It is also generally
> recommended to not have a switch in line as some switches can reorder
> packets. You should directly connect to the USRP for the streaming
> interfaces. On the N3xx, it's fine to access the RJ45 management port via a
> switch.
>
> Regards,
> Nate Temple
>
>
>
> On Tue, Jan 28, 2020 at 2:52 PM Austin Adam via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi everyone,
>> I have a very basic GNU script with just a USRP block and a time sink
>> that when I run, there are tons of streaming errors with the tx and rx. In
>> GNU, the console is being filled with 'D's and the console for the N210 is
>> getting filled with 'U's and 'S's.
>>
>> My setup is just a USRP N210 connected to the RX LO ports of the N310. I
>> am sending the following command to the N210:
>>
>> *"sudo '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms'
>> --args "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX"
>> --subdev "A:0" --channels 0 --rate 1.25e6 --gain 29.5"*
>>
>> The USRPs are connected to a router via cat 5e cables, and then my laptop
>> is connected to the router via wifi. Something I noticed is that when I
>> connect to the router via ethernet to my laptop, I don't get any of the
>> performance issues. It seems to only happen over the wifi.
>>
>> When I run ifconfig on my laptop, my MTU is set to 1500, and on the USRP
>> N310 the MTU on the sfp0 port that we are using is 8000. I wasn't able to
>> change the MTU on the N310 because it said the device was in use, but those
>> values seem to work fine over ethernet so I didn't look too much into it.
>>
>> The sample rate on my GNU script is set to 5M for now, and lowering it
>> does seem to reduce the amount of 'D's that I get, but also negatively
>> affects our data.
>>
>> Lastly, here is some output from the N210 that shows the error:
>>
>> *austin@Austin-Blade:~$ sudo '/home/*austin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> */workarea-uhd/uhd/host/build/examples/tx_waveforms' --args
>> "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX" --subdev
>> "A:0" --channels 0 --rate 1.25e6 --gain 29.5Creating the usrp device with:
>> addr=192.168.10.15,type=usrp2...[INFO] [UHD] linux; GNU C++ version 8.3.0;
>> Boost_106700; UHD_3.14.0.HEAD-0-g6875d061[INFO] [USRP2] Opening a
>> USRP2/N-Series device...[INFO] [USRP2] Current recv frame size: 1472
>> bytes[INFO] [USRP2] Current send frame size: 1472 bytesUsing Device: Single
>> USRP:  Device: USRP2 / N-Series Device  Mboard 0: N210r4  RX Channel: 0
>> RX DSP: 0RX Dboard: ARX Subdev: SBXv3 R

Re: [USRP-users] [UHD] FPGA code will be merged back into the UHD repository

2020-02-05 Thread Nate Temple via USRP-users

Hi Jeff,

Yes, it will change the process slightly, you will no longer need to do a
--recursive clone of the UHD repo (to pull in the FPGA repo submodule).

We will be updating the applications notes to be in sync with 4.0/master
soon.

Regards,
Nate Temple

On Wed, Feb 5, 2020 at 11:42 AM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Will this significantly change the Application Notes (AN-823) for RFNoC
> Development?  Or is it just removing the git fpga?
>
> Our IT guys use the AN for their install process.
>
> Thx,
> Jeff
>
> --
> *From:* USRP-users  on behalf of
> Martin Braun via USRP-users 
> *Sent:* Tuesday, February 4, 2020 4:55 PM
> *To:* USRP-users@lists.ettus.com 
> *Subject:* [USRP-users] [UHD] FPGA code will be merged back into the UHD
> repository
>
> Hi all,
>
> I just pushed a pretty big change to the UHD repository. Going forward, we
> will be tracking the FPGA code and the UHD code in the same repository, as
> we did pre-2014.
>
> For most of you, this won't be a big change, except for a big changeset on
> your next git pull. If you are running UHD from pre-built binaries, this
> won't affect you at all. However, for those who play around in the git
> repositories, and build FPGA images from source, there will be some changes.
>
> *Summary of changes going forward:*
> - The fpga-src submodule is no longer part of the repository
> - FPGA code is now tracked in the fpga/ subdirectory
> - Commits that affect FPGA and UHD code alike (or FPGA and MPM code) will
> be committed in a single commit going forward
> - We are planning to provide release tarballs both with and without the
> FPGA source code. The details on that are still in the works.
>
> *Why are we doing this?*
> I'll be frank: This is something we did for our own benefit, since we
> treat the FPGA and UHD code bases as a unit, it is easier to develop within
> a single repository. In particular, the ability to commit FPGA and UHD
> changes in a single atomic commit, is a great win. I do think this is good
> for anyone who wants to inspect the codebase, though. Occasionally when we
> introduced changes that would modify both UHD and FPGA, and then changed a
> compat number as well, users weren't sure which versions of FPGA and UHD to
> match up. This is also true for us at Ettus Research / NI, most importantly
> in our continuous integration systems, where it is much easier to verify
> the consistency of a single code base, than running two separate checks and
> stitching them together.
>
> *How can I rebase code from the FPGA repository onto the new UHD
> repository?*
> With git, this is very easily done. The git commit message contains all
> the required instructions.
> See here:
> https://github.com/EttusResearch/uhd/commit/bafa9d95453387814ef25e6b6256ba8db2df612f
>
> *How will this affect the images manifest?*
> FPGA images will continue to contain the git commit hash they were built
> from. That means that a commit that changes something in the FPGA source
> code cannot also contain image manifest changes containing those FPGA
> images. However, we are planning some modifications to
> uhd_images_downloader such that it will be able to also download the
> correct image zip files for those commits. This is something that can come
> in handy for git bisect, it is not something that most users will require.
>
> *What about the UHD-3.15.LTS branch?*
> This change is only rolled out to master branch. UHD 3.15 will, for the
> duration of its lifetime, receive FPGA updates the same way it always has
> (i.e., the fpga repository on GitHub will be updated, and the submodule
> pointer will be updated as well). This is also why the fpga-src/ submodule
> and the fpga/ directory have different path names, so branch switching
> between master and UHD-3.15.LTS remains easily possible without submodule
> clashes.
>
> *What about the fpga repository on GitHub?*
> For the reasons laid out above, it will remain as-is. The master branch
> will be frozen, though, to the state it was in before the merge into UHD.
> This is useful for the history of the branch, bisecting before the merge,
> and git blame.
>
> Please respond to this thread with questions. Thanks!
>
> --Martin
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310, 3.15 LTS, Windows

2020-02-24 Thread Nate Temple via USRP-users

Hi Simon,

The E310 network mode was removed from UHD with the switch to the MPM based
file systems. If you need to use the network mode, you should use an older
version of UHD.

Regards,
Nate Temple

On Mon, Feb 24, 2020 at 11:05 AM Simon G4ELI via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
>
>
> A user cannot ‘see’ his E310 using 3.15 LTS compiled from source by me.
> The E310 is connected by Ethernet GigE.
>
>
>
> I’m wondering if there’s something special needed or if there’s a magic
> option I should enable in the source – the ENABLE_E300 option is checked,
> all looks good to me.
>
>
>
> There is a second person who will soon be testing just in case it’s finger
> trouble.
>
>
>
> 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

Re: [USRP-users] E310, 3.15 LTS, Windows

2020-02-24 Thread Nate Temple via USRP-users

Hi Simon,

No, the USB cable will only provide serial access.

You could use GNU Radio to stream samples via ZMQ/TCP/UDP sockets. You
could also use pure C++/UHD API to stream via a UDP interface such as with
the example program rx_samples_to_udp.

Regards,
Nate Temple

On Mon, Feb 24, 2020 at 11:19 AM  wrote:

> Thanks,
>
>
>
> Would the E310 work with the USB cable?
>
>
>
> Simon Brown, G4ELI
>
> https://www.sdr-radio.com
>
>
>
> *From:* Nate Temple 
> *Sent:* 24 February 2020 19:11
> *To:* si...@sdr-radio.com
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] E310, 3.15 LTS, Windows
>
>
>
> Hi Simon,
>
> The E310 network mode was removed from UHD with the switch to the MPM
> based file systems. If you need to use the network mode, you should use an
> older version of UHD.
>
> Regards,
> Nate Temple
>
>
>
> On Mon, Feb 24, 2020 at 11:05 AM Simon G4ELI via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi All,
>
>
>
> A user cannot ‘see’ his E310 using 3.15 LTS compiled from source by me.
> The E310 is connected by Ethernet GigE.
>
>
>
> I’m wondering if there’s something special needed or if there’s a magic
> option I should enable in the source – the ENABLE_E300 option is checked,
> all looks good to me.
>
>
>
> There is a second person who will soon be testing just in case it’s finger
> trouble.
>
>
>
> 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

Re: [USRP-users] X310 software reset revisted

2018-07-23 Thread Nate Temple via USRP-users

Hi Jason,

This magic poke should do the trick:

python $UHD_INSTALL_DIR/firmware/usrp3/x300/x300_debug.py --addr=
--poke=0x100058 --data=1


Regards,
Nate Temple

On Mon, Jul 23, 2018 at 9:45 AM, Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I've solved this with the USB JTAG interface and an external machine. An
> RPi will happily run Vivado Lab.
>
> AFAIK there are no plans to integrate a software reset into the X310.
>
> Nick
>
> On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I know it has been questioned many times on here, but I wanted to verify
>> something.  It has always been said that there is no way to do a software
>> reset on the X310; I am curious if that is "currently" or "ever?"
>>
>> I wasn't sure if there was a way to send a packet either via UHD or RFNoC
>> that could trigger a reset of some kind (this assumes that you have a
>> functioning X310 on the other end), and no one has had time to look into
>> it?  Or if it has been looked into and there truly is no way to do it.
>>
>> I have some situations where I cannot get to my X310s easily, so if I
>> need to reflash the bitfile (which is going to be necessary for RFNoC
>> flowgraphs, I will have to add an external appliance to get the job
>> done.  I was thinking about looking into it, but if it already has and was
>> deemed a non-starter, I don't want to waste the cycles.
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

2018-09-04 Thread Nate Temple via USRP-users

Hi David,

We would like to debug this off the mailing list. Could you please email us
at supp...@ettus.com with the device's serial number?


Regards,
Nate Temple

On Tue, Sep 4, 2018 at 8:31 AM, David Zamorano Fernández via USRP-users <
usrp-users@lists.ettus.com> wrote:

> 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
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] n310 offset tuning seems broken

2018-09-25 Thread Nate Temple via USRP-users

Hi Bob,

What USRP / DB are you using?

Regards,
Nate Temple

On Thu, Sep 13, 2018 at 6:53 AM, Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Running 3.13.0.0 on Windows.
>
>
>
> I have a flag in my app to enable/disable offset tuning.
>
>
>
> Application works properly and receives signal when not using offset
> tuning, but when I enable it and tell it to offset tune by 1 MHz, I get no
> signal on Rx.
>
>
>
> Worked fine on 3.9.2.
>
>
>
> Any known issues?
>
>
>
> Thanks,
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N3xx operational questions

2018-11-01 Thread Nate Temple via USRP-users

Hi EJ,

Thanks for the detailed report. We are working on addressing these issues
and will follow up with a more detailed response soon.

Regards,
Nate Temple

On Wed, Oct 24, 2018 at 3:01 PM, EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I've been working with the N3xx series for a week or so and I've hit a few
> issues in the "operational" side of things that are either not addressed in
> the manual or work differently than expected. I'll just handle this as a
> "laundry list" of items/issues...
>
> To start, I've been directly testing on the N300 so far. I reflashed the
> N300 SD card with version UHD-3.13.02 last week.
>
> 1. As a heads up, and I'm sure you're aware, I've had a fair bit of
> trouble coordinating the uhd_images_downloader with the correct images...
> First, when I originally built UHD-3.13.0.0 as described in the manual,
> there's no images provided for 3.13.0.0. I just noticed today that if I
> update to UHD-3.13 branch (currently 3.13.0.3) and run the downloader, it
> tries to pull images for 3.13.0.2, which is likely incompatible with the
> 3.13.0.3 head (noc shell seems to be updated to version 3 in the most
> recent 3.13.0.3).
>
> 2. I keep running into a number of issues trying to download new FPGA
> images. Could someone explain the mechanics of FPGA loading for N3xx? I'm
> assuming this is similar to X310, however I would have expected that a
> zynq-based platform would simply program to /dev/xdevcfg like the E310.
>
> More tactically, I have a few issues when trying to download FPGA images.
> If I run a "host mode update", then I get an unexpected error:
>
> ```
> $ uhd_image_loader --args "type=n3xx,addr=10.1.151.245"
> --fpga-path=n3xx.bit
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.13.0.3-14-gd1555232
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=10.1.151.245,type=n3xx,product=n300,serial=
> 3145FF4,claimed=False,skip_init=1
> [INFO] [MPMD] Claimed device without full initialization.
> [WARNING] [MPMD IMAGE LOADER] RuntimeError: Component file does not exist:
> /home/ejk/fpga-build/he360-fpga-builder/src/uhd-fpga/
> usrp3/top/n3xx/build-N300_RFNOC_HG/n3xx.dts
> [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
> [ERROR] [UHD] An unexpected exception was caught in a task loop.The task
> loop will now exit, things may not work.rpc::timeout: Timeout of 5000ms
> while calling RPC function 'get_log_buf'
> [INFO] [MPM.PeriphManager] Device serial number: 3145FF4
> [INFO] [MPM.PeriphManager] Initialized 1 daughterboard(s).
> [INFO] [MPM.PeriphManager] init() called with device args `'.
> Error: rpc::timeout: Timeout of 2ms while calling RPC function
> 'update_component'
> ```
>
> Fortunately, this error appears that it doesnt materially impact anything,
> and I can now probe the FPGA successfully afterwards.
>
> When trying to load FPGA images in embedded mode, first, I get an error
> when running uhd_images_downloader that suggests argparse is not installed
> into the rootfs:
>
> ```
> root@ni-n3xx-3145FF4:~# uhd_images_downloader
> Traceback (most recent call last):
>   File "/usr/bin/uhd_images_downloader", line 11, in 
> import argparse
> ImportError: No module named argparse
> ```
>
> Oddly, pip3 seems to be installed, and I can run `pip3 install argparse`
> but there's no pip or python2 argparse :(
>
> Anyway, if I scp a relevant image onto the N300 PS, I get a similar issue
> as over network mode.
>
> At one point, I found fpga programming in embedded mode crashed the N300
> and require a hard reboot, but I cant recreate that right now so I'll leave
> that off my list.
>
> 3. Embedded mode vs host/network mode: Ideally, I would like to run the
> N3xx using both a high rate ethernet connection through the sfp's, and a
> connection to the Zynq PS over the RJ45. (not at the same time from the
> same program, but both ports physically connected)... However, I cannot
> succeed in switching between embedded mode and host mode without 1)
> physically unplugging the ethernet cables, or 2) taking down the IP
> interface that I'm not using at the moment. Is there a way to do this??
>
> To give a specific example of behavior I see, I've set up the N300 to
> boot with 1GigE connection on sfp0 and RJ45 on the eth0. From a host
> device, in network mode, I fail to probe the N300:
>
> ```
> $ uhd_usrp_probe --args "type=n3xx"
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.13.0.HEAD-0-g0ddc19e5
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=10.1.151.60,type=n3xx,product=n300,serial=
> 3145FF4,claimed=False,addr=10.1.151.245
> [INFO] [MPM.PeriphManager] init() called with device args
> `mgmt_addr=10.1.151.60,product=n300'.
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>   at /home/ejk/prefix/gnuradio-default/src/uhd/ho

Re: [USRP-users] N310 Rack mount Kit

2018-11-16 Thread Nate Temple via USRP-users

Hi David,

You can find the N3xx rack mount kit here:
https://www.ettus.com/product/details/n3xx-rack-mount

Regards,
Nate Temple

On Fri, Nov 16, 2018 at 8:19 AM Bengtson, David E. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Is there a 19” Rack mount Kit for the N310 available or planned?
>
> Thanks
>
> Dave
>
>
>
>
> ___
> 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] get_rx_antenna() bug in RFNoC x300_radio_ctrl_impl.cpp

2018-11-16 Thread Nate Temple via USRP-users

Hi Rob,

Thanks for bringing this to our attention. We will file an issue on our
internal bug tracker and get it resolved.

Regards,
Nate Temple

On Fri, Nov 16, 2018 at 10:41 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am using the RFNoC radio_ctrl API with my X310 and when I call
> get_rx_antenna() , I get an empty string.  The problem is in
> x300_radio_ctrl_impl.cpp.  The corresponding set_rx_antenna() function
> should be calling the base class radio_ctrl_impl->set_rx_antenna() so that
> the locally cached value is updated.  But, this call is missing.  Thus, any
> call to get_rx_antenna() which is not overridden for the X310 always
> returns an empty string.
> Rob
> ___
> 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] synchronizing multiple USRP N310

2018-12-10 Thread Nate Temple via USRP-users

Hi Florian,

If you pass the arg  "--ref external" to tx_waveforms, does it resolve this
frequency offset?

https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L62

Regards,
Nate Temple

On Thu, Dec 6, 2018 at 12:22 AM Florian Kaltenberger via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Marcus,
>
> I have measured this with a spectrum analyzer simply by setting markers to
> the peak of the sinusoid (one marker per measured USRP) and then taking the
> delta.
>
> Could it be that the USRP is ignoring the external reference when used
> alone? Remember, I am doing the test with one USRP at a time, as the test
> using multiple USRP simultaneously does not work.
>
> Florian.
> On 06/12/2018 00:29, Marcus Müller wrote:
>
> oh! That means 341 ppb frequency error, which *really* shouldn't be
> happening.
>
> I'd like to get some statistics of that error, how are you measuring
> it?
>
> Best regards,
> Marcus
>
> On Wed, 2018-12-05 at 12:55 +0100, Florian Kaltenberger wrote:
>
> Sorry typo. I did use a frequency of 3.51GHz.
>
>
> On 5 Dec 2018, at 12:54, Marcus Müller  
> 
> wrote:
>
> Hi Florian,
>
> trying to get my head to understand the order of problems here:
> Could you try to use a higher frequency (say, --freq 2e9 instead of
> 3.5e6)?
> I'd thing 3.51 MHz is out of range for the N310, anyway?
>
> Best regards,
> Marcus
>
> On Wed, 2018-12-05 at 11:49 +0100, Florian Kaltenberger via USRP-
> users
> wrote:
>
> So I can confirm that there is a frequency offset between the two
> USRP N310s when using only an octoclock (10MHz + PPS) to
> synchronize.
> I have measured with the tx_waveforms program
> ./tx_waveforms --args
> "addr=192.168.x.2,time_src=external,clock_src=external,master_clo
> ck_r
> ate=122.88e6" --rate 122.88e6 --freq 3.51e6 --wave-type SINE --
> wave-
> freq 10e6 --gain 100
> on the first USRP N310 (x=10) and then on the other (x=20). There
> is
> an offset of 1200Hz between the peaks of the sinusoids between
> the
> two measurements.
> Using an external LO didn't change anything either. Unless I need
> to
> provide any other arguments in that case?
> I also tried to do a test where I use both USRPs simultaneously
> ./tx_waveforms --args
> "addr0=192.168.10.2,addr1=192.168.20.2,time_src=external,clock_sr
> c=ex
> ternal,master_clock_rate=122.88e6" --rate 122.88e6 --freq 3.51e6
> --
> wave-type SINE --wave-freq 10e6 --gain 100--channels "0,4"
> but unfortunately that does not work at all at my testbench
> (program
> hangs and no signal transmitted).
> My UHD version is 3.13.0.2 (UHD_3.13.0.HEAD-0-g0ddc19e5)
> Any help appreciated.
> Thanks!
> Florian.
>
>
> On 04/12/2018 21:29, Florian Kaltenberger via USRP-users wrote:
> Hi Marcus and Robin,
> thanks for your answers, this is helpful information. I should
> add,
> that I actually tried the synchronization with an octoclock
> (10MHz
> + PPS), but it did not give me the expected results, i.e., I
> saw
> some residual frequency offsets. But maybe I screwed up at some
> point. Let me do some more measurements and get back to you on
> this.
> Florian.
>
>
> On 04/12/2018 18:57, Marcus D. Leech via USRP-users wrote:
> On 12/04/2018 10:14 AM, Florian Kaltenberger via USRP-users
> wrote:
>
> Hi there,
> I just discovered that in addition to the external 10MHz
> reference in, the USRP N310 also has external local
> oscilator
> inputs, one for each daughterboard and each TX/RX. So does
> that
> mean that in order to synchronize multiple N310 in
> frequency,
> phase, and time, it is no longer sufficient to use an
> octoclock
> to provide a 10MHz reference and PPS? If so, at what
> frequency
> do you have to drive the external LOs and at what power?
> Florian.
>
>
> In addition to what Robin posted, I'll observe that the
> external
> LO port is an *additional feature* of this device.
>
> You should still be able to use the external 10MHz and 1PPS
> ports
> the same way you would with a B210 or E310, since the AD9371
>  front-end chip is similar to the AD9361 chip used in the
> B210
> and E310.
>
> The thing about synchronizing multiple independent PLL
> synthesizers, though, compared to a strictly-shared-LO, is
> that
> the former will
>  experience both phase ambiguities, and have a higher mutual
> phase-noise than the latter, which is why you might decide to
> choose
>  the latter.
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Follow us on Google+, LinkedIn, or Twitter!
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Follow us on Google+, LinkedIn, or Twitter!
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Follow us

Re: [USRP-users] Device String for external clock source USRP N210

2019-01-09 Thread Nate Temple via USRP-users

Hi Andre,

GQRX uses gr-osmosdr under the hood to interface to the USRP, the setters
and getters are there [0] to set the sources for an external ref/timing
source, but it does not parse the device arg to set them [1].  If you add
the parsing and rebuild gr-osmosdr and then GQRX, it will work.

https://github.com/osmocom/gr-osmosdr/blob/master/lib/uhd/uhd_source_c.cc#L392-L437
https://github.com/osmocom/gr-osmosdr/blob/master/lib/uhd/uhd_source_c.cc#L51-L127

Regards,
Nate Temple

On Wed, Jan 9, 2019 at 5:05 PM Andre Kraller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> i tried to get the N210  working with external clock source on GQRX by
> adding the following to the device string:
>
> *clock_source*=*external*
>
> *But it is not working.*
>
> *With gnuradio the external clock source is working fine.*
>
> *Please, anyone can help me?*
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Python uhd API

2019-01-16 Thread Nate Temple via USRP-users

Hi Luz,

You can call the api calls just as you would in C++ from the usrp object.

For example:

usrp = uhd.usrp.MultiUSRP(args.args)

usrp.set_clock_source("external")
usrp.set_time_source("external")

Regards,
Nate Temple

On Wed, Jan 16, 2019 at 2:51 PM Florez Manduca, Luz E CIV USARMY (USA) via
USRP-users  wrote:

> Does anyone have any sample python uhd API code to select the clock source
> (internal, external, GPSDO)? The UHD manual has no documentation on the
> python uhd APIs (only the C++ ones and I am quite lost there). Any
> suggestion would be greatly appreciated.
>
> Thank you very much.
>
> Sincerely.
>
> Luz Elena (Luchi) Florez Manduca (formerly Roth)
> R&D Electrical Engineer
> US Army Armament Research Development & Engineering Center
> Precision Armaments & Intelligent Sensors Division
> Munition Sensors Branch
> RDAR-MEF-P, Bldg 407 Buffington Road, Picatinnny Arsenal, NJ 07806-5000
> Desk 973-724-6618
> Cell 267-884-9517
> New Home 267-247-5839
> luz.e.florezmanduca@mail.mil
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 something or other

2019-01-21 Thread Nate Temple via USRP-users

Hi Steve,

Those application notes are outdated. We are working on updating them
currently and expect to have the new versions posted soon.

I'll follow up with you off list with a set of instructions using a newer
version of UHD.

Regards,
Nate Temple

On Mon, Jan 21, 2019 at 9:43 AM Steve Clift via USRP-users <
usrp-users@lists.ettus.com> wrote:

> We are working on an application that involves development of an RFNOC
> module to be used in the Gnuradio environment. What is the recommended way
> to build working, compatible versions of UHD (with RFNOC), Gnuradio and
> gr-ettus for the E310? So far we are not having much luck.
>
>
>
> We have tried following
>
>
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
>
>
> which uses PyBOMBS recipe e3xx-rfnoc. That fails during the Gnuradio cmake
> runs because the Python “six” module is not included in the
> cross-development environment. This can be worked around by installing six
> while PyBOMBS is busy compiling UHD, but Gnuradio compilation then fails,
> apparently because an incompatible version of volk is checked out.
>
>
>
> Also
>
>
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>
>
>
> The git clone command for UHD probably should include the –recursive
> option to have the FPGA source submodule included in the UHD tree,
> presumably with a compatible commit. The version of Gnuradio is limited to
> 3.7.13.4 or earlier because later versions require a more recent version of
> cmake than that in the cross-development environment. FPGA bit files built
> from this setup fail to load with uhd_usrp_probe, which reports a CODEC
> loopback test failure.
>
>
>
> There is more, but for the sake of brevity, I’ll stop there.
>
>
>
> What to do?
>
>
>
> Thanks, Steve
> --- CONFIDENTIALITY NOTICE: This
> email and any attachments are for the sole use of the intended recipient
> and may contain material that is proprietary, confidential, privileged or
> otherwise legally protected or restricted under applicable government laws.
> Any review, disclosure, distributing or other use without expressed
> permission of the sender is strictly prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies without
> reading, printing, or saving..
> ___
> 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] Issues with N300 - GPSDO Lock/Synchronization, Spectrum asymmetry, MPM performance and Low band phase

2019-01-25 Thread Nate Temple via USRP-users

Hi Sam,

These are all new issues that we were unaware of. I will follow up with you
off list to debug these issues through your previously sent email to
supp...@ettus.com.


Regards,
Nate Temple

On Fri, Jan 25, 2019 at 2:13 PM Samuel Prager via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We are experiencing a number of issues with our N300s. We would like to
> know if these are known issues and whether or not they are being addressed.
>
> We have recently updated the filesystems, FPGA images and UHD/MPM to
> 3.13.1 (currently up to date with UHD 3.13.1 release, commit 711ec8a). We
> are using our N300s in embedded mode. All software/rfnoc firmware has been
> previously tested and used on X300s and E312s.
>
> I have uploaded a few supporting images to a google drive folder. (Link:
> https://drive.google.com/drive/folders/1b1T69G7AAA2-QlIByBYp9UQ_gs8_1253?usp=sharing
> )
>
>
> 1) GPSDO Locking and Synchronization:
>
> - The time to obtain and GPS lock, even when outside is long and often
> unstable. Code used to query GPSDO lock:
>
> *uhd::property_tree::sptr tree = _usrp->get_tree();*
> *uhd::fs_path path;*
> *std::vector mboard_names = tree->list("/mboards");*
> *path = "/mboards/" + mboard_names[0];*
> *try {*
> *path = "/mboards/" + mboard_names[0];*
> *try {*
> * tree->access(path / "sensors" / "gps_locked").get().value;*
> *} catch (std::exception &) {*
> *} catch (std::exception &) {*
> * std::cerr << "Error: No response from GPSDO" << std::endl;*
> * return false;*
> *}*
> *//Check for GPS lock*
> *uhd::sensor_value_t gps_locked = tree->access(path / "sensors" /
> "gps_locked").get();*
> *return(gps_locked.to_bool());*
> *}*
>
>
> This is a printout of the N300 sensor values when GPSDO is in a non-locked
> state:
>
> *- Sensors -*
> *Clock Source: gpsdo*
> *Time Source: gpsdo*
> *ref_locked: true*
> *gps_locked: false*
> *gps_time: 1548206414*
> *gps_tpv: {"ept": 0.0050001, "speed": 3.7042,
> "epv": 73.594, "device": "/dev/ttyPS1", "eps":
> 141.210001, "lon": -118.169881667, "epy": 109.009, "epx": 101.339,
> "alt": 367.69, "lat": 34.20062666702, "class": "TPV",
> "epc": 92.0, "track": 318.0, "time": "2019-01-23T01:20:14.000Z", "mode": 3,
> "climb": 32.203}*
> *gps_sky: {"hdop": 9.3007, "class": "SKY", "device":
> "/dev/ttyPS1", "pdop": 9.8007, "vdop": 3.2002,
> "ydop": 7.2696, "tdop": 3.6201, "gdop": 11.09,
> "satellites": [{"PRN": 30, "az": 53, "el": 71, "ss": 26, "used": false},
> {"PRN": 28, "az": 327, "el": 67, "ss": 0, "used": false}, {"PRN": 135,
> "az": 205, "el": 47, "ss": 34, "used": false}, {"PRN": 7, "az": 101, "el":
> 44, "ss": 33, "used": true}, {"PRN": 17, "az": 188, "el": 44, "ss": 32,
> "used": true}, {"PRN": 13, "az": 308, "el": 38, "ss": 0, "used": false},
> {"PRN": 11, "az": 80, "el": 32, "ss": 34, "used": true}, {"PRN": 1, "az":
> 99, "el": 17, "ss": 27, "used": false}, {"PRN": 19, "az": 199, "el": 17,
> "ss": 28, "used": true}, {"PRN": 18, "az": 70, "el": 14, "ss": 28, "used":
> true}, {"PRN": 8, "az": 39, "el": 11, "ss": 0, "used": false}, {"PRN": 9,
> "az": 164, "el": 10, "ss": 27, "used": false}, {"PRN": 15, "az": 321, "el":
> 7, "ss": 0, "used": false}, {"PRN": 5, "az": 255, "el": 4, "ss": 0, "used":
> false}], "xdop": 6.7598}*
> *fan: 4320*
> *temp: 42.0*
>
>
> This is a printout of the N300 sensor values when GPSDO is in a locked
> state:
>
> *- Sensors -*
> *Clock Source: gpsdo*
> *Time Source: gpsdo*
> *ref_locked: true*
> *gps_locked: true*
> *gps_time: 1548215759*
> *gps_tpv: {"lat": 34.200188333, "class": "TPV", "speed": 0.0, "device":
> "/dev/ttyPS1", "epv": 112.7, "ept": 0.0050001, "alt":
> 341.12, "mode": 3, "time": "2019-01-23T03:55:57.000Z", "climb":
> 0.69996, "lon": -118.169401667, "epc": 225.41,
> "track": 148.09}*
> *gps_sky: {"hdop": 3.2998, "class": "SKY", "satellites":
> [{"used": false, "el": 80, "az": 318, "PRN": 19, "ss": 12}, {"used": false,
> "el": 58, "az": 32, "PRN": 17, "ss": 13}, {"used": true, "el": 49, "az":
> 199, "PRN": 133, "ss": 35}, {"used": false, "el": 47, "az": 205, "PRN":
> 135, "ss": 31}, {"used": true, "el": 42, "az": 159, "PRN": 6, "ss": 31},
> {"used": false, "el": 36, "az": 311, "PRN": 24, "ss": 0}, {"used": true,
> "el": 35, "az": 75, "PRN": 28, "ss": 29}, {"used": true, "el": 24, "az":
> 221, "PRN": 13, "ss": 32}, {"used": false, "el": 19, "az": 258, "PRN": 15,
> "ss": 17}, {"used": false, "el": 17, "az": 189, "PRN": 2, "ss": 23},
> {"used": false, "el": 16, "az": 146, "PRN": 30, "ss": 21}, {"used": false,
> "el": 8, "az": 290, "PRN": 12, "ss": 15}, {"used": false, "el": 5, "az":
> 35, "PRN": 1, "ss": 0}], "vdop": 4.9004, "device":
> "/dev/ttyPS1", "pdop": 5.9004}*
> *fan: 4320*
> *temp: 38.0*
>
>
> We note that

Re: [USRP-users] Live rate changes within an RFNOC block

2019-01-28 Thread Nate Temple via USRP-users

Hi Andrew,

This is an issue we are aware of related to the RFNoC DDC/DUC blocks. We
are working on a fix and expect to have in a future release of UHD.

Regards,
Nate Temple

On Mon, Jan 28, 2019 at 10:11 AM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have an RFNOC block that, based on a control register can either
> decimate the signal it's working on or leave the output rate the same as
> the input rate. If I set the control register to an initial value (either
> decimate, or not decimate) and let the system run, it works fine in either
> mode. If I try to change the decimation mode while the block is running, I
> start getting timeout errors. I currently use the axi_rate_change block to
> help handle the rate change, and have tried to synchronize changing the
> block's mode (decimate or not) with the axi_rate_change's clear_user flag.
> Any thoughts?
>
> Thanks,
> Andrew
>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> 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] Utilisation of core RFNoC Image

2019-01-29 Thread Nate Temple via USRP-users

Hi Andrew,

Please take note of this section of the KB with regards to FPGA
modifications: https://kb.ettus.com/X300/X310#FPGA_User_Modifications

The PCIe interface and LvFpga_Chinch_Interface cannot be modified, even if
you are not using PCIe as a transport, as it will brick the flash memory:
https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/x300/x300.v#L656

As Leandro mentioned, removing the DDC/DUCs will result in the most gains.
You could possibly adjust the HB and max CIC within the DDC/DUC to reduce
utilization at the cost of reducing your resampling range.

Regards,
Nate Temple

On Tue, Jan 29, 2019 at 11:55 AM Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Andrew,
>
> Have you confirmed the available resources are not enough for your
> purpose?
> If so, I'd suggest you run the build command with the GUI option on,
> implement the design using the Vivado interface, and run a
> post-implementation utilization report to see which blocks are consuming
> the most. Still, there is not much that can be taken away without bricking
> the core, but if I recall correctly removing the DDCs and DUCs could
> release about 5 or 10% of the resources. This would, of course, reduce the
> functionality, forcing you to run the device at full rate all the time.
>
> Regards,
>
> Leo
>
> On Tue, Jan 29, 2019 at 4:15 PM Andrew Thommesen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> I was wondering if there is any way to reduce the resources used by the
>> default RFNoC image. It currently utilises ~50% of the Kintex-7 FPGA of the
>> Ettus X310, and I want to make more resources available (LUTs and FFs
>> mainly) for bespoke firmware development.
>>
>> Thanks,
>>
>> Andy
>>
>> Sent from Outlook 
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

2019-02-08 Thread Nate Temple via USRP-users

Hi Robert,

Can you try adding the NIC configuration to /root/.uhd/uhd.conf instead of
/etc/uhd/uhd.conf ? You'll need to run your UHD applications as root as
well.

You will also need to change the line:

dpdk-driver=/usr/local/lib/dpdk-pmds/

to be:

dpdk-driver=/usr/lib/x86_64-linux-gnu/

You'll also need to update the MAC addresses for your NICs.


With the config setup, you'll see the NICs come up like this when running a
UHD application:

...
PMD: ixgbe_dev_link_status_print():  Port 0: Link Down
EAL: Port 0 MAC: xx xx xx xx xx xx
EAL: Port 0 UP: 1
PMD: ixgbe_dev_link_status_print():  Port 1: Link Down
EAL: Port 1 MAC: xx xx xx xx xx xx
EAL: Port 1 UP: 1
EAL: Init DONE!
EAL: Starting I/O threads!
USER2: Thread 1 started
[00:00:00.03] Creating the usrp device with:
...

We'll be updating the DPDK docs to reflect a few of these changes before
the final 3.14 release.

Regards,
Nate Temple


On Fri, Feb 8, 2019 at 6:40 AM Robert via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I found this wiki page on DPDK:
> https://files.ettus.com/manual/page_dpdk.html
>
>
>
> Tried to follow the described steps on Xubuntu 18.04 with UHD
> v3.14.0.0-rc1 (also updated SD and FPGA image) and Intel X520DA, but no
> success so far.
>
>
>
> -  IOMMU is enabled for NIC, checked with short bash script:
>
> #!/bin/bash
>
> shopt -s nullglob
>
> for d in /sys/kernel/iommu_groups/*/devices/*; do
>
> n=${d#*/iommu_groups/*}; n=${n%%/*}
>
> printf 'IOMMU Group %s ' "$n"
>
> lspci -nns "${d##*/}"
>
> done;
>
>
>
> shows:
>
>
>
> IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation Device
> [8086:3ec2] (rev 07)
>
> IOMMU Group 10 00:1d.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #9 [8086:a298] (rev f0)
>
> IOMMU Group 11 00:1f.0 ISA bridge [0601]: Intel Corporation Device
> [8086:a2c9]
>
> IOMMU Group 11 00:1f.2 Memory controller [0580]: Intel Corporation 200
> Series PCH PMC [8086:a2a1]
>
> IOMMU Group 11 00:1f.3 Audio device [0403]: Intel Corporation 200 Series
> PCH HD Audio [8086:a2f0]
>
> IOMMU Group 11 00:1f.4 SMBus [0c05]: Intel Corporation 200 Series PCH
> SMBus Controller [8086:a2a3]
>
> IOMMU Group 12 00:1f.6 Ethernet controller [0200]: Intel Corporation
> Ethernet Connection (2) I219-V [8086:15b8]
>
> IOMMU Group 13 04:00.0 Network controller [0280]: Intel Corporation
> Wireless 8265 / 8275 [8086:24fd] (rev 78)
>
> IOMMU Group 14 3e:00.0 Non-Volatile memory controller [0108]: Samsung
> Electronics Co Ltd Device [144d:a808]
>
> IOMMU Group 1 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe
> Controller (x16) [8086:1901] (rev 07)
>
> IOMMU Group 1 01:00.0 Ethernet controller [0200]: Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>
> IOMMU Group 1 01:00.1 Ethernet controller [0200]: Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>
> IOMMU Group 2 00:02.0 VGA compatible controller [0300]: Intel Corporation
> Device [8086:3e92]
>
> IOMMU Group 3 00:14.0 USB controller [0c03]: Intel Corporation 200 Series
> PCH USB 3.0 xHCI Controller [8086:a2af]
>
> IOMMU Group 3 00:14.2 Signal processing controller [1180]: Intel
> Corporation 200 Series PCH Thermal Subsystem [8086:a2b1]
>
> IOMMU Group 4 00:16.0 Communication controller [0780]: Intel Corporation
> 200 Series PCH CSME HECI #1 [8086:a2ba]
>
> IOMMU Group 5 00:17.0 SATA controller [0106]: Intel Corporation 200 Series
> PCH SATA controller [AHCI mode] [8086:a282]
>
> IOMMU Group 6 00:1b.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #17 [8086:a2e7] (rev f0)
>
> IOMMU Group 7 00:1c.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #1 [8086:a290] (rev f0)
>
> IOMMU Group 8 00:1c.2 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #3 [8086:a292] (rev f0)
>
> IOMMU Group 9 00:1c.4 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #5 [8086:a294] (rev f0)
>
>
>
>
>
> -  hugepages are available and free according to cat
> /proc/meminfo | grep Huge:
>
> AnonHugePages: 0 kB
>
> ShmemHugePages:0 kB
>
> HugePages_Total:2048
>
> HugePages_Free: 2048
>
> HugePages_Rsvd:0
>
> HugePages_Surp:0
>
> Hugepagesize:   2048 kB
>
>
>
>
>
> -  vfio-pci is loaded and binding is changed to DPDK driver with
> dpdk-devbind script, dpdk-devbind shows
>
> Network devices using DPDK-compatible driver
>
> 
>
> :01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> drv=vfio-pci unused=ixgbe
>
> :01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> drv=vfio-pci unused=ixgbe
>
>
>
>
>
> -  edited the /etc/uhd/uhd.conf file according to the wiki page
>
>
>
> -  Running benchmark_rate with the use_dpdk=1 option
>
> sudo /usr/local/lib/uhd/examples/benchmark_rate  \
>
>--args
> "type=n3xx,mgmt_add

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

2019-02-08 Thread Nate Temple via USRP-users

Hi Robert,

Can you send the output of:

tree /sys/kernel/iommu_groups/

Do you have an external GPU installed on your system?

Regards,
Nate Temple



On Fri, Feb 8, 2019 at 9:13 AM  wrote:

> Hi Nate,
>
>
>
> thanks for the quick reply. I changed the dpdk-driver and copied the
> config file to /root/.uhd/uhd.conf. MAC addresses are correct. Started
> benchmark_rate as root this time, without using sudo. Still get the same
> error.
>
>
>
> Robert
>
>
>
> *From:* Nate Temple [mailto:nate.tem...@ettus.com]
> *Sent:* Friday, February 08, 2019 5:58 PM
> *To:* Pöhlmann, Robert
> *Cc:* Nick Foster; Michael West; USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1
>
>
>
> Hi Robert,
>
> Can you try adding the NIC configuration to /root/.uhd/uhd.conf instead of
> /etc/uhd/uhd.conf ? You'll need to run your UHD applications as root as
> well.
>
> You will also need to change the line:
>
> dpdk-driver=/usr/local/lib/dpdk-pmds/
>
> to be:
>
> dpdk-driver=/usr/lib/x86_64-linux-gnu/
>
> You'll also need to update the MAC addresses for your NICs.
>
>
> With the config setup, you'll see the NICs come up like this when running
> a UHD application:
>
> ...
> PMD: ixgbe_dev_link_status_print():  Port 0: Link Down
> EAL: Port 0 MAC: xx xx xx xx xx xx
> EAL: Port 0 UP: 1
> PMD: ixgbe_dev_link_status_print():  Port 1: Link Down
> EAL: Port 1 MAC: xx xx xx xx xx xx
> EAL: Port 1 UP: 1
> EAL: Init DONE!
> EAL: Starting I/O threads!
> USER2: Thread 1 started
> [00:00:00.03] Creating the usrp device with:
> ...
>
> We'll be updating the DPDK docs to reflect a few of these changes before
> the final 3.14 release.
>
> Regards,
> Nate Temple
>
>
>
> On Fri, Feb 8, 2019 at 6:40 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I found this wiki page on DPDK:
> https://files.ettus.com/manual/page_dpdk.html
>
>
>
> Tried to follow the described steps on Xubuntu 18.04 with UHD
> v3.14.0.0-rc1 (also updated SD and FPGA image) and Intel X520DA, but no
> success so far.
>
>
>
> -  IOMMU is enabled for NIC, checked with short bash script:
>
> #!/bin/bash
>
> shopt -s nullglob
>
> for d in /sys/kernel/iommu_groups/*/devices/*; do
>
> n=${d#*/iommu_groups/*}; n=${n%%/*}
>
> printf 'IOMMU Group %s ' "$n"
>
> lspci -nns "${d##*/}"
>
> done;
>
>
>
> shows:
>
>
>
> IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation Device
> [8086:3ec2] (rev 07)
>
> IOMMU Group 10 00:1d.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #9 [8086:a298] (rev f0)
>
> IOMMU Group 11 00:1f.0 ISA bridge [0601]: Intel Corporation Device
> [8086:a2c9]
>
> IOMMU Group 11 00:1f.2 Memory controller [0580]: Intel Corporation 200
> Series PCH PMC [8086:a2a1]
>
> IOMMU Group 11 00:1f.3 Audio device [0403]: Intel Corporation 200 Series
> PCH HD Audio [8086:a2f0]
>
> IOMMU Group 11 00:1f.4 SMBus [0c05]: Intel Corporation 200 Series PCH
> SMBus Controller [8086:a2a3]
>
> IOMMU Group 12 00:1f.6 Ethernet controller [0200]: Intel Corporation
> Ethernet Connection (2) I219-V [8086:15b8]
>
> IOMMU Group 13 04:00.0 Network controller [0280]: Intel Corporation
> Wireless 8265 / 8275 [8086:24fd] (rev 78)
>
> IOMMU Group 14 3e:00.0 Non-Volatile memory controller [0108]: Samsung
> Electronics Co Ltd Device [144d:a808]
>
> IOMMU Group 1 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe
> Controller (x16) [8086:1901] (rev 07)
>
> IOMMU Group 1 01:00.0 Ethernet controller [0200]: Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>
> IOMMU Group 1 01:00.1 Ethernet controller [0200]: Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>
> IOMMU Group 2 00:02.0 VGA compatible controller [0300]: Intel Corporation
> Device [8086:3e92]
>
> IOMMU Group 3 00:14.0 USB controller [0c03]: Intel Corporation 200 Series
> PCH USB 3.0 xHCI Controller [8086:a2af]
>
> IOMMU Group 3 00:14.2 Signal processing controller [1180]: Intel
> Corporation 200 Series PCH Thermal Subsystem [8086:a2b1]
>
> IOMMU Group 4 00:16.0 Communication controller [0780]: Intel Corporation
> 200 Series PCH CSME HECI #1 [8086:a2ba]
>
> IOMMU Group 5 00:17.0 SATA controller [0106]: Intel Corporation 200 Series
> PCH SATA controller [AHCI mode] [8086:a282]
>
> IOMMU Group 6 00:1b.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #17 [8086:a2e7] (rev f0)
>
> IOMMU Group 7 00:1c.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #1 [8086:a290] (rev f0)
>
> IOMMU Group 8 00:1c.2 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #3 [8086:a292] (rev f0)
>
> IOMMU Group 9 00:1c.4 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #5 [8086:a294] (rev f0)
>
>
>
>
>
> -  hugepages are available and free according to cat
> /proc/meminfo | grep Huge:
>
> AnonHugePages: 0 kB
>
> ShmemHugePages:0 kB
>
> HugePages_To

Re: [USRP-users] [Discuss-gnuradio] [UHD] Announcing 3.14.0.0 Release Candidate 1

2019-02-14 Thread Nate Temple via USRP-users

Hi Andre,

The one example I can give at this time is limited and semi-anecdotal as
I've only tested it on a single machine.

With an i7-4790k / Intel x520-DA2 and N310, to stream at full duplex, over
two channels at 125 MS/s, the lowest I can run my CPU clock freq at without
flow control errors is 3.8 GHz using benchmark_rate and the native
networking stack. Using DPDK I can run 2x2 @ 125 MS/s with my CPU freq
locked at 1.5 GHz with no flow control errors.

Regards,
Nate Temple

On Thu, Feb 14, 2019 at 3:57 AM Andre Puschmann <
andre.puschm...@tu-ilmenau.de> wrote:

> Hey guys,
>
> any idea or numbers on the performance improvement using DPDK, e.g. CPU
> usage during rx/tx streaming, when compared to the legacy approach?
> Would be great to get a feeling for the achievable gains.
>
> Thanks
> Andre
>
>
> On 13/2/19 20:58, Nick Foster via USRP-users wrote:
> > Any plans to update to the latest API? Won't compile with anything after
> > 17.05.
> >
> > On Wed, Feb 13, 2019, 11:33 AM Michael West
> >  > > wrote:
> >
> > Hi Nick,
> >
> > Information on using DPDK can be found here:
> > http://files.ettus.com/manual/page_dpdk.html
> >
> > DPDK can be used with any example.  Think of it as an accelerator
> > for Ethernet transports if using Intel NICs.
> >
> > Regards,
> > Michael
> >
> > On Thu, Feb 7, 2019 at 10:29 AM Nick Foster
> >  > > wrote:
> >
> > Great news! DPDK support is an interesting development. Is there
> > any documentation or examples which show this capability?
> >
> > Nick
> >
> >
> > On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users
> >  > > wrote:
> >
> > The release candidate of UHD version 3.14.0.0 has been
> > tagged and is available for testing.  This API release
> > introduces support for the N320 and N321 USRPs soon to be
> > released (watch for the announcement on ettus.com
> > !), a DPDK-based transport, and several
> > other features and bug fixes.  This release includes all bug
> > fixes and enhancements in the 3.13.0.1, 3.13.0.2, and
> > 3.13.1.0 maintenance releases.
> >
> > The tag for this release candidate:
> >
> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
> >
> > There have been 406 commits since the last API release
> > (3.13.0.0)which can be viewed here:
> >
> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
> >
> > Please report any bugs found on the UHD issue tracker:
> > http://github.com/EttusResearch/uhd/issues
> > * Please do not use the issue tracker for help or support.
> >
> > Pull requests for direct code changes may be submitted to
> > the UHD or FPGA repositories:
> > http://github.com/EttusResearch/uhd/pulls
> > http://github.com/EttusResearch/fpga/pulls
> >
> > CHANGELOG:
> > ## 003.014.000.000
> > * N320: Add N320 and N321
> > * Test: Add Python API test
> > * Device3: Move from packet-based to byte-based flow control
> > * X300: Reduce default send_frame_size to 4000 over Ethernet
> > * UHD: Release recv buffers earlier in rx_streamer
> > * Device3: Constrain send_buff_size to input fifo size
> > * X300: Change Ethernet buffering
> > * MPMD: Parallelize broadcast-finding
> > * Device: Parallelize device discovery
> > * Docs: Fix Doxygen warnings
> > * B100: Move fifo_ctrl_excelsior to b100 subdir
> > * B100: Fix fifo_ctrl_excelsior not exiting
> > * B100: Remove all Boostisms from fifo_ctrl_excelsior
> > * B100: Demote some clocking-related log messages to trace
> > * X300: Log git hash and compat number as debug message
> > * N310: Modify AD9371 reset function to keep it in reset
> > * N3xx: clocking API changes for transitioning clock and
> > time sources
> > * E320: bist: Fix ref_clock lock test implementation
> > * UHD: Fix ADF400x driver for ref counter and charge pump
> mode
> > * E320: bist: Add link_up test
> > * MPM: Get list of temperatures from all thermal zones
> > * E320: Add all 5 temp sensors, fan sensor and rssi sensors
> > per channel
> > * E320: Fix tx/rx atr - antenna and frequency settings
> > * E320: Enable devtest for E320
> > * X300: Move defaults to their own header
> > * UHD: Improve constrained_device_args_t
> > * X300: Use constrained_args
> > * X300: Enable clock_source and time_source device

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

2019-02-15 Thread Nate Temple via USRP-users

Hi Kurt,

There is work being done to convert the E310/2 to the MPM architecture, but
it is not ready for release yet.

DPDK is only supported on devices that have an additional management
interface such as the N3xx. It should work on the E320, but I have not
tested it yet. The UHD DPDK implementation requires the separate management
interface as it only currently handles UDP packets and doesn't support the
MPM TCP RPC commands or the device initialization.

Additional the streaming restrictions of the E31x USRPs over the 1Gb
interface are due to the routing through the onboard ARM processor, even if
DPDK was supported on the E31x, it would not make any performance
improvements for that device.

Regards,
Nate Temple

On Fri, Feb 15, 2019 at 10:26 AM Kurt Kiefer via USRP-users <
usrp-users@lists.ettus.com> wrote:

> > a DPDK-based transport, and several other features and bug fixes.
>
>
> Can we still expect to see MPM support (and presumably DPDK support)
> on E310/E312 devices? Last July it sounded like there was ongoing work to
> update the E31x codebase to support these kinds of features.
>
> Kurt
>
> ___
> 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] GPS week rollover readiness?

2019-02-15 Thread Nate Temple via USRP-users

Hi Joshua,

The Jackson Labs based GPSDOs (for B2xx, X3xx and N3xx, E320) are all ready
for the GPS roll over event. We dont expect any issues with the JL GPSDOs
until 2028 and later. Depending upon when the units were manufactured it is
out until 2038.

I'll need to look into the Ublox on the E310.

Regards,
Nate Temple


On Fri, Feb 15, 2019 at 1:29 PM Sirkin, Joshua F. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I was wondering if Ettus or anyone on this listserve has tested their
> products to make sure that no issues are going to come up with the gps week
> rollover in April?
>
>
> https://www.orolia.com/resources/blog/lisa-perdue/2018/gps-2019-week-rollover-what-you-need-know
>
> The product that would worry me the most potentially is the E310 and how
> the UBLOX gps and how GPSD deal with the rollover, but I would also want to
> try to be prepared for any issues with the B or X series products that use
> a gpsdo.
>
> 
>  This message is intended only for the use of the individual or entity to
> which it is addressed and may contain ZETA Associates confidential or
> proprietary information. If you are not the intended recipient, any use,
> dissemination, or distribution of this communication is prohibited. If you
> have received this communication in error, please notify the sender and
> delete all copies.
>
> ___
> 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

1 2 >

1 - 100 of 158 matches

Mail list logo