[USRP-users] E313 PoE requirements

[Sebastian Bräuer via USRP-users]

Hi everyone,

just a quick questions: Which PoE standards are supported by the USRP 
E313? I have a 802.3at PoE injector (30W) but it does not seem to boot 
up (although the LED on the outside is on). Do I need more power?


Thanks in advance!

Sebastian


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

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

[Rob Kossler via USRP-users]

The issue is solved now.  At first I didn't realize that the patch was
related to the build of the DDR IP component, so when I rebuilt without
clean-ing, the DDR output files were not re-built.  I deleted the DDR IP
folder in the build-ip folder and re-ran the build and now it is past the
point where the error occurred.  Sorry for the false alarm.
Rob

On Thu, Jan 30, 2020 at 3:43 PM Rob Kossler  wrote:

> Hi Nate,
> I encountered the "Conflicting VCC voltages in bank 32" error while trying
> to build an N310 XG RFNOC image on v3.15.0.0 and noticed your user's list
> email below which indicated that Vivado 2018.3 requires patch AR71898 in
> order to overcome a bug causing this error. However, after installing the
> patch I am still getting the error.  Perhaps the patch is not installed
> correctly, but the build log file (see snippets below) seems to indicate
> that it is. The second line in the log file shows "# Vivado v2018.3_AR71898
> (64-bit)" which to me indicates that it sees the patch. However, you will
> find the build error mentioned above toward the end of the log.  Any ideas?
> Is there another way to determine if the patch is successfully installed?
>
> Rob
>
> #---
> # Vivado v2018.3_AR71898 (64-bit)
> # SW Build 2405991 on Thu Dec  6 23:36:41 MST 2018
> # IP Build 2404404 on Fri Dec  7 01:43:56 MST 2018
> # Start of session at: Thu Jan 30 11:51:43 2020
> # Process ID: 6739
> # Current directory: /afs/
> crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build-N310_RFNOC_XG
> # Command line: vivado -mode batch -source /afs/
> crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build_n3xx.tcl
> -log build.log -journal n3xx.jou
> # Log file: /afs/
> crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build-N310_RFNOC_XG/build.log
> # Journal file: /afs/
> crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build-N310_RFNOC_XG/n3xx.jou
> #---
> ...
> ...
> ...
> Attempting to get a license for feature 'Implementation' and/or device
> 'xc7z100'
> INFO: [Common 17-349] Got license for feature 'Implementation' and/or
> device 'xc7z100'
> INFO: [Common 17-1540] The version limit for your license is '2019.07' and
> has expired for new software. A version limit expiration means that,
> although you may be able to continue to use the current version of tools or
> IP with this license, you will not be eligible for any updates or new
> releases.
> INFO: [DRC 23-27] Running DRC with 8 threads
> INFO: [Vivado_Tcl 4-198] DRC finished with 0 Errors
> INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for
> more information.
> Running DRC as a precondition to command place_design
> INFO: [DRC 23-27] Running DRC with 8 threads
> ERROR: [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank
> 34. For example, the following two ports in this bank have conflicting
> VCCOs:
> ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15]
> (LVCMOS18, requiring VCCO=1.800)
> WARNING: [DRC CHECK-3] Report rule limit reached: REQP-1839 rule limit
> reached: 20 violations have been found.
> WARNING: [DRC CHECK-3] Report rule limit reached: REQP-1840 rule limit
> reached: 20 violations have been found.
> ...
> ...
> ...
> INFO: [Vivado_Tcl 4-198] DRC finished with 1 Errors, 52 Warnings
> INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for
> more information.
> ERROR: [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
> INFO: [Common 17-83] Releasing license: Implementation
> 34 Infos, 63 Warnings, 0 Critical Warnings and 2 Errors encountered.
> place_design failed
> place_design: Time (s): cpu = 00:01:07 ; elapsed = 00:00:58 . Memory (MB):
> peak = 9161.891 ; gain = 0.000 ; free physical = 43703 ; free virtual =
> 93417
> ERROR: [Common 17-39] 'place_design' failed due to earlier errors.
>
> while executing
> "place_design -directive $pla_dir"
> (procedure "vivado_strategies::implement_design" line 23)
> invoked from within
> "vivado_strategies::implement_design $n3xx_strategy"
> (file "/afs/
> crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build_n3xx.tcl"
> line 28)
> INFO: [Common 17-206] Exiting Vivado at Thu Jan 30 12:40:04 2020...
>
>
>>
>>
>> On Mon, Dec 9, 2019 at 2:43 PM Nate Temple via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Robert,
>>>
>>> So this is a bug related to Vivado, you will need to install this linked
>>> below patch and it should resolve it.
>>>
>>> https://www.xilinx.com/support/answers/71898.html
>>>
>>> Regards,
>>> Nate Temple
>>>
>>> On Mon, Dec 9, 2019 at 10:38 AM Nate Temple 
>>> wrote:
>>>
 Hi Robert,

 Thanks for the bug report.

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

[USRP-users] GNU Radio Conference 2020: Call for Participation!

[Martin Braun via USRP-users]

GRCon 2020 celebrates and showcases the substantial and remarkable progress
of GNU Radio over the past two decades. We invite developers and users from
the GNU Radio community to present your projects, presentations, papers,
posters, and problems at GNU Radio Conference 2020.

GRCon20 will be held September 14-18, 2020 in Charlotte, North Carolina,
USA. 

You may make one or more submissions under the following categories for
presentation at GRCon. In addition to submitting a presentation, you may
submit a paper to the Technical Proceedings of GRCon20. You do not need to
submit a paper to the Proceedings in order to present at GRCon.
*Talks* are 30 minutes long, including 5 minutes reserved for audience
questions. Each presentation should be a slide-deck that can be shared
publicly (PDF) after the conference. Real-world results using GNU Radio and
hardware will be favored over simulation-only work.

Talks will be recorded and published on the GNU Radio YouTube channel after
the conference.

*Papers* can be submitted with or without a talk. Authors are encouraged to
attend the conference, but it is not a requirement for paper acceptance.
Detailed real-world results using GNU Radio are encouraged.

*Workshops* are 1–4 hours long, and should have an educational or “How-To”
approach, with a large hands on portion. If slides are used, they should be
publicly shareable (PDF) after the conference.

*Lightning Talks* are very concise (4-5 minutes), talks on topics of high
interest to GNU Radio users and developers, and provide a chance for new
presenters to share their use cases, projects or demos.

*Posters* can display any type of material that you believe is interesting
to the community, and while most posters are technical, they don’t have to
be.

To submit your content for the conference, visit the submission page for
more details and instructions:
https://www.gnuradio.org/grcon/grcon20/submit/

*Dates*

Submission deadlines are split into two rounds:

First round closes *17 April 2020*. Final round closes *1 September 2020*.

All contributions submitted by 17 April 2020 will get a final decisions of
acceptance by *29 June 2020*. All contributions submitted between 17 April
and 1 September will be accepted/rejected on a rolling basis. We do not
guarantee a notification deadline for submissions after 17 April.
Submissions for presentations may close sooner than 1 September if all
available speaker slots are taken.

If you have questions or need assistance with the submission system, or
have content that doesn't quite fit and you want to talk it over, please
email us at gr...@gnuradio.org.

If your submission is accepted, you *must* register for the conference or
your talk will be dropped from the schedule. Please use the speaker
registration in this case in order to lock in the regular price.

Please note that submitting a paper to the Technical Proceedings is *not*
required to submit a Talk, Tutorial, or Poster, but is *strongly*
encouraged. You also do *not* need to attend the conference to publish in
the Technical Proceedings.


We are looking forward to your submissions!

--The GNU Radio Conference Committee
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E313 PoE requirements

[Michael Dickens via USRP-users]

Hi Sebastian - The power draw of the E313 in 2x2 MIMO is peak of about 9 W
and more typically averaging around 6 W. An injector meeting the original
PoE 802.3af standard at 12.95 W at the device should be plenty sufficient.
What PoE injector are you trying to use? Do you have any others to try out?
If PoE isn't working directly, you can always try a PoE splitter such as
the TRENDnet TPE-104GS. There are plenty of options for both injectors and
splitters. - MLD

On Fri, Jan 31, 2020 at 6:07 AM Sebastian Bräuer via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> just a quick questions: Which PoE standards are supported by the USRP
> E313? I have a 802.3at PoE injector (30W) but it does not seem to boot
> up (although the LED on the outside is on). Do I need more power?
>
> Thanks in advance!
>
> Sebastian
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://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 POE+ Adapter Suggestions

[Michael Dickens via USRP-users]

Hi Kyle - Pretty much any PoE+ splitter should do the trick so long as it
can match the E320's input voltage & power plug size. Some of the Ettus
developers have tested a few stock splitters with good success. We don't
have a specific recommended device. Cheers! - MLD

On Tue, Jan 28, 2020 at 7:13 PM Kyle A Logue via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I'm interested in using a E320 via POE+ to deliver 12v power. Does anyone
> have suggestions for injectors/adapters to use in combination with the
> E320? POE+ is supposed to be able to deliver up to 30W, which is
> conveniently how the E320 is 12V rated. I found one an Amazon that will do
> 24W (SMAKN® Active Gigabit PoE Splitter Adapter, IEEE 802.3at compliant, Up
> To 100 meters, 5V / 12V /18v Output), is there a better alternative?
>
> I know I will have to make a cable. Thanks.
>
> *Kyle Logue*
>
> *Engineering Manager ⚝ Comm Software Implementation Dept *
> *The Aerospace Corporation*
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://ettus.com/
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Error "clock synchronizer offset" loading N310 rfnoc image

[Rob Kossler via USRP-users]

Hi,
I just successfully built an N310 rfnoc XG image (build rpt attached) with
some custom blocks using fpga-src version v3.15.0.0, but I can't load the
image successfully on the device.  Below you will find four consecutive
commands (highlighted in yellow) where I do the following:

   1. uhd_image_loader to load my custom image (results show "clock
   synchronizer offset" error)
   2. uhd_usrp_probe (results show "'NoneType' object has no attribute
   'get'" error)
   3. uhd_image_loader to load default XG image (no errors)
   4. uhd_usrp_probe (no errors)

I have tried multiple times but I am getting the same results each time. I
have tried rebooting the N310, but still the same results.  Any suggestions?
Rob


$ uhd_image_loader --args="type=n3xx,addr=192.168.64.2"
--fpga-path=usrp_n310_fpga_RFNOC_XG.bit
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.64.2,type=n3xx,product=n310,serial=318F043,claimed=False,skip_init=1
[INFO] [MPMD] Claimed device without full initialization.
[WARNING] [MPMD IMAGE LOADER] RuntimeError: Component file does not exist:
/home/irisheyes1/uhd_nd/fpga_images/n310/v3.15.0.0/20200131_ddc-duc-txarb-radarfilter3-fifo/build/usrp_n310_fpga_RFNOC_XG.dts
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 318F043
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args
`time_source=internal,clock_source=internal'.
[ERROR] [MPM.Magnesium-0.init] Clock synchronizer measured an offset of
132.5 ps!
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
[WARNING] [MPM.PeriphManager] Failed to initialize device on boot: Clock
synchronizer measured an offset of 132.5 ps!

$ uhd_usrp_probe --args="addr=192.168.64.2"
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.64.2,type=n3xx,product=n310,serial=318F043,claimed=False,addr=192.168.64.2
[ERROR] [RPC] 'NoneType' object has no attribute 'get'
[INFO] [MPM.PeriphManager] init() called with device args
`time_source=internal,clock_source=internal,product=n310,mgmt_addr=192.168.64.2'.
[ERROR] [MPM.RPCServer] init() failed with error: 'NoneType' object has no
attribute 'get'
Error: RuntimeError: Error during RPC call to `init'. Error message:
'NoneType' object has no attribute 'get'

$ uhd_image_loader --args="type=n3xx,addr=192.168.64.2,fpga=XG"
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.64.2,type=n3xx,product=n310,serial=318F043,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'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 318F043
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args
`clock_source=internal,time_source=internal'.
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.

$ uhd_usrp_probe --args="addr=192.168.64.2"
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.64.2,type=n3xx,product=n310,serial=318F043,claimed=False,addr=192.168.64.2
[INFO] [MPM.PeriphManager] init() called with device args
`time_source=internal,clock_source=internal,product=n310,mgmt_addr=192.168.64.2'.
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
  _
 /
|   Device: N300-Series Device
| _
|/
|   |   Mboard: ni-n3xx-318F043
|   |   eeprom_version: 2
|   |   mpm_version: