On 04/17/2018 06:01 AM, Allouche Ishai via USRP-users wrote:
> Hi all,
>
>
>
> I am working on a USRP X310 with a source file block and I have some issues.
>
>
>
> My setup is :
>
>
>
> Source File -> Throttle -> RFNoC: Window -> RFNoC: FIFO -> Copy ->
> Vector to Stream -> File Sink.
>
On 04/16/2018 09:52 AM, Francesco Restuccia via USRP-users wrote:
> Hi all,
>
> I am trying to add the schmidlcox, fft and and eq to my X310.
>
> Looks like the S&C block does not meet timing constraints. This is the
> report from Vivado.
>
> Any help would be much appreciated, thank you...
Hav
On 04/16/2018 01:54 AM, Yeo Jin Kuang Alvin (IA) via USRP-users wrote:
> Hi all,
>
>
>
> I have two questions regarding the USRP B210 configurations using API
> and FPGA at the same time.
For the archive: this was addressed in various other threads.
-- M
_
On 04/15/2018 06:20 PM, Miklos Maroti via USRP-users wrote:
> Dear All,
>
> I am new to RFNoC development, and hope some of you can give some
> insight. I was looking the fpga-src repository, and reading RFNoC docs
> online. Reading the source code I see that m_axis_data_tdata and
> s_axis_data_td
On 04/11/2018 07:05 PM, Marcus D. Leech via USRP-users wrote:
>> Q: Do you have a rough idea of how long the calibration is good for (a
>> few days vs a few months)?
> I'm not sure that anyone has ever asked that question before. Certainly
> component-aging plays some role in shifting I/Q and DC-o
On 04/04/2018 02:27 AM, Ivan Zahartchuk via USRP-users wrote:
>
> Hello. I use B200 to scan the spectrum in a certain band. I have two
> problems.
> 1) the last part of the collection of the spectrum becomes the
> beginning. Fig. 1
> 2) the switching time from frequency to frequency is alternated
On 04/09/2018 02:24 AM, Yeo Jin Kuang Alvin (IA) via USRP-users wrote:
> Hi everyone,
>
>
>
> I tried to build the USRP B210 FPGA for Xilinx ISE 14.7 (Windows) and I
> got this in my cmd prompt:
>
>
>
> C:\Users\WORK\Desktop\fpga-maint\usrp3\top\b200>make B210 PROJECT_ONLY=1
>
> "ISE Versi
age_logging.html
> <http://files.ettus.com/manual/page_logging.html>
>
> ...and this email:
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-April/024653.html
>
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus
On 03/06/2018 02:03 AM, Goh Liang Zhen via USRP-users wrote:
> Dear fellow users,
>
>
>
> I intend to put together a 8 channel data collection system using 2
> X310s, each mounted with 2 TwinRXs. With the guidance from the past
> experience in this forum, I have installed the hardware and star
On 04/21/2018 11:45 PM, Allouche Ishai wrote:
> Hi Martin,
>
> Thank for your quick respond.
>
> The output is invalid. In order to verify, I connect the output to 2 blocks:
> File Sink and QT Sink.
> The File Sink don’t change and stay blank, and the QT Sink show zero all the
> time ,in the fr
On 05/02/2018 11:04 AM, Dave NotTelling via USRP-users wrote:
> Are versions >= 3.10 still considered experimental? I thought that any
> version with a release_XXX_XXX_XXX was considered stable. When I run
> cmake ../ on any version 3.10 or higher it warns me that I am on a
> development branch.
Yes,
two release candidates back to back!
While we're wrapping up the 3.11.1.0 release, we're already preparing
for a 3.12.0.0 release.
If you're wondering which version to choose (3.11.1.0 or 3.12.0.0),
here's a few guidelines:
- 3.12.0.0 added White Rabbit support for the N310, so if you need
The RC1 is based off of master branch, see also:
https://github.com/EttusResearch/uhd/releases/tag/v3.12.0.0-rc1
Cheers,
Martin
On 05/17/2018 02:31 PM, Martin Braun wrote:
> Yes,
>
> two release candidates back to back!
>
> While we're wrapping up the 3.11.1.0 release, we're already preparing
Hi all,
after release-candidating, we have now finalized the 3.12.0.0 release.
As mentioned before, you might not want to upgrade, but simply run the
3.11.1.0 release which has fewer feature-related changes, but most of
the bugfixes. Here's the decision guidelines which were already in the
RC1 not
On 06/06/2018 08:41 AM, Philip Balister wrote:
>> Tag, FPGA images and github-auto-produced tarballs can be found here:
>> https://github.com/EttusResearch/uhd/releases/tag/v3.12.0.0
>
> If you are using tarball checksums to validate the tarball, github will
> occasionally regenerate the tarball l
On 06/06/2018 08:26 AM, Martin Braun wrote:
> - 3.12.0.0 removed some public API calls, it is thus an API-breaking
> release (note that these were some obscure API calls, most users
> won't see a difference. GNU Radio users certainly won't).
> If you want to keep everything as stable as possi
On 06/13/2018 12:49 PM, Farhad Mirkazemi via USRP-users wrote:
> I'm trying to manipulate my usrp2 clock using the example clock_ctrl.cpp
> but when I try to build it, I get cmake error related as following; the
> warning should be ok but I don't understand the error which says it does
> not know L
On 06/13/2018 12:30 AM, ishai alouche via USRP-users wrote:
> Hi all,
>
> I open with rfnocnodtool new block with the name siggen like the block
> that exist in the basic rfnoc block in the gnu-radio. So i have two
> rfnoc block with the same name in different directory.
> I decide to delete the n
On 06/12/2018 10:28 AM, Ayaz Mahmud via USRP-users wrote:
> Hi,
>
>
>
> I am trying to transmit and receive a .png file through OFDM (*Block
> diagram attached*). The file size is only 1.5kB. While running I am
> getting the below warning & error in console. Can someone point out the
> reason b
I would expect it grow indefinitely, but it might slow down after 1.2
MB. If repeat is on, expect lots of data.
The 106 bytes vs. 64 bytes is more interesting. I don't see why, but
maybe somewhere the last 42 bytes are getting stuck. It might even be in
GNU Radio.
Try a file that's a multiple of
Two more comments:
- The clock is not exported by default. So MB 1 won't see a reference
clock, and then you get the error you saw.
- You can get frequency alignment between the boards this way, but the
time will definitely be un-aligned, like Michael said.
-- M
On 06/11/2018 03:38 PM, Michael W
On 06/11/2018 12:42 PM, Luis Felipe Albarracin Sanchez via USRP-users wrote:
>
> Hello all,
>
> I am having an Issue when trying to test a model with a USRP B210, i
> have instaled GNURadio, via:
>
> *$ apt install gnuradio*
>
> then i tried to connect mi USRP to the model, but the followig er
I'm not sure this is the XML file. It looks like the traffic is going
from your block to the radio block controller because the outgoing SID
is not set properly.
However, the outgoing ctrl_iface SID is derived from the incoming
packet. Have you had other blocks work in the past?
Did it stop working
On 06/09/2018 12:59 PM, Zhongyuan Zhao via USRP-users wrote:
> Hi,
>
> I was configuring N310 for the first time. My UHD version is 3.12 with
> branch of python-api,
>
> When I try to update the SD image of firmware, according to
> the https://kb.ettus.com/N300/N310_Getting_Started_Guides
>
>
Matis,
you also need to keep in mind that via USB, we can only receive a
certain amount of samples at a time, and it's not a factor of 16384.
-- M
On 06/08/2018 04:18 PM, Marcus Müller via USRP-users wrote:
> Hi Matis,
>
> the time stamp of the first buffer after a disruption should indeed be
>
On 06/07/2018 03:55 AM, Derek Kozel via USRP-users wrote:
> Hello Walter,
>
> The N310 uses MPMD as it's host side interface so the appropriate flag
> is -DENABLE_MPMD. I'll see about documenting that better. The E3xx build
> flag is entirely separate.
> http://files.ettus.com/manual/page_usrp_n3x
I assume you're using a BasicRX/TX combo and a recent UHD version (3.11
and above).
How exactly are you using receiving? Are you sending a single stream
command, or multiple stream commands? If its the latter, are you setting
time stamps?
-- M
On 06/05/2018 11:25 AM, Nicolai Kern via USRP-users
It's the right file, however, this kind of modification is outside of
the scope of what we can help you with. Good luck!
-- M
On 06/13/2018 02:49 PM, Farhad Mirkazemi wrote:
> Hello martin,
>
> Thanks for your reply;meanwhile, I am modifying/setting the r divider to
> "2" in the clock_ctrl.cpp o
On 01/26/2018 02:28 AM, Дмитрий Михайличенко via USRP-users wrote:
> Hi,
>
> I am trying to do FFT using corresponding RFNoC block in X310. It works
> if FFT size is 1024 but fails if the size is 2048 or 4096. The block
> does not return any data and I see the following errors in uhd:
>
> [ERROR]
On 05/01/2018 05:13 AM, Ronakraj Gosalia via USRP-users wrote:
> Hi everyone,
>
> I am using a USRP E312 with GNU Radio 3.7.10.2. GNU Radio has an inbuilt
> FEC block that supports Turbo Product Codes (TPC). I'm trying to run a
> flowgraph (completely in simulation) on the E312 that includes a TPC
On 05/12/2018 05:17 AM, EJ Kreinar via USRP-users wrote:
> I also find this confusing...
>
> Even better: how about a scheme where x3xx finds both x300/x310, but
> x310 only gets x310, etc??
We use the 'product' key for that.
-- M
___
USRP-users maili
On 05/18/2018 05:55 PM, harfan ryanu via USRP-users wrote:
> Hi All,
> I have question related to two function in UHD. There is a function to
> choose subdev (set_tx/rx_subdev_spec) and set antenna
> (set_tx/rx_antenna). What is the difference between these two function?
> If i choose for example s
On 05/10/2018 11:16 AM, Devin Kelly via USRP-users wrote:
> Hello,
>
> I'm trying to log underflows. All I really need is a list of timestamps
> (or sample numbers) when an underflow occurs. I can't easily figure out
> how to do this. I'm using UHD 3.9.7.
You will need to call recv_async_msg(
Hi,
we just pushed changes to the script live. However, you should be able
to build an RFNoC image by modifying the rfnoc_ce_auto_inst_n310.v, and
building an RFNoC image, e.g. by running
$ make N310_RFNOC_HG
Cheers,
Martin
On 06/20/2018 06:52 AM, Rob Kossler via USRP-users wrote:
> Hi Dere
Hi all,
after a while of testing and gathering feedback, we have merged the UHD
Python API into master branch. In general, we are happy with its state,
but that doesn't mean it's perfect and complete.
First off, there's at least one known issue with the Python API: It does
not build on Windows. W
On 06/21/2018 10:57 AM, Ayaz Mahmud via USRP-users wrote:
> Hello All,
>
>
>
> I am trying to build OFDM_MIMO (2 x 2). I have used the blocks from OFDM
> example folders and joined tx & rx together and transmitting/receiving
> over USRP B210.
>
>
>
> My aim is to get a channel state informa
Can you try recv_frame_size=1024 as part of the device args?
-- M
On 06/13/2018 03:23 PM, Ayaz Mahmud wrote:
> Hi,
>
>
>
> Yes, Its B210 and works with other example like tx_ofdm.
>
>
>
> Ayaz
>
>
>
>
> *From:* M
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
Hi all,
I just pushed a pretty big change to the UHD repository. Going forward, we
will be tracking the FPGA code and the UHD code in the same repository, as
we did pre-2014.
For most of you, this won't be a big change, except for a big changeset on
your next git pull. If you are running UHD from
> Development? Or is it just removing the git fpga?
>
> Our IT guys use the AN for their install process.
>
> Thx,
> Jeff
>
> --
> *From:* USRP-users on behalf of
> Martin Braun via USRP-users
> *Sent:* Tuesday, February 4, 2020 4:5
On 3/5/20 2:53 PM, Long, Jeffrey P. via USRP-users wrote:
> Maybe this is a stupid question but I can’t find anything in google
> land. Can we use the jtag port on the N310 to chipscope? I have
> successfully built and run images and so I created a build with some
> debug via a single ILA. It looks
It does; the channel parameter on E310 is used to address the A- or B-side.
On Mon, May 4, 2020 at 1:39 PM Rob Kossler wrote:
> Does the 2nd argument to set_rx_antenna() indicate which radio port? If
> so, try setting it to 1.
> Rob
>
> On Mon, May 4, 2020 at 2:02 PM Ivan Zahartchuk via USRP-us
On 8/24/20 7:28 PM, Jonathan V Nguyen via USRP-users wrote:
> I was wondering if there was a way to get the addresses of all the USRPS
> currently connected to a host on the Python API. I saw that the C++ API
> had the uhd::device::find() function, but this seems to be missing in
> the Python API.
Sylvain,
the UHD/C++ code you're quoting is for USRP2/B100. timekeeper.v on the
other hand is in the usrp3/ subdirectory, so it's for the Gen-3 devices,
and B200 (because B200 is Gen-2.5 and we round it up to 3... or something
like that).
If we take a look at time_core_3000.cpp, then we see:
On 8/25/20 11:03 AM, Snehasish Kar via USRP-users wrote:
> We are trying to implement some filters in rfnoc, we wanted to use fixed
> point numbers. As per my knowledge, I and Q are I16 bits individually
> and IQ combined I32 bits. We wanted to convert them into fixed
> point numbers. But I am conc
On 9/8/20 4:01 PM, Marcus D. Leech via USRP-users wrote:
>> 2 days back I have used a C++ code which can acquire data from Antenna
>> via USRP 2955. Previously that code works fine in another machine. But
>> when I tried to run in another machine, it was showing "no device
>> found" when I run the
On 9/5/20 2:59 PM, Ofer Saferman via USRP-users wrote:
> Hello,
>
> I am just starting out with the USRP E310 so bare with me.
> I am trying to capture samples to file using: ./rx_samples_to_file
> --freq 2.4e9 --rate 40e6 --bw 40e6 --gain 30 --nsamps 100 --file
> samp4.dat
> I get the followi
On 9/8/20 3:51 PM, Rob Kossler via USRP-users wrote:
> One more question. I just looked at the latest commits which include
> the Replay block in the default images. I notice that for each device
> only one multi-port Replay block is added rather than multiple one-port
> Replay blocks (e.g., for
On 9/5/20 4:59 PM, Koyel Das (Vehere) via USRP-users wrote:
> NI told me magnitude of IQ samples received in usrp is the voltage in volts.
Can you point us to where you got that information?
For the list archives: UHD 4.0 will have the ability to map digital
signals to power levels for X3x0 and B
On 9/9/20 5:46 AM, Ofer Saferman via USRP-users wrote:
> Thank you Marcus and Martin.
> Maybe I will try to explain what I am trying to do and you can correct
> what I am doing wrong.
> I don't want to stream the samples. I understand the limitations of the
> ARM processor.
> What I would like to d
ll that.
--M
> Rob
>
> On Wed, Sep 9, 2020 at 3:28 AM Martin Braun via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> On 9/9/20 5:46 AM, Ofer Saferman via USRP-users wrote:
> > Thank you Marcus and Martin.
> > Maybe I will try to explain
On 9/15/20 2:14 PM, Koyel Das (Vehere) via USRP-users wrote:
> Hi,
>
> When we set sample rate at 100 MSps in usrp 2955, is the actual sample
> rate 100 MSps only or 128 MSps?
This USRP can do 100 Msps, 200 Msps, or 184.32 MHz. It can't do 122.88
or 128 Msps.
--M
___
On 9/14/20 12:56 PM, Daniel Ozer via USRP-users wrote:
> Hi everone ,
> Im working on usrp x310 .
> I have tried to ifind what is the architecture of the axi crossbar and i
> didnt found any thing in the auto generated vivado project .
> Is it Shared Write and Read Address Arbitration?
> axi_cross
On 9/15/20 3:19 PM, Martin Braun wrote:
> On 9/15/20 2:14 PM, Koyel Das (Vehere) via USRP-users wrote:
>> Hi,
>>
>> When we set sample rate at 100 MSps in usrp 2955, is the actual sample
>> rate 100 MSps only or 128 MSps?
>
> This USRP can do 100 Msps, 200 Msps, or 184.32 MHz. It can't do 122.88
>
On 9/17/20 12:38 AM, Rob Kossler via USRP-users wrote:
> Hi,
> After playing around with UHD 4.0 and migrating existing applications &
> custom blocks to 4.0, I have several questions (see below).
> Thanks.
> Rob
Hi Rob,
great questions. I'll take a stab:
> * What is the status of the need for
On 9/17/20 3:58 AM, Rob Kossler via USRP-users wrote:
> and one more question:
>
> * How do we include 'rfnoc_chdr_utils.vh' in our out-of-tree rfnoc
> module? Is there a way to specify an include path so that we don't
> have to hardcode it?
That looks like something for us to improve.
On 9/18/20 8:19 AM, Marcus D. Leech via USRP-users wrote:
> On 09/17/2020 11:19 PM, Thomas james wrote:
>> HI Marcus,
>> thanks. and is the source code of stm32 and cpld avaiable?
>>
> I don't believe that any of the CPLD code is available, but the STM32
> code might be. I can ask R&D.
STM32:
h
On 9/22/20 8:00 AM, Jayant Chhillar via USRP-users wrote:
> Hi everyone,
> I’m developing a RFNoC block to perform correlation operation which
> outputs a value between 0 and 1007. I’m not able to figure out how to
> get integer output from the block at GNURadio side. I’ve tried defining
> the outp
On 9/23/20 4:27 PM, Rob Kossler wrote:
> On Wed, Sep 23, 2020 at 4:21 AM Martin Braun via USRP-users
> wrote:
>>> Finally is there any documentation on how to read the “readback”
>>> registers on the host side (GNURadio) ?
>>
>> We haven't actually expos
On 9/25/20 11:29 AM, Andreas B via USRP-users wrote:
> Hi,
>
> I have asetup of several X310s connected over 10Gbit Ethernet, and
> synced with an Octoclock. I’m generating signals on a PC, and streaming
> the signals to the X310s to get coherent waveforms. For now I’m
> generating sinusoids where
Note that on UHD 3.15, the N310 will also not let you do that over the RJ45.
--M
On Fri, Oct 2, 2020 at 8:01 PM Michael Dickens via USRP-users <
usrp-users@lists.ettus.com> wrote:
> UHD 3.15: just on the E310. No network mode.
>
> UHD 4.0: either.
>
>
> On Fri, Oct 2, 2020 at 1:57 PM Rob Kossler
See also https://files.ettus.com/manual/page_usrp_b200.html#b200_customfpga
On Sun, Oct 11, 2020 at 3:05 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 10/10/2020 05:38 PM, Jay Labhart via USRP-users wrote:
>
> I am in the process of modifying the b210 fpga files and
Ben,
we can't provide you with PetaLinux support, but you can rebuild our
OE-Based filesystems. For novice OpenEmbedded users, we provide a Docker
image (here's a link from the E320 manual:
https://github.com/EttusResearch/ettus-docker/blob/master/oe-build/README.md),
and if you're more of an expe
Austin,
you can update the version of your N310 as well. See e.g. here:
https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_getting_started_fs_update
--M
On Sat, Oct 10, 2020 at 7:49 AM Austin Adam via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi everyone,
> It has been a few months
you are unable to help with PetaLinux issues, are you implying
> you are able to help with another mechanism for generating the FSBL, u-boot
> and kernel? Or are you stating that you flat out refuse to help with issues
> related to generating these binaries?
>
> Regards,
>
> B
A quick reminder that
uhd_images_downloader -t e320 -t sdk
will download the corresponding SDK for your UHD version even when the link
Michael provided is no longer accurate.
M
On Mon, 12 Oct 2020, 17:48 Michael Dickens via USRP-users, <
usrp-users@lists.ettus.com> wrote:
> Hi Mark - You need
Question: Can you run set_tx_lo_export_enabled(true, "LO_OUT_0", 0) on your
usrp object, or does that also fail?
--M
On Mon, Sep 28, 2020 at 11:36 PM Yu-Hsuan Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
>> Date: Mon, 28 Sep 2020 10:38:26 -0400
>> From: "Marcus D. Leech"
>> To: us
Just an FYI, all of our USRPs define 0 dB gain as the smallest overall gain
that is supported, and then it goes up. TwinRX has a wide input range of
amplitudes, so much of that 90 dB is from attenuators that enable you to
nicely see the +10 dBm input signals. So gain range != amplification, it's
th
Hi,
you didn't paste an error message.
--M
On Mon, Jan 25, 2021 at 7:02 AM --- via GNU Radio, the Free & Open-Source
Toolkit for Software Radio wrote:
> Dear friends:
> I'm installing rfnoc on E312, when I cross compile gnu radio, I
> execute this command：cmake -Wno-dev
> -DCMAKE_TOOLCHAI
Hi all,
we have recently been working more on the RFNoC side of things, and
there's some updates I want to bring to you.
The first step we did to a more stable version of RFNoC is merging all
of the work on rfnoc-devel back into master. This will make it a lot
easier to keep features in sync betw
Hi all E310/E312/E313 users,
I would like to focus people's attention to some changes we have just
started rolling out, and will continue to roll out over the next months.
Executive Summary
=
- For those requiring *no* RFNoC support whatsoever, just plain RX/TX
and UHD support,
On 07/10/2018 07:14 PM, Rob Kossler wrote:
> Thanks Michael,
> Is there any place where the minor branches are summarized? In other
> words, what are the primary differences among 3.9, 3.10, 3.11, and 3.12?
Rob,
good question. We provide a changelog for that:
https://github.com/EttusResearch/uh
Hey Sebastian,
this has been fixed on master branch
(8f16f05b20efcc9e5371c89585b992b237b43eb3) but not on a current release.
We'll remedy as soon as possible.
In a nutshell, there were product IDs that we didn't know about (but
were still valid) when we wrote the code, so we added the new ones
rec
y that, too.
Thanks for bringing all of this up!
Cheers,
Martin
>
> Rob
>
>
> On Mon, Jul 9, 2018 at 1:48 PM Martin Braun via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi all,
>
> we have recently been working more on the RFNoC side
On 07/12/2018 02:37 PM, Rob Kossler via USRP-users wrote:
> * Inaccurate Tx power output levels using UHD 3.12 or Master. The
> graph below shows the issue of erratic Tx power levels using 3.12
> (right plot) and well-behaved Tx power levels using 3.11 (left plot)
> o this problem
On 07/13/2018 11:41 AM, Rob Kossler via USRP-users wrote:
> Hi,
> With the recent changes to the branches, I understand that users doing
> RFNoC development should be using master branch and users that
> previously used 'maint' should be using 3.10, 3.11, or 3.12 as
> appropriate. I am wondering a
On 07/17/2018 09:14 AM, Martin Braun wrote:
> On 07/13/2018 11:41 AM, Rob Kossler via USRP-users wrote:
>> Hi,
>> With the recent changes to the branches, I understand that users doing
>> RFNoC development should be using master branch and users that
>> previously used 'maint' should be using 3.10,
On 07/12/2018 03:24 PM, Jacob Knoles via USRP-users wrote:
> Hey all,
>
> I have built the latest version of UHD and am trying to load up my X300
> but having major issues.
> I have used the image downloader script to get the latest versions of
> the FPGA image and the image loader to burn the i
On 07/09/2018 03:06 PM, Rob Kossler via USRP-users wrote:
> Using the latest 'rfnoc-devel' (eec24d7b) with my N310, I get the
> following error when running the example program 'benchmark_rate'. The
> error message indicates no PPS detected whenever the channel count is
> greater than one. Note t
Louis,
you don't need to start something, but I'm wondering if MPM is maybe
crashing (it's the service that turns the device into a smart USRP).
Can you try ssh'ing in and running
$ ps | grep usrp
You should see something like this:
root@ni-n3xx-***:~# ps | grep usrp
1422 root 264
On 06/27/2018 11:31 AM, Rob Kossler via USRP-users wrote:
> Hi,
> I am getting some unexpected behavior from my N310 using the example
> 'tx_waveforms' utility and stock FPGA image using 'rfnoc-devel'. If I
> simply switch to 'maint', things behave as expected. Here are the issues...
>
> 1. Wit
Hi all,
we have just tagged the 3.13.0.0-RC1 version of UHD. It includes a
variety of improvements for the N310 and B200, and is the first version
to include the Python API. Please find the full changelog below.
When we release the full version, we will also publish up-to-date SD
card images for
TX Subdev: Magnesium
>
> [00:00:34.792002] Setting device timestamp to 0...
> [INFO] [MULTI_USRP] 1) catch time transition at pps edge
> [INFO] [MULTI_USRP] 2) set times next pps (synchronously)
> [00:00:36.807511] Testing receive rate 12.50 Msps on 2 chan
TX DSP: 0
> > TX Dboard: B
> > TX Subdev: Magnesium
> > TX Channel: 2
> > TX DSP: 0
> > TX Dboard: C
> > TX Subdev: Magnesium
> > TX Channel: 3
> > TX DSP: 0
> >
On 07/23/2018 06:57 AM, Rob Kossler wrote:
> Martin,
> Re-flashing the SD card with the 3.12 image fixed my issue!
Rob,
that's great news, and I'm happy you're unstuck! I'm still not entirely
sure what the exact reason is for this is, but here's a short analysis:
On the N310, we use an architect
Keith,
what's the subdev spec you're using?
There shouldn't have been any issues, and we do test releases using the
N200, but maybe we missed a case here.
-- M
On 07/24/2018 12:42 PM, Keith k via USRP-users wrote:
> Hello all
>
> My multiusrp application will run using 3.11 and below, but when
We can't speed up Vivado, unfortunately. Maybe if we design an RFNoC
block that does place and route
So, there's not much you can do. You might be able to use design
checkpoints, but that's an advanced Vivado feature and we don't have
support out of the box for that. You need to know what you
FYI, we fixed a couple of sc12/8 related issues on our latest master
branch. As Marcus says, if you're doing dual channel on the B210, you
can only go to 30.72 Msps though.
-- M
On 07/24/2018 12:06 PM, Marcus D. Leech via USRP-users wrote:
> On 07/24/2018 03:18 AM, RizThon via USRP-users wrote:
Rob,
two more comments: The git hash of the FPGA source gets baked into the
image, and you can read /mboards/0/fpga_version_hash to identify the image.
As for logging, sure, go use UHD. It was designed to make it easy to
distinguish the source of logging messages. I sometimes run UHD in
high-verb
On 07/24/2018 01:59 PM, Martin Braun wrote:
> Rob,
>
> two more comments: The git hash of the FPGA source gets baked into the
> image, and you can read /mboards/0/fpga_version_hash to identify the image.
...and uhd_usrp_probe prints that, too.
-- M
__
;mailto:keithko...@gmail.com>> wrote:
>
> Hello Martin
>
> Im using "tx_subdev" : "A:A" in my config.
>
> On Tue, Jul 24, 2018 at 2:16 PM, Martin Braun via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> Kei
On 07/23/2018 03:17 PM, Erik Malone via USRP-users wrote:
> Hi
>
> I'm looking for a way to log all signals when simulating an RFNoC design
> in batch mode. This would help me to run longer tests and then bring up
> a waveform whenever an error occurred. Preferably, I'd like to keep
> within Et
Jason,
this is a tough one. I have no ideas, other than 'throw in a couple of
ILAs and see where it's stuck'.
-- M
On 07/23/2018 12:03 PM, Jason Matusiak via USRP-users wrote:
> I have a flowgraph with a custom RFNoC block in the middle. That block
> has 2 inputs and 2 outputs. Just to get sta
I think you might be fine changing this line:
https://github.com/EttusResearch/fpgadev/blob/f27926410328883a315d5230146936d2d782bd09/usrp3/top/e300/e310_core.v#L319
...but it's untested and unsupported.
Cheers,
Martin
On 07/22/2018 04:02 AM, carry chen via USRP-users wrote:
> Hi,
>
> list,
>
On 07/18/2018 05:40 AM, Massimo Bastianon via USRP-users wrote:
> I'm struggling with an easy task: get USRP B200mini working with my code.
>
> I'm using windows 10 x64 and visual studio 2017, I downloded and
> compiled boost 1.67.0 (both 32 and 64 bit). I used udh.dll from UHD
> 3.12.0.0 and GNUR
On 06/28/2018 05:09 AM, Fabian Schwartau via USRP-users wrote:
> Hi everyone,
>
> I am still working on the synchronization of my two USRP X310. Both get
> the same 10 MHz, 1 PPS and LO signals. I made a small piece of code to
> toggle one of the GPIOs at the Aux I/O of each USRP in a timed manner
Link should be:
https://github.com/EttusResearch/fpga/blob/f27926410328883a315d5230146936d2d782bd09/usrp3/top/e300/e310_core.v#L319
On 07/24/2018 02:20 PM, Martin Braun wrote:
> I think you might be fine changing this line:
>
> https://github.com/EttusResearch/fpgadev/blob/f27926410328883a315d52
On 06/25/2018 07:20 AM, Andreas Bauer via USRP-users wrote:
> Hello,
>
>
> we are currently working with a USRP X310 with a Twin RX daughter board.
> We are interested on more information about the CHDR protocol.
>
>
> The documentation on https://files.ettus.com/manual/page_rtp.html seems
> to
On 07/25/2018 02:08 PM, Jim Rorick via USRP-users wrote:
> Folks -
>
> Quick question - saw that 3.13 was released with lots of changes. I’m a poor
> old retired guy using a legacy USRP-1 (WX, LFTX/LFRX daughter boards) with
> GNURADIO for amateur radio. At what version should I lock-in UHD? Whe
Hassna,
you can't build RFNoC images with Vivado_Lab. You need the full Vivado.
-- M
On 07/31/2018 12:14 PM, Ouassal, Hassna via USRP-users wrote:
> Hello,
>
>
>
> I ma wokring through "Build custom image with pre-built RFNoC blocks"
>
>
> I am running the following script:
>
> hassna@has
101 - 200 of 239 matches
Mail list logo
