What does your network setup look like? Could you please provide the SFP+
card and the motherboard you are using on the host side?
Alternatively, if you are using some adapters (SFP+ to cat 6 RJ45 to
thunderbolt) please provide that as well or instead.
Thanks,
Ali
On Wed, Jun 19, 2019 at 12:21
Great additions and changes. Everything seems to be working smoothly on our
end. Realtime scheduling is an important option I forgot to enable. Future
users should use that.
On Sun, May 5, 2019 at 1:18 PM GhostOp14 wrote:
> I folks, to complete the timing set, I also just added another timer
>
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
I don't think updating the FPGA from the root of the N300 is the way to fix
this.
Use your host machine to have a normal connection to the N300 via Ethernet
management port (DHCP or static IP).
Once you have a connection that functions (uhd_find_devices executed from
host or test with 'ping'
Hello fellow N310 users. My lab has 6 N310's all operating and streaming to
a single data server (10 Gbe links).
We use GNU Radio for everything. The software is great for controlling
multiple devices with many antennas easily (highly recommended). My
experience with native C++ UHD driver
Hello GhostOp14 and USRP users,
Your oot blocks are amazing. They do exactly what we need in a clean way.
In testing, we have found that there are rare anomalies though (occur like
a rare Poisson process).
1. Sometimes the advanced file sink will create an empty file of 0 bytes.
2. Sometimes
A device name/model would help.
I'm going to explain how our USRP's (Ettus N310's) and hosts (linux
machines) are configured. The N310 has a linux running inside on the SD
card. Don't know how to configure other kinds of USRP's.
For each N310:
1. ssh into root or use screen via USB
2. cd
edu> wrote:
> I’ve seen a similar lessening of performance with 3.14.
>
> Mike
>
> Sent from my iPhone
>
> On Apr 3, 2019, at 5:56 PM, Ali Dormiani via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello everyone,
>
> I recently upgraded two
Hello everyone,
I recently upgraded two of our N310's and our host server from 3.13.1.0 to
3.14.0.0.
UHD, GNU Radio (host), FPGA, SDIMG, were all uninstalled, compiled again,
and updated/flashed/imaged appropriately.
Additionally, nothing in our set up has changed other than the version of
UHD.
Hello all,
Sorry for spreading misinformation. I frequently conflate clock and LO
incorrectly. Additionally the results I posted are for an array of multiple
N310's which definitely have different clocks.
I was taught in class that carrier frequency offset happens when an access
point (AP) and
Hello everyone,
I've spent a few hours trying to learn docker and get a N310 filesystem
with gnuradio on it.
So far no luck.
I followed the documentation:
https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_fsbuild
And got this output:
WARNING: unable to chmod /home/oe-builder/build
that UHD does not understand but gnuradio
does.
On Thu, Feb 7, 2019 at 4:43 PM Rob Kossler wrote:
> On Thu, Feb 7, 2019 at 1:36 PM Ali Dormiani via USRP-users
> wrote:
> > 1. 1.25 Ms/s would be nice but lower is ok. We are trying to sound some
> channels as a test so bandwidth is
9000. However, UHD only reads the 1500 size regardless of what is set.
>
> Any ideas?
>
>
>
> Cheers,
>
> Emanuel
>
>
>
> *Von:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *Im Auftrag
> von *Ali Dormiani via USRP-users
> *Gesendet:* Thursday,
1. 1.25 Ms/s would be nice but lower is ok. We are trying to sound some
channels as a test so bandwidth is not a big deal.
2. If gnuradio can run on the arm cpu then thats great! We already have
python files (made by gr-companion) so all we would need to do is make a
custom N310 filesystem that
em
> lies.
>
>
>
> We had to change our setup and are now using a card with the Intel chip
> again.
>
>
>
> Best regards,
>
> Emanuel
>
>
>
>
>
> *Von:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *Im Auftrag
> von *Ali Dormiani via USRP-us
> custom RFNoC image from UHD.
>
> Rob
>
>
> On Wed, Feb 6, 2019 at 5:15 PM Ali Dormiani via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello everyone,
>>
>> I'm trying to set up a few N310's in neighboring buildings. I want each
>> N31
Hello everyone,
I'm trying to set up a few N310's in neighboring buildings. I want each
N310 to be its own 4 TX transmitter.
For space and cost reasons I am putting the waveforms (in binary float32)
directly on the SD card filesystem. My goal is to have each N310 send the
waveform on loop
It seems that Linux kernel 4.11 added support for the AQC107.
https://www.phoronix.com/scan.php?page=news_item=Linux-4.11-Networking
Ubuntu 18.04 and higher has kernel 4.15 so you should be fine.
Our lab has been using this converter.
https://www.sonnettech.com/product/twin10g.html
Even
I have N310's but we don't use GPS.
Will start testing issue 4 next week and see if I can reproduce.
On Fri, Jan 25, 2019 at 2:31 PM Nate Temple via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Sam,
>
> These are all new issues that we were unaware of. I will follow up with
> you off
I tested all five of our N310's with 1.92 MS/s at the master clock of
122.88 MS/s with no issues.
64 is an even multiple so it should be fine.
Normally I would blame this kind problem on NIC or settings of said NIC
but you get good performance on higher sample rates and errors on lower
rates.
Hmm that is odd.
I run wave-forms at 1.25 MS/s with a master clock of 125 MS/s just fine.
Will try your sample rate and master clock and see if I can reproduce.
On Tue, Jan 22, 2019 at 10:31 AM Bandi Bandi via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello Marcus,
>
> This is from a
So you installed GNU radio from source but what about UHD?
Also how did you clone? dd?
I've used clones before successfully with various Debian distros but I
needed to compile both UHD and GNU radio from source (in that order).
On Mon, Jan 21, 2019 at 8:33 PM Achilleas Anastasopoulos
wrote:
everyone.
On Mon, Jan 21, 2019 at 4:08 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 01/21/2019 05:39 PM, Ali Dormiani via USRP-users wrote:
>
> * sorry typo
>
> Each of my N310's SFP+0 ports is configured as follows:
>
> MTU: 8000
&g
="addr=192.168.20.51"
On Mon, Jan 21, 2019 at 2:47 PM Martin K
wrote:
> Ali,
>
> What is your full command line for uhd_find_devices?
>
> -
> Martin Klingensmith
>
>
> On Mon, Jan 21, 2019 at 5:39 PM Ali Dormiani via USRP-users
> wrote:
> >
> > H
* sorry typo
Each of my N310's SFP+0 ports is configured as follows:
MTU: 8000
Address: 192.168.20.5x/24
On Mon, Jan 21, 2019 at 2:37 PM Ali Dormiani wrote:
> Hello everyone,
>
> I am having a strange (new) problem where my host machine can not detect
> more than one USRP at a time. I
Hello everyone,
I am having a strange (new) problem where my host machine can not detect
more than one USRP at a time. I recently re-installed everything to update
all devices to 3.13.1.0.
Each of my N310's SFP+0 ports is configured as follows:
MTU: 8000
Address: 192.168.5x/24
Where x is the
Hello everyone,
I have an application in which we will be deploying some N310's on a pier
(right next to the ocean).
The USRP's will be in a small 10x13x8 ft shack that is reasonably
weatherproofed. I say reasonably because there are gaps in the door-frame
and a small hole for passing coaxial
Hello,
I have run into this problem regularly. This problem seems to be linked
with the SD card and is not a software issue.
Try the following:
1. Cleanly format the SD card (write all 0's to it) and then use UHD to
image it. I prefer to use CCleaner and windows disk manager. It should take
an
Your time offset is in line with the time offset we are seeing in our
N310's. I think this is because TX 0, 1 is on one RF chain (with its own
local oscillator) while TX 2, 3 is on its own RF chain with a separate LO.
As far as time delay or how long it takes for the RF components to warm up
TX
>
> Twitter: @skydelsol <https://twitter.com/skydelsol>
>
> Avis : Ce message est confidentiel et protégé par le secret professionnel.
> Si vous n'êtes pas le destinataire, veuillez informer l'expéditeur par
> courriel immédiatement et effacer ce message et en détruire toute copie. /
&g
For FPGA loading I do the following:
1. connect N3xx to host through the RJ45 management port *and* USB (I have
had strange corruption issues when updating over an SFP+ port)
2. Use serial connection to assign a static IP to the RJ45
3. uhd_image_loader --args "type=n3xx"
Adding more
s D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 10/10/2018 03:08 PM, Ali Dormiani via USRP-users wrote:
>>
>> Hello,
>>
>> We have the exact same problem. My lab is waiting on some sfp+ cables so
>> in a few days I will shar
Never-mind. It was an issue unrelated to USRP. At least those searching the
mailing list in the future know now that these parts are known good.
On Tue, Oct 16, 2018 at 11:39 AM Ali Dormiani wrote:
> Hello
>
> I am having a lot of problems getting 10 Gbe SFP+ working between an N310
> and a
Hello
I am having a lot of problems getting 10 Gbe SFP+ working between an N310
and a server.
I want to isolate the problem. It seems that SFP+ is a very finicky
standard. The readme for the Intel drivers say only certain cables will
work with it.
Is an N310 running UHD 3.13.0.2 and the latest
1 Gbe Ethernet can't handle that much data. Most 1 Gbe class NIC
controllers prevent you from setting the MTU over 1500 anyway. I would be
surprised if the GUI settings in network manager actually went through. If
you type 'ifconfig' in a command console the host NIC is probably still
running at
Hello,
We have the exact same problem. My lab is waiting on some sfp+ cables so in
a few days I will share our screenshots, code, and data binary files in
order to provide this thread with a second example of this issue. For now,
all I can say is this problem is not isolated to your N310 or
The N310 SD card has a custom version of open-embedded linux on it with UHD
as well.
You could place your script and binary files in the SD card file system
itself which would resolve streaming to the N310.
The problem is the data generated has no where to go. There is 1 GB of ram
soldered on
Agreed. Our N310 does not work with usb to 1 Gbe adapters (amazon basics).
We have had success with thunderbolt 3 to 10 Gbe adapter boxes.
https://www.sonnettech.com/product/twin10g-thunderbolt3.html
On Sat, Sep 29, 2018 at 10:13 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com>
Here is my Lab's N310 experiance:
3.12 had your issue (2)
3.13.0.0 had bizarre TX behavior and lock ups that required a reboot or
re-image. Our RX noise floor was also suspiciously high.
3.13.0.1 was no better
3.13.0.2 fixed all our problems. As long as we tell linux to allocate
plenty of ram
I am not qualified to answer your specific questions but our N310 had some
bugs when using 3.13.0.0. There are a few N310 specific bug-fixes in
3.13.0.2.
## 003.013.000.002
* N3xx: Fix issue where changing the clock/time source could result in
clocks becoming unlocked
* N3xx: Improve error
I don't have a lot of experience with these USB adapters (amazon basics one
is the only one I ever tried). I think you are dropping packets because the
bandwidth test is trying to max things out (as it should). If your use case
does not need full 1 Gbe you might be fine. Our N310 (in 1 Gbe mode)
As a start please post the output of 'ifconfig' (linux command on your host
machine) or 'ipconfig /all" (windows cmd command).
Are you on 1 Gbe or 10? Please describe the entire connection chain from
the USRP to your host machine. (include any adapters you are using along
the way)
Also paste the
42 matches
Mail list logo
