Re: [USRP-users] USRP E100/E110 linux update

[Robin Coxe via USRP-users]

There is a legacy Ettus E100 github repo that may or may not be useful:
https://github.com/EttusResearch/ettus_oe

This product has been EOL for >5 years, so as Philip points out, the
institutional memory of it is basically non-existent.

On Mon, Nov 23, 2020 at 5:22 AM Sébastien DI MERCURIO via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Philips,
>
> thank you for your answer. I will have a look to your git repository. I'm
> not very good with linux kernel intrinsics but I will try to have driver
> work with newer kernel.
>
> If I succed, i will post my results.
>
> Thank you !
> Le 23/11/2020 à 14:10, Philip Balister a écrit :
>
> On 11/23/20 7:09 AM, Sébastien DI MERCURIO via USRP-users wrote:
>
> Hi,
>
> I've got several USRP E100/E110 with outdated Linux and Gnuradio
> software on it. So I decided to build a Yocto image, more up-to-date and
> succeeded in after several tries.
> The new image boots and run a reasonable updated version of Linux and
> Gnuradio.
>
> But, because of Ettus proprietary kernel driver, I cannot connect to
> FPGA and so the board is useless.
>
> It's an open driver, just non of us remember how it works. I did find
> the code:
> https://github.com/balister/linux-omap-philip
>
> The linux DMA architecture has likely changed, so the driver will need
> work, but the code is out there. Let me know if you have questions, it
> would be great to see these running. I'll answer as best I can. It has
> been like 6-7 years since I last looked at it though.
>
> Using it like an N-series is likely not possible. The fpga is connected
> to the Overo via the GPMC (General Purpose Memory Controller).
>
> Philip
>
>
> My questions are:
>
> - Did someone achieve to get an updated Linux base and Gnuradio
> software, with working FPGA communications (whatever the method)
>   - Is it possible to get source code of Ettus kernel driver, as the
> board is now End-of-life
>   - Is it possible to enable Ethernet communication pass-throughto
> FPGA, a bit like in N series, in order to use it over Ethernet(not
> standalone)
>
> Regards!
>
> Sebastien
>
>
>
>
>
>
>
>
>
> .
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> [image: INSA Toulouse]
>
> *Sébastien DI MERCURIO*
> *Ingénieur d'étude Systèmes embarqués et IoT*
> Département GEI
> Tél. : 05 61 55 98 34
> dimer...@insa-toulouse.fr
>
> INSA Toulouse
> 135 avenue de Rangueil
> 31077 Toulouse CEDEX 04
>
> *www.insa-toulouse.fr  *
> ___
> 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] Use of IEEE1588 PTP

[Robin Coxe via USRP-users]

The X310 does not support White Rabbit or IEEE 1588.

The N310/N320 have only been validated using a White Rabbit Master such as
this one: https://sevensols.es/index.php/index/timing-products/wr-len/
A simple PTP Master will almost certainly not work with the WR FPGA
bitstream.


On Thu, Oct 29, 2020 at 1:56 AM Bruckmeyer, Heiko via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> I have a question regarding the use of the simple synchronization protocol
> IEEE1588 Precision-Time-Protocol.
>
> I want to use Ettus USRP N3xx. I know that they support the White Rabbit
> protocol for synchronizing. PTP is a part of the White Rabbit. So is it
> possible to use a simple PTP Master and synchronize the USRP to it or do I
> need a White Rabbit Master?
>
> I know that the use of simple PTP will degrade the synchronization
> accuracy.
>
>
>
> Does the USRP X3xx also support White Rabbit or IEEE1588 PTP?
>
>
>
> Thanks and best regards,
>
> H. Bruckmeyer
>
>
>
>
>
>
>
>
> ___
> 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 HOST build fails on ubuntu 20.04 LTS - (missing dependencies)

[Robin Coxe via USRP-users]

This branch will allow you to build UHD 4.0.0 from source on Ubuntu 20.04:
https://github.com/EttusResearch/uhd/tree/atrnati/ubuntu-20.04-workaround

You could also try disabling the GPSDO if you don't need it with the cmake
argument  *-DENABLE_GPSD=OFF*



On Thu, Oct 29, 2020 at 5:21 AM Baroch Oren via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thank you so much Johannes for the prompt reply. It was very helpful.
>
> Actually I just need to build UHD HOST from source, as I'm tweaking code
> from the examples directory.
>
>
> I've removed python 2 & 2.7 from the system completely. now only python 3
> is there.
>
> still same casting errors for compiling 3.14 in file gpsd_iface.cpp
>
>
> here:
>
> baroch@reliable:~/uhd/host/build$ make
> [  2%] Built target uhd_rpclib
> [  2%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/gpsd_iface.cpp.o
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp: In member function ‘int64_t
> uhd::usrp::gpsd_iface_impl::_epoch_time()’:
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:141:62: error: cannot
> convert ‘timespec_t’ {aka ‘timespec’} to ‘time_t’ {aka ‘long int’}
>   141 | return (boost::posix_time::from_time_t(_gps_data.fix.time)
>   |~~^~~~
>   |  |
>   |
> timespec_t {aka timespec}
> In file included from /usr/include/boost/thread/xtime.hpp:16,
>  from /usr/include/boost/thread/pthread/mutex.hpp:20,
>  from /usr/include/boost/thread/mutex.hpp:16,
>  from
> /usr/include/boost/thread/pthread/shared_mutex.hpp:14,
>  from /usr/include/boost/thread/shared_mutex.hpp:28,
>  from /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:16:
> /usr/include/boost/date_time/posix_time/conversion.hpp:27:33: note:
> initializing argument 1 of ‘boost::posix_time::ptime
> boost::posix_time::from_time_t(time_t)’
>27 |   ptime from_time_t(std::time_t t)
>   | ^
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp: In member function
> ‘boost::gregorian::date uhd::usrp::gpsd_iface_impl::_gregorian_date()’:
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:148:61: error: cannot
> convert ‘timespec_t’ {aka ‘timespec’} to ‘time_t’ {aka ‘long int’}
>   148 | return
> boost::posix_time::from_time_t(_gps_data.fix.time).date();
>   |   ~~^~~~
>   | |
>   |
> timespec_t {aka timespec}
> In file included from /usr/include/boost/thread/xtime.hpp:16,
>  from /usr/include/boost/thread/pthread/mutex.hpp:20,
>  from /usr/include/boost/thread/mutex.hpp:16,
>  from
> /usr/include/boost/thread/pthread/shared_mutex.hpp:14,
>  from /usr/include/boost/thread/shared_mutex.hpp:28,
>  from /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:16:
> /usr/include/boost/date_time/posix_time/conversion.hpp:27:33: note:
> initializing argument 1 of ‘boost::posix_time::ptime
> boost::posix_time::from_time_t(time_t)’
>27 |   ptime from_time_t(std::time_t t)
>   | ^
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp: In member function
> ‘std::string uhd::usrp::gpsd_iface_impl::_gps_gprmc()’:
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:206:49: error: invalid cast
> from type ‘timespec_t’ {aka ‘timespec’} to type ‘time_t’ {aka ‘long int’}
>   206 | intfixtime = (time_t) _gps_data.fix.time;
>   | ^~~~
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp: In member function
> ‘std::string uhd::usrp::gpsd_iface_impl::_gps_gpgga()’:
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:241:45: error: invalid cast
> from type ‘timespec_t’ {aka ‘timespec’} to type ‘time_t’ {aka ‘long int’}
>   241 | intfixtime = (time_t) _gps_data.fix.time;
>   | ^~~~
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:268:42: error: ‘struct
> gps_data_t’ has no member named ‘separation’
>   268 | if (boost::math::isnan(_gps_data.separation))
>   |  ^~
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:272:58: error: ‘struct
> gps_data_t’ has no member named ‘separation’
>   272 | str(boost::format("%.3f,M,") %
> _gps_data.separation));
>   |  ^~
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:272:17: error: ‘str’ was not
> declared in this scope
>   272 | str(boost::format("%.3f,M,") %
> _gps_data.separation));
>   | ^~~
> /home/baroch/uhd/host/lib/usrp/gpsd_iface.cpp:272:17: note: suggested
> alternatives:
> In file included from /usr/include/boost/format.hpp:53,
> 

Re: [USRP-users] -- GPIO on N320 --

[Robin Coxe via USRP-users]

When a group of former Ettus engineers who helped develop the N320
investigated, Alex Williams discovered that FP0 for USRP N320 was added to
the host side in UHD v.3.15, but was not included in UHD v.3.14.  Upgrading
to UHD v.3.15 should solve your problem.



On Wed, Sep 2, 2020 at 11:29 AM Sumit Kumar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Just now I tried to print the available GPIO available. For N310 it shows:
>
> FP0
> RXA
> TXA
> RXB
> TXB
>
> But for N320 it shows:
> RXA
> TXA
> RXB
> TXB
>
>
> On Wed, Sep 2, 2020 at 7:58 PM Sumit Kumar  wrote:
>
>> Hi,
>>
>> I am also having the issue. Can anyone please help with the information :)
>>
>> For N310, there is FP0 available but for N320 I get following run time
>> error:
>> "  what():  RuntimeError: The hardware has no GPIO bank `FP0' "
>>
>> Regards
>> Sumit
>>
>> On Mon, Jan 27, 2020 at 11:02 PM Nowicki, Ed H. via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> When I call the UHD API function get_gpio_banks()
>>>
>>> I get the following banks:
>>>
>>> ‘RXB’ ‘TXB’ ‘RXA’ TXA’ but I do NOT get ‘FP0’.
>>>
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Ed
>>>
>>>
>>>
>>> *From: *USRP-users  on behalf of
>>> "Nowicki, Ed H. via USRP-users" 
>>> *Reply-To: *"Nowicki, Ed H." 
>>> *Date: *Monday, January 27, 2020 at 8:45 AM
>>> *To: *"usrp-users@lists.ettus.com" 
>>> *Subject: *[EXT] [USRP-users] -- GPIO on N320 --
>>>
>>>
>>>
>>> *APL external email warning: *Verify sender
>>> usrp-users-boun...@lists.ettus.com before clicking links or attachments
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I’m having a problem using the front panel GPIO on an N320.  I reverted
>>> back to a standard “HG” FPGA build and compiled the GPIO example program
>>> (UHD 3.14.0).   However, when I run the example program I get the following:
>>>
>>>
>>>
>>> Error: RuntimeError: The hardware has no gpio bank `FP0'
>>>
>>>
>>>
>>> Is the front panel GPIO bank on the N320 called “FP0” or something
>>> else?  I did not see a reference to this in the .dts.
>>>
>>>
>>>
>>> See below for a “uhd_uspr_probe”, “uhd_config_info” dump, and the
>>> terminal output after running ./gpio.
>>>
>>>
>>>
>>> Thanks for any help.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ed Nowicki
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ~~
>>>
>>> xku@sdr_nuc:~/workarea-uhd/uhd/host/examples/gpio/build$ uhd_usrp_probe
>>>
>>> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
>>> UHD_3.14.0.HEAD-0-g6875d061
>>>
>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>>> mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=31A5C5A,claimed=False,addr=192.168.20.2
>>>
>>> [INFO] [MPM.PeriphManager] init() called with device args
>>> `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320'.
>>>
>>> [INFO] [MPM.Rhodium-0] init() called with args
>>> `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320'
>>>
>>> [INFO] [MPM.Rhodium-1] init() called with args
>>> `mgmt_addr=192.168.20.2,clock_source=internal,time_source=internal,product=n320'
>>>
>>> [INFO] [0/Replay_0] Initializing block control (NOC ID:
>>> 0x4E91A004)
>>>
>>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
>>> 0x12AD1320)
>>>
>>> [INFO] [0/Radio_1] Initializing block control (NOC ID:
>>> 0x12AD1320)
>>>
>>> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC1)
>>>
>>> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC1)
>>>
>>> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
>>>
>>> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>>>
>>> [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
>>>
>>> [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
>>>
>>> _
>>>
>>> /
>>>
>>> |   Device: N300-Series Device
>>>
>>> | _
>>>
>>> |/
>>>
>>> |   |   Mboard: ni-n3xx-31A5C5A
>>>
>>> |   |   eeprom_version: 2
>>>
>>> |   |   mpm_version: 3.14.1.0-gbfb9c1c7
>>>
>>> |   |   pid: 16962
>>>
>>> |   |   product: n320
>>>
>>> |   |   rev: 7
>>>
>>> |   |   rpc_connection: remote
>>>
>>> |   |   serial: 31A5C5A
>>>
>>> |   |   type: n3xx
>>>
>>> |   |   MPM Version: 1.2
>>>
>>> |   |   FPGA Version: 5.3
>>>
>>> |   |   FPGA git hash: 3de8954.clean
>>>
>>> |   |   RFNoC capable: Yes
>>>
>>> |   |
>>>
>>> |   |   Time sources:  internal, external, gpsdo, sfp0
>>>
>>> |   |   Clock sources: external, internal, gpsdo
>>>
>>> |   |   Sensors: temp, gps_tpv, gps_time, fan, gps_sky, ref_locked,
>>> gps_gpgga, gps_locked
>>>
>>> |   | _
>>>
>>> |   |/
>>>
>>> |   |   |   RX Dboard: A
>>>
>>> |   |   |   ID: Unknown (0x0152)
>>>
>>> |   |   |   Serial: 3191E7D
>>>
>>> |   |   | _
>>>
>>> |   |   | 

Re: [USRP-users] cpld source code on UBX-160

[Robin Coxe via USRP-users]

The code for the CPLDs on the USRP daughtercards (UBX, N310, N320) is not
open source.   Under normal circumstances, there should be no reason to
modify it.




On Wed, Sep 2, 2020 at 5:48 PM 张忠山 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> There is a cpld (U38 epm570) on daughter board ubx-160. But I can't found
> the source code for it.
> Does it close source ? If not, Where are the souce code ?
>
> --
> Best Regards,
> zzs
>
>
> ___
> 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] B2xx/AD936x I/Q corrections

[Robin Coxe via USRP-users]

The AD9361 calibrations are described in great detail in the first 15 pages
or so of the AD9361 Reference Manual (ADI UG-570).   The TX QEC calibration
in particular takes a long time-- something like 100K RF clock cycles. You
can disable the various calibrations by mucking around with the register
map.


On Fri, Aug 28, 2020 at 7:03 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Does anyone know what time-scale the I/Q correct loop operates at in the
> AD9361?
>
> I'm using a B210 with my pulsar software and it just occurred to me that
> the failure of it to produce anything useful might be due to
>the I/Q corrections loop, which is fine for many types of telecom
> signals, but may well impress additional "noise" onto a pulsar signal,
> rendering
>synchronous detection useless.
>
>
>
> ___
> 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] Precise Time Synchronization In B200/N210

[Robin Coxe via USRP-users]

The phase ambiguity is introduced by the divide-by-2 in the PLLs of the
Analog Devices AD9361 RF integrated transceiver on the B200.   These
dividers randomly introduce a 0-degree or 180-degree phase shift when they
come up.



On Fri, Jun 12, 2020 at 4:08 PM Aaron Smith via USRP-users <
usrp-users@lists.ettus.com> wrote:

> All of the devices share a 10 MHz reference that is generated from the
> same source as the 1 PPS.
>
> When you say it's a phase ambiguity, are you suggesting that it's a
> problem with the 10Hz reference or something inherent in the radio hardware
> that I will have to deal with? Or is there a software fix?
>
> On Fri, Jun 12, 2020, 4:05 PM Nick Foster  wrote:
>
>> The change in time of arrival with B200s is due to phase ambiguity. Do
>> you have a 10MHz reference shared between your devices as well?
>>
>> Don't know why N210 has that off-by-one timestamp. I'm guessing that
>> there's an extra flop in the logic for the PPS timing chain somewhere -- as
>> in, the clock starts ticking on the first tick after PPS comes in. I've
>> made that error about half a million times, myself.
>>
>> Nick
>>
>> On Fri, Jun 12, 2020 at 2:23 PM Aaron Smith via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello all,
>>>
>>> I have two separate, but related, questions.
>>>
>>> I am trying to trigger an RF transmission every second, and I am
>>> receiving the transmission with a receiver that has very precise time
>>> stamps. I am driving the receiver with the same 1 PPS source as the B200
>>> and N210. For my simple test, I want the time of arrival at the receiver to
>>> register at 1 PPS + propagation delay of the RF coax cable + the USRP front
>>> end delay. In all cases I am running UHD 3.15.LTS
>>>
>>> With the N210 I can achieve this. However when I call
>>>
>>> usrp->set_time_next_pps(uhd::time_spec_t(0.0));
>>>
>>> and poll the last pps time, I see that it is consistently 20 ns before a
>>> second. That is, the pps shows at:
>>>
>>> 99980 ns
>>> 199980 ns
>>> 299980 ns
>>>
>>> If I call usrp->set_time_next_pps(uhd::time_spec_t(20.0e-9)); then the 1
>>> PPS registers on the second. It's almost like the clock is biased by 20 ns.
>>> I have observed this across 3 different N210s. What could be causing this?
>>>
>>> With the B200, every time I destroy and recreate the
>>> uhd::usrp::multi_usrp there is a random change in the time of arrival at
>>> the receiver that appears to be uniformly distributed between 0 and
>>> 1/master_clock_rate. Is this expected? The Ettus website says "All
>>> functions that directly interact with the AD93xx (tuning, gain change, etc)
>>> are subject to the scheduling of the AD93xx. The determinism of these
>>> operations are not guaranteed. "
>>>
>>> Is this what I am experiencing?
>>>
>>> Thank you for the help!
>>>
>>> ___
>>> 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] Dockerfile that builds GR v3.8.1.0 and UHD v.3.15.0.0 from source on Ubuntu 18.04

[Robin Coxe via USRP-users]

Since the release of UHD v3.15.0.0 and GNU Radio v.3.8.1.0, the Ubuntu
18.04 dependencies to build from source have evolved. The
documentation has not.

I've been looking for an excuse to learn how to use Docker containers,
so I created a Dockerfile based on Ubuntu 18.04 with the latest and
greatest UHD and GNU Radio builds. Hopefully it will save some pain
for people who are just getting started or who want to upgrade without
going bonkers:

https://github.com/robincoxe/ettus-docker/tree/master/ubuntu-uhd-gnuradio


Undoubtedly, the path of least resistance would be to upgrade your PC
to Ubuntu 20.04 and install UHD and GNU Radio as follows:
sudo apt install libuhd3.15.0
sudo apt install gnuradio

However, if you'd like to build GNU Radio and UHD from source as well
as keep running an older version of Ubuntu for whatever reason, you
could either refer to the dependencies in this Dockerfile as a
reference or you could just deploy the Docker image.


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

Re: [USRP-users] Cygwin build of E310_SG3

[Robin Coxe via USRP-users]

What version of UHD are you using?  If memory serves, you'll need Vivado
2017.4 for UHD versions up to v.3.14.x.x.  v.3.15 uses 2018.3 I think.

