Hello Leon,
Did you check to see if your custom image failed timing?
Jonathon
On Thu, May 9, 2019 at 12:12 AM zluudg via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello!
>
> I'm having some issues while trying to transmit a signal using the
> RFNoC: Radio block in Gnuradio. My block
Hello all,
I don't see why PCIe cards wont work. There are plenty of them out there
with Intel and Mellonox chips (2 QSFP+ ports per PCIe 3.0 x8 card).
Note that you need to check your host machine has the correct PCIe
revision. A lot of boards have one 3.0 x16 slot and a bunch of 2.0 x4 or x8
What does the signal look like in the time domain?
Is it driving the amplifier on the B205mini into saturation?
Brian
On Wed, May 8, 2019 at 7:57 PM Michael Deacon wrote:
> I added some attenuation. The overload is gone but the condition persists.
>
>
>
> Thanks,
>
>
>
> Mike
>
>
>
> *From:*
I see. Okay. I would like to investigate the precompiled packages back as far
as the Ettus repository has them but being new to Linux I’m ignorant about how
to use PPAs to actually get to the code I need and use it so I’ll need to do
some intensive research to find a tutorial or instructions
Thanks, Marcus.
Joe
> On May 8, 2019, at 6:41 PM, Joe Martin wrote:
>
> I see. Okay. I would like to investigate the precompiled packages back as
> far as the Ettus repository has them but being new to Linux I’m ignorant
> about how to use PPAs to actually get to the code I need and use it
I added some attenuation. The overload is gone but the condition persists.
Thanks,
Mike
From: Brian Padalino
Sent: Wednesday, May 8, 2019 4:37 PM
To: Michael Deacon
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Relationship between IQ values, gain and noise on
B205mini
On 05/08/2019 07:34 PM, Joe Martin via USRP-users wrote:
Thanks Philip, I’ll check out the precompiled versions on the link Robin
provided, to see if they go back far enough first. I tried the 3.9.0 so I’m
thinking 3.8.x might still be too recent but if none of these work perhaps I
can ask
On Wed, May 8, 2019 at 7:28 PM Michael Deacon via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
>
>
> I have a simple transmitter consisting of a file source connected to a
> USRP sink (attached image radio.png). The file contains interleaved
> floating point IQ representing a few
Thanks Philip, I’ll check out the precompiled versions on the link Robin
provided, to see if they go back far enough first. I tried the 3.9.0 so I’m
thinking 3.8.x might still be too recent but if none of these work perhaps I
can ask you to take a look for something earlier. Thanks!
Joe
>
Ah, okay, thanks! I’ll give them a try to see if it makes any difference.
Joe
> On May 8, 2019, at 3:40 PM, Robin Coxe wrote:
>
> You could try using the .deb or .rpm pre-built binaries if you're running on
> Linux. See, for instance:
>
Hello,
I'm trying to implement a burst transmitter with the B205-mini. I would
like to set it to transmit a sine wave, phase modulated wave, or arbitrary
waveform for a given duration and stop for set duration. Repeat for several
bursts and then terminate program. It is crucial that the bursts
I've got the 3.8.4 images zipfile lying around in my OE download
directory, if it helps I can put it on dropbox. I might be able to find
some older ones if needed.
Yeah, I save ancient source in case of a GPL compliance exercise :)
Philip
On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:
Also Ramazan note that even then you will still get far reduced
bandwidth as compared to N210/B210 over ethernet or USB:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/041697.html
[1]
If cutting FPGA code isn't an option but you wish to have a larger
bandwidth with the
You could try using the .deb or .rpm pre-built binaries if you're running
on Linux. See, for instance:
http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/
On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I’ve successfully built UHD v3.9.0
I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
complains that it is expecting compatibility number 11 but is receiving 6. So
I think that means I need an earlier version of UHD than 3.9.0.
On 05/08/2019 04:55 PM, Minutolo, Lorenzo (389I) via USRP-users wrote:
Hi,
I have some question about your new products.
1) What is the suggested hardware for communicating with the QSFP+ port? As I
understand this a normal 40 Gbit PCIe card won’t work.
2) Does the embedded linux system gives
Hi,
I have some question about your new products.
1) What is the suggested hardware for communicating with the QSFP+ port? As I
understand this a normal 40 Gbit PCIe card won’t work.
2) Does the embedded linux system gives any error while handling two channels
at 200Msps full duplex without
Okay, thanks, that’s what I thought but that isn’t useful for me until I find a
UHD version that can communicate with it. I’ve been trying to build older UHD
versions from 003_007_002_rc1 forward but all so far fail to build due to
compiler errors. Am up to 003_008_005_rc1 now, moving forward
Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
way to figure out what image is loaded other than asking UHD to query it
for FPGA compat number.
On Wed, May 8, 2019 at 1:04 PM Joe Martin wrote:
> I guess the proper way to ask is “Is there a way to determine what fpga
>
I guess the proper way to ask is “Is there a way to determine what fpga .bin
file is in the N210?”, since the .bit file that I loaded into the fpga is
volatile code that disappears upon power cycling to be reloaded from an EEPROM
or something, yes?
Joe
> On May 8, 2019, at 1:55 PM, Joe Martin
Hi Nick,
Thanks for the comments. Is there a way to determine what bit file is
currently in the N210? If so, how please?
Joe
> On May 8, 2019, at 1:33 PM, Nick Foster wrote:
>
> I see you got there already! If you're still having trouble, I'll see what I
> can dig up over here.
>
> On
I see you got there already! If you're still having trouble, I'll see what
I can dig up over here.
On Wed, May 8, 2019 at 12:31 PM Nick Foster wrote:
> You might be best off reverting to a UHD old enough to support the bitfile
> currently loaded on your N210. You could then bootstrap your N210
You might be best off reverting to a UHD old enough to support the bitfile
currently loaded on your N210. You could then bootstrap your N210 by using
the old UHD to load a newer FPGA image.
Otherwise, it's fairly simple to convert the binfiles (which still exist --
usrp_n210_r2_fpga.bin) to
FYI, I have created a “usrp_n210_r2_fpga.bit" file by adding the additional
header to the usrp_n210_r2_fpga.bin file, renamed it, and loaded it into the
N210’s FPGA. Will report back on the ability to install an older version of
UHD than the current version to see if the elderly N210 can be
Hi USRP Users!
Ettus Research is proud to announce the USRP N320 and USRP N321 software
defined radios (SDRs). These high-performing, stand-alone SDRs deliver
frequency coverage from 3 MHz to 6 GHz with 200 MHz of instantaneous
bandwidth per channel. With reliability and fault tolerance and the
Thanks, Robin, I’ll certainly try that!
As I mentioned, we are amenable to running this particular N210 with an old
version of UHD to gain some functionality.
> On May 8, 2019, at 12:07 PM, Robin Coxe wrote:
>
> You might want to try this:
>
You might want to try this:
https://forums.xilinx.com/t5/Configuration/Is-it-possible-to-convert-bin-file-to-bit-file-or-mcs-file/td-p/870351
but YMMV.
-Robin
On Wed, May 8, 2019 at 11:04 AM Joe Martin wrote:
> Very good, Marcus. I would greatly appreciate it.
>
> If we can get our hands on
Very good, Marcus. I would greatly appreciate it.
If we can get our hands on the “usrp_n210_r2_fpga.bit” from anywhere we could
load it and install an ancient UHD version that has the associated .bin files
for rev2 and run with that setup to have at least a minimal amount of utility
from the
On 05/08/2019 01:24 PM, Robin Coxe wrote:
Hi Joe and Jason. So, I took a walk down Memory Lane and discovered
that the N210 was first released by Ettus Research in November 2010,
which was about 6 months after we were acquired by National Instruments.
It is a true statement that v2 of the
On 05/08/2019 01:24 PM, Robin Coxe wrote:
Hi Joe and Jason. So, I took a walk down Memory Lane and discovered
that the N210 was first released by Ettus Research in November 2010,
which was about 6 months after we were acquired by National Instruments.
It is a true statement that v2 of the
Hi Joe and Jason. So, I took a walk down Memory Lane and discovered that
the N210 was first released by Ettus Research in November 2010, which was
about 6 months after we were acquired by National Instruments.
It is a true statement that v2 of the hardware is quite geriatric and no
longer
On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
Wow, okay; that’s disheartening. Thanks much for the info, Jason.
Nope, the Rev3 bit file doesn’t work; tried it. I’ll see if the
support email adr can be of use.
Joe
There was a hardware change, as I recall, between Rev2 and Rev3
R3 didn't work for me either. I am not sure I would even bother with the
support email, I think they tried hard for me last year and they couldn't
revive that rev's source code at all. We abandoned our r2 Ns and just worked
on the ones that were already working.
Wow, okay; that’s disheartening. Thanks much for the info, Jason. Nope, the
Rev3 bit file doesn’t work; tried it. I’ll see if the support email adr can be
of use.
Joe
> On May 8, 2019, at 10:44 AM, Jason Matusiak
> wrote:
>
> Joe, I think you might be SOL. If you take a look at this
Have you simulated your RFNoC CEs with Verilog testbenches?
On Wed, May 8, 2019 at 8:12 AM zluudg via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello!
>
> I'm having some issues while trying to transmit a signal using the
> RFNoC: Radio block in Gnuradio. My block diagram is:
>
>
>
Apologies, the instruction document I’m following is “USRP_Hardware Driver and
USRP Manual: USDRP2 and N2x0 Series” not what is mentioned below.
Joe
> On May 8, 2019, at 9:11 AM, Joe Martin wrote:
>
> I am trying to bring an elderly N210 r2.0 with unknown history to life by
> loading current
Hello!
I'm having some issues while trying to transmit a signal using the
RFNoC: Radio block in Gnuradio. My block diagram is:
Signal Source (constant) -> RFNoC: DmaFIFO -> RFNoC: Radio (in
TX mode).
I run the block diagram by calling "python top_block.py" from the
command line
See here: https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
From: USRP-users on behalf of Ramazan
Çetin via USRP-users
Sent: Wednesday, May 8, 2019 8:02 AM
To: Ettus Research Support; usrp-users@lists.ettus.com
Subject: [USRP-users] Running
On Wed, May 8, 2019 at 5:43 AM Marwa Boukhari via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> I want to send and receive a Signal at the frequency 900MHz with the
> Channel 0 , and want to receive another Signal from the generator at the
> frequency 5,68GHz with the other channel.
>
Hello,
We want to run USRP E310 in network mode. I think the samples coming
from FPGA passing through CPU before sending to network. This decreases
bandwidth because of CPU limitations.
So, is there any ettus image or suggestions that we can run E310
directly from FPGA to network without
Hi,
I want to send and receive a Signal at the frequency 900MHz with the
Channel 0 , and want to receive another Signal from the generator at the
frequency 5,68GHz with the other channel.
I tried to realize this but it didn't work.
Has someone maybe an idea what's the problem is.
Thanks.
Hello everyone,
I have a NI USRP 2954 and when i am trying to
connect it with my Laptop, with a working Ethernet cable,in the "network
connections" window i notice that the Ethernet connection status stands at:
"Network cable unplugged".
Can someone help me sort this
42 matches
Mail list logo
