Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: making NI USRP radios work with GNU Radio framework
(Nicolas Cuervo)
2. B200mini repeating waveform (Frank Liu)
3. Re: B200mini repeating waveform (Marcus M?ller)
4. Re: B200mini repeating waveform (Ian Buckley)
5. Re: Vivado HDL-SDK hand-off (Jonathon Pendlum)
6. Kalibrate-uhd with b200 (ayush gupta)
7. AssertionError: block_def with X300 (Claudio Cicconetti)
8. "No GPSDO found" with X300 (Jason Roehm)
9. Cannot use UHD driver with RFNOC in Windows 10 (Pol Henarejos)
10. Re: "No GPSDO found" with X300 (Marcus D. Leech)
11. Re: Cannot use UHD driver with RFNOC in Windows 10 (Marcus M?ller)
12. USRP x300 uhd_usrp_probe error
(Chathura M. Sarathchandra Magurawalage)
13. Re: "No GPSDO found" with X300 (Neel Pandeya)
14. Re: USRP x300 uhd_usrp_probe error (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 6 Oct 2016 10:03:07 -0700
From: Nicolas Cuervo <[email protected]>
To: Ammar Mahmood <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] making NI USRP radios work with GNU Radio
framework
Message-ID:
<caoupcvjs6nizpxngdrgrek_e-qwvy0ion5fpxerzu8mtjxa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Mahmood,
The device that you are intend to use is from the N-Family, so you'd have
to use those images. Ie, the b200 fpga image plays no role here. For this
case you will have to update the FPGA image to convert it into a N210.
We have an app note that follows the standard procedure, which can be found
here: https://kb.ettus.com/Running_UHD_and_GNU_Radio_on_NI-USRP_RIO. This
assumes that the device that you intend to convert is from the X3XX family,
but it should apply for you too. Also, the version written in that document
is not the latest. If you use UHD 3.9.5 LTS you should be fine. After
compiling the UHD version that you want to use, please be sure to run the
uhd_images_downloader before trying to burn the image into your device.
This will ensure that you get the version of the image that match the
software.
Please let us know if you have more questions about this.
Cheers,
-Nicolas
On Wed, Oct 5, 2016 at 10:14 PM, Ammar Mahmood via USRP-users <
[email protected]> wrote:
> Dear all,
>
> I am trying to build FPGA/Firmware images on my NI USRP 2930 to make it
> work with GNU Radio framework. I have tried with the Firmware and FPGA
> images of n200, n210 and b200 to no avail. The error that I have been
> encountering in the process is : "The FPGA image selected is not valid for
> the selected hardware. The revision numbers do not match" Can anybody help
> me out in this process? Thanks in advance.
>
>
> Regards,
>
> --
>
>
>
> Ammar Mahmood
> Research Associate
> ITU Lahore
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161006/c35313c6/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 6 Oct 2016 14:18:18 -0700
From: Frank Liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B200mini repeating waveform
Message-ID:
<CAMZy46Zmi369-0FrFyWW3z2=FZbTUd8=fveasclymadg3sg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We're looking to use the B200mini as a small, standalone transmitter,
emitting a short burst followed by the exact same burst over and over again.
To make our system as low power as possible, we'd like to encode this
signal directly into the FPGA, using the USB port purely to power the
board. Has anybody attempted this in the past, and if so, would you mind
sharing code? If not, would it be possible to provide pointers to FPGA code
that we'll need to change to make this possible?
Thanks in advance.
--Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161006/5b0b4b57/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 6 Oct 2016 23:34:00 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200mini repeating waveform
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Frank,
The B200mini needs an external computer to load the FPGA image,
configure everything and supply the samples. The FPGA has no means to do
that yourself, hence a complete standalone application is impossible.
Also note that even theoretically, the amount of memory you could
synthesize into the FPGA of the B200mini isn't very much, and hence, the
amount of stored signal would have to be extremely short. In other
words, what you want is sadly impossible.
Maybe you could share a bit of the requirements (bandwidth, duration,
pulse repetition rate...) of your application, so that we might come up
with an elegant alternative?
Best regards,
Marcus
On 06.10.2016 23:18, Frank Liu via USRP-users wrote:
>
> We're looking to use the B200mini as a small, standalone transmitter,
> emitting a short burst followed by the exact same burst over and over
> again.
>
> To make our system as low power as possible, we'd like to encode this
> signal directly into the FPGA, using the USB port purely to power the
> board. Has anybody attempted this in the past, and if so, would you
> mind sharing code? If not, would it be possible to provide pointers to
> FPGA code that we'll need to change to make this possible?
>
> Thanks in advance.
>
> --Frank
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161006/a2713be3/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 6 Oct 2016 14:35:52 -0700
From: Ian Buckley <[email protected]>
To: Frank Liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200mini repeating waveform
Message-ID:
<CAM_0ocG0bcg9vRHvqQwBWLgnEh3zJ=uh9tb4yjfkbwjc8bh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Frank,
The B2x0 USRP's have no on board non-volatile storage for the FPGA image
and micro-controller firmware so they bootstrap it via USB at power up.
Your best bet is to hook this upto a super cheap ARM system that can host
the USB downloads and also run UHD to get you API control of the Radio.
-Ian
On Thu, Oct 6, 2016 at 2:18 PM, Frank Liu via USRP-users <
[email protected]> wrote:
>
> We're looking to use the B200mini as a small, standalone transmitter,
> emitting a short burst followed by the exact same burst over and over again.
>
> To make our system as low power as possible, we'd like to encode this
> signal directly into the FPGA, using the USB port purely to power the
> board. Has anybody attempted this in the past, and if so, would you mind
> sharing code? If not, would it be possible to provide pointers to FPGA code
> that we'll need to change to make this possible?
>
> Thanks in advance.
>
> --Frank
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161006/786926fa/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 6 Oct 2016 18:57:37 -0500
From: Jonathon Pendlum <[email protected]>
To: "Patel, Chintan" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Vivado HDL-SDK hand-off
Message-ID:
<CAGdo0uTjJ2o8k2iS3ZwmkB--cJ07aO6eLuJ06ER=6tbbx3b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI Chintan,
You can make changes to the PS-PL interface. You'll need to edit the PS IP,
which is usrp3/top/e300/ip/processing_system7_1/processing_system7_1.xci or
usrp3/top/e300/ip/processing_system7_3/processing_system7_3.xci if you have
a speed grade 3 E310. You'll also need to use the generated ps7_init.c and
ps7_init.h files to generate a new bootloader via our OpenEmbedded build.
Finally, you'll need to edit e3xx_ps.v and add the signals for the new
interface.
Jonathon
On Wed, Oct 5, 2016 at 8:21 AM, Patel, Chintan <[email protected]>
wrote:
> Hi Jonathon,
>
>
>
> I am trying to understand how customizable the USRP/UHD framework is,
> particularly vis-?-vis making custom edits to the HDL/PL and being able to
> build an Zynq image (software) which has the ?new? PL bitstream. When I try
> to correlate the Xilinx prescribed methodology for typical Zynq development
> flow to the source code available on the USRP git, I see there are some
> ?discrepancies?. Specifically, Xilinx talks about creating/exporting a
> hardware definition file from Vivado that can then be used by their SDK to
> create the binary that contains the software + bitstream. But I think to
> create this hw definition file, Vivado seems to need a block design that
> describes the system ? not the e310.v top level that is provided.
>
>
>
> I know that I can create new .bit files from Vivado and place them in the
> USRP file system which provides an easy mechanism to update the PL. But
> given the absence of the aforementioned hw definition file, my current
> theory is that the changes I make to the HDL/PL have to be such that the
> PS-PL interfaces are not changed. For e.g, I can add all the blocks I want
> in the DDC/DUC chain, but I can?t add a second HPC port to the PS-PL
> interface.
>
>
>
> Any clarifications will be much appreciated.
>
>
>
> Thanks
>
> Chintan
>
>
>
> *From:* Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Tuesday, October 04, 2016 3:52 PM
> *To:* Patel, Chintan
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Vivado HDL-SDK hand-off
>
>
>
> Hi Chintan,
>
>
>
> Can you describe what you want to accomplish? Are you trying to make a
> RFNoC block using HLS?
>
>
>
>
>
>
>
> Jonathon
>
>
>
> On Tue, Oct 4, 2016 at 1:27 PM, Patel, Chintan via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
>
>
> A question related to creating modified FPGA bitstreams using the Ettus
> source code. Based on Xilinx documentation, one needs to create a hardware
> handoff file (.hdf) file that the Xilinx SDK uses. If I try to create this
> .hdf file from the Vivado environment (for a project that builds
> successfully), Vivado complains it can?t do that since It doesn?t have the
> required file (IPI hardware definition file). Is this .hdf file not needed
> for the software development process prescribed by Ettus?
>
>
>
> Thanks
>
> Chintan
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161006/b466fc7f/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 7 Oct 2016 09:16:01 +0530
From: ayush gupta <[email protected]>
To: [email protected]
Subject: [USRP-users] Kalibrate-uhd with b200
Message-ID:
<cagf-_vm_qjaqw1_+d9mleb+cztfaaipri-e0emzxxyvxntz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
greetings everyone!
I wish to use kalibrate (ttsou.github.io/kalibrate-uhd/) with my usrp b200
board,
but currently its not working it is not creating makefile.in
i am using ubuntu 16.04 and latest uhd
i want to scan and confirm few gsm frequencies in my area
also i would be glad if someone can confirm me that its use wont compromise
the performance of my board in any manner?
would really appreciate the help
thanks in advance
Ayush Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161007/04fc50dd/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 7 Oct 2016 12:45:17 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: [USRP-users] AssertionError: block_def with X300
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear all,
I am starting experimenting with RFNoC but I encountered the following
blocking issue.
As recommended in the "Testing the installation" section of the "RFNoC
Getting Started Guides" I ran:
$ uhd_usrp_probe --init-only
but unfortunately I obtained the following error (full output at the
bottom of this email):
Error: AssertionError: block_def
in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
size_t, size_t, const uhd::sid_t&, uhd::device_addr_t, uhd::endianness_t)
at /home/ccicconetti/uhd/host/lib/usrp/device3/device3_impl.cpp:148
This happens both with 3.10.0.0-release (FW release 32), Ubuntu 16.04
packages and compiled from source, and with the latest code from git
rfnoc-devel branch (FW release 33).
I have an X300 with a single WBX-120 and no GPSDO on board.
The radio works perfectly fine with stable UHD versions until 3.9.5
(both Ubuntu packages and compiled versions).
Best regards,
Claudio
--
Full output of 'uhd_usrp_probe --init-only':
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_004.000.000.rfnoc-devel-641-g8773fb2c
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:30)...OK
-- Port 48: Found NoC-Block with ID F1F0D00000000000.
-- Using default block configuration.
Error: AssertionError: block_def
in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
size_t, size_t, const uhd::sid_t&, uhd::device_addr_t, uhd::endianness_t)
at /home/ccicconetti/uhd/host/lib/usrp/device3/device3_impl.cpp:148
------------------------------
Message: 8
Date: Fri, 7 Oct 2016 08:45:39 -0400
From: Jason Roehm <[email protected]>
To: [email protected]
Subject: [USRP-users] "No GPSDO found" with X300
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I have a new X300 and GPSDO (with OCXO) that I just powered up for the
first time today. I followed the installation instructions for the GPSDO
and believe that it is installed correctly. After powering up the X300,
there are 2 green LEDs on the GPSDO that light up. After a second or two
one of them shuts off, then after a few more seconds, the other one
shuts off. When I connect to the device via UHD, however, I always get:
-- Detecting internal GPSDO.... No GPSDO found
Are there any additional troubleshooting steps that I can try, or should
I conclude that I just got a bad unit?
Jason
------------------------------
Message: 9
Date: Fri, 7 Oct 2016 14:48:42 +0200
From: Pol Henarejos <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Cannot use UHD driver with RFNOC in Windows 10
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Dear all,
I compiled the UHD driver for Windows 10 using MSVC 2015 with RNOC
enabled but I cannot set up the usrp object due to the following assertion:
-- Creating WSA UDP transport for 10.1.10.2:49153
[2016-10-07 14:44:45.771 ERROR] Exception thrown: AssertionError: block_def
in void __cdecl
uhd::usrp::device3_impl::enumerate_rfnoc_blocks(unsigned
__int64,unsigned __int64,unsigned __int64,const class uhd::sid_t &,class
uhd::device_addr_t,enum uhd::endianness_t)
at C:\CTTC\UHD\host\lib\usrp\device3\device3_impl.cpp:148
The source code is from the maint branch and corresponds to the version
UHD_003.010.000.000-79-ON
Any clue?
Thank you so much.
--
Pol Henarejos
Researcher, MSc
[email protected]
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 645 29 00 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3741 bytes
Desc: Signatura criptogr??fica S/MIME
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161007/bf773722/attachment-0001.p7s>
------------------------------
Message: 10
Date: Fri, 07 Oct 2016 09:10:58 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] "No GPSDO found" with X300
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 10/07/2016 08:45 AM, Jason Roehm via USRP-users wrote:
> I have a new X300 and GPSDO (with OCXO) that I just powered up for the
> first time today. I followed the installation instructions for the
> GPSDO and believe that it is installed correctly. After powering up
> the X300, there are 2 green LEDs on the GPSDO that light up. After a
> second or two one of them shuts off, then after a few more seconds,
> the other one shuts off. When I connect to the device via UHD,
> however, I always get:
>
> -- Detecting internal GPSDO.... No GPSDO found
>
> Are there any additional troubleshooting steps that I can try, or
> should I conclude that I just got a bad unit?
>
> Jason
>
What version of UHD are you running?
------------------------------
Message: 11
Date: Fri, 7 Oct 2016 16:24:25 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Cannot use UHD driver with RFNOC in Windows
10
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Pol Henarejos,
my first approach here: Are you using the FPGA image that belongs to
that release? We'd generally recommend using the uhd_images_downloader
tool; since you've built UHD yourself, you probably have a working
python installation, so that should just work fine. If for some reason
it doesn't you can find the exact file name you should download from [1]
in uhd/host/CMakeLists.txt as the variable UHD_IMAGES_DOWNLOAD_SRC.
Best regards,
Marcus
[1] https://files.ettus.com/binaries/images/
On 07.10.2016 14:48, Pol Henarejos via USRP-users wrote:
> Dear all,
>
> I compiled the UHD driver for Windows 10 using MSVC 2015 with RNOC
> enabled but I cannot set up the usrp object due to the following
> assertion:
>
> -- Creating WSA UDP transport for 10.1.10.2:49153
> [2016-10-07 14:44:45.771 ERROR] Exception thrown: AssertionError:
> block_def
> in void __cdecl
> uhd::usrp::device3_impl::enumerate_rfnoc_blocks(unsigned
> __int64,unsigned __int64,unsigned __int64,const class uhd::sid_t
> &,class uhd::device_addr_t,enum uhd::endianness_t)
> at C:\CTTC\UHD\host\lib\usrp\device3\device3_impl.cpp:148
>
> The source code is from the maint branch and corresponds to the
> version UHD_003.010.000.000-79-ON
>
> Any clue?
>
> Thank you so much.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161007/f14aadaf/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 7 Oct 2016 12:13:09 +0100
From: "Chathura M. Sarathchandra Magurawalage" <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP x300 uhd_usrp_probe error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Dear all,
I have a USRP x300 with SBX-120 USRP Daughterboard setup. But when I do
"uhd_usrp_probe --init-only", I get the following error.
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.000.000-release
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
Error: AssertionError: block_def
in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t, size_t, size_t,
const uhd::sid_t&, uhd::device_addr_t, uhd::endianness_t)
at /build/uhd-SfT4TV/uhd-3.10.0.0/host/lib/usrp/device3/device3_impl.cpp:148
Thanks for your help in advance!
Best Regards,
Chathura
------------------------------
Message: 13
Date: Fri, 7 Oct 2016 08:42:40 -0700
From: Neel Pandeya <[email protected]>
To: Jason Roehm <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] "No GPSDO found" with X300
Message-ID:
<cacaxmv_+nkbekl4odfuifb9g62_yy5xu+nnvtjk68pske6l...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Jason:
Did you use the small square adhesive pad that came with the GPSDO when you
installed it?
Also, could you please post a photo of the receptacle/connector for the
GPSDO on your X300 motherboard?
--Neel Pandeya
On 7 October 2016 at 06:10, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 10/07/2016 08:45 AM, Jason Roehm via USRP-users wrote:
>
>> I have a new X300 and GPSDO (with OCXO) that I just powered up for the
>> first time today. I followed the installation instructions for the GPSDO
>> and believe that it is installed correctly. After powering up the X300,
>> there are 2 green LEDs on the GPSDO that light up. After a second or two
>> one of them shuts off, then after a few more seconds, the other one shuts
>> off. When I connect to the device via UHD, however, I always get:
>>
>> -- Detecting internal GPSDO.... No GPSDO found
>>
>> Are there any additional troubleshooting steps that I can try, or should
>> I conclude that I just got a bad unit?
>>
>> Jason
>>
>> What version of UHD are you running?
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161007/07cea3c8/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 7 Oct 2016 17:57:46 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP x300 uhd_usrp_probe error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Chathura,
have you done "uhd_images_downloader; uhd_image_loader --args
type=x300,addr=xxx.xxx.xxx.xxx" (replacing xxx.... with the IP address
of your USRP)?
Best regards,
Marcus
On 07.10.2016 13:13, Chathura M. Sarathchandra Magurawalage via
USRP-users wrote:
> Dear all,
>
> I have a USRP x300 with SBX-120 USRP Daughterboard setup. But when I do
> "uhd_usrp_probe --init-only", I get the following error.
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.000.000-release
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> Error: AssertionError: block_def
> in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t, size_t,
> size_t, const uhd::sid_t&, uhd::device_addr_t, uhd::endianness_t)
> at /build/uhd-SfT4TV/uhd-3.10.0.0/host/lib/usrp/device3/device3_impl.cpp:148
>
> Thanks for your help in advance!
>
> Best Regards,
> Chathura
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 74, Issue 7
*****************************************