On Mon, Apr 20, 2020 at 11:24 AM Harris, Dan via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
> Is the windows Cygwin build of the E310_SG3 target being maintained?
>
>
>
> I have been following the build instructions and have Vivado 2019.1
> installed.  It is failing in multiple points in the generation of the IP.
> I had to correct some paths that should have been windows-ized but did not
> seem to be in tools/make/viv_hls_ip_builder.mak.
>
>
>
> I can build at least one of the components (IP fifo_short_2clk), so I am
> somewhat confident that Vivado is installed correctly, and that my ‘source
> setupenv.sh’ was done properly.
>
>
>
> However now I am getting this error which is just impenetrable (this is
> with a clean git pull, not the changes I reference above):
>
>
>
> 
>
> BUILDER: Building IP mig_7series_0 - zynq xc7z020/clg484/-3
>
> 
>
> BUILDER: Staging IP in build directory...
>
> BUILDER: Reserving IP location:
> /cygdrive/c/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/top/e31x/build-ip/xc7z020clg484-3/mig_7series_0
>
> BUILDER: Retargeting IP to part zynq/xc7z020/clg484/-3...
>
> BUILDER: Building IP...
>
> [00:00:00] Executing command: vivado -mode batch -source
> C:/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/tools/scripts/viv_generate_ip.tcl
> -log mig_7series_0.log -nojournal
>
> [00:00:47] Current task: Initialization +++ Current Phase: Starting
>
> [00:00:48] Current task: Initialization +++ Current Phase: Finished
>
> [00:00:48] Process terminated. Status: Failure
>
>
>
> 
>
> Warnings:   0
>
> Critical Warnings:  0
>
> Errors: 0
>
>
>
> BUILDER: Releasing IP location:
> /cygdrive/c/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/top/e31x/build-ip/xc7z020clg484-3/mig_7series_0
>
> make[1]: ***
> [/cygdrive/c/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/top/e31x/ip/mig_7series_0/Makefile.inc:32:
> /cygdrive/c/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/top/e31x/build-ip/xc7z020clg484-3/mig_7series_0/mig_7series_0.xci]
> Error 1
>
> make[1]: Leaving directory
> '/cygdrive/c/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/top/e31x'
>
> make: *** [Makefile:71: E310_SG3] Error 2
>
>
>
>
>
> build-ip/xc7z020clg484-3/ mig_7series_0.log is not helpful:
>
>
>
> #---
>
> # Vivado v2019.1 (64-bit)
>
> # SW Build 2552052 on Fri May 24 14:49:42 MDT 2019
>
> # IP Build 2548770 on Fri May 24 18:01:18 MDT 2019
>
> # Start of session at: Mon Apr 20 19:14:06 2020
>
> # Process ID: 181720
>
> # Current directory:
> C:/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/top/e31x/build-ip/xc7z020clg484-3
>
> # Command line: vivado.exe -mode batch -source
> C:/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/tools/scripts/viv_generate_ip.tcl
> -log mig_7series_0.log -nojournal
>
> # Log file:
> C:/Users/user/Documents/e310/usrp/uhd/fpga/usrp3/top/e31x/build-ip/xc7z020clg484-3/mig_7series_0.log
>
> # Journal file:
>
> #---
>
> source
> C:/Users/user/Documents/e310/usrp/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
> 'C:/Xilinx/Vivado/2019.1/data/ip'.
>
>
>
>
>
> There appears to be an error file and a core file:
>
> $ cat hs_err_pid181720.log
>
> #
>
> # An unexpected error has occurred (EXCEPTION_ACCESS_VIOLATION)
>
> #
>
> Stack:
>
> no stack trace available, please use hs_err_.dmp instead.
>
>
>
>
>
> Is this build maintained enough to use? Because of my limited setup at
> home, I really don’t want to spin up a new server or VM for this, but if it
> is required then I guess I will.
>
>
>
> Thanks,
>
> Dan Harris
>
>
> 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 

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

[Robin Coxe via USRP-users]

Hi Lukas.   Most USRP X310 Linux users employ 10gigE to connect to the host
PC.  PCIe on the USRP X310 uses a proprietary ASIC and the driver is, as
you discovered, built on an obsolete kernel.  You could attempt to appeal
directly to NI for support if switching to 10 gigE isn't an option for you.

-Robin


On Mon, Feb 24, 2020 at 10:23 AM Lukas Haase via USRP-users <
usrp-users@lists.ettus.com> wrote:

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

Re: [USRP-users] N310 schematic don't show all part

[Robin Coxe via USRP-users]

The N310 motherboard does not have a PCIe interface, proprietary or
otherwise.  Schematic p. 20 was a PoE controller on earlier, unreleased
versions of the N310, but it was omitted because it could not source enough
current to the device when both RF daughtercards were enabled.   The PoE
components were not populated on earlier module revisions and have been
eliminated entirely from recent revisions of the motherboard PCB.

Marcus is correct that several pages of the X310 schematic featuring the NI
PCIe ASIC were redacted because NI never authorized them for public release.




On Sun, Nov 17, 2019 at 9:28 PM Marcus D Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> That is, AFAIR, the properietary PCIE interface that NI don’t publish
> schematics for.
>
> Sent from my iPhone
>
> On Nov 18, 2019, at 12:12 AM, Thomas james via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> 
> Hi,
> i read N310 mother board schematic find that there should be a sheet 20
> but not in the pdf schematic. what is this part for?
> ___
> 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] emergence, help, build uhd with error about dpdk

[Robin Coxe via USRP-users]

What USRP are you targeting?
Also, I'm not sure it makes sense to enable DPDK on an XPS15 laptop with a
USRP.  It was targeted by Ettus for use with the USRP X3x0 and N3x0, which
most people use with desktop PCs with  dual10gigE NICs or a QSFP in the
case of the N320/N321.



On Sun, Oct 27, 2019 at 10:51 AM Nate Temple via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jane,
>
> What host OS are you using? What version of DPDK do you have installed?
>
> Can you try using the latest stable release, UHD 3.14.1.1, master can be
> unstable.
>
>
> Regards,
> Nate Temple
>
> On Sun, Oct 27, 2019 at 10:24 AM Jane Zhang via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> hello, i am a new user with ubuntu and uhd. Later i need to build
>> gnuradio.
>> I build uhd(look from changelog, release 3.15). There were errors about
>> dpdk as follows.
>> Would you please help to solve this problem. I have time to finish this
>> task.
>> Thank you so much!
>>
>> dell@dell-XPS-15-9550:~/uhd/host/build$ cmake ../
>> --
>> -- Configuring the Python interpreter...
>> -- Manually determining build Python version...
>> -- Python interpreter: /usr/bin/python3.6 Version: 3.6.8
>> -- Override with: -DPYTHON_EXECUTABLE=
>> -- Manually determining runtime Python version...
>> -- Python runtime interpreter: /usr/bin/python3.6 Version: 3.6.8
>> -- Override with: -DRUNTIME_PYTHON_EXECUTABLE=
>> -- Finding Python Libraries...
>> -- Could not find Python Libraries.
>> -- Operating on master branch.
>> -- Using UHD Images Directory: /usr/local/share/uhd/images
>> -- Build type not specified: defaulting to release.
>> --
>> -- Configuring Boost C++ Libraries...
>> -- Looking for optional Boost components...
>> -- Found Boost: /usr/include (found suitable version "1.58.0", minimum
>> required is "1.58")
>> -- Looking for required Boost components...
>> -- Found Boost: /usr/include (found suitable version "1.58.0", minimum
>> required is "1.58") found components:  chrono date_time filesystem
>> program_options regex system unit_test_framework serialization thread
>> atomic
>> -- Boost include directories: /usr/include
>> -- Boost library directories: /usr/lib/x86_64-linux-gnu
>> -- Boost libraries:
>> /usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_program_options.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so;/usr/lib/x86_64-linux-gnu/libboost_serialization.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;-lpthread;/usr/lib/x86_64-linux-gnu/libboost_atomic.so
>> --
>> -- Python checking for Python version 2.7 or greater
>> -- Python checking for Python version 2.7 or greater - found
>> --
>> -- Python checking for Mako templates 0.4.2 or greater
>> -- Python checking for Mako templates 0.4.2 or greater - found
>> --
>> -- Python checking for requests 2.0 or greater
>> -- Python checking for requests 2.0 or greater - found
>> --
>> -- Python checking for numpy 1.7 or greater
>> -- Python checking for numpy 1.7 or greater - found
>> --
>> -- Configuring LibUHD support...
>> --   Dependency Boost_FOUND = TRUE
>> --   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
>> --   Dependency HAVE_PYTHON_MODULE_MAKO = TRUE
>> --   Enabling LibUHD support.
>> --   Override with -DENABLE_LIBUHD=ON/OFF
>> --
>> -- Configuring LibUHD - C API support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Enabling LibUHD - C API support.
>> --   Override with -DENABLE_C_API=ON/OFF
>> --
>> -- Configuring LibUHD - Python API support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Dependency HAVE_PYTHON_MODULE_NUMPY = TRUE
>> --   Dependency HAVE_PYTHON_LIBS = FALSE
>> --   Disabling LibUHD - Python API support.
>> --   Override with -DENABLE_PYTHON_API=ON/OFF
>> --
>> -- Configuring Examples support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Enabling Examples support.
>> --   Override with -DENABLE_EXAMPLES=ON/OFF
>> --
>> -- Configuring Utils support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Enabling Utils support.
>> --   Override with -DENABLE_UTILS=ON/OFF
>> --
>> -- Configuring Tests support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Enabling Tests support.
>> --   Override with -DENABLE_TESTS=ON/OFF
>> --
>> -- Could NOT find LIBERIO (missing: LIBERIO_LIBRARY LIBERIO_INCLUDE_DIR)
>> --
>> -- Configuring LIBERIO support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Dependency LIBERIO_FOUND = FALSE
>> --   Disabling LIBERIO support.
>> --   Override with -DENABLE_LIBERIO=ON/OFF
>> --
>> -- Configuring USB support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Dependency LIBUSB_FOUND = TRUE
>> --   Enabling USB support.
>> --   Override with -DENABLE_USB=ON/OFF
>> --
>> -- Configuring B100 support...
>> --   Dependency ENABLE_LIBUHD = ON
>> --   Dependency ENABLE_USB = ON
>> --   Enabling B100 

Re: [USRP-users] python 2.7 on N310

[Robin Coxe via USRP-users]

Python 3 has been the default for MPM on the N310 since June of 2017.
https://github.com/EttusResearch/uhd/commit/5f99240bd283da3da71588fcb1c1886937693928

On Mon, Oct 21, 2019 at 9:37 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am just starting to play with the N310 and I am having issues with some
> of our flowgraphs that work fine with the X310 and the E320.  The issue
> seems to be that there seems to be minimal support for python 2.7 for the
> N310.  Is there a toolchain or anything else I can do to get better
> support?  Things like threading.py are missing and only in python3.5 for it.
>
> Thanks.
> ~Jason
> ___
> 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 Completing Radio Build and Installation

[Robin Coxe via USRP-users]

The E310/E312 has a small-ish FPGA that does not have enough resources to
accommodate the overhead associated with 14 RFNoC blocks.   You have
discovered empirically that you run out of space above 5 blocks.

On Wed, Oct 16, 2019 at 10:06 AM Jonathan Lockhart via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Greetings Nate,
>
> So been working through your instructions you linked and everything
> appears to be good on the software end. It is all cross-compiling and
> running on the E312. Unfortunately there appears to be a new issue. So when
> running the GUI for building an FGPA bit file, per the instructions, I have
> included an FFT, Window, and Fosphor, and selected the option to "File with
> FIFOS," which causes the build to fail. The GUI reports for the E310_SG3 it
> can support 14 blocks. I tested this with the command line version and 14
> also fails. The instructions show a command line option of 5 modules
> (blocks) which builds fine. If I up it to 6 it immediately fails. I have
> attached a copy of the failure output as a .txt file for 6 blocks.
>
> Regards,
> Jon
>
>
> On Fri, Oct 11, 2019 at 2:51 PM Jonathan Lockhart 
> wrote:
>
>> Greetings Nate,
>>
>> Thanks for getting back to me so quickly. I will be sure to flash the OS
>> to release 4 and roll back my dev environment to match the instructions.
>>
>> Regards,
>> Jon Lockhart
>>
>>
>> On Fri, Oct 11, 2019, 1:20 PM Nate Temple  wrote:
>>
>>> Hi Jon,
>>>
>>> If you are following this app note [0], I would recommend starting with
>>> the release-4 image. The pre-3.15 MPM based image that has been released is
>>> currently a "beta" release. It lacks several of the dependencies required
>>> to build out GNU Radio. We are working on a new release and hope to have it
>>> posted soon.
>>>
>>> [0] -
>>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>>>
>>>
>>> Regards,
>>> Nate Temple
>>>
>>> On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart <
>>> jlockhar...@gmail.com> wrote:
>>>
 Greetings Ettus Radio List,

 I have recently acquired and began using an Ettus E312 and have been
 trying to configure the dev host and the cross compile environment.
 Unfortunately I am having issues completing some of these tasks with the
 pre-release version of 3.15 image that Ettus mentions you should use in the
 manual for the E312. I forward those issues to support but have heard no
 reply. Please refer below to the issues I am reporting. The GNURadio cross
 compile issue with the SDK and environment is the more crucial one at the
 moment. I was wondering if anyone else has been experiencing these issues
 and if so how did you proceed to get it resolved. Is there an image, sdk,
 GNURadio version that I should be using other than the 3.15 image and
 instructions that Ettus currently recommends using until a stable RC is
 provided?

 Thanks for your help and feedback.

 Regards,
 Jon Lockhart


 -- Forwarded message -
 From: Jonathan Lockhart 
 Date: Mon, Oct 7, 2019 at 3:16 PM
 Subject: Issues Completing Radio Build and Installation
 To: 


 Greetings Ettus Support,

 I recently acquired an Ettus E312 and I was looking to do some
 development on it. Unfortunately I am have been having some issues. The
 manual via files.ettus.com and the "Getting Started" both failed to
 provide a working environment.

 The farthest I got was downloading the meta section direction for the
 E312 to get 3.15.0 image and sdk for the radio, and then following this
 guide page for 3.14, correcting the UHD install accordingly to comply with
 3.15. (Guide
 https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor
 )

 When mounting the cross compiled UHD folders via the instructions on
 the radio, and using the uhd_usrp_probe command, there is an error checking
 for the libusb_init information.

 root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe
 [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
 UHD_3.15.0.HEAD-0-g6563c537
 [ERROR] [UHD] Device discovery error: AssertionError:
 libusb_init(&_context) == 0
   in libusb_session_impl::libusb_session_impl()
   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36

 [ERROR] [UHD] Device discovery error: AssertionError:
 libusb_init(&_context) == 0
   in libusb_session_impl::libusb_session_impl()
   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36

 [ERROR] [UHD] Device discovery error: AssertionError:
 libusb_init(&_context) == 0
   in libusb_session_impl::libusb_session_impl()
   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36

 [INFO] [MPMD] Initializing 1 device(s) 

Re: [USRP-users] Getting started with our new N310s

[Robin Coxe via USRP-users]

Hi Johannes.  Things tend to go badly when the UHD and FPGA bitstream
versions on the N310 SD card don't match those on the host for the N3xx.
 Avoid using master with the N310 out of the box because the
filesystem/FPGA images most likely don't exist.

Burn this SD card image:
http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.14.1.1/n3xx_common_sdimg_default-v3.14.1.1.zip
(yes, the location is non-obvious) then build UHD v.3.14.1.1 on the host PC.

Starting with UHD v.3.14, the SFP+ ports are mapped to IP addresses
192.168.10.2 and 192.168.20.2, to be more consistent with the X310.  When
you issue the uhd_usrp_probe command, try adding the --args
"addr=192.168.x0.2" command.
I can't remember for certain if the HG (SFP0 = 1gigE and SFP1=10 gigeE) or
XG image (both 10gigE) is loaded by default.   I think it's HG.   Set the
MTU on the host side to 8000 for the 10gigE port.

The N310 Getting Started guide outlines the mender method of updating the
filesystem, which should also work, but I tend to prefer downloading the SD
card image and burning it myself.  Good luck.

-Robin



On Tue, Oct 15, 2019 at 2:47 AM Johannes Demel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> we just received some new N310s. Yeah!
>
> They don't work! N.
>
> Let me explain what I tried so far and what I found out. So far, I work
> with 2 devices.
>
> Summary:
> With factory default image I can find the device but `uhd_usrp_probe`
> fails.
> With a newly flashed image on the SD card, The SFP ports don't show up
> anymore.
>
>
> How do I recover my device that doesn't show the SFP ports anymore?
>
> What do I need to do to successfully run `uhd_usrp_probe`? Since this
> command errors out with the same error as a flowgraph, I assume if I get
> passed `uhd_usrp_probe` there is a good chance I'll be able to run a
> flowgraph.
>
> What is dtc? It errors out during FPGA image updates.
>
> What is the latest `sdimg` to install? I want to make sure I'm up to
> date. As soon as I figured out why the devices don't work.
>
> I append all the information I could find so far for my devices.
>
> Cheers
> Johannes
>
>
>
> On Host:
> $ uhd_config_info --print-all
> UHD 3.15.0.git-79-gf353db8f
> Build date: Tue, 08 Oct 2019 12:08:10
> C compiler: GNU 7.4.0
> C++ compiler: GNU 7.4.0
> C flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1
> -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
> C++ flags: -DUHD_RFNOC_ENABLED -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1
> -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR
> -fvisibility=hidden -fvisibility-inlines-hidden
> Enabled components: LibUHD, LibUHD - C API, LibUHD - Python API,
> Examples, Utils, Tests, USB, B100, B200, USRP1, USRP2, X300, N230, MPMD,
> N300, N320, E320, E300, OctoClock
> Install prefix: /gnuradio38
> Boost version: 1.65.1
> Libusb version: 1.0.23
> Package path: /gnuradio38
> Images directory: /gnuradio38/share/uhd/images
> ABI version string: 3.15.0
>
>
> $ uhd_image_loader --args "type=n3xx,addr=X.X.X.212,fpga=HG"
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.git-79-gf353db8f
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>
> mgmt_addr=X.X.X.128,type=n3xx,product=n310,serial=XXX,claimed=False,skip_init=1
> [INFO] [MPMD] Claimed device without full initialization.
> [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
> [INFO] [MPM.PeriphManager] Updating component `fpga'
> [INFO] [MPM.PeriphManager] Updating component `dts'
> [ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc',
> '--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n310.dtbo',
> '/lib/firmware/n310.dts']' returned non-zero exit status 1
> [INFO] [MPM.RPCServer] Resetting peripheral manager.
> [INFO] [MPM.PeriphManager] Device serial number: XXX
> [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
> [WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected
> compat for component `FPGA'. Expected: 5.2 Actual: 5.3
> [INFO] [MPM.PeriphManager] init() called with device args `'.
> [INFO] [MPMD IMAGE LOADER] Update component function succeeded.
>
> Rebooted devices, then:
>
> $ uhd_find_devices
> --
> -- UHD Device 0
> --
> Device Address:
>  serial: XX
>  addr: X.X.X.212
>  claimed: False
>  mgmt_addr: X.X.X.128
>  product: n310
>  type: n3xx
>
>
> --
> -- UHD Device 1
> --
> Device Address:
>  serial: n/a
>  claimed: False
>  mgmt_addr: X.X.X.123
>  product: n/a
>  reachable: No
>  type: n/a
>
>
> On Device 0:
>
> $ uhd_config_info --print-all
> UHD 3.13.0.2-0-unknown
> Build date: Fri, 08 Mar 2019 18:43:32
> C compiler: GNU 7.3.0
> C++ compiler: GNU 7.3.0
> C flags: -DUHD_IMAGES_DIR=OFF 

Re: [USRP-users] N310 link speed, buffer overflows and GPS locking / NMEA string

[Robin Coxe via USRP-users]

Hi Baroch.
When you update UHD on the host, you should also update the N310 SD card
filesystem to the corresponding version.  In your case:
http://files.ettus.com/binaries/cache/n3xx/meta-ettus-v3.14.0.0/

 DIrections on how to update the SD card can be found here:
https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card

You could try forcing the SFP+ network connections on your host PC to be
10gigE from the network manager.  Be sure to set the MTU manually to 8000
for both SFP+ ports to correspond to the network settings on the N310.
Double-check that you're loading the XG FPGA image (both SFP+ ports
provisioned as 10gigE).

Issue #3 may be related to the UHD version mismatch mentioned above.
 There is some info about how to query the GPSDO sensor from the ARM
processor on the N310 on the Ettus KB: https://kb.ettus.com/N300/N310 (scroll
down to the GSPDO section).

-Robin


On Wed, Oct 2, 2019 at 1:05 PM Baroch Oren via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all. This is my first post here so hopefully it will stand the
> expectations.
>
>
> My setup is:
> Device - N310 with UHD 3.13.0.2-0-uknown serial=31950A8
> Host - rebuilt UHD on the host computer, using
> 3.14.0.HEAD-0-g6875d061
> connected via mgmt via 1Gb eth, and 2 sfp ports.
> cpu_governor is set to performance (4 cores at 3.75GHz)
> network buffers (r_mem/w_mem) are 625,000,000
>
> 1. Once upgraded the host's UHD to 3.14.0 (and the FPGA image as well), we
> keep getting "Could not determine link speed; using 1GibE max speed of
> 12500". (These messages were not there before the upgrade). Is there
> any way to connect with both 10Gb connections and get feedback that this
> link speed is used by the software?
>
> 2. I cannot manage to sample for periods longer than 0.06 sec (0.08 fails)
> on 4 channels. the benchmark_rate example application cannot reach 10
> seconds without DDD or DDODD on sampling rate of 30.72e6 when clock is
> 122.88e6 . This limitation is fairly reproducable. Also it does not matter
> if I use GnuRadio or "rx_samples_to_file". Anyway data is routed to a
> ramdrive (write speed should be > 2Gbyte/sec). What I need is about 3
> seconds of continuous capture.
>
> 3. If I use usrp->set_time_source("external") I get an error "At least one
> PLL did not lock!" or "Failed to capture PPS within 1.1 seconds.
> TDC_STATUS: 0x0"
> and if I use "gpsdo", I cannot get any feedback that gps is pps locked and
> used. only the message "1) catch time transition at pps edge 2) set times
> next pps (synchronously)" - does it mean that gps is locked?
>
> 4. how can I get NMEA string from the internal GPSDO of the N310?
>
> Thanks in advance,
> Baroch Oren
> --
>
> ___
> 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 example programs - weird environment variable issue?

[Robin Coxe via USRP-users]

Your output indicates that you're executing UHD v.3.10.0.3, not version
3.14.1, so you must have multiple versions installed.

Go to /usr/local/lib (or wherever you installed UHD on your machine) and
make sure it looks something like this when you type in "ls -l uhd*":
lrwxrwxrwx 1 root root   16 Sep 16 11:03 libuhd.so -> libuhd.so.3.14.1
-rw-r--r-- 1 root root 15583328 Sep 16 11:01 libuhd.so.3.14.1

On Thu, Sep 19, 2019 at 3:55 PM David Smay via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I recently did a clean installation of UHD 3.14.1 and gnuradio 3.7.13.5 on
> Ubuntu 18.04 LTS, following the steps outlined in the Ettus knowledge base
> for installation from source.
>
> The installation worked great, and I started experimenting with the
> example programs installed with UHD (located in /usr/lib/uhd/examples/).
> At first they ran correctly and I was able to run the gpio and
> benchmark_rate programs without issue, getting the normal expected output
> for my b205mini-i.
>
> Without making any changes to the system, and in the same shell session,
> all of a sudden the example programs all started consistently generating
> errors when I tried to run them:
>
> dsmay4@UbuntuPrecision7530:/usr/lib/uhd/examples$ ./benchmark_rate
> --rx_rate 10e6
> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
>
>
>
> UHD Warning:
> EnvironmentError: IOError: Could not find path for image:
> usrp_b200_fw.hex
> Using images directory: 
> Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow
> the below instructions to download the images package.
> Please run:
>  "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
> Creating the usrp device with: ...
>
> UHD Warning:
> EnvironmentError: IOError: Could not find path for image:
> usrp_b200_fw.hex
> Using images directory: 
> Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow
> the below instructions to download the images package.
> Please run:
>  "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
> Error: LookupError: KeyError: No devices found for ->
> Empty Device Address
>
> This is quite strange as my uhd_images_downloader isn't installed to that
> directory, but it does run just fine.  uhd_find_devices and uhd_usrp_probe
> run fine and indicate no problems with the radio itself.  Other sdr apps
> using the b205 work just fine - the problem seems to only impact these
> example programs.
>
> I tried rebooting, as well as uninstalling and reinstalling UHD (which
> reinstalled the example programs) but the problem persists.  I'm mostly
> interested in figuring out what caused the spontaneous change in system
> behavior.  I can't for the life of me figure out why just these apps can't
> find the fpga images but everything else works just fine...
>
> TIA,
>
> 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] USRP B100 Help

[Robin Coxe via USRP-users]

Does this help?
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Configuring_USB

On Wed, Sep 11, 2019 at 1:08 PM Javier Uranga via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear Members in the List,
>
> I'm working with an old USRP B100 that came with a cubesat development
>  kit,
>
> Now suddenly stop working, no longer respond to:
>
> uhd_find_devices
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-⁠0-⁠unknown
> No UHD Devices Found
>
> uhd_usrp_probe
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-⁠0-⁠unknown
> Error: LookupError: KeyError: No devices found for -⁠-⁠-⁠-⁠-⁠>
> Empty Device Address
>
> I must to say that, until few minutes before, the device showed no
> problems, but after a switch OFF/ON the device, problems came up
>
> And when I ask:
>
> $lsusb
> the device found is:
> Bus 003 Device 003: ID 04b4:8613 Cypress Semiconductor Corp. CY7C68013
> EZ-⁠USB FX2 USB 2.0 Development Kit
>
> As you can see, the detected device is not longer Ettus USRP as use to be.
> More over, in the front panel, new led is on, there is a new led in ON
> status, the LED B: FPGA loaded
> (in addition to:
> LED A: transmitting,ON
> LED C: receiving,  ON
> LED D: FPGA loaded,   OFF
> LED E: reference lock, ON
> LED F: board power, ON )
>
> I already re installed the GNU RADIO 3.7.9 drivers for Ubuntu 16.04 and
> GNU RADIO 3.7.11 for Ubuntu 18.04, all systems where it use to work, But
> the USRP is no longer detected.
>
> drivers in Ubuntu 16.04:
> /usr/share/uhd/images$ ls
> usrp_b100_fw.ihx
> usrp_b100_fpga.bin
>
> What can be wrong ?, it's Firmware problem ?
> How can I solve it?
>
> I'll be very grateful with any comments or suggestions
>
> Best Regards,
> Javier Nicolas
> ___
> 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 Cannot ping or connect

[Robin Coxe via USRP-users]

que (s/n based) hostname...
>  Starting USRP Hardware Daemon (MPM)...
>  Starting Telephony service...
>  Starting Login Service...
>  Starting Hostname Service...
> [  OK  ] Started Login Service.
> [  OK  ] Started Telephony service.
> [  OK  ] Started Hostname Service.
> [  OK  ] Started Setting unique (s/n based) hostname.
>  Starting Avahi mDNS/DNS-SD Stack...
>  Starting Network Service...
> [  OK  ] Started Avahi mDNS/DNS-SD Stack.
> [  OK  ] Started Network Service.
>  Starting Network Name Resolution...
> [  OK  ] Started Network Name Resolution.
> [  OK  ] Started Mender OTA update service.
> [  OK  ] Reached target Host and Network Name Lookups.
> [  OK  ] Reached target Network.
>
> Alchemy 2018.04 ni-n3xx-3177E63 ttyPS0
>
> ni-n3xx-3177E63 login: root
> root@ni-n3xx-3177E63:~# [   24.582582] fpga_manager fpga0: writing
> n310.bin to Xilinx Zynq FPGA Manager
> [   25.414692] libphy: nixge_mii_bus: probed
> [   25.451582] libphy: nixge_mii_bus: probed
> [   25.469428] nixge 4000.ethernet sfp0: renamed from eth1
> [   25.713083] rfnoc_crossbar crossbar0: NI Platform RFNoC Crossbar
> registered
> [   25.751871] nixge 40008000.ethernet sfp1: renamed from eth1
> [   25.836282] usrp-dma-core: Registered rx-dma0
> [   25.887989] usrp-dma-core: Registered rx-dma1
> [   25.909555] usrp-dma-core: Registered rx-dma2
> [   25.949161] usrp-dma-core: Registered rx-dma3
> [   25.961521] usrp-dma-core: Registered rx-dma4
> [   25.966603] usrp-dma-core: Registered rx-dma5
> [   25.981382] usrp-dma-core: Registered rx-dma6
> [   25.991645] usrp-dma-core: Registered rx-dma7
> [   25.996824] usrp-dma-core: Registered rx-dma8
> [   26.011477] usrp-dma-core: Registered rx-dma9
> [   26.022402] usrp-dma-core: Registered tx-dma0
> [   26.027511] usrp-dma-core: Registered tx-dma1
> [   26.041439] usrp-dma-core: Registered tx-dma2
> [   26.052196] usrp-dma-core: Registered tx-dma3
> [   26.062320] usrp-dma-core: Registered tx-dma4
> [   26.067453] usrp-dma-core: Registered tx-dma5
> [   26.081501] usrp-dma-core: Registered tx-dma6
> [   26.092381] usrp-dma-core: Registered tx-dma7
> [   26.101605] usrp-dma-core: Registered tx-dma8
> [   26.112430] usrp-dma-core: Registered tx-dma9
> [   26.820220] nixge 4000.ethernet sfp0: Link is Up - Unknown/Unknown
> - flow control off
> [   26.900861] nixge 40008000.ethernet sfp1: Link is Up - 10Gbps/Full -
> flow control off
> [   29.080221] nixge 40008000.ethernet sfp1: Link is Down
> [   31.595778] random: crng init done
>
> On Thu, Sep 5, 2019 at 8:19 PM Robin Coxe via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Austin.  Is *enx70886b87f283 *a 1 gigE or 10gigE connection?  If it's
>> 1gigE, my guess is that your problem may be that the new SD card is loading
>> the XG FPGA image, which expects 10 gigE connections to the host on both
>> ports SFP0 and SFP1.   You'll need to update the SD card to load the HG
>> image from /lib/firmware at bootup (1 gigE on SFP0 on the N310, connected
>> to the Host PC using a cat 5 Ethernet cable and the SFP-to-RJ45 adapter).
>>
>> Instructions here:
>> https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Network_Mode_FPGA_Image_Update
>>
>> -Robin
>>
>>
>> On Thu, Sep 5, 2019 at 8:02 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 09/05/2019 10:28 PM, Austin Adam via USRP-users wrote:
>>>
>>> I recently had my USRP N310 sent out for repairs to fix one of the SMA
>>> connectors, and when it came back, there was a new SD card in the slot.
>>> When I turned it on after getting it back, I was unable to connect to it
>>> via 'uhd_find_devices'. I figured it was something with the SD card, so I
>>> eventually decided to rewrite the whole thing, in case it needed an update.
>>>
>>> That still did not fix the issue, and after trying just about
>>> everything, and following every possible tutorial on the ettus docs, and
>>> checking the forums, I have decided to ask you guys for help.
>>>
>>> Below you can find all the information about the UHD versions and the
>>> ifconfigs... hopefully that is enough to spark some ideas!
>>>
>>> The USRP can find itself on localhost as you can see here:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *root@ni-n3xx-3177E63:~# uhd_find_devices [INFO] [UHD] linux; GNU C++
>>> version 7.3.0; Boost_106600; UHD_3.14.0.0-0-g6875d061
>>> ---

Re: [USRP-users] USRP N310 Cannot ping or connect

[Robin Coxe via USRP-users]

Hi Austin.  Is *enx70886b87f283 *a 1 gigE or 10gigE connection?  If it's
1gigE, my guess is that your problem may be that the new SD card is loading
the XG FPGA image, which expects 10 gigE connections to the host on both
ports SFP0 and SFP1.   You'll need to update the SD card to load the HG
image from /lib/firmware at bootup (1 gigE on SFP0 on the N310, connected
to the Host PC using a cat 5 Ethernet cable and the SFP-to-RJ45 adapter).

Instructions here:
https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Network_Mode_FPGA_Image_Update

-Robin


On Thu, Sep 5, 2019 at 8:02 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 09/05/2019 10:28 PM, Austin Adam via USRP-users wrote:
>
> I recently had my USRP N310 sent out for repairs to fix one of the SMA
> connectors, and when it came back, there was a new SD card in the slot.
> When I turned it on after getting it back, I was unable to connect to it
> via 'uhd_find_devices'. I figured it was something with the SD card, so I
> eventually decided to rewrite the whole thing, in case it needed an update.
>
> That still did not fix the issue, and after trying just about everything,
> and following every possible tutorial on the ettus docs, and checking the
> forums, I have decided to ask you guys for help.
>
> Below you can find all the information about the UHD versions and the
> ifconfigs... hopefully that is enough to spark some ideas!
>
> The USRP can find itself on localhost as you can see here:
>
>
>
>
>
>
>
>
>
>
>
> *root@ni-n3xx-3177E63:~# uhd_find_devices [INFO] [UHD] linux; GNU C++
> version 7.3.0; Boost_106600; UHD_3.14.0.0-0-g6875d061
> -- -- UHD Device 0
> -- Device Address:
> serial: 3177E63 claimed: False mgmt_addr: 127.0.0.1 product:
> n310 type: n3xx*
>
> But when I run the command from the host machine, this is what I get:
>
>
>
> * admin@PC:~$ uhd_find_devices [INFO] [UHD] linux; GNU C++ version 8.3.0;
> Boost_106700; UHD_3.14.0.HEAD-0-g6875d061 No UHD Devices Found*
>
> *Here is ifconfig from the USRP:*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *root@ni-n3xx-3177E63:~# ifconfig eth0  Link encap:Ethernet  HWaddr
> 00:80:2F:24:01:14   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0   TX
> packets:0 errors:0 dropped:0 overruns:0 carrier:0   collisions:0
> txqueuelen:1000   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> Interrupt:27 Base address:0xb000 loLink encap:Local Loopback
> inet addr:127.0.0.1  Mask:255.0.0.0   UP LOOPBACK RUNNING
>  MTU:65536  Metric:1   RX packets:89 errors:0 dropped:0 overruns:0
> frame:0   TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000   RX bytes:7480 (7.3 KiB)  TX
> bytes:7480 (7.3 KiB) sfp0  Link encap:Ethernet  HWaddr
> 00:80:2F:24:01:15   inet addr:192.168.10.2  Bcast:192.168.10.255
>  Mask:255.255.255.0   UP BROADCAST RUNNING MULTICAST  MTU:8000
>  Metric:1   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000   RX bytes:0 (0.0 B)  TX bytes:2577
> (2.5 KiB) sfp1  Link encap:Ethernet  HWaddr 00:80:2F:24:01:16
> UP BROADCAST MULTICAST  MTU:8000  Metric:1   RX packets:0 errors:0
> dropped:0 overruns:0 frame:0   TX packets:1 errors:0 dropped:0
> overruns:0 carrier:0   collisions:0 txqueuelen:1000   RX
> bytes:0 (0.0 B)  TX bytes:62 (62.0 B)*
>
>
>
> *And here is ifconfig from the host machine: *
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *ugikie@Austin-Blade:~$ ifconfig enx70886b87f283:
> flags=4163  mtu 8000 inet
> 192.168.10.1  netmask 255.255.255.0  broadcast 192.168.10.255 inet6
> fe80::73b:c879:60cf:8127  prefixlen 64  scopeid 0x20 ether
> 70:88:6b:87:f2:83  txqueuelen 1000  (Ethernet) RX packets 0  bytes
> 0 (0.0 B) RX errors 0  dropped 0  overruns 0  frame 0 TX
> packets 46  bytes 4966 (4.9 KB) TX errors 0  dropped 0 overruns 0
>  carrier 0  collisions 0 lo: flags=73  mtu 65536
>   inet 127.0.0.1  netmask 255.0.0.0 inet6 ::1  prefixlen 128
>  scopeid 0x10 loop  txqueuelen 1000  (Local Loopback)
> RX packets 5037  bytes 466961 (466.9 KB) RX errors 0  dropped 0
>  overruns 0  frame 0 TX packets 5037  bytes 466961 (466.9 KB)
>   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 wlp59s0:
> flags=4163  mtu 1500 inet
> 172.28.229.114  netmask 255.255.240.0  broadcast 172.28.239.255
> inet6 fe80::c9b4:5623:34c4:ae56  prefixlen 64  scopeid 0x20
> ether 9c:b6:d0:18:53:3f  txqueuelen 1000  (Ethernet) RX packets
> 110339  bytes 123997000 (123.9 MB) RX errors 0  dropped 0  overruns
> 0  

Re: [USRP-users] Vivado Version Compatiability, X310

[Robin Coxe via USRP-users]

What Neel says in the previous is correct, but it doesn't answer your
question.  This error is telling you that the script is having issues with
the Vivado licenses on your PC.  One of the first things that the
*uhd_image_builder.py
*script does is execute *setupenv.sh *in *fpga/usrp3/top/x300*.  To attempt
to debug, navigate to that directory, and execute the setup script manually
from the command line *(source ./setupenv.sh* on Linux) and then try to
launch Vivado from the command line.  If Vivado launches successfully, go
the Help-->License Manager and make sure there aren't any expired licenses
and that Vivado is properly recognizing your 2018.3 license.   If Vivado
doesn't launch, make sure that the setup script is pointing to the location
where you installed Vivado.

You might also try running *uhd_image_builder.py -c*, which will clean up
any old IP cores and regenerate them.

-Robin



On Mon, Sep 2, 2019 at 8:08 AM Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Steve:
>
> In the UHD 3.14 release series, RFNoC requires the use of Xilinx Vivado
> version 2017.4.  In the UHD 3.15 release series, RFNoC will require the use
> of Xilinx Vivado version 2018.3.  Other versions of Vivado have not been
> tested and are not supported.  Please note that 3.15.0.0 has not been
> released yet.  I would suggest that you continue using the 3.14 release
> series until 3.15.0.0 is available, and this will allow you to continue
> using Vivado 2017.4.  Your Xilinx license should allow you to install and
> use multiple versions of Vivado.  Please let me know if you have any
> further questions.
>
> --Neel Pandeya
>
>
>
> On Mon, 2 Sep 2019 at 09:05, shachar J. brown via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I have been working for a long while with rfnoc on an X310.
>>
>> I have lately upgraded the rfnoc, and now when I try to run
>> uhd_image_builder.py I receive an error indicating I need Vivado 2018.12,
>> while my licence is for 2018.3. Upgrading the Vivado is currently not
>> available.
>>
>> 1. Is there any workaround for using the updated rfnoc version alongside
>> Vivado 2018.3 or older?
>> 2. If the first suggestion is not an option, is there any way to
>> downgrade the rfnoc to a version that is compatiable with Vivado 2018.3 or
>> older?
>>
>> Thanks in advance!
>> Steve
>>
>> ___
>> 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] e320 GPIO pinout

[Robin Coxe via USRP-users]

[image: e320_mini_hdmi.png]
Here's the pinout of the E320 GPIO connector.   Someone from Ettus Support
(i.e., who is still employed by NI) will have to comment on when the E320
schematics will be available.

On Tue, Aug 27, 2019 at 1:06 PM Aaron Holtzman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> The pinout for the e320 GPIO connector at
> https://files.ettus.com/manual/page_gpio_api.html does not indicate which
> pin is used for the return current. Is it pin 17 (non-mini HDMI) which HDMI
> uses for the single ended signal return?
>
> On a related note, will the schematics for e320 ever be released?
>
> Thanks.
>
> cheers,
> Aaron
> ___
> 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 install from source with Pybombs failed

[Robin Coxe via USRP-users]

It looks like UHD didn't build because it's missing the Python library
numpy.   You can try "pip install numpy" and rerunning PyBombs, but to be
honest you might have better luck starting over and installing from source
by following these instructions--
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux

On Fri, Jul 26, 2019 at 12:28 PM Saeid Hashemi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Attempting to install boost libraries shows that they are already the
> latest version:
>
> libboost-dev is already the newest version.
> libboost-all-dev is already the newest version.
>
> On Fri, Jul 26, 2019 at 3:26 PM Saeid Hashemi  wrote:
>
>> Hello everyone,
>>
>> I've attempted to install UHD using Pybombs, following up on a previous
>> issue I had due to my first binary install, but this is failing.
>>
>> $ pybombs prefix init -a default prefix/default/ -R gnuradio-default
>>
>> Results in:
>>
>> -- Configuring incomplete, errors occurred!
>> See also
>> "/home/saeid/prefix/default/src/uhd/host/build/CMakeFiles/CMakeOutput.log".
>> See also
>> "/home/saeid/prefix/default/src/uhd/host/build/CMakeFiles/CMakeError.log".
>> PyBOMBS.Packager.source - ERROR - Configuration failed after running at
>> least twice.
>> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
>> uhd:
>> Configuration failed
>> PyBOMBS.install_manager - ERROR - Error installing package uhd. Aborting.
>>
>> I have attached the full results, and it seems that it's not finding the
>> boost library, however I'm not entirely sure.
>>
>> ___
> 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: Ettus X300 -- NO TX/RX, RX2 Avaliability

[Robin Coxe via USRP-users]

Sorry, I misunderstood your question-- did you set up the mode in UHD
correctly?
http://files.ettus.com/manual/page_dboards.html

Also, you might want to double-check the SMA connections just in case.
Not sure if the subdev spec has changed in the last year.  Someone who
knows the UHD codebase better than I do would have to answer that question.



On Thu, Jul 18, 2019 at 3:26 PM Taylor Eisman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Robin,
>
> We've set it up so that the RX Daughterboard connects to RX2 and the TX
> Daughterboard connects to TX/RX. Previously, we've been able to use these
> ports, but now it no longer identifies that we even have these ports. I
> don't think the issue is the Daughterboard as this worked less than a year
> ago.
>
> Thanks,
>
> Taylor
>
> ___
> 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] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

[Robin Coxe via USRP-users]

The RF capabilities of USRPs are determined by the daughterboards that are
installed in the X300.  From your uhd_usrp_probe output, you have a BasicTX
and BasicRX installed in your device, which only support 1 bare bones
transmit channel and one receive channel.

Check out the daughtercard section of ettus.com and
https://kb.ettus.com/Selecting_a_RF_Daughterboard or contact Ettus Sales (
sa...@ettus.com) for more info.
The UBX-160 is the most popular daughtercard for the X300/X310 these days.

-Robin



