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
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
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
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
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
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
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
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
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
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
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/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/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/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/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/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/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 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
___
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/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
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/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 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 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 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
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/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.
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 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
> 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
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
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
Ishai,
it's a bit hard to tell from this snippet, since we're missing the
definitions of random_word and s. Which one is wrong, is it random_word, or
readback?
-- M
On Thu, Oct 3, 2019 at 12:56 AM ishai alouche via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> I work with X310 and I
Is this with vanilla code, or your own custom code?
On Thu, Sep 26, 2019 at 5:49 PM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I'm trying to take what I learned from GRCon2019 from Neel and company's
> workshop, and I'm trying to perform the uhd_image_builder_gui.py script. It
>
No, you can do FPGA dev on the B200 series. However, you can't do RFNoC on
the B200 series. The manual has a few comments on it:
http://files.ettus.com/manual/page_usrp_b200.html#b200_customfpga
We expose a register interface (meaning you might not also have to modify
UHD), and there's a scratch s
Half-Bands are very flat in the passband, and somewhat efficient to
implement because every second tap is zero. The CIC on the other hand, is
super efficient, but has a horrible frequency response.
So, you want to use the half-bands for decimation whenever possible. You
will have fewer aliases, th
Janos,
the purpose of the the API call is to configure analog filters, and not the
sampling rate. If your analog bandwidth is lower than the sampling rate,
there's nothing wrong with that. In fact, for the AD9361-based devices,
this is not unusual, since the analog bandwidth is 56 MHz, but the max
Make sure the driver is running:
$ lsmod | grep niusrp
niusrpriok421888 0
nistreamk 139264 2 niusrpriok,NiRioSrv
nibds 57344 2 niusrpriok,NiRioSrv
nikal 118784 4 niusrpriok,nibds,NiRioSrv,nistreamk
If not, check the output of niusrprio_
Armin,
I'd like to learn a little more about this failure. Here's a couple of
questions:
- How many USRPs are you running at once? Does this also happen with a
single USRP?
- Does this also happen when using a vanilla UHD example? Since you're
running a custom RFNOC block, it would be good to elim
This pokes a register in the STC3. It'll pull the FPGA into reset. You then
need to wait a bit before the FPGA is back up.
-- M
On Fri, Feb 22, 2019 at 10:21 AM Brian Padalino via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On Wed, Feb 20, 2019 at 7:45 PM Jonathon Pendlum <
> jonathon.pend
You can feed the OctoClock from the X310, and then use the OctoClock's
output to drive the N210. All devices will be synchronized, in frequency,
and the N210s will be synchronized in time, but the X310 and N210s will not
be synchronized in time. However, that timing offset you might able to
calibra
Rob,
yes, you can query UHD_RFNOC_FOUND. Check out this example:
https://github.com/EttusResearch/gr-ettus/blob/dcb780b77a114a265bb355fdba4f24033c3412c4/CMakeLists.txt#L138-L141
-- M
On Wed, Feb 20, 2019 at 8:52 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> I have a
On Wed, Feb 13, 2019 at 11:58:41AM -0800, Nick Foster wrote:
>Any plans to update to the latest API? Won't compile with anything after
>17.05.
UHD only works with DPDK 17.11. DPDK changes APIs quite often, so we've
decided to lock it down.
-- M
>
>On Wed, Feb 13, 2019, 11:33 AM Micha
That is correct, and that will also allow you to run said example.
-- Martin
On Thu, Jan 10, 2019 at 10:27 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:
> It works by setting tx-blockid to 0/Radio_0 and tx-chan to 1. I think
> there is only one radio in E312 but two chann
Emanuel,
the TwinRX only works with 200e6 clock rate. The analog filtering is not
designed for other rates. So if you have even one TwinRX, you need 200e6.
I'll make sure we update our manual to clarify that.
-- M
On Fri, Jan 11, 2019 at 4:51 AM Emanuel via USRP-users <
usrp-users@lists.ettus.co
Varala,
you only need to add a logging backend if you want the log message to go
somewhere other than stderr or a log file.
The 'console logger' means 'stderr'. So, just grab your stderr output if
you want to have those log messages. You can control the console log level
with the UHD_LOG_LEVEL an
You have two options:
1. Burst both TX and RX. To do that, you call send() on the TX streamer
with the EOB flag set in the metadata, and you use issue_stream_command()
on the RX streamer to request fixed number of samples. In both cases, you
would also provide a timestamp.
2. Permanently RX, and
Tobias,
you would provide multiple addrs in the device args (e.g.,
addr0=192.168.40.2,addr1=192.168.40.3) but you would have a single device3
block.
-- M
On Tue, Oct 30, 2018 at 6:07 AM Mitterer, Tobias via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
>
>
> We couldn’t find any ex
I would recommend not modifying the radio, but to add an RFNoC block of
your own. Take a look at our RFNoC resources on the Knowledge Base (
kb.ettus.com).
-- M
On Thu, Nov 1, 2018 at 6:46 AM carry chen via USRP-users <
usrp-users@lists.ettus.com> wrote:
> hi,
> this days I make some modify in
On Wed, Oct 24, 2018 at 3:02 PM EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi All,
>
> I've been working with the N3xx series for a week or so and I've hit a few
> issues in the "operational" side of things that are either not addressed in
> the manual or work differently tha
Note that we are working on a revised filesystem for E310 which we
anticipate to ship around the end of the year; it will include a much more
recent kernel and gcc version.
-- M
On Fri, Nov 2, 2018 at 12:52 PM Philip Balister via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 11/01/2018 04
Thanks for reporting this back to us! I'm glad this resolved your issues.
-- M
On Fri, Nov 2, 2018 at 2:16 PM Ali Dormiani via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I can second Daniel. Mr. West has troubleshooted our N310's and came to
> the same conclusion. Our N310 units (hardware
Dear friends and fans of software defined radio and free/open source
radio topics in general,
next year's FOSDEM (the free and open source developer's meeting in
Brussels, Europe) will, once again, feature a track on Software Defined
Radio and other radio-related topics. To better capture the broa
You can do this, as long as you have 2 separate streamers. The master
clock rate will be the same on both, so you can only have different
decimations/interpolations. For example, you could have 10 Msps on one
and 20 Msps on the other if your MCR is 200 MHz (which is the default).
-- M
On 09/07/20
On Wed, Sep 05, 2018 at 11:01:18AM -0400, Marcus D. Leech wrote:
> I also tried benchmark_rate. In random mode, I have no overflow in sc8,
> but in sc16 I have lots of overflows and error messages. Without the
> random mode, I can go up to 36MS/s in sc16, and 56MS/s in sc12! So for
>
/Xilinx/. Although I have modified
>uhd-fpga/usrp3/tools/scripts/setupenv_base.sh for path to VIvado, 'make
>xsim' doesn't seem to touch it when running.
Did you try running setup_env.sh --vivado-path=?
-- M
>Tien
>On Fri, Feb 9, 2018 at 11:05 AM, Marti
On Fri, Aug 17, 2018 at 01:02:28PM -0400, Daryl Lee via USRP-users wrote:
> In November of 2016, I cross-compiled UHD (git-cloned) on my Ubuntu 16.04
> development host targeting a Zynq chip with Linux built with Petalinux
> 2016.3. Life has passed me by and now I need to re-build the library usin
On Fri, Aug 17, 2018 at 03:53:56PM -0700, Andrew Danowitz via USRP-users wrote:
> Hi,
> I generated an rfnoc fpga image using the latest UHD-fpga tools on the
> rfnoc-devel branch. When I go to run it with the latest UHD on the
> rfnoc-devel branch, I get RuntimeError: RuntimeError: FPGA component
On Fri, Aug 31, 2018 at 10:14:27AM -0400, Marcus D. Leech via USRP-users wrote:
> On 08/31/2018 09:26 AM, Flo A. via USRP-users wrote:
> >Hei!
> >
> >I have a very general question regarding the function of the digital mixer
> >as part of the USRP motherboard-DDC:
> >
> >Since the RF signal is alre
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 m
On 09/03/2018 08:21 PM, Chintan Patel via USRP-users wrote:
> Hello,
>
> I have defined a new readback register in the FPGA in the b205_core
> file, adjacent to the lock state register. What is the least invasive
> function call/method in the UHD driver/software to be able to read this
> newly def
On 09/03/2018 07:50 PM, Marcus D. Leech via USRP-users wrote:
> On 09/03/2018 12:15 AM, Marcus D. Leech via USRP-users wrote:
>> On 09/03/2018 12:11 AM, RizThon wrote:
>>> Thanks, I'll try to run it on some intel hardware ("Ettus Research
>>> recommends using the Intel Series 7, 8, and 9 USB contro
Andreas,
you *should* be able to use the .bit file. Does this happen when you
build from master branch? The Vivado version is correct.
-- M
On 08/23/2018 02:11 AM, Sylvain Munaut via USRP-users wrote:
> Hi,
>
>> Just for curiosity:
>> The .bit-file is exactly the same as the .bin-file, except t
On 08/24/2018 10:14 AM, Tom McDermott via USRP-users wrote:
> I installed and built gnuradio and UHD some time ago from the SBRAC script.
>
> I am at the head of gnuradio maint-3.7, and am on uhd maint. My
> version of uhd is 3.10.2.0 and my FPGA
> images are also 3.10.2. There appears to be 3
ow
> as soon as we have a fix.
>
> Regards,
> Michael
>
>
> On Wed, Aug 15, 2018 at 3:52 PM, Martin Braun via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> On 08/09/2018 02:31 PM, Rob Kossler via USRP-users wrote:
> > When I first start
On 08/09/2018 08:50 AM, Philip Balister via USRP-users wrote:
> On 08/08/2018 11:49 PM, Walter Maguire via USRP-users wrote:
>> Hi all,
>>
>> The readme file at https://github.com/EttusResearch/meta-ettus seems to
>> be out of date with the current sumo release of poky. meta-ettus seems
>> to requi
On 08/09/2018 02:31 PM, Rob Kossler via USRP-users wrote:
> When I first started using MPM 3.13, I was pleased to see the fast
> initialization times compared to previous versions. Now, after spending
> the better part of a couple of days troubleshooting issues, I am much
> less thrilled with this
The actual AXI interface is pretty fast, but for all practical purposes,
if you want to stream samples, you're in the 1-2 Msps range.
You can run benchmark_rate on the device to get an idea. It will top out
at around 12.5 Msps, and you can push it a little if you use taskset to
nail it to one core
On 08/15/2018 11:46 AM, Rob Kossler via USRP-users 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]
On 08/07/2018 12:22 PM, Jay Kuhn via USRP-users wrote:
> Error: RuntimeError: FPGA component `DDC' is revision 1 and UHD supports
> revision 2. Please either upgrade the FPGA image (recommended) or
> downgrade UHD.
Jay,
this means you upgraded the FPGA, but not to the correct version. Please
make
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
On 07/31/2018 11:40 AM, Sirkin, Joshua F. via USRP-users wrote:
> Has sc8 capability been added to the X310? I know it the past it hasn't but
> this page seems to indicate sc8 is generally implemented
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html. We have an
> X310 with a
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
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
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/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
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
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,
>
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
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
;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/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
__
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
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:
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
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
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
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
> >
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
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
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
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 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
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/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/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/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
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
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
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
1 - 100 of 239 matches
Mail list logo
