Hi all,
I have the same issue. I've checked everything in different computer
(disk with particular Ubuntu 16.04 installation, PCIexpress card and
PCIe cable) and everything worked fine.
What was left was that caused the issue was particular
motherboard+processor. I don't know if it is just this o
Hi again,
In addition to the previous post: in one of the posts about this issue
(there are many, but without solution) I've found result of lspci.
It was in the post titled "X310 PCIe Error enumerating NI-RIO devices":
00:00.0 Host bridge: Intel Corporation Device 591f (rev 05)
00:01.0 PCI brid
I've attached the makefiles of the IPs and the other subdirectories in the
rfnoc folder.
Thanks,
Kirsten
From: EJ Kreinar
Sent: Monday, July 22, 2019 6:36:27 PM
To: Kirsten S Leong
Subject: Re: RFNoC OOT Issues
Okay sounds good.
Rfnoc devel branch should be
Hi Scott,
The CORDIC Xilinx IP is breaking timing. The CORDIC's bit width could be
better optimized, but changing it would require editing of other parts of
the code too.
One simple thing you could try is hand editing
fpga/usrp3/top/x300/rfnoc_ce_auto_inst_x310.v and changing
noc_block_schmidl_co
Sounds good. I'll allow others to comment on the GNURadio side of things.
Let me know if you have any specific HW concerns and I can chime in.
-Daniel
On Mon, Jul 22, 2019 at 5:17 PM m2wagner via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
>
> Hey Daniel,
>
> Right now I'm setting an exter
I havent seen anything too egregious inspecting the files you sent.
A few debugging ideas...
- Are you able to run the simulation testbench correctly for
noc_block_fmdemod?
- I didnt see your file that corresponds with the ip/Makefile.inc (
https://github.com/ejk43/rfnoc-ootexample/blob/master/rfn
Do you need anything from my side of things?
From: Nate Temple
Sent: Thursday, July 18, 2019 3:49 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-users] E320 unable to lock to external reference
Hi Jason,
This might be a bug with the E320. I will
Hi Jason,
I've been able to recreate this and have filed an issue on our internal bug
tracker and escalated as a high priority issue. I'm not able to provide any
ETA on when we will have a fix for it, but hope it will be soon.
I will follow up as soon as I have more information.
Regards,
Nate Te
Thank you Nate. Good to hear that it wasn't a screw up on our part. Do you
have a gut as to whether or not it is a hardware or software issue?
From: Nate Temple
Sent: Tuesday, July 23, 2019 2:01 PM
To: Jason Matusiak
Cc: Ettus Mail List
Subject: Re: [USRP-us
Hi Zhenghao - To the best of my knowledge and memory, all of the examples
provided by UHD and GR are just single-channel. My guess is you'll need to
create your own custom flowgraph to handle 2 output channels from a single
input file. That said, if what you hope to do is the equivalent of
"tx_
Hi Jason,
I'm fairly confident that this is just a software issue.
Regards,
Nate Temple
On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:
> Thank you Nate. Good to hear that it wasn't a screw up on our part. Do
> you have a gut as to whether or not it is
In GNU Radio, there is a dual channel B210 example flow graph in the DTV
component. The file is:
/share/gnuradio/examples/dtv/vv018-miso.grc
The download location of the test input file can be found in the README.
/share/gnuradio/examples/dtv/README.dvbt2
It sends an Alamouti coded MISO (Mult
Hi Michael,
Thank you very much for your message. As you said, I am just trying to
get the equivalent of "tx_samples_from_file." I will just need to
pushing half of the data in the file to each antenna. I will look into
the cpp file you pointed me to.
Over 10 years ago, I spent one summer on the
If you're connected over a 10GbE link, make sure to set your host's MTU
appropriately. I set mine to 9000.
Sam Reiter
SDR Support Engineer
Ettus Research
On Fri, Jul 19, 2019 at 2:21 AM 汤 飞 via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi, all,
>
> When benchmarking my N310, I keep gett
When you plug in either link, do you see the LEDs on the SFP ports
illuminate? You may have bricked the X310 if these ports are unresponsive.
Here's a *discovery* guide that might be helpful:
https://kb.ettus.com/Troubleshooting_X300/X310_Device_Discovery_Issues
Here's a *recovery* guide if that
It’s a 1g SFP0 link. I set MTU to 8000 according to the Application Note.
发件人: Sam Reiter
发送时间: Wednesday, July 24, 2019 4:56:21 AM
收件人: 汤 飞
抄送: usrp-users@lists.ettus.com
主题: Re: [USRP-users] N310 "Bad CHDR or packet fragment" Problem
If you're connected ove
Some Ethernet 1g controllers won’t actually do MTUs greater than 1500 despite
ethnology telling them to. Some Realtek for example.
If it’s just 1G try default MTU of 1500 and work your way up to see where it
fails.
Sent from my iPhone
> On Jul 23, 2019, at 7:15 PM, 汤 飞 via USRP-users
> wro
Actually my pc’s Ethernet card chip is from Realtek.
I’ve tried all possible MTU sizes of auto, 1000, 1500, 2000, and up to 9000.
Always the same errors.
Is it the inherent problem with the Realtek chip?
If that, is there any workaround? eg. Changing the default Linux driver,
or the last solution,
Normally Intel controllers have better performance but even a RealTek chip
should have no problem at those data rates.
Sent from my iPhone
> On Jul 23, 2019, at 10:01 PM, 汤 飞 wrote:
>
> Actually my pc’s Ethernet card chip is from Realtek.
> I’ve tried all possible MTU sizes of auto, 1000, 1
19 matches
Mail list logo