On Thu, Jul 18, 2019 at 2:51 PM Taylor Eisman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey guys,
>
> I've been trying to resolve this issue with our X300 USRPs. Apparently,
> they do not have an RX2 or TX/RX port. I've downloaded the latest version
> of UHD-host and the latest X300 fpga=HG images. This is the error I'm
> getting...
>
>
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3700, in set_antenna
> return _uhd_swig.usrp_source_sptr_set_antenna(self, ant, chan)
> RuntimeError: LookupError: KeyError: key "TX/RX" not found in
> dict(NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE,
> NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE)
>
> This is the result of the UHD_USRP_PROBE:
>
>
>   _
>  /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X300
> |   |   revision: 11
> |   |   revision_compat: 7
> |   |   product: 30817
> |   |   mac-addr0: 00:80:2f:16:ea:d1
> |   |   mac-addr1: 00:80:2f:16:ea:d2
> |   |   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: 3116DC5
> |   |   FW Version: 6.0
> |   |   FPGA Version: 35.1
> |   |   FPGA git hash: e39334f
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: Basic RX (0x0001)
> |   |   |   Serial: 310CF7E
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: AB
> |   |   |   |   Name: BasicRX (AB)
> |   |   |   |   Antennas: AB, BA, A, B
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: -250.000 to 250.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 5.0 to 5.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: BA
> |   |   |   |   Name: BasicRX (BA)
> |   |   |   |   Antennas: AB, BA, A, B
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: -250.000 to 250.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 5.0 to 5.0 step 0.0 Hz
> |   |   |   |   Connection Type: QI
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: BasicRX (A)
> |   |   |   |   Antennas: AB, BA, A, B
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: -250.000 to 250.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 25000.0 to 25000.0 step 0.0 Hz
> |   |   |   |   Connection Type: I
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: B
> |   |   |   |   Name: BasicRX (B)
> |   |   |   |   Antennas: AB, BA, A, B
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: -250.000 to 250.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 25000.0 to 25000.0 step 0.0 Hz
> |   |   |   |   Connection Type: Q
> |   |   |   |   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: Basic RX (0x0001)
> |   |   |   Serial: 310CF94
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: AB
> |   |   |   |   Name: BasicRX (AB)
> |   |   |   |   Antennas: AB, BA, A, B
> |   |   |   |   Sensors:
> |   |   |   |   Freq range: -250.000 to 250.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 

Re: [USRP-users] USRP E313

[Robin Coxe via USRP-users]

The USRP E313 is an E310 in a weatherproof enclosure with PoE capability.
 As Marcus points out, the network interface to the PC (over 1gigE RJ-45)
has far less bandwidth than an Ettus-branded USRP X310 or NI USRP 294x or
295x using a PCIe or 2x10 gigE link to a host PC.



On Mon, Jul 15, 2019 at 7:44 AM Marcus D Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Not really possible except for a test mode called network mode that offers
> very low bandwidth
>
> Sent from my iPhone
>
> On Jul 15, 2019, at 4:27 AM, Koyel Das (Vehere) via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi,
>
>
> The following USRP
>
>
> https://www.ettus.com/all-products/usrp-e313/
> 
> USRP E313 | Ettus Research, a National Instruments Brand | The leader in
> Software Defined Radio (SDR)
> 
> www.ettus.com
> The USRP E313 is a rugged and weatherproof SDR designed for outdoor
> deployment. Containing an embedded USRP E310 inside an IP67-rated
> enclosure, the USRP E313 provides ingress protection against dust and water
> with extensive testing to ensure operation under demanding environmental
> conditions.
>
> has embedded processor I think. So is it possible that we don't use the
> embedded processor and use it like USRP 2955 that is capture data using
> gnuradio API and process it in our computer as we are doing with 2955?
>
>
>
> Regards,
>
> Koyel Das
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W:
> www.vehere.com
>
>
>
> *[image: unnamed]
>  [image: unnamed
> (1)]  [image: unnamed (2)]
>    Vehere is the proud recipient of
> the Fastest Growing Technology Company Awards in India & Asia since 2012!*
>
> The content of this e-mail is confidential and intended solely for the use
> of the addressee. The text of this email (including any attachments) may
> contain information, which is proprietary and/or confidential or privileged
> in nature belonging to Vehere Interactive Pvt Ltd and/or its associates/
> group companies/ subsidiaries. If you are not the addressee, or the person
> responsible for delivering it to the addressee, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it
> is prohibited and may be unlawful. If you have received this e-mail in
> error, please notify the sender and remove this communication entirely from
> your system. The recipient acknowledges that no guarantee or any warranty
> is given as to completeness and accuracy of the content of the email. The
> recipient further acknowledges that the views contained in the email
> message are those of the sender and may not necessarily reflect those of
> Vehere Interactive Pvt Ltd. Before opening and accessing the attachment
> please check and scan for virus. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
>
> ___
> 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] rx error code: 1

[Robin Coxe via USRP-users]

Hi Mike.

Did you try putting the original (not the cloned) SD card in the 2nd unit?
Do you still observe the same error?  Doing so would eliminate an issue
with a corrupted SD card during duplication.

-Robin


On Thu, Jul 11, 2019 at 1:35 PM Michael Don via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have 2 E312 units.  On one I have a gnuradio script that works fine.
> I cloned the sd card from the first E312, and put it on the second
> E12, and am getting the following error:
>
> WARN: USRP Source Block caught rx error code: 1
>
> Is this some sort of hardware problem, since the 2 systems have
> identical software?  Anyone know what rx error code: 1 means?  Any
> suggestions on how to fix this?
>
> Also, while playing around to try to fix this I'm pretty sure I set
> the rx gain to 50 on one of the units, and got the "rx error code: 1"
> error, and reduced the gain, and the error went away.  On the unit
> that is currently failing, I set the gain to 0 and still get the
> error.  The unit that's working has the gain set to 25.  I thought the
> max gain of the E312 was 76, not sure what's going on here.
>
> -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] Discrepancy between N310 MB Schematic and PS Pinout and other questions

[Robin Coxe via USRP-users]

See interleaved responses below.

On Wed, Jul 10, 2019 at 6:42 AM Samuel Berhanu via USRP-users <
usrp-users@lists.ettus.com> wrote:

> The N310 design (i have tried both the HG and XG ) specify the following:
> UART0 on MIO pin 14:15,
> PJTAG on pin 10:13
> UART1 on MIO pin 8:9
> I2C0 on MIO pin 50:51
>
> there is also GPIO pins on 46:49.
>
> All the above pins when looking at the MB schematic have different
> assignments.
> Namely,
> MIO 14:15 -> PS-I2C0-SCL, PS-I2C0-SDA
> MIO 10:13 -> PS-UART0-RX, PS-UART0-TX,SYS-PS-I2C-SCL, ...SDA
> et.al
>
> 1) In short, which one is correct? Datasheet or NI design? and whichever
> is corect, does that hold true for all the other connections also?
>

The pinouts in the Vivado TCL file are the correct ones--
https://github.com/EttusResearch/fpga/blob/UHD-3.14/usrp3/top/n3xx/ip/n310_ps_bd/n310_ps_bd.tcl


> 2) I only see one of the two I2C controllers enabled in the PS. Where is
> SYS-PS-I2C-SCL coming from the schematic?
>
> It's connected to the STM32 microcontroller (U55).


> 3) Where is the microcontroller code for the STM32F072RBT6 code located? I
> tried looking under ./firmware but I dont see it?
>
> The ChromeOS source code for the STM32 MCU is in the usrp-firmware repo in
the EttusResearch github.  More specifically:
https://github.com/EttusResearch/usrp-firmware/tree/sulfur/board/sulfur


> 4) Am i correct in assuming for all FPGA images except White Rabbit, the
> phase dac that is used for controlling VCXO is set at just about mid-range
> and does not get adjusted? In general, a clearer picture of what the values
> are being programmed in the LMK and their sequence or an overview of the
> clock output values generated would be appreciated.
>
> I'm not sure-- maybe someone still employed by NI could answer this
question.   More details on the LMK settings are in the DB FPGA folder:
https://github.com/EttusResearch/fpga/blob/UHD-3.14/usrp3/top/n3xx/dboards/mg/db_timing.xdc



> Thank you,
>
> Samuel Berhanu
>
> ___
> 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 Version

[Robin Coxe via USRP-users]

After cloning the gnuradio repo, you can edit this file:
https://github.com/gnuradio/gr-recipes/blob/master/uhd.lwr

On Fri, Jun 28, 2019 at 3:39 PM Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> When installing rfnoc using pybombs is it possible to specify the version
> of UHD that you want to install? If so, how?
>
> Thanks,
>
> Andy
>
>
> ___
> 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 v3.15.0.0 pre-release

[Robin Coxe via USRP-users]

Maybe the contents of this file will point you in the right direction?
https://github.com/EttusResearch/meta-ettus/blob/master/meta-e31x/recipes-support/uhd/uhd-fpga-images_git.bbappend

On Fri, Jun 28, 2019 at 1:19 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 06/28/2019 04:06 PM, d.des via USRP-users wrote:
> > Marcus Leach wrote:
> >> See this thread here:
> >
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/046784.html
> >
> >
> > I understand how it's supposed to work, and it's always worked that way
> > before including in the outdated
> > http://files.ettus.com/e3xx_images/e3xx-release-4/ setup. With this new
> > image and toolchain (from
> >
> http://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0-e310_prerelease/
> > ), though, I can't seen to find out where uhd is getting the image it's
> > loading let alone change it. No matter what files are in standard
> > images path or $UHD_IMAGES_DIR or what I tell args="fpga="...
> > uhd_usrp_probe gives the exact same output that indicates 1 DDC and one
> > DUC.
> >
> > logging doesn't seem to be working (maybe related to the first error)
> > so I've been attempting to use print statements (see "ddd" comments) to
> > trace the long and winding path that "args" takes as it makes its way
> > to MPM and eventually the function loads the fpga. I haven't found it
> > yet. I've gone so far as to delete all the existing fpga images I can
> > find but still uhd finds this one. That's what made me think that it
> > had been somehow baked into the uhd executable.
> What happens if you specify an fpga image that doesn't actually exist?
> Does it error out?
>
>
> >
> > Here are a few outputs, first for uhd_usrp_probe and then for
> > uhd_config_info:
> >
> > root@ni-e31x-***:~/newinstall# uhd_usrp_probe
> > Error opening log file: basic_ios::clear: iostream error
> > [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
> > UHD_3.15.0.HEAD-0-g6563c537
> > ddd in rpc.hpp mb_args=
> > [ERROR] [UHD] Device discovery error: AssertionError:
> > libusb_init(&_context) == 0
> >in libusb_session_impl::libusb_session_impl()
> >at /home/mal/315/src/uhd/host/lib/transport/libusb1_base.cpp:36
> >
> > [ERROR] [UHD] Device discovery error: AssertionError:
> > libusb_init(&_context) == 0
> >in libusb_session_impl::libusb_session_impl()
> >at /home/mal/315/src/uhd/host/lib/transport/libusb1_base.cpp:36
> >
> > [ERROR] [UHD] Device discovery error: AssertionError:
> > libusb_init(&_context) == 0
> >in libusb_session_impl::libusb_session_impl()
> >at /home/mal/315/src/uhd/host/lib/transport/libusb1_base.cpp:36
> >
> > [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> > mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,claimed=F
> > alse
> >
> > [ddd
> > mb_args=mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,c
> > laimed=False
> > INFO] [MPMD dd in mpmd_mboard_impl.cpp mb_args=49601  size=4
> > ] ddd in rpc.hpp mb_args=
> > MPMD Claiming mboard 0
> > [INFO] [MPMD ddd] Device args:
> > `mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg1,serial=309C7C2,claimed=
> > False'. RPC address: 127.0.0.1
> > ddd in mpmd_mboard_impl.cpp mb_args=49601  size=4
> > ddd in rpc.hpp mb_args=
> > [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> > [INFO] [MPMD ddd] just called setup_mb
> >
> > [INFO] [MPMD ddd] just called init_property_tree
> >
> > [INFO] [MPMD] Mboard 0 reports 1 crossbar(s).
> >
> >
> > [INFO] [MPMD ddd] Enumerating RFNoC blocks for xbar 0. Total blocks: 3
> > Base port: 1 Local address: 2
> > [INFO] [0/Radio_0] Initializing block control (NOC ID:
> > 0x12AD10003310)
> > [INFO] [MPM.PeriphManager] init() called with device args
> > `mgmt_addr=127.0.0.1,product=e310_sg1'.
> > [INFO] [0/DDC_0] Initializing block control (NOC ID:
> > 0xDDC0)
> > [INFO] [0/DUC_0] Initializing block control (NOC ID:
> > 0xD0C2)
> > [INFO] [MPMD ddd] just called setup_rfnoc_blocks
> >
> > [INFO] [0/Radio_0] RX freq = 2.4e+09
> > [INFO] [0/Radio_0] RX band = 6
> > [INFO] [0/Radio_0] RX SW1 = 5
> > [INFO] [0/Radio_0] RX SWC = 0
> > [INFO] [0/Radio_0] RX SWB = 1
> > [INFO] [0/Radio_0] RX VCRX_SW = 1
> > [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> > [INFO] [0/Radio_0] RX freq = 2.4e+09
> > [INFO] [0/Radio_0] RX band = 6
> > [INFO] [0/Radio_0] RX SW1 = 5
> > [INFO] [0/Radio_0] RX SWC = 0
> > [INFO] [0/Radio_0] RX SWB = 1
> > [INFO] [0/Radio_0] RX VCRX_SW = 1
> > [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> > [INFO] [0/Radio_0] RX freq = 2.4e+09
> > [INFO] [0/Radio_0] RX band = 6
> > [INFO] [0/Radio_0] RX SW1 = 5
> > [INFO] [0/Radio_0] RX SWC = 0
> > [INFO] [0/Radio_0] RX SWB = 1
> > [INFO] [0/Radio_0] RX VCRX_SW = 1
> > [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> > [INFO] [0/Radio_0] RX freq = 2.4e+09
> > [INFO] [0/Radio_0] RX band = 6
> > [INFO] [0/Radio_0] RX SW1 = 5
> > [INFO] [0/Radio_0] RX SWC = 0
> > [INFO] [0/Radio_0] RX SWB = 1
> > [INFO] [0/Radio_0] RX 

Re: [USRP-users] X310 with CBX 120 daughter board looses uplink RF Connection

[Robin Coxe via USRP-users]

One debugging technique you could try would be to connect Tx to Rx directly
via an SMA cable with ~30dB of inline attenuation to eliminate any RF
propagation effects.


On Thu, Jun 27, 2019 at 10:58 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 06/27/2019 12:22 PM, Jaya Thota via USRP-users wrote:
>
>
>
> Hi all,
>
>
>
> I have a two X310 with CBX-120 daughter board running on UHD version
> 3.13.0 on Ubuntu 16.04.
>
> I am using it to tx/rx LTE 5MHz BW and 10 MHz BW signals at 2.85MHz using
> directional LP0965 antennas.
>
> However after few minutes the USRP looses uplink RF connection.
>
>
>
> Do I need to calibrate them?
>
> I did send the following commands without any RF connectors to calibrate.
> But I have the same issue.
>
> The master clock rate for LTE is 184.32e6 Hz. Do I need to send this as
> well.
>
> Any suggestions will be helpful.
>
> 1. sudo uhd_cal_rx_iq_balance --verbose --args="addr=192.168.40.2"
> --freq_start 2.4e9 --freq_stop 2.9e9 --freq_step 1e6
>
> 2. sudo uhd_cal_tx_iq_balance --verbose --args="addr=192.168.40.2"
> --freq_start 2.4e9 --freq_stop 2.9e9 --freq_step 1e6
>
> 3. sudo uhd_cal_tx_dc_offset --verbose --args="addr=192.168.40.2"
> --freq_start 2.4e9 --freq_stop 2.9e9 --freq_step 1e6
>
>
>
> Regards
>
> Jaya
>
> There are a LOT of reasons for a complex system like LTE to lose its RF
> link.  Does the underlying LTE application provide any hints?
>   Perhaps a debugging mode?
>
> This likely IS NOT related to underlying UHD or hardware, per se, but
> probably some environmental issue, and the app should be able to help
>   you debug it.
>
>
>
> --
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> --
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> --
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] Running E310 in Network Mode

[Robin Coxe via USRP-users]

If you need higher BW streaming to a host PC in network mode with a similar 
front end to the E310, take a look at the USRP E320 if you need a 10gigE link 
or the B210 if USB 3.0 data rates are sufficient.

The E310 was designed to be a standalone embedded SDR, not a networked device 
with full BW streaming capabilities.

-Robin



From: USRP-users  on behalf of Ramazan 
Çetin via USRP-users 
Sent: Wednesday, May 8, 2019 11:21 PM
To: Jason Matusiak; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Running E310 in Network Mode


Hello Jason,

Thank you for your answer. Actually, i have investigated this link. But, i 
would like to remove limitations on network mode and use USRP E310 line USRP 
N210. Passing samples directly from FPGA to network. Is it possible?


Regards.

On 8.05.2019 17:14, Jason Matusiak wrote:
See here: https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode



From: USRP-users 
 
on behalf of Ramazan Çetin via USRP-users 

Sent: Wednesday, May 8, 2019 8:02 AM
To: Ettus Research Support; 
usrp-users@lists.ettus.com
Subject: [USRP-users] Running E310 in Network Mode

Hello,

We want to run USRP E310 in network mode. I think the samples coming
from FPGA passing through CPU before sending to network. This decreases
bandwidth because of CPU limitations.


So, is there any ettus image or suggestions that we can run E310
directly from FPGA to network without speed limitations? (like N210 or B210)

Best regards.

Ramazan


___
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] Bringing an elderly N210 to life by loading current firmware/fpga images

[Robin Coxe via USRP-users]

You could try using the .deb or .rpm pre-built binaries if you're running
on Linux.  See, for instance:
http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/

On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
> complains that it is expecting compatibility number 11 but is receiving 6.
> So I think that means I need an earlier version of UHD than 3.9.0.
>
> I will dig into the earliest version in the git tag -l, namely
> 003_007_002_rc1, that would not build without errors and try to work out
> the compiler errors then.  Unless someone has a better idea to try.
> Thanks!
>
> Regards,
>
> Joe
>
> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Okay, thanks, that’s what I thought but that isn’t useful for me until I
> find a UHD version that can communicate with it.  I’ve been trying to build
> older UHD versions from 003_007_002_rc1 forward but all so far fail to
> build due to compiler errors.  Am up to 003_008_005_rc1 now, moving forward
> until I can successfully build one to try.  Are there any old pre-built
> versions I could simply try without having to build each one myself?
>
> Joe
>
> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
>
> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
> way to figure out what image is loaded other than asking UHD to query it
> for FPGA compat number.
>
> On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:
>
>> I guess the proper way to ask is “Is there a way to determine what fpga
>> .bin file is in the N210?”, since the .bit file that I loaded into the fpga
>> is volatile code that disappears upon power cycling to be reloaded from an
>> EEPROM or something, yes?
>>
>> Joe
>>
>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hi Nick,
>>
>> Thanks for the comments.  Is there a way to determine what bit file is
>> currently in the N210?  If so, how please?
>>
>> Joe
>>
>> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>>
>> I see you got there already! If you're still having trouble, I'll see
>> what I can dig up over here.
>>
>> On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
>>
>>> You might be best off reverting to a UHD old enough to support the
>>> bitfile currently loaded on your N210. You could then bootstrap your N210
>>> by using the old UHD to load a newer FPGA image.
>>>
>>> Otherwise, it's fairly simple to convert the binfiles (which still exist
>>> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
>>> usrp_n210_r3_fpga.bit and just stick it onto the front of
>>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
>>> header is everything up until FF FF FF FF AA 99 55 66.
>>>
>>> Lastly, the source is all there, so building using ISE should still be
>>> possible.
>>>
>>> Nick
>>>
>>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
 Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
 email adr can be of use.

 Joe

 On May 8, 2019, at 10:44 AM, Jason Matusiak <
 ja...@gardettoengineering.com> wrote:

 Joe, I think you might be SOL.  If you take a look at this thread from
 me last year, I had no luck:
 http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html


 Also, when I pinged Ettus directly, here is some info I got back from
 them (from two different emails in the thread):
 "we've been having some trouble tracking down Rev2 bitfiles, because no
 one here was around when that was built. If you're trying to unbrick
 them, Rev3 bitfiles might be OK, but I'm not completely sure.

 supp...@ettus.com might know more by know.
 really sorry, but those Rev2s are just so old. And all the people from
 that era seem to be gone. Sorry, can't help you with those Rev2s."

 --
 *From:* USRP-users  on behalf of
 Joe Martin via USRP-users 
 *Sent:* Wednesday, May 8, 2019 11:55 AM
 *To:* Joe Martin via USRP-users
 *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
 current firmware/fpga images

 I am trying to bring an elderly N210 r2.0 with unknown history to life
 by loading current UHD firmware and fpga images from a 1Gigabit ethernet
 connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
 UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.

 Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
 and N2x0 Series”:

 My initial action was to load the “usrp_n210_r4_fpga.bit" file into the

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Robin Coxe via USRP-users]

You might want to try this:
https://forums.xilinx.com/t5/Configuration/Is-it-possible-to-convert-bin-file-to-bit-file-or-mcs-file/td-p/870351
 but YMMV.

-Robin


On Wed, May 8, 2019 at 11:04 AM Joe Martin  wrote:

> Very good, Marcus.  I would greatly appreciate it.
>
> If we can get our hands on the “usrp_n210_r2_fpga.bit” from anywhere we
> could load it and install an ancient UHD version that has the associated
> .bin files for rev2 and run with that setup to have at least a minimal
> amount of utility from the N210, albeit not all the niceties and
> functionality of a modern UHD version.
>
> Thanks Jason, Marcus, and Robin for the information.  Much appreciated.
> At least we know now what we need for this N210 and what to expect from it
> in terms of performance if we ever find the .bit file too.
>
> Best regards to all,
>
> Joe
>
> On May 8, 2019, at 11:30 AM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> On 05/08/2019 01:24 PM, Robin Coxe wrote:
>
> Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered that
> the N210 was first released by Ettus Research in November 2010, which was
> about 6 months after we were acquired by National Instruments.
> It is a true statement that v2 of the hardware is quite geriatric and no
> longer supported in modern versions of UHD.   However, all hope is not lost.
>
> There *is* support for N200/N210 in the oldest version of UHD that is
> still downloadable on files.ettus.com, UHD v.3.8.0.0.   The FPGA images
> are in this zip file:
>
> http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip
>
> We unfortunately don't have a v2 in the office to confirm that it still
> works, but you might want to take a look.
>
> -Robin
>
> I'm going to go through some old disk drives on mine from "back in the
> day", and see if I have the r2 .bit files.
>
> That can't happen until the weekend, however...
>
>
>
>
>
> On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
>>
>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
>> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
>> adr can be of use.
>>
>> Joe
>>
>> There was a hardware change, as I recall, between Rev2 and Rev3 involving
>> the inputs to the ADCs.
>>
>>
>> On May 8, 2019, at 10:44 AM, Jason Matusiak <
>> ja...@gardettoengineering.com> wrote:
>>
>> Joe, I think you might be SOL.  If you take a look at this thread from me
>> last year, I had no luck:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>
>>
>> Also, when I pinged Ettus directly, here is some info I got back from
>> them (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>>
>> supp...@ettus.com might know more by know.
>> really sorry, but those Rev2s are just so old. And all the people from
>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>>
>> --
>> *From:* USRP-users  on behalf of Joe
>> Martin via USRP-users 
>> *Sent:* Wednesday, May 8, 2019 11:55 AM
>> *To:* Joe Martin via USRP-users
>> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
>> current firmware/fpga images
>>
>> I am trying to bring an elderly N210 r2.0 with unknown history to life by
>> loading current UHD firmware and fpga images from a 1Gigabit ethernet
>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>>
>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
>> and N2x0 Series”:
>>
>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
>> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
>> showing activity on the connection port.
>>
>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
>> following commands result in the responses shown in the screenshot image
>> below:
>>
>> 
>>
>> My (naive!) interpretation of the above responses is that the FPGA may
>> not actually have been programmed with the *.bit code even though iMPACT
>> reported success in programming.  Can someone assist me in understanding
>> whether my interpretation is correct or not and, most importantly, suggest
>> what I might try next to bring this N210 to life?
>>
>> The “Please run:” suggestion results in the “Received invalid reply 32
>> from device” error.  It seems no matter what I try the “Received invalid
>> reply 32 from device” RuntimeError is reported back when I 

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Robin Coxe via USRP-users]

Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered that
the N210 was first released by Ettus Research in November 2010, which was
about 6 months after we were acquired by National Instruments.
It is a true statement that v2 of the hardware is quite geriatric and no
longer supported in modern versions of UHD.   However, all hope is not lost.

There *is* support for N200/N210 in the oldest version of UHD that is still
downloadable on files.ettus.com, UHD v.3.8.0.0.   The FPGA images are in
this zip file:
http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip

We unfortunately don't have a v2 in the office to confirm that it still
works, but you might want to take a look.

-Robin



On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
>
> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
> adr can be of use.
>
> Joe
>
> There was a hardware change, as I recall, between Rev2 and Rev3 involving
> the inputs to the ADCs.
>
>
> On May 8, 2019, at 10:44 AM, Jason Matusiak 
> wrote:
>
> Joe, I think you might be SOL.  If you take a look at this thread from me
> last year, I had no luck:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>
>
> Also, when I pinged Ettus directly, here is some info I got back from them
> (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>
> supp...@ettus.com might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
>
> --
> *From:* USRP-users  on behalf of Joe
> Martin via USRP-users 
> *Sent:* Wednesday, May 8, 2019 11:55 AM
> *To:* Joe Martin via USRP-users
> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
> current firmware/fpga images
>
> I am trying to bring an elderly N210 r2.0 with unknown history to life by
> loading current UHD firmware and fpga images from a 1Gigabit ethernet
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>
> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and
> N2x0 Series”:
>
> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
> showing activity on the connection port.
>
> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
> following commands result in the responses shown in the screenshot image
> below:
>
> 
>
> My (naive!) interpretation of the above responses is that the FPGA may not
> actually have been programmed with the *.bit code even though iMPACT
> reported success in programming.  Can someone assist me in understanding
> whether my interpretation is correct or not and, most importantly, suggest
> what I might try next to bring this N210 to life?
>
> The “Please run:” suggestion results in the “Received invalid reply 32
> from device” error.  It seems no matter what I try the “Received invalid
> reply 32 from device” RuntimeError is reported back when I try to load any
> new firmware/FPGA images.
>
> Thanks!
>
> Joe
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] B200 Overrun

[Robin Coxe via USRP-users]

Are you using USB 3.0?  USB 2.0 will max out at about 8 Ms/s.



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


From: USRP-users  on behalf of Rensi Mathew 
via USRP-users 
Sent: Friday, May 3, 2019 9:17 PM
To: Vsr Ravi via USRP-users
Subject: [USRP-users] B200 Overrun

Dear sir
I am using B200 SDR to run the program usrp_spectrum_sense.py with a sampling 
frequency of 16e6.
I think I am using a fairly low sampling rate.
Still I am getting some ''.

Could someone tell me the possible reasons for the same? And how I can avoid 
the same?

Thanking you
Rensi Sam

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

Re: [USRP-users] N310 Initial Connection Issues

[Robin Coxe via USRP-users]

Hi Marc.

Are you trying to connect using 1 gigE or 10gigE?
The default N310 FPGA bitstream is the HG image, which expects 10gigE on
SFP port 1 (192.168.20.2) and/or 1 gigE on SFP port 0 (192.168.10.2).

-Robin


On Tue, Mar 12, 2019 at 10:43 AM Nate Temple via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Marc,
>
> What version of UHD are you using? If you're not running with any
> 3.14.0.0-rcX release, can you please try v3.14.0.0-rc3 ?
>
> Regards,
> Nate Temple
>
> On Tue, Mar 12, 2019 at 10:37 AM Marc Lichtman via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey,
>>
>> I'm having issues connecting to a N310 with stock firmware.  Its eth0
>> port works fine; it can get an IP address and I can even SSH into it from a
>> different (host) computer, but when I set up a second ethernet port on my
>> host with a static IP of 192.168.10.1 and mask 255.255.255.0, and connect
>> it to SFP0 on the N310, pinging 192.168.10.2 fails with destination
>> unreachable.  I'm using the transceiver that came with it, and the lights
>> above the SFP0 port on the USRP are on (one is solid, one flashes on
>> occasion).  I verified my host was using 192.168.10.1 on the port connected
>> to SFP0.
>>
>> Some possible clues- When I run uhd_find_devices on the host, the N310
>> shows up, but said "Reachable: No" (which is a new field to me).  When I
>> SSH into the N310 and do ifconfig, it shows the eth0 with its assigned IP
>> address, and it shows sfp1 but with no IP address, and no sfp0/sfp2 (not
>> sure how its suppose to be labeled).  I was expected to do ifconfig and see
>> sfp0 showing 192.168.10.2 and sfp1 with 192.168.20.2 since it's static.
>>
>> Any help would be greatly appreciated!  Thanks!
>>
>> -Marc
>> ___
>> 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] Weird effects setting external clock source in a B200mini

[Robin Coxe via USRP-users]

The B200/B210 has an Analog Devices analog PLL (ADF4002) [U101].

The B200mini series are intended as small form factor, low-cost SDRs, not
high-precision devices.  The PLL is implemented as digital logic in the
FPGA to minimize both cost and PCB board space, but limits the phase and
frequency accuracy.

-Robin


On Wed, Jan 2, 2019 at 11:53 AM Martin K via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Brais,
>
> I have two USRP here in front of me: B210, B200mini
> When I run a sample program (C++) which specifies an external
> reference, the B200mini shows a variable frequency offset. It seems to
> lock (with high jitter) but then it "jumps" and I would say the offset
> changes by +-10 Hz for a few seconds, then it stabilizes (and repeats
> this behavior, forever).
>
> When I run the same exact program with my B210 the phase stays visibly
> locked and I see no problems with the frequency jumping around.
>
> Therefore (I hesitantly say) I believe there is something undesirable
> going on with the B200mini or something in UHD/firmware.
>
> My test setup is thus:
>
> 10MHz rubidium reference --> N5182B Vector Signal Generator (BPSK
> mode, 10kHz symbol rate) --> Ettus B200mini --or-- B210 (same 10 MHz
> reference attached)
>
> Sample code is C++, derived from usrp_recv_to_udp
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.1; Boost_106800;
> UHD_3.13.0.3-0-unknown
>
> External reference is specified (and an exception is raised if 10 MHz
> is not present).
> My code is filtering and downsampling to baseband. I am viewing the
> data in a constellation diagram which allows me to see the phase lock
> or baseband rotation of the BPSK points.
>
> I am happy to provide more information to solve this issue.
> --
> Martin Klingensmith
>
>
>
>
>
>
>
>
> On Wed, Jan 2, 2019 at 9:56 AM Brais Ares via USRP-users
>  wrote:
> >
> > Hello,
> >
> > We've just bought an AXIOM90 OCXO [1] (actual configuration: 5 V, ±50
> ppb, +7.7 dBm) and we are having trouble configuring it as an external
> clock reference on a B200mini.
> >
> > All we do in code is set the clock source as external:
> >
> > usrp->set_clock_source("external");
> >
> > And loop until it gets locked by checking:
> >
> > uhd::sensor_value_t ref_locked = usrp->get_mboard_sensor("ref_locked",
> 0);
> >
> > Once it's locked we capture 60 seconds of a RF sinusoid waveform
> centered at the central frequency (100 MHz) and plot its spectrum using
> Matlab. We would expect:
> >
> > Frequency drift - Internal oscillator [2] @  ±2 ppm =  ±200 Hz
> >
> > Captured tone shows a freq. offset of +126 Hz, makes sense (see image
> and image zoomed in)
> >
> > Frequency drift - External oscillator (Agilent E4438C Signal generator,
> output power: +10 dBm)
> >
> > Captured tone shows a freq. offset of -3 Hz, makes sense, but the tone
> is heavily distorted (see image and image zomeed in).
> >
> > Frequency drift - External oscillator (AXIOM90)  @  ±50 ppb (0.05 ppm)
> =  ±5.4 Hz
> >
> > Freq. offset of +127 Hz, which does not make sense, and the tone is
> heavily distorted as well (see image and image zomeed in).
> >
> > We've been fighting this for a few days. Any point of view is welcome
> here.
> >
> > Regards and happy new year :)
> > Brais.
> >
> > [1] - http://www.axtal.com/cms/docs/doc86239.pdf
> > [2] - https://www.ettus.com/content/files/USRP_B200mini_Data_Sheet.pdf
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> --
> Martin K.
>
> ___
> 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] USRP1 support: "unknown" daughterboard

[Robin Coxe via USRP-users]

You may have multiple versions of GNU Radio and/or UHD libraries still 
installed on your PC.  Try navigating to the wherever you installed them (e.g., 
/usr/local/lib) and deleting the ones you don’t want by hand.



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


From: USRP-users  on behalf of Carlos 
Alberto Ruiz Naranjo via USRP-users 
Sent: Wednesday, December 12, 2018 4:17 AM
To: patchvonbr...@gmail.com
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] USRP1 support: "unknown" daughterboard

Hi Marcus,

I have changed the version to UHD-3.9.LTS. With uhd_usrp_probe 
--args="type=usrp1" I haven't erros. But I don't know why the GNURadio version 
hasn't changed... I have, with the previous errors :

GNU C++ version 7.3.0; Boost_106501; UHD_4.0.0.rfnoc-devel-702-geec24d7b

Any idea?

Thank you.

El mar., 11 dic. 2018 a las 22:42, Marcus D. Leech via USRP-users 
(mailto:usrp-users@lists.ettus.com>>) escribió:
On 12/11/2018 04:36 PM, Carlos Alberto Ruiz Naranjo via USRP-users wrote:
> Hello,
>
> I have found a USRP1 and I am playing with it. I have this error:
>
> carlos@carlos-pc:~$ sudo uhd_usrp_probe --args="type=usrp1"
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_4.0.0.rfnoc-devel-702-geec24d7b
> [INFO] [USRP1] Opening a USRP1 device...
> [INFO] [USRP1] Using FPGA clock rate of 64.00MHz...
> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable
> error in init.
> Loading the "unknown" daughterboard implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> AssertionError: m and ref_clock/m >= 1e6 and ref_clock/m <= 2.5e6
>   in double dbsrx::set_lo_freq(double)
>   at /home/carlos/rfnoc/uhd/host/lib/usrp/dboard/db_dbsrx.cpp:305
>
> _
>  /
> |   Device: USRP1 Device
> | _
> |/
> |   |   Mboard: USRP1
> |   |   serial: 479b9db3
> |   |
> |   |   Time sources:  none
> |   |   Clock sources: internal
> |   |   Sensors:
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: DBSRX (0x0002)
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: Unknown (0x) - 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: ad9522
> |   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: Unknown (0x) - 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: ad9522
> |   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |
> |   |   |   Freq range: -44.000 to 44.000 MHz
> |   | _
> |   |/
> |   |   |   TX DSP: 1
> |   |   |
> |   |   |   Freq range: -44.000 to 44.000 MHz
> |   | _
> |   |/
> |   |   |   TX Dboard: A
> |   |   | _
> |   |   |/
> |   |   |   |   TX Frontend: 0
> |   |   |   |   Name: Unknown (0x) - 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
> |   |   | _
> |   |   |/
> |   |   |   |   TX Codec: A
> |   |   |   |   Name: ad9522
> |  

Re: [USRP-users] synchronizing multiple USRP N310

[Robin Coxe via USRP-users]

https://kb.ettus.com/N300/N310#Front_Panel

The AD9371 has a divide-by-2 PLL and the input baluns are optimized for RF 
center frequencies 300 MHz-4 GHz (external LO inputs 600 MHz-8 GHz).  Consult 
the AD9371 user guide on the Analog Devices website for more details on what 
goes on inside the RF integrated transceiver.

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


From: USRP-users  on behalf of Florian 
Kaltenberger via USRP-users 
Sent: Tuesday, December 4, 2018 7:15 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] synchronizing multiple USRP N310


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.

--
Follow us on Google+, 
LinkedIn, or 
Twitter!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] VITA time question

[Robin Coxe via USRP-users]

To clarifiy, the B200mini, B200mini-i, and B205mini-i do not have an
on-board GPSDO, but they do have 1 PPS and 10 MHz Reference Inputs.

-Robin


On Wed, Nov 14, 2018 at 12:46 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 11/14/2018 02:37 PM, Chintan Patel via USRP-users wrote:
> > Hi,
> >
> > A conceptual question: for the b205 mini, how does the FPGA get the
> > 64-bit VITA timefield? I know the PPS/10 MHz can be used to sync the
> > clocks to, but trying to understand how the timestamp is synchronized
> > to a UTC/known-good reference value. Reading the HDL, it seems that
> > the timestamp is programmed from software, but needed confirmation.
> >
> > Thanks
> > Chintan
> >
> >
> The software side of things takes care of that.  If the on-board GPSDO
> is working, it will get a GPS-based timestamp from that.
>
> Otherwise, the application can set the time to whatever it wants see API
> elements:
>
> set_time_now()
> set_time_next_pps()
> set_time_unknown_pps()
>
>
>
>
> ___
> 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] 2x N200 GPSDO PPS relative drift

[Robin Coxe via USRP-users]

Hi Stephan.  Your issue looks similar to one that has been previously
reported.   The Hardware Sustaining Engineering team is currently
investigating.

Would it be possible for you to try powering the GPSDO module from a lab
supply instead of plugging it in to the N210 motherboard and checking if
your issue still persists?
That would help us determine if you are experiencing the same problem.
Another helpful measurement would be to measure the voltage drop of the 6V
wall wart when the GPSDO IS powered by the N210 motherboard.

We will keep you and list updated on the progress of the investigation.

-Robin


On Fri, Nov 9, 2018 at 3:06 AM Stephan Esterhuizen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I have two N200 USRPs with Jackson-Labs Firefly 1A GPSDO. I'm doing a very
> basic test, where I have a common active GPS antenna split 2 ways (with DC
> block on one N200 GPS antenna port). I then watch the 1PPS from each GPSDO
> on a scope, and unfortunately see the PPS drift by as much as 14
> microseconds per second relative to each other. When this offset reaches
> about 1.5-2.0 milliseconds, I see the PPS relative offset "snap" down to a
> few micro seconds error, but then they immediately start drifting apart
> again.
>
> The N200 GPSDO reports they're locked. I wrote some quick python code to
> query sensors:
>
> --
> FIRST N200:
> --
> [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev
> 0.929
> [INFO] [USRP2] Setting references to the internal GPSDO
> GPS lock status: locked
> GPS_GPGGA:
> $GPGGA,095011.00,.x,N,.x,E,1,10,0.9,320.7,M,46.9,M,,*6C
> GPS_SERVO: 18-11-09 3888 94089 21.81 2.08E-11 13 10 6 0x0
> GPS epoch time: 1541757012 seconds
> Ref: locked
>
>
> --
> SECOND N200
> --
>
> [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev
> 0.929
> [INFO] [USRP2] Setting references to the internal GPSDO
> GPS lock status: locked
> GPS_GPGGA:
> $GPGGA,095027.00,.x,N,.,E,1,08,1.1,317.9,M,46.9,M,,*63
> GPS_SERVO: 18-11-09 2948 12 796.02 9.59E-09 13 8 2 0x326
> GPS epoch time: 1541757029 seconds
> Ref: locked
>
> 
>
> At this point, it might be a question for Jacksonlabs, since I'm not
> really using any N200 functions except for reading back the Ublox GPS NMEA
> strings.
>
> Has anyone seen this kind of behavior before?
>
> I'm suspecting the GPS_SERVO field might shed some light, but don't quite
> know how to read it.
>
> Thanks for any pointers
>
> Stephan
> ___
> 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] Cordic Algorithm quadrant selection

[Robin Coxe via USRP-users]

Hi Immi.   This paper is one of the better overviews of the CORDIC
algorithm in FPGAs:  http://www.andraka.com/files/crdcsrvy.pdf

Also, if you search the archives of this list, there are threads regarding
the specific application of the CORDIC algorithm in the USRP FPGA designs.
For example:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-April/034497.html
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-December/039692.html

-Robin

On Tue, Nov 6, 2018 at 8:58 AM imran qureshi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I want to learn the cordic implementation of the duc_chain, and want to
> understand how the quadrant selection is done in the cordic_z.v code for
> vector rotation.(fpga
> 
> /usrp3
> 
> /lib
> 
> /dsp
> 
> /cordic_z24.v)
> code snippet
>
>   case (zi[zwidth-1:zwidth-2])
> 2'b00, 2'b11 :
>   begin
> x0 <= xi_ext;
> y0 <= yi_ext;
>   end
> 2'b01, 2'b10 :
>   begin
> x0 <= -xi_ext;
> y0 <= -yi_ext;
>   end
>   endcase // case(zi[zwidth-1:zwidth-2])
> Regards,
> Immi
> ___
> 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] B210 EnvironmentError: IOError: usb rx6 transfer status: LIBUSB_TRANSFER_OVERFLOW

[Robin Coxe via USRP-users]

Hi Andrew.  It looks like your USRP B210 is connected via USB2.  Do you
still see the same error when connected to a USB3 port?

-Robin

On Wed, Oct 17, 2018 at 1:00 PM Harper, Andrew via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi, I'm having trouble receiving samples with my B210. I get the following
> error when I run either a GNU Radio Companion script or the benchmark
> utillity:
>
> EnvironmentError: IOError: usb rx6 transfer status:
> LIBUSB_TRANSFER_OVERFLOW
>
>
> Does anyone have a way to resolve this? Below is the benchmark output:
>
>
> sdrl@star00:/usr/local/lib/uhd/examples$ ./benchmark_rate --random
> --rx_rate 320
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.14.0.0-62-g3b42e6f0
> [WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> Using random number of samples in send() and recv() calls.
>
> [00:00:00.05] Creating the usrp device with: ...
> [INFO] [B200] Detected Device: B210
> [INFO] [B200] Operating over USB 2.
> [INFO] [B200] Detecting internal GPSDO
> [INFO] [GPS] Found an internal GPSDO: GPSTCXO , Firmware Rev 0.929a
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Setting master clock rate selection to 'automatic'.
> [INFO] [B200] Asking for clock rate 16.00 MHz...
> [INFO] [B200] Actually got clock rate 16.00 MHz.
> Using Device: Single USRP:
>   Device: B-Series Device
>   Mboard 0: B210
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
>   RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
>   TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> [00:00:03.369817] Setting device timestamp to 0...
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] Actually got clock rate 51.20 MHz.
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] OK
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] OK
> [INFO] [B200] Asking for clock rate 51.20 MHz...
> [INFO] [B200] OK
> [WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> [00:00:03.783883] Testing receive rate 3.20 Msps on 1 channels
> [00:00:03.785322] Caught an IO exception.
> EnvironmentError: IOError: usb rx6 transfer status:
> LIBUSB_TRANSFER_OVERFLOW
> [00:00:13.783967] Benchmark complete.
>
> Benchmark rate summary:
>   Num received samples: 0
>   Num dropped samples:  0
>   Num overruns detected:0
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
>
> 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] X310 schematic

[Robin Coxe via USRP-users]

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

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


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

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

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

Re: [USRP-users] About the PCIe connection and drivers

[Robin Coxe via USRP-users]

Minor typo in the link.  Try this one!
https://github.com/EttusResearch/uhd/blob/master/host/docs/ni_rio_kernel.dox



On Wed, Sep 5, 2018 at 12:36 PM, ALEJANDRO BLANCO PIZARRO via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I am really happy about the upgrading of the NI RIO drivers. Up to what
> Ubuntu Kernel Will be?
>
> By the way, the GitHub link in the previous email does not work.
>
> I am looking forward to new information.
>
> Best,
> Alejandro
>
>
> El mar., 4 sept. 2018 21:24, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> escribió:
>
>> On Mon, Sep 03, 2018 at 11:39:56AM +, Peng Wang via USRP-users wrote:
>> >Hi all,
>> >
>> >I have couple of USRP X310 and also the PCIe connectivity kit.
>> However, I
>> >found that the driver [1] says that it can only support up to kernel
>> >version 4.2.x. Since I am using ubuntu 18.04 with much newer kernel
>> so I
>> >cannot install the driver. My questions would be:
>> >
>> >1. What is the status of the new driver? It is going to be updated to
>> >support newer Linux kernel soon?
>> >
>> >2. Is it possible to install the 4.2.x kernel in Ubuntu 18.04? I am
>> not an
>> >expert in Linux and my test failed in waiting for "Loading initial
>> >ramdisk" after installing the kernel 4.2.8.
>>
>>
>> We very recently updated; the current public manual is still lagging
>> master branch, but you can see this page for reference:
>> https://github.com/EttusResearch/uhddev/blob/master/host/docs/ni_rio_
>> kernel.dox
>>
>> Drivers:
>> http://files.ettus.com/binaries/niusrprio/niusrprio-
>> installer-18.0.0.tar.gz
>>
>> -- M
>> ___
>> 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] running E310 on battery power

[Robin Coxe via USRP-users]

Hi Andy.  The E310 external power connector is capable of handling 5-15 VDC
@ max current of 3.5 A.  So if you use an external battery pack with the
correct mating connector instead of the wall wart, it should work without
modification, although it is not an officially supported configuration.
You should consult the schematic at
http://files.ettus.com/schematics/e310/e310.pdf to ensure that the pinout
is correct.

-Robin

On Tue, Aug 21, 2018 at 10:56 AM, andy klein via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi folks,
>
> I wondered if someone can clear up some questions I have about running
> the E310 on battery power.  I'm aware that I can purchase an E312, but
> I'd like to use my existing E310's if possible.
>
> ** BACKGROUND **
>
> I'm aware that there's a "newer" (circa 2015, so 3 years old now)
> firmware available for the E310 that apparently enables support for
> powering the device with a 3.7V battery.  However, installing the
> firmware requires opening the device, connecting a JTAG programmer to
> the ISP header, and folks in this thread here have reported trouble
> finding a compatible connector --
>   http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2015-October/016085.html
> If I can avoid opening the device, hacking a connector on there, etc,
> I'd like to.
>
> Meanwhile, some users in these forums report success by just
> connecting a 7.2V battery to the device with no mention of a firmware
> upgrade, such as this thread --
>   http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2017-May/024803.html
> Yet, Neel at Ettus claims that the E310 (presumably running the
> original firmware) needs an external DC power supply, in this thread
> here --
>   http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2015-May/014048.html
>
> ** QUESTIONS **
>
> 1. Does one really need to upgrade the E310 firmware to be able to
> power the E310 with a battery?  Or is this only necessary if one seeks
> to use a 3.7V battery?
>
> 2. Can one just connect a (for example) 7.2V battery to the device
> without bothering with the firmware upgrade?  Maybe with a voltage
> regulator if necessary and a plug that's compatible with the E310
> power jack on the end (such as the KLDX-PA-0202-A-LT that is suggested
> in yet another thread on these forums).
>
> Thanks.
> Andy
>
> --
> https://aspect.engd.wwu.edu
>
> ___
> 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 startup error: AD9371 product ID

[Robin Coxe via USRP-users]

You should be able to just recompile MPM to get yourself unstuck.

On Wed, Aug 15, 2018 at 1:08 PM, Rob Kossler  wrote:

> Oh.  Forgot to ask.  Do I need to re-flash the whole OS or can I just
> recompile MPM on the device?
> Rob
>
> On Wed, Aug 15, 2018 at 4:05 PM Rob Kossler  wrote:
>
>> Ok.  Thanks for the suggestions.  I just tried to download the latest
>> 3.13 image and got an error message.  Any idea why?
>>
>> $ uhd_images_downloader -t n3xx_common
>> [INFO] Images destination: /home/irisheyes9/uhd/3_13/share/uhd/images
>> [ERROR] Downloader raised an unhandled exception: URL does not exist:
>> http://files.ettus.com/binaries/cache//n3xx/meta-
>> ettus-v3.13.0.2/n3xx_common_mender_default-v3.13.0.2.zip
>> You can run this again with the '--verbose' flag to see more information
>> If the problem persists, please email the output to: supp...@ettus.com
>>
>>
>> On Wed, Aug 15, 2018 at 4:01 PM Robin Coxe  wrote:
>>
>>> Hi Rob.   Have you updated MPM on your N310 device?  This particular
>>> issue was an MPM bug that should have been resolved in the UHD v. 3.13.0.1
>>> filesystem, so updating the SD card should also resolve the issue.  If you
>>> just update UHD on the host PC without updating MPM on the device, it will
>>> not fix the problem.
>>>
>>> -Robin
>>>
>>>
>>> On Wed, Aug 15, 2018 at 12:13 PM, Rob Kossler via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Thanks for the suggestion, but no luck.  Just tried the latest off of
 3.13 branch.

 Given that I've been using this N310 for weeks on the original UHD
 version, I didn't expect that an update would cure it.

 It seems that maybe EEPROM has been corrupted for some reason.  I hope
 there is a reset option because my N310 is basically brick-ed now.

 Rob

 On Wed, Aug 15, 2018 at 2:55 PM Sayyed Dormiani Tabatabaei <
 sdorm...@eng.ucsd.edu> wrote:

> Well I had this problem with UHD 3.12 but 3.13 fixed it. Do not know
> why it is back.
>
> The github has 13.0.0.2 now and it seems some N310 related things are
> in that mini patch. Last commit was 20 hours ago so that may be it?
>
> ## 003.013.000.002
> * N3xx: Fix issue where changing the clock/time source could result in
> clocks becoming unlocked
> * N3xx: Improve error messages for invalid clock/time settings
> * N3xx: Add support for Rev G mboard
> * MPM: Add function parameter to support holding AD9371 in reset
> * Docs: Add section on building fs/SD images for N3xx
> * Docs: Fix Doxygen warnings
>
> On Wed, Aug 15, 2018 at 11:46 AM, Rob Kossler via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Anyone know the cause & solution to the following startup error?
>> This just started today after a cascade of problems which ultimately
>> required me to reflash the SD card.
>>
>> $ uhd_usrp_probe --args="addr=192.168.61.2"
>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_3.13.0.1-0-g5b236772
>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial=
>> 315A34B,claimed=False,addr=192.168.61.2
>> [INFO] [MPM.PeriphManager] init() called with device args
>> `mgmt_addr=192.168.61.2,product=n310'.
>> [ERROR] [RPC] RuntimeError: AD9371 product ID does not match expected
>> ID! Read: 1 Expected: 3
>> [ERROR] [MPM.RPCServer] init() failed with error: RuntimeError:
>> AD9371 product ID does not match expected ID! Read: 1 Expected: 3
>> Error: RuntimeError: Error during RPC call to `init'. Error message:
>> RuntimeError: AD9371 product ID does not match expected ID! Read: 1
>> Expected: 3
>>
>>
>> ___
>> 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] N310 startup error: AD9371 product ID

[Robin Coxe via USRP-users]

Hi Rob.   Have you updated MPM on your N310 device?  This particular issue
was an MPM bug that should have been resolved in the UHD v. 3.13.0.1
filesystem, so updating the SD card should also resolve the issue.  If you
just update UHD on the host PC without updating MPM on the device, it will
not fix the problem.

-Robin


On Wed, Aug 15, 2018 at 12:13 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks for the suggestion, but no luck.  Just tried the latest off of 3.13
> branch.
>
> Given that I've been using this N310 for weeks on the original UHD
> version, I didn't expect that an update would cure it.
>
> It seems that maybe EEPROM has been corrupted for some reason.  I hope
> there is a reset option because my N310 is basically brick-ed now.
>
> Rob
>
> On Wed, Aug 15, 2018 at 2:55 PM Sayyed Dormiani Tabatabaei <
> sdorm...@eng.ucsd.edu> wrote:
>
>> Well I had this problem with UHD 3.12 but 3.13 fixed it. Do not know why
>> it is back.
>>
>> The github has 13.0.0.2 now and it seems some N310 related things are in
>> that mini patch. Last commit was 20 hours ago so that may be it?
>>
>> ## 003.013.000.002
>> * N3xx: Fix issue where changing the clock/time source could result in
>> clocks becoming unlocked
>> * N3xx: Improve error messages for invalid clock/time settings
>> * N3xx: Add support for Rev G mboard
>> * MPM: Add function parameter to support holding AD9371 in reset
>> * Docs: Add section on building fs/SD images for N3xx
>> * Docs: Fix Doxygen warnings
>>
>> On Wed, Aug 15, 2018 at 11:46 AM, Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Anyone know the cause & solution to the following startup error?  This
>>> just started today after a cascade of problems which ultimately required me
>>> to reflash the SD card.
>>>
>>> $ uhd_usrp_probe --args="addr=192.168.61.2"
>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_3.13.0.1-0-g5b236772
>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>>> mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial=
>>> 315A34B,claimed=False,addr=192.168.61.2
>>> [INFO] [MPM.PeriphManager] init() called with device args
>>> `mgmt_addr=192.168.61.2,product=n310'.
>>> [ERROR] [RPC] RuntimeError: AD9371 product ID does not match expected
>>> ID! Read: 1 Expected: 3
>>> [ERROR] [MPM.RPCServer] init() failed with error: RuntimeError: AD9371
>>> product ID does not match expected ID! Read: 1 Expected: 3
>>> Error: RuntimeError: Error during RPC call to `init'. Error message:
>>> RuntimeError: AD9371 product ID does not match expected ID! Read: 1
>>> Expected: 3
>>>
>>>
>>> ___
>>> 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] OctoClock CDA-2990 wiki missing links

[Robin Coxe via USRP-users]

Hi Alejandra.

The Octoclock (NI CDA-2990) user manual lives on the National Instruments
website:
http://www.ni.com/pdf/manuals/375747c.pdf

Here is the product page:
http://sine.ni.com/nips/cds/view/p/lang/en/nid/213460

-Robin


On Thu, Jul 26, 2018 at 9:18 AM, Alejandra Mercado via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear USRP folks,
>
> I've just received a CDA-2990 8 Channel Clock Distribution Accessory with
> GPSDO, and I'm looking for a user's manual in
> https://kb.ettus.com/OctoClock_CDA-2990
>
> Under the Section
>
>- *Where can I find user manuals for the OctoClock and USRP*
>
> Here is helpful document. Sync. and MIMO w/ the USRP
>
> Also, here is some documentation on how to use UHD™ to interact with
> multi-USRP systems.
>
>
> ...all the links in this FAQ section are missing. Could someone please
> direct me to a manual for the Octo-Clock?
>
>
> Thanks and 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] N310 Certificate of Volatility

[Robin Coxe via USRP-users]

Hi Bob.  The USRP N310 Letter of Volatility lives on the National
Instruments website.
http://www.ni.com/pdf/manuals/377420a.pdf

-Robin


On Thu, Jul 26, 2018 at 8:34 AM, Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> I was looking on the kb, but did not see, is there a Certificate of
> Volatility for the N310 somewhere?
>
>
>
> 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] RFNoC On B210

[Robin Coxe via USRP-users]

Hi Dan.  Such a product is in the works.  It was mentioned in Manuel Uhm's
presentation at GRCon 2017-- the USRP E320.
Single board approximately the size of a B210, AD9361, RFNoC-capable with
larger Zynq FPGA than E310 (XC7Z045).

Ettus Research intends to demo the E320 at GRCon 2018, so sign up today
(early bird registration ends tomorrow)!
https://www.eventbrite.com/e/gnu-radio-conference-2018-tickets-42793672025

-Robin



On Fri, Jun 29, 2018 at 11:40 AM, Dan CaJacob via USRP-users <
usrp-users@lists.ettus.com> wrote:

> What I meant and didn't explain well enough is a potential new Ettus
> product would be a Zynq-based B2X0 clone. That would be RFNOC-capable.
>
> On Fri, Jun 29, 2018 at 2:32 PM Ian Buckley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Er no.
>>
>> B200 has approximately the same number of FPGA logic gates as E310, B210
>> twice that amount.
>> The current design is simply larger than it needs to be because it shares
>> all it’s code with X300, I could have made it much smaller had there been a
>> good reason to.
>>
>> The FPGA was simply chosen because it was the biggest and newest
>> available when that project was begun.
>> The Vivado/ISE split wasn’t customer visible at that point in time,
>> remember X300 was also ISE based at initial release.
>>
>> It remains a potent platform for capable FPGA designers to do custom
>> stuff on, just not RFNoC.
>> -Ian
>>
>>
>> > On Jun 29, 2018, at 1:35 AM, Marcus Müller 
>> wrote:
>> >
>> > To give an uplifting spin to all this:
>> >
>> > Now, also, although larger than the one on the B200, the B210's FPGA
>> > isn't really large unoccupied, so the amount of logic that you could
>> > even hypothetically put in there is limited. Why's that uplifiting?
>> >
>> > That FPGA was chosen for the board because there's usually little need
>> > to do anything but the hardware interfacing and the DDC/DUC in the
>> > FPGA. The B210 can, with good USB3 controllers, pretty much directly
>> > hand through its analog bandwidth to a computer. So, unless you have a
>> > workload that your PC including GPU and whatnot can't achieve, you
>> > don't even have to think about implementing things on the B210's FPGA –
>> > and frankly, I've got no idea what'd be easy to do on the free space of
>> > a B210 but impossible on a high-end PC. And a high-end PC is still
>> > cheaper than a ISE14 license.
>> >
>> > Only thing that comes into mind is the latency restrictions you incur
>> > with USB; that's really something that no amount of computing power on
>> > the host computer side could solve.
>> >
>> > So, maybe, if I can encourage you to discuss your specific application,
>> > we can find a sensible solution on what to put on the SDR peripheral
>> > device itself, and what to do on your PC?
>> >
>> > Best regards,
>> > Marcus
>> >
>> > On Thu, 2018-06-28 at 15:56 -0700, Peter Sanchez via USRP-users wrote:
>> >> Thank you
>> >>
>> >> On Thu, Jun 28, 2018 at 2:01 PM, Ian Buckley 
>> >> wrote:
>> >>> There is no conceptual reason why you can’t build an RFNoC design
>> >>> on B210, it uses the same USRP3 base architecture and FPGA source
>> >>> files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all
>> >>> the implementation work for RFNoC is done using Xilinx’s Vivado
>> >>> design tools which support only the newer FPGA architectures like
>> >>> Zynq (Artix) and Kintex…Spartan6 users are stuck with ISE14
>> >>> forever, so in practical terms, no, it’s not possible without you
>> >>> completely recreating all that infrastructure.
>> >>>
>> >>> -Ian
>> >>>
>>  On Jun 28, 2018, at 1:47 PM, Peter Sanchez via USRP-users > >>> s...@lists.ettus.com> wrote:
>> 
>>  Hi All,
>>  Is it possible to generate RFNoC blocks for the B210? I can't
>> >>> find a lot of information about it. Can some one show me the URL if
>> >>> there  is a website talking about it?
>> 
>>  Cheers
>>  ___
>>  USRP-users mailing list
>>  USRP-users@lists.ettus.com
>>  http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co
>> >>> m
>> >>>
>> >>
>> >> ___
>> >> 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
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
> ___
> 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 B205 mini radios

[Robin Coxe via USRP-users]

Ian is correct regarding B210 and B200mini not supporting an external LO.

It is worth noting that we do support external LO mode for the N310 (the
AD9371 has the same divide-by-2 as the AD9361) and optionally for the N230.

In any event, the ADI Engineer Zone post in my original message references
an ADI wiki page that does in fact describe AD9361 MCS:
https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms5-ebz/multi-chip-sync
.

-Robin








On Mon, Jun 25, 2018 at 9:31 PM, Ian Buckley  wrote:

> Robin,
> that ADI support thread is not applicable to B2x0, it’s for AD9361
> external LO mode which isn’t used by Ettus products.
>
> In internal LO mode there is always a phase ambiguity in the RF
> synthesizers that requires higher level S/W to calibrate and correct for.
> The baseband synthesizer can be made phase coherent between multiple
> AD936x’s if you use the MCS mechanism, however that’s not included in the
> factory FPGA image, (though I have used it in custom images) so you also
> see some phase ambiguity here too between REF locked USRP's
> -Ian
>
>
> On Jun 25, 2018, at 9:15 PM, Robin Coxe via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Marcus is correct and the schematics do in fact provide the answer.
>
> Please refer to p.1 of the B210 schematic.  It contains an ADF4002 analog
> PLL.
> The B200mini clocking circuitry is on p. 4 of the schematic.  The PLL is
> digital and implemented inside the FPGA.
>
> There is a divide-by-2 for the external LO input in the AD9361/AD9364 RFIC
> that can result in a 180 degree phase ambiguity.   More details here
> provided by my former colleague at ADI also named Robin:
> https://ez.analog.com/thread/73543?commentID=225150#comment-225150
>
>
> -Robin
>
>
> On Mon, Jun 25, 2018 at 9:07 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 06/25/2018 11:57 PM, Dan CaJacob wrote:
>>
>> Without looking at the schematic, I'd guess that the difference is in the
>> implementation of the PLLs for tracking.
>>
>> On Mon, Jun 25, 2018 at 11:21 AM Chintan Patel via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Marcus,
>>>
>>> Two follow-up questions related to B205/B210 synchronization.
>>>
>>> 1. What is the fundamental reason why B210 supports phase coherent sync
>>> across multiple devices and B205 does not. The reference manuals on the
>>> AD9364/AD9361 does not point to any clues, and neither does the schematic.
>>>
>> Because on B210, the reference PLL is a hardware, analog PLL, whereas on
>> the B205mini, it's a DPLL that simply cannot maintain low mutual
>>   phase noise because of the way the servo works.
>>
>>
>>> 2.  If we feed identical 40 MHz to multiple B205 from the reference
>>> input to the output of the DPLL (remove X1 and run a wire from R35-1 to
>>> X1-3) and identical 1PPS to a GPIO pin, is there a way to phase and
>>> frequency align the rx sample (CAT-DCLK) signals.
>>>
>> Yes, if you basically provide a shared 40MHz clock, and ignore whatever
>> the DPLL is doing, and perhaps re-jig the FPGA code to take 1PPS
>>   from a GPIO pin, this should, in theory, work.   But no guarantees.
>> Modified hardware.  Modified FPGA code.
>>
>>
>>
>>
>>> Thanks
>>>
>>> Chintan
>>>
>>> On Sat, Jun 23, 2018 at 11:26 AM, Marcus D. Leech 
>>> wrote:
>>>
>>>> On 06/23/2018 09:06 AM, Chintan Patel wrote:
>>>>
>>>> Hi Marcus,
>>>>
>>>> Thanks for the response. I came to a similar conclusion reading the
>>>> Ettus app note on MIMO synchronization.
>>>>
>>>> Do you know if the DPLL code (or any other way) can be modified to
>>>> achieve phase coherence across multiple B205 minis.
>>>>
>>>> My understanding is that it is likely a very challenging exercise with
>>>> the existing hardware, otherwise, it would already be in place.
>>>> But the code, like all the other Ettus FPGA and host-side UHD code is
>>>> freely available.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks
>>>> Chintan
>>>>
>>>> On Sat, Jun 23, 2018 at 1:07 AM, Marcus D. Leech via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> On 06/23/2018 12:25 AM, Chintan Patel via USRP-users wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>&g

Re: [USRP-users] Synchronizing multiple B205 mini radios

[Robin Coxe via USRP-users]

Marcus is correct and the schematics do in fact provide the answer.

Please refer to p.1 of the B210 schematic.  It contains an ADF4002 analog
PLL.
The B200mini clocking circuitry is on p. 4 of the schematic.  The PLL is
digital and implemented inside the FPGA.

There is a divide-by-2 for the external LO input in the AD9361/AD9364 RFIC
that can result in a 180 degree phase ambiguity.   More details here
provided by my former colleague at ADI also named Robin:
https://ez.analog.com/thread/73543?commentID=225150#comment-225150


-Robin


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

> On 06/25/2018 11:57 PM, Dan CaJacob wrote:
>
> Without looking at the schematic, I'd guess that the difference is in the
> implementation of the PLLs for tracking.
>
> On Mon, Jun 25, 2018 at 11:21 AM Chintan Patel via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Marcus,
>>
>> Two follow-up questions related to B205/B210 synchronization.
>>
>> 1. What is the fundamental reason why B210 supports phase coherent sync
>> across multiple devices and B205 does not. The reference manuals on the
>> AD9364/AD9361 does not point to any clues, and neither does the schematic.
>>
> Because on B210, the reference PLL is a hardware, analog PLL, whereas on
> the B205mini, it's a DPLL that simply cannot maintain low mutual
>   phase noise because of the way the servo works.
>
>
>> 2.  If we feed identical 40 MHz to multiple B205 from the reference
>> input to the output of the DPLL (remove X1 and run a wire from R35-1 to
>> X1-3) and identical 1PPS to a GPIO pin, is there a way to phase and
>> frequency align the rx sample (CAT-DCLK) signals.
>>
> Yes, if you basically provide a shared 40MHz clock, and ignore whatever
> the DPLL is doing, and perhaps re-jig the FPGA code to take 1PPS
>   from a GPIO pin, this should, in theory, work.   But no guarantees.
> Modified hardware.  Modified FPGA code.
>
>
>
>
>> Thanks
>>
>> Chintan
>>
>> On Sat, Jun 23, 2018 at 11:26 AM, Marcus D. Leech 
>> wrote:
>>
>>> On 06/23/2018 09:06 AM, Chintan Patel wrote:
>>>
>>> Hi Marcus,
>>>
>>> Thanks for the response. I came to a similar conclusion reading the
>>> Ettus app note on MIMO synchronization.
>>>
>>> Do you know if the DPLL code (or any other way) can be modified to
>>> achieve phase coherence across multiple B205 minis.
>>>
>>> My understanding is that it is likely a very challenging exercise with
>>> the existing hardware, otherwise, it would already be in place.
>>> But the code, like all the other Ettus FPGA and host-side UHD code is
>>> freely available.
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>> Chintan
>>>
>>> On Sat, Jun 23, 2018 at 1:07 AM, Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 06/23/2018 12:25 AM, Chintan Patel via USRP-users wrote:

> Hello,
>
> I am an Ettus newbie. We have an application that requires us to
> synchronize multiple B205 mini radios (RX side) using the PPS in signal. 
> In
> the FPGA, the pps_in is reclocked into the radio clock domain. What we
> notice is that when we monitor this PPS signal (reclocked in radio clock
> domain) from two different radios on a scope, there is a time variation
> between the alignment of these two PPS signals across different trials. In
> other words, after each reset the time skew between the two signals 
> varies.
> Since the PPS_in for both radios is the same, I think this variation 
> across
> different reboot iterations means that the radio clock is not guaranteed 
> to
> be phase aligned/locked to the PPS for the B205 radio.
>
> Curiously, when we repeat the same experiment using the B210, we do
> not see this time alignment variation across reboots. Which only makes
> sense if somehow for the B210 the radio clock is phase locked to the PPS
> in.
>
> Any thoughts from folks who might have tried similar applications
> and/or who understand the B205 mini/B210 radios.
>
> Thanks
> Chintan
>
> The 1PPS/10MHz DPLL on the B205mini series is not designed to provide
 close phase coherence across multiple devices.  It is designed to
   synchronize the clock on the board to an external reference.

 The DPLL servo code in the B205mini drives the control voltage on the
 VCTCXO that provides all clocking signals on the board.



 ___
 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
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
>
>
> ___
> USRP-users mailing list
> 

Re: [USRP-users] FPGA or Computer?

[Robin Coxe via USRP-users]

Hi Alvin.All Ettus Research USRP SDRs ship with default FPGA bitstreams
that have the same basic functionality: 1) a digital interface to the RF
front end (ADCs/DACs), 2) digital up and down converters, 3) interpolation
and decimation blocks to adjust the sample rate, and 4) digital logic for
control, system configuration, data streaming, synchronization, and
interfaces to the host PC running UHD/GNU Radio.   In the case of the B210,
the data/control interface between the USRP and the B210 is orchestrated by
a Cypress FX3 USB3 controller IC that resides on the B210.

The product datasheets available at www.ettus.com, the schematics (
https://files.ettus.com/schematics/b200/), and the Knowledge Base (
kb.ettus.com) are good references for additional details.

*It is worth emphasizing that a majority of USRP users do not need to
modify the FPGA and should not attempt to do so unless they possess
expertise in FPGA design.  *

Ettus Research does make the FPGA code for all of our products freely
available on Github, although we cannot provide support on this mailing
list for people who customize this code and encounter difficulties.

In the case of the USRP B210, with the exception of the USRP Source and
USRP Sync GNU Radio Companion blocks, which are graphical representations
of the USRP receive and transmit chains, the functionality represented by
the GNU Radio flowgraph runs primarily on the host PC.

I encourage you to work through the GNU Radio guided tutorial:
https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations
Also, it it well worth consulting some supplementary reference material to
build up general knowledge about RF and SDR:
https://wiki.gnuradio.org/index.php/SuggestedReading

-Robin


On Mon, May 21, 2018 at 8:18 PM, Yeo Jin Kuang Alvin (IA) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> Just a quick question, everything done using the UHD C++ and GNU Radio
> Companion, is it done in the FPGA or computer itself? I am using USRP B210
> and what is the FPGA used for, as I know Gnu Radio is a
> software-defined-radio framework, and all the blocks execute on the PC host.
>
>
>
> Thank you in advanced!
>
> ___
> 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] auto start for e313

[Robin Coxe via USRP-users]

Hi Jon.  First of all, you should not be using a SG1 image with the E313.
All E313s contain E310s with Speed Grade 3 FPGAs.

The behavior you describe is a result of a corrupted bit in the AVR EEPROM
firmware that results in the power on sequence requiring the power button
to be pushed.   This corruption can occur when power is abruptly removed
from the device instead of powering it down cleanly.   The most
straightforward way to resolve this issue is to RMA your E313.   The latest
revision of the E313 always powers on when power is applied and ignores the
state of the power button.

-Robin


On Sun, May 13, 2018 at 11:19 PM, liu Jong via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> We have two pieces of E313,the difference of them is one of them insert
> sg1 imges and another insert sg3 image.
> When we take DC power supply(12V) for e313,the  sg1's e313 would  auto
> start,but for the sg3's e313,we must press power button,then e313 power on.
> Is it normal?How could make auto start for sg3's e313?
>
> best regards
> Jon
>
> ___
> 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] Lightning Surge Protection for USRP N310

[Robin Coxe via USRP-users]

Hi Zhongyuan.   The USRP N310 does not have any internal lighting surge
protection.  It is intended as a benchtop SDR.   For other use cases, you
are free to customize the device as you see fit.   Marcus's suggestions are
good ones.

-Robin



On Fri, May 11, 2018 at 10:06 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/11/2018 12:57 PM, Zhongyuan Zhao via USRP-users wrote:
>
> Hi,
>
> I have an USRP N310 that will be connected to rooftop antennas. The USRP
> is located in an equipment room filled with telecom equipments on the
> rooftop of a high building. The antenna is outdoor along with many other
> cellular/microwave antennas.
>
> Does the USRP N310 has any internal lightning surge protection circuit?
> What is your recommend practice for lightning surge protection? Or do you
> have any documents for this?
> Shall I use lightning surge arrester on every antenna cable including the
> active GPS antenna?
>
> Thanks!
>
> Zhongyuan Zhao
>
> PhD Candidate,
> Department of Computer Science & Engineering,
> University of Nebraska-Lincoln
>
>
> Yes, you should probably have well-grounded lightning protection in front
> of the device.  The telecom folks probably already have an "entry bulkhead"
> where
>   all their coax comes through, with inline arrestors on every circuit.
> It would be wise to follow their practice in this regard.
>
> Here at CCERA  (http://www.ccera.ca) we use an aluminum bulkhead panel on
> the cable entrance to the lab, and that panel is directly grounded to
>   a ground rod right outside the lab window.  Each coax circuit has a
> relatively-inexpensive inline coaxial surge protector on it--designed for
> 75 ohm
>   CATV circuits.
>
> You may want to look at products by companies like Polyphaser.
>
>
>
>
> ___
> 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] How can I upgrade a standard Octoclock CDA-2990 to a Octoclock-G CDA-2990?

[Robin Coxe via USRP-users]

...and to confirm, you have the correct GPSDO module.783173-01 GPSDO
(OCXO) (LC_XO with OCXO)



On Tue, Apr 17, 2018 at 9:10 AM, Derek Kozel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Martin,
>
> Yes, you can just install the GPSDO in and have the full functionality.
> The switch is used to tell the onboard software which reference source is
> *preferred*. Switching to internal when there is no internal source will
> fail (there is active detection of the reference signal) and the octoclock
> will default back to external. Once you have a GPSDO plugged into the
> internal socket you will be able to switch to internal.
>
> Regards,
> Derek
>
> On Tue, Apr 17, 2018 at 9:39 AM, Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> How can I upgrade a standard Octoclock CDA-2990 to a Octoclock-G CDA-2990?
>> Can I just put in the GPSDO. Or do I need to do more?
>>
>> I already have a Board Mounted 783173-01 GPSDO (OCXO) (LC_XO with OCXO)
>>
>> The documentation says:
>>
>> http://files.ettus.com/manual/page_octoclock.html
>>
>>> Both OctoClock models can input a 10 MHz reference and a 1 PPS signal
>>> via the SMA connectors EXT 10 MHZ INPUT and EXT PPS INPUT, respectively,
>>> located on the front of the device. Additionally, the OctoClock-G contains
>>> an internal GPSDO which provides its own internal references to the device.
>>>
>>> There is a switch on the front panel of the device with two positions
>>> INTERNAL and EXTERNAL that specifies which reference will be used, when
>>> applicable. For the OctoClock, there is no internal timing or clocking
>>> source, so the OctoClock will always use external 10 MHz and 1 PPS sources,
>>>
>>
>> Is the switch not connected on the Octoclock?
>> Or is it a software/firmware/EEPROM setting?
>>
>>
>> Thanks in advance?
>>
>> 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
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Ettus Code (FPGA) for USRP B210

[Robin Coxe via USRP-users]

B200.v is the top level Verilog file.  If you inspect this file, you will
see that B200_core.v and B200_io.v are instantiated within it.

All of our FPGA code is freely available-- please take some time to look
through the files in the usrp3/lib directories here: https://github.com/
EttusResearch/fpga/tree/maint/usrp3/lib

-Robin




On Mon, Apr 9, 2018 at 10:59 AM, Yeo Jin Kuang Alvin (IA) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
>
>
> I want to use the ettus code for the USRP B210, however, may I know which
> is the Top file as I noticed there are 3 different ones. B200.v ,
> B200_core.v , B200_io.v. Tried to add the source file to Xilinx ISE 14.7
> but there are some files that I couldn’t find, eg. Gpif_sync, slave_fifo32,
> uart_timing_fifo etc.
>
>
>
> What are the essentials file and where do I find it?
>
>
>
> 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] examples using N310 with ext LO

[Robin Coxe via USRP-users]

Hi Rob.  You are specifying use of the RX external LO correctly via device
arguments.   Each of the daughtercards on the N310 contains a single Analog
Device AD9371 2 TX x 2 Rx RF integrated transceiver.   The two Tx channels
share an LO and the 2 Rx channels share an LO.  Consequently, the TX or RX
frequency of RF channel 0 and RF channel 1 are constrained by the RFIC to
be the same and the TX or RF frequency of RF channel 2 and RF channel 3
must be the same.   The AD9371 is capable of FDD operation, so the TX
frequency does not need to be equal to the RX frequency.

The LO tuning code for the N310 daughterboard in UHD is (not obviously)
located here and, as you correctly point out, is handled differently from
previous USRPs:
https://github.com/EttusResearch/uhd/tree/maint/host/lib/usrp/dboard/magnesium

Magnesium is the internal code Ettus Research name for the N310
daughterboard.We will make this obscure fact more obvious in the
documentation.

-Robin


On Sun, Apr 8, 2018 at 2:31 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 04/07/2018 10:39 AM, Rob Kossler wrote:
>
> Hi Marcus,
> No, I haven't fooled with LO level adjustments.  I set the LO at about 3
> dBm and did not change it.  The LO freq is indeed 2x (LO at 4884MHz with
> center freq at 2442MHz).  I suspect that my custom software, which was
> developed for first B210 and then X310 with several daughterboard variants,
> may be sending tune commands in a way that is not ideal for an external LO
> configuration.  There was a similar issue when I first started using TwinRx
> with "companion" or "external" LO and UHD would issue warnings about tuning
> one channel first and then the other when both channels had to be at the
> same freq because they shared an LO.  So, my request for examples was to
> help me see if I am issuing the tuning requests correctly for this external
> LO config.
>
> Rob
>
> Understood.
>
> Hopefully, one of the R folks will chime in here.  I don't currently
> have one in my inventory, so running a bit blind.
>
>
>
> On Fri, Apr 6, 2018 at 7:32 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 04/06/2018 05:14 PM, Rob Kossler via USRP-users wrote:
>>
>>> Hi,
>>> Are there any examples for using the N310 with external LO?  I have
>>> gotten some strange results (strange spectral mirror-ing) when using as
>>> just a 4 channel receiver.  I am using the "args" argument to set
>>> rx_lo_source, but my code is setting the individual channel frequencies as
>>> I do for other USRPs and I noticed various warnings in the terminal window
>>> for each channel that I tune.
>>>
>>> On a separate note, I get some strange results if I set the clock_source
>>> to external in the args (using with OctoClock). If I leave it internal, no
>>> problem. For now, I am leaving it internal until I can solve the problem
>>> above with LO source.
>>>
>>> Rob
>>>
>>>
>>> Rob, just shooting from the hip here, since I haven't "lived" with an
>> N310 yet...
>>
>> Have you tried adjusting the LO levels let's say 2dB in either direction
>> to see if that changes the imaging behavior?  Also, remember that the
>> external LO input
>>   on the N310 must be a 2XLO -- at twice the desired Fc, and only up to
>> 8GHz (giving a 4GHz antenna frequency).
>>
>>
>>
>>
>> ___
>> 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] N310 questions

[Robin Coxe via USRP-users]

Hi Rob.   Thank you for pointing out the issue with the USB cable and
connector.   We have discovered that the cable is out of spec. and are
investigating alternative vendors.

Also, did you try uhd_find_devices with the IP address as an argument
(i.e., uhd_find_devices --args "addr=192.168.10.2")?

-Robin



On Thu, Mar 29, 2018 at 9:56 AM, Moritz Fischer 
wrote:

> Hi Rob,
>
> On Thu, Mar 29, 2018 at 7:46 AM, Rob Kossler via USRP-users
>  wrote:
> > Thanks Robin,
> > A couple additional questions/comments:
> > 1) I used Mender to update the FS and it seemed to work so I issued the
> > commit command.  Now, I'm having trouble with "uhd_find_devices" not
> finding
> > anything and so I'm wondering how I go about swapping back to the
> previous
> > partition?
>
> A quick way would be:
>
> $ fw_setenv mender_boot_part 2 && reboot
>
> If not mender docs might have some hints on how to do this correctly ;-)
>
> Thanks,
> Moritz
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 Faceplate Screws

[Robin Coxe via USRP-users]

Hi Devin. You'll need a Torx-T8 driver.

You can buy a socket set like this one:
https://www.amazon.com/dp/B019ZSK57K/ref=sspa_dk_detail_2?pd_rd_i=B019ZSK57K_rd_wg=wZFLO_rd_r=WZRD45JZ9JXAQTKBXND9_rd_w=MuS17=1

-Robin


On Wed, Mar 21, 2018 at 11:21 AM, Devin Kelly via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Does anyone know what type of screw driver (or security key or whatever
> it's called) I have to get to remove the faceplate for the X310?
>
> Thanks,
> Devin
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 Questions

[Robin Coxe via USRP-users]

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

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

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


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

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

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


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

Re: [USRP-users] OctoClock CDA-2990 FAQ missing link

[Robin Coxe via USRP-users]

Also:
https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices
https://files.ettus.com/manual/page_sync.html

On Thu, Mar 1, 2018 at 8:45 AM, Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Professor Mercado:
>
> Our apologies, you have stumbled on a typo in our documentation on the
> Knowledge Base (KB), which I'll fix shortly. The correct link is listed
> below.
>
> http://files.ettus.com/manual/page_octoclock.html
>
> Please let me know if you have any further questions.
>
> --​Neel Pandeya
>
>
>
>
> On 1 March 2018 at 08:39, Mercado, Alejandra via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear OctoClock CDA-2990 users/support,
>>
>> Just got mine in the mail today. I'm reading https://kb.ettus.com/O
>> ctoClock_CDA-2990
>>
>> and was happy to see under the FAQ subheading:
>>
>>
>>- *Where can I find user manuals for the OctoClock and USRP*
>>
>> Here is helpful document. Sync. and MIMO w/ the USRP
>>
>> Also, here is some documentation on how to use UHD™ to interact with
>> multi-USRP systems.
>>
>>
>> However, there are no links in either of those lines.
>>
>> So, where do I find the helpful document and the documentation on how to
>> use the UHD to interact with my B210 devices?
>>
>> Regards
>>
>> ===
>> Dr. Alejandra Mercado
>> Associate Director
>> Electrical and Computer Engineering
>> Master's in Telecommunications Program
>> A.V. Williams Building
>> University of Maryland at College Park
>> College Park, MD 20742
>> ===
>>
>> ___
>> 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] help needed in setting up USRP 210

[Robin Coxe via USRP-users]

Hi Shrishail.  Did you follow the instructions in the error message?
>From the Linux command line, type: /usr/local/lib/uhd/utils/
uhd_images_downloader.py

Then try running *uhd_find_devices* again.

The FPGA bitstreams and firmware images for USRPs must be downloaded
separately.
This application note has more details on how to get started with your USRP.
https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio

-Robin

On Thu, Feb 22, 2018 at 3:17 AM, Shrishailayya M Hiremath via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear All
>
> I have installed UHD and GNU radio using procedure given in the Ettus
> webpage. https://kb.ettus.com/Building_and_Installing_the_USRP_Open-
> Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux.
>
> I could find the my USRP connected  by command lsusb
> Bus 002 Device 004: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
> Bus 002 Device 003: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard
> Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 004: ID 2500:0020
> Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> But when I run command uhd_find_devices : I get following error
> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.11.0.git-49-g7a06c6f0
> [WARNING] [B200] EnvironmentError: IOError: Could not find path for image:
> usrp_b200_fw.hex
>
> Using images directory: 
>
> Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow the
> below instructions to download the images package.
>
> Please run:
>
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
> No UHD Devices Found
>
>
> Please let me how it can be resolved.
>
> With Best Regards
> Shrishail Hiremath,
> Department of Electronics and Communication Engineering
> National Institute of Technology
> Rourkela, PIN - 769008
> ORISSA, INDIA
> hirema...@nitrkl.ac.in
> Mob:9438503621
> Office:0661-2462459
>
> ___
> 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 two USRP-B205 mini

[Robin Coxe via USRP-users]

The Analog Devices AD9361 RF integrated transceiver in the B205mini has a
divide-by-2 PLL inside when using an external reference input, so there
will always be a 180 degree phase ambiguity.

See this post from my former colleague (also named Robin) at ADI:
https://ez.analog.com/thread/73543

-Robin


>
> On Tue, Feb 20, 2018 at 8:53 AM, Francois Quitin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear all,
>>
>>
>>
>> I’m having a problem synchronizing two USRP-B205 mini.
>>
>>
>>
>> The setup is as follows: I use one USRP as a transmitter, the other as a
>> receiver, and they are connected by cable. The “ref” input of both USRPs is
>> connected to a 10MHz output (also tried with PPS output) of an Octoclock.
>> In GNURadio, the “Clock source” (“Time source” when using PPS) is set to
>> “external”.
>>
>>
>>
>> I then transmit a signal with one USRP (constant source, real sine
>> source, BPSK sequence) with one USRP and receive it with the other USRP.
>> The received signal is rotating in the IQ-plane, as if there were some LO
>> frequency offset remaining.
>>
>>
>>
>> In principle, if both USRPs are connected to the same reference, there
>> should be no frequency offset. Any ideas where this is coming from?
>>
>>
>>
>> Cheers,
>>
>> François
>>
>>
>>
>>
>>
>> ___
>> 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 Noise Figure Meter

[Robin Coxe via USRP-users]

On p.8 of B200 schematic:
T801 is Macom ETC1-1-13TR (RF2)
T800 is Minicircuits TC1-1-43A+ (RF3)
U802 is Anaren BD3150L50100AHF (RF1)

On Thu, Feb 1, 2018 at 5:45 PM, Ron Economos via USRP-users <
usrp-users@lists.ettus.com> wrote:

> There's also a balun on the AD9361 input. Unfortunately, the balun part
> number for the low frequency path is not on the schematic.
>
> Ron
> On 02/01/2018 05:39 PM, Dan CaJacob via USRP-users wrote:
>
> That's an interesting thought. The 9361 does have a pretty bad match. I'll
> try adding a 50 Ohm attenuator and see if that helps.
>
> On Thu, Feb 1, 2018 at 5:14 PM Robin Coxe  wrote:
>
>> Hi Dan.   Both the B200 and the E312 use the Analog Devices AD9361 RF
>> integrated transceiver. This chip does have an integrated LNA.   Perhaps
>> there's some sort of mismatch between your DUTs and this integrated LNA at
>> <1 GHz?
>>
>> ADI publishes the RX S-parameters:  https://ez.
>> analog.com/thread/41208#137929
>>
>> -Robin
>>
>> On Thu, Feb 1, 2018 at 7:46 AM, Dan CaJacob via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hey guys,
>>>
>>> I have put together a noise figure meter application that uses a USRP as
>>> the sensing device. It started off as a way to measure the NF of the USRP
>>> itself. I have a calibrated noise source from an HP 8970B Noise Figure
>>> Meter. To test the NF of the USRP, I connect the head to the USRP input. My
>>> GNURadio flowgraph maximizes the USRP gain and measures a moving average of
>>> the received power while I switch the noise source on and off. The
>>> difference in the received power level, in addition to the ENR table from
>>> the noise source, can then be used to calculate the NF of the USRP itself
>>> using the y-factor method.
>>>
>>> Once you have the NF for the USRP at many frequencies (I test every 50
>>> MHz from 50 MHz - 6000 MHz), you can modify the same procedure to test the
>>> NF of a Device Under Test (DUT) which is connected between the noise source
>>> and the (now calibrated) USRP. You can use the USRP cal table we generated
>>> in the previous step to derive the NF of the DUT corrected for the NF of
>>> the USRP.
>>>
>>> In short, this all works incredibly well and garners very repeatable
>>> results. One complication is that you will see wild NF at certain
>>> frequencies due to local interference like LTE and WIFI. I've also compared
>>> the results to that which the HP device measures and they're very
>>> comparable. ... Except below ~ 1GHz.
>>>
>>> And here's the issue - I am seeing higher NF for DUTs below about 1GHz
>>> and particularly worse below 500 MHz. I was hoping someone at Ettus might
>>> be able to shed some light on why this might be. Curiously, the USRPs NF
>>> doesn't seem to be too bad, just the DUT.
>>>
>>> I'll note that I am nominally using a B200 for these tests, but I also
>>> tried an E312 just in case the filter banks might help out somehow. I
>>> didn't see a difference - they both had the same problem.
>>>
>>> I have used several DUTs for this test, including LNA boards we have
>>> designed ourselves and a Mini-Circuits ZX60-P103LN+ (
>>> https://www.minicircuits.com/pdfs/ZX60-P103LN+.pdf). Both seem to
>>> exhibit higher NF when measured with a USRP below 1 GHz. When testing them
>>> on the HP NF meter, the NF is as expected all the way down to 50 MHz.
>>>
>>> I have attached the B200 cal data for your enjoyment as well as the
>>> B200-measured ZX60 NF and the HP-measured ZX60. The HP NF meter only goes
>>> up to 1600 MHz, which is why that data file stops there. I was surprised to
>>> see the B200 seemed to have a better NF than the E312, which averaged 8 dB
>>> NF, by the way.
>>> --
>>> Very Respectfully,
>>>
>>> Dan CaJacob
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>> --
> Very Respectfully,
>
> Dan CaJacob
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] B200 Noise Figure Meter

[Robin Coxe via USRP-users]

Hi Dan.   Both the B200 and the E312 use the Analog Devices AD9361 RF
integrated transceiver. This chip does have an integrated LNA.   Perhaps
there's some sort of mismatch between your DUTs and this integrated LNA at
<1 GHz?

ADI publishes the RX S-parameters:
https://ez.analog.com/thread/41208#137929

-Robin

On Thu, Feb 1, 2018 at 7:46 AM, Dan CaJacob via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey guys,
>
> I have put together a noise figure meter application that uses a USRP as
> the sensing device. It started off as a way to measure the NF of the USRP
> itself. I have a calibrated noise source from an HP 8970B Noise Figure
> Meter. To test the NF of the USRP, I connect the head to the USRP input. My
> GNURadio flowgraph maximizes the USRP gain and measures a moving average of
> the received power while I switch the noise source on and off. The
> difference in the received power level, in addition to the ENR table from
> the noise source, can then be used to calculate the NF of the USRP itself
> using the y-factor method.
>
> Once you have the NF for the USRP at many frequencies (I test every 50 MHz
> from 50 MHz - 6000 MHz), you can modify the same procedure to test the NF
> of a Device Under Test (DUT) which is connected between the noise source
> and the (now calibrated) USRP. You can use the USRP cal table we generated
> in the previous step to derive the NF of the DUT corrected for the NF of
> the USRP.
>
> In short, this all works incredibly well and garners very repeatable
> results. One complication is that you will see wild NF at certain
> frequencies due to local interference like LTE and WIFI. I've also compared
> the results to that which the HP device measures and they're very
> comparable. ... Except below ~ 1GHz.
>
> And here's the issue - I am seeing higher NF for DUTs below about 1GHz and
> particularly worse below 500 MHz. I was hoping someone at Ettus might be
> able to shed some light on why this might be. Curiously, the USRPs NF
> doesn't seem to be too bad, just the DUT.
>
> I'll note that I am nominally using a B200 for these tests, but I also
> tried an E312 just in case the filter banks might help out somehow. I
> didn't see a difference - they both had the same problem.
>
> I have used several DUTs for this test, including LNA boards we have
> designed ourselves and a Mini-Circuits ZX60-P103LN+ (
> https://www.minicircuits.com/pdfs/ZX60-P103LN+.pdf). Both seem to exhibit
> higher NF when measured with a USRP below 1 GHz. When testing them on the
> HP NF meter, the NF is as expected all the way down to 50 MHz.
>
> I have attached the B200 cal data for your enjoyment as well as the
> B200-measured ZX60 NF and the HP-measured ZX60. The HP NF meter only goes
> up to 1600 MHz, which is why that data file stops there. I was surprised to
> see the B200 seemed to have a better NF than the E312, which averaged 8 dB
> NF, by the way.
> --
> Very Respectfully,
>
> Dan CaJacob
>
> ___
> 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] All incoming messages from qq.com are now blocked

[Robin Coxe via USRP-users]

Due to the immense volumes of Chinese spam this list has been receiving
recently (hundreds of messages per hour), I have asked the cloud hosting
provider for usrp-users@lists.ettus.com to block all incoming messages from
qq.com.

If you are located in China and have a legitimate post for the usrp-users
mailing list, please send your message from a different domain.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] If I can change the DDR3L by myself

[Robin Coxe via USRP-users]

Hi Hu.  Before you start desoldering chips from the circuit board, could
you be more specific about how your E312 "didn't work"?   It may be
possible to resurrect your E312 by means of less extreme measures.

What were you trying to do with it?  Did it boot?  If not, could you
connect to the device over the UART and post the log messages from the
startup sequence?

-Robin




On Thu, Dec 28, 2017 at 3:06 AM, Hu Chaoran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> My usrp e312  didn't work and I think it was because of the chip DDR3L
> stop working. I want to replace a new one by myself. but I can only find
> DDR3 with speed of 933MHz, maybe the speed is different  with the old one.
> I don't know if it is ok to change it. and when I change it, if I need to
> change the software of the system at the same time?
>
> Thank u very much.
>
>
> Regards.
>
> -Hu.
>
> ___
> 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] Reprogramming a "Bricked" N210

[Robin Coxe via USRP-users]

Hi Mark.  Have you tried ISE on Windows machine?   The Xilinx Linux cable
drivers from that era were quite unreliable.

Alternatively, there are also some old blog posts about Linux workarounds:
http://dreamrunner.org/blog/2012/09/12/install-xilinx-ise-on-the-ubuntu/

-Robin

On Mon, Nov 13, 2017 at 10:51 AM, Marcus D. Leech  wrote:

> On 11/13/2017 08:55 AM, Mark Koenig wrote:
>
>> Just to follow up, all of the voltages on J105, J104, and J107 are
>> correct.
>>
>> Mark
>>
> I would focus on trying to get Impact working in your environment. The
> Xilinx support forums may be a more fruitful avenue for that part of the
>   problem.
>
>
>
>
>> On 11/9/17, 6:15 PM, "Mark Koenig" 
>> wrote:
>>
>>  Robin and Marcus,
>>   Thank you for the suggestions.  Marcus, I did try and follow
>> your suggestion, however, I cannot communicate with the N210 other than
>> through the Jtag port communication.
>>   Robin,  I did install the Xilinx ISE 14.7 Labtools and ran
>> Impact, however, I kept getting a windrv6 driver error.  I downloaded the
>> cable drivers, but it still won’t work.
>>   Below are some questions I found on the ETTUS website, and my
>> answers are below each question.
>>   Listed below are some specific things that you can check to
>> verify whether or not your N200/N210 hardware is working correctly. If the
>> answer to any of the questions listed below is "no", then there is probably
>> a hardware problem.
>>   I would appreciate any other suggestions.  Thank you.
>>   Does the fan spin?
>>  Yes.
>>  Do any of the LEDs on the front panel light up? Which ones? (
>> http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds)
>>  No.
>>  Are the lights on the Ethernet port flashing, when the N210 is
>> connected to the host computer? Note that the N200/N210 must be connected
>> to a 1 Gigabit Ethernet port. A 100 Mbps Ethernet port will not work.
>>  No.
>>  Check the voltages on these connectors on the motherboard: J105
>> (should be 2.5V); J104 (should be 3.3V); J107 (should be 1.2V). Do you see
>> the correct voltages on those connectors?
>>  I will acquire a DMM and measure the voltages.
>>  Does the LED at D203 on the motherboard light up? If you're holding
>> the N210 such that the front panel is facing you, then D203 is located near
>> the left connector for the daughterboard.
>>  No, another LED is lit up (D202)
>>   Message: 13
>>  Date: Tue, 31 Oct 2017 14:12:58 -0700
>>  From: Robin Coxe 
>>  To: "Marcus D. Leech" 
>>  Cc: USRP-users 
>>  Subject: Re: [USRP-users] Reprogramming a "Bricked" N210
>>  Message-ID:
>> > cxpf2unwmwwnjs8tlud...@mail.gmail.com>
>>  Content-Type: text/plain; charset="utf-8"
>>   Hi Mark.  One thought-- Vivado does not support the
>> Spartan-3A FPGA on the
>>  USRP N210.The JTAG protocol should in principal be the same,
>> but Vivado
>>  definitely does not include Xilinx device files for older FPGAs.
>>   Have you tried to resurrect the device using Xilinx ISE
>> 14.7 Labtools?
>>  https://www.xilinx.com/member/forms/download/xef.
>> html?filename=Xilinx_LabTools_14.7_1015_1.tar=1
>>   If that fails, please report back and we will try to
>> assist you further.
>>   -Robin
>>On Tue, Oct 31, 2017 at 1:46 PM, Marcus D.
>> Leech via USRP-users <
>>  usrp-users@lists.ettus.com> wrote:
>>   > On 10/31/2017 04:21 PM, Mark Koenig via USRP-users
>> wrote:
>>  >
>>  > Again,
>>  >
>>  >
>>  >
>>  > Looking to see if anyone can help on this.
>>  >
>>  >
>>  >
>>  > One more detail is that I am unable to reboot the N210 into
>> safe mode,
>>  > thus no green lights come on.
>>  >
>>  >
>>  >
>>  > Thanks
>>  >
>>  >
>>  >
>>  > Mark
>>  >
>>  > OK, so you've followed the JTAG-based procedures here
>>  >
>>  > https://kb.ettus.com/N200/N210_Device_Recovery
>>  >
>>  > ANd still cannot get it to "go" ?
>>
>>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: USRP2 schematic vs. FPGA source discrepancy

[Robin Coxe via USRP-users]

Hi Michal.   The USRP2 is a discontinued product that was introduced before
Ettus Research was integrated into the National Instruments manufacturing
infrastructure.Unfortunately, the only schematics and FPGA pin
constraints files that we have on hand are the ones that you have already
located.   All of the people who were involved in developing the USRP2 no
longer work at Ettus Research.

The Xilinx XC3S2000 FPGA used on the USRP2 is the FG456 package.   Detailed
information about the pinout can be found starting at p. 175 of the Xilinx
datasheet:
https://www.xilinx.com/support/documentation/data_sheets/ds099.pdf

You could try powering on the board and probing pin V15 with an
oscilloscope to see if you observe either a clock signal or a pulse when
you press SW1.  If I had to guess, the FPGA constraints file is most likely
more up to date than the schematic.

If you would prefer to develop on a USRP that is still a released and
actively supported, you might consider the USRP N200 or N210.

-Robin



On Sat, Nov 4, 2017 at 5:37 AM, Michał Wróbel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear usrp-users,
>
> Maybe you've got the answer to my question below.
>
> Thanks,
> Michał
>
> -- Forwarded message --
> From: Michał Wróbel 
> Date: 2017-10-28 19:32 GMT+02:00
> Subject: USRP2 schematic vs. FPGA source discrepancy
> To: supp...@ettus.com
>
>
> Dear Ettus Research support team,
>
> I am considering customizing USRP2 FPGA contents, however there seems to
> be a discrepancy between USRP2 schematics
>  and FPGA constraints
> file
> .
> On the schematics the pin V15 is connected to S1 switch, while the
> constraints file attaches this pin to PHY_CLK signal. Is it possible that
> the schematics and the constraints file are for different revisions of
> USRP2 hardware?
>
> Judging from the filename I presume the FPGA constraints file is for
> "revision 3". Which hardware revision do the schematics describe? Where can
> I find schematics and FPGA constraints file for "USRP2 Rev 4.0", which I
> own?
>
> Thank you in advance,
> Michał Wróbel
>
>
> ___
> 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] 2011 Matt's Talk Materials

[Robin Coxe via USRP-users]

Matt gave this talk again at GR Con 2015 in Boulder.  Slides here:
https://drive.google.com/file/d/0B6ccrJyAZaq3UHpEQld1YmZjbWs/view

On Mon, Oct 16, 2017 at 1:56 PM, Sumit Kumar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I was wondering if anyone has the materials for the famous talk by Matt
> Ettus in 2011 GRCon.
>
> *"Why Doesn't My Signal Look Like the Textbook?"*
>
> I remember it was hosted on Tom's webpage. The link is still there,
> however the files are missing.
>
> http://www.trondeau.com/grc2011-abstracts/
>
> Go to the schedule of 15th September 9-9:30
>
> Regards
>
> Sumit
>
> ___
> 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] B210 input power supply

[Robin Coxe via USRP-users]

Easy answer-- refer to p. 8 of the schematic.

http://files.ettus.com/schematics/b200/b210.pdf

-Robin

On Fri, Oct 13, 2017 at 4:58 AM, Jose Benito Diéguez Teixeira via
USRP-users  wrote:

> Hello,
>
> Easy question, can the B210 deal with another input voltage than 6V (as
> the power supply has)? What input voltage range can manage this device?
>
> Thanks and regards.
>
> --
>
> [image: logo_170x100px.png] 
>
>
>
> José Benito Diéguez Teixeira
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030>  Ext. 3012
> jdieg...@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] B210 operating temperature range

[Robin Coxe via USRP-users]

Hi Jose.   The temperature ranges quotes for the B200mini in the enclosure
were derived from thermal test results.   The B210 enclosure will extend
the operational temperature range, but Ettus Research has not performed
thermal testing on this configuration and we have no immediate plans to do
so.   You can perform your own thermal modeling/analysis/testing for your
particular application.

-Robin



On Mon, Oct 9, 2017 at 12:47 PM, Jose Benito Diéguez Teixeira via
USRP-users  wrote:

> Hello all,
>
> I'm intended to use the B210 platform in our application. But we have a
> temperature requirement for the complete system that we are implementing
> right now.
>
> As I see in Ettus database, the operating temperature for the B210 is
> within 0-40ºC. If we use it enclosure, may the operanting range be greater?
>
> I saw that B200mini increases the operative range from 0-40ºC to -20-60ºC.
> Is the same situation for the B210 platform?
>
> Regards.
>
> --
>
> [image: logo_170x100px.png] 
>
>
>
> José Benito Diéguez Teixeira
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030>  Ext. 3012
> jdieg...@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] C674 fail on B210 rev 4

[Robin Coxe via USRP-users]

Hi Billy.  C674 is Kemet T495C107K016ATE200
CAP,SM,100UF,16V,10%,TANTALUM,6032.

Schematics for the B210 are available here:
http://files.ettus.com/schematics/b200/b210.pdf

-Robin



On Fri, Sep 22, 2017 at 8:23 PM, Billy Jones via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have been using a B210 board for about a week now to run OpenBTS and
> OpenBTS-UMTS.  I left the board powered on in its enclosure overnight, and
> when I arrived in the morning discovered it not working, the power led
> flickering, and my computer alerting that there was a USB power surge.  I
> took the board out of its enclosure and discovered capacitor C674 had
> completely burned up.
>
> Has anyone else encountered a hardware failure as catastrophic as this
> with the power supply?
>
> Does anyone know the specs on that capacitor (capacitance, voltage rating,
> etc.) so I can possibly replace it on the board myself?
>
> I'm using Rev 4 of the B210, and I have a GPSDO-TCXO module installed.  I
> was using a 9V, 1.5A wall wart as the power supply and had the USB3 cable
> connected to my PC.
>
> Thanks,
> Billy
>
>
> ___
> 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] Sample code for twin RX

[Robin Coxe via USRP-users]

Hi Snehasish.  The NI USRP 2954R has UBX-160 daugthercards and a GPSDO
module.  The TwinRX is in the NI USRP 2945/2955 (with GPSDO)


-Robin


On Thu, Aug 10, 2017 at 7:56 AM, Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello i am using NI usrp 2954 R, which I believe is using twin rx (Please
> correct me if I am wrong). I need to tune the two daughter boards to two
> different frequencies and receive samples simultaneously. So is there any
> sample code, I can reference from?
>
>
> BR
>
> 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] support with NI USRP 2942R GPSDO

[Robin Coxe via USRP-users]

Hi Snehasish.  The NI USRP-2942R does not actually have an integrated
GPSDO, the* NI USRP-2952R* does.  That may be your problem.

-Robin

On Wed, Jul 26, 2017 at 7:43 AM, Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello
>
>
> I have procured a NI USRP 2942R, which has an inbuilt GPS clock. But
> whenever I run uhd_usrp_probe, it shows no gpsdo detected and even the
> same  in gnuradio. Also the GPS led doesnot glow, I have connected the GPS
> antenna to the GPS SMA connector port.
>
>
> Please help me with it.
>
>
> BR
> 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