Hi Simon,
No, the USB cable will only provide serial access.
You could use GNU Radio to stream samples via ZMQ/TCP/UDP sockets. You
could also use pure C++/UHD API to stream via a UDP interface such as with
the example program rx_samples_to_udp.
Regards,
Nate Temple
On Mon, Feb 24, 2020 at 11:1
Hi Simon,
The E310 network mode was removed from UHD with the switch to the MPM based
file systems. If you need to use the network mode, you should use an older
version of UHD.
Regards,
Nate Temple
On Mon, Feb 24, 2020 at 11:05 AM Simon G4ELI via USRP-users <
usrp-users@lists.ettus.com> wrote:
Hi Jeff,
Yes, it will change the process slightly, you will no longer need to do a
--recursive clone of the UHD repo (to pull in the FPGA repo submodule).
We will be updating the applications notes to be in sync with 4.0/master
soon.
Regards,
Nate Temple
On Wed, Feb 5, 2020 at 11:42 AM Jeff S v
Hi Austin,
>Is there a way to do it directly via the jtag and using the screen command
to speak with the N310?
You could connect to the ARM via JTAG as detailed in the link below, but
you're better off just SSH'ing into it.
https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Conn
Hi Austin,
The MTUs on your host and N310 must match. You should modify the systemd
configuration on the N310 are restart the whole device or restart
systemd-networkd
https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations
It is not recommended to
ctly. Suppose
> I have a system with 8 channels with X310+TwinRX and shared LO. Can I turn
> it off and come back the next day and still have the same phase offset
> between the channels that I had the day before?
>
> Sammy
>
> Nate Temple via USRP-users schrieb am Mo.,
>
Hi Rob,
Thanks for trying your setup with 3.15.0.0.
I will see what I can do about getting these fixes backported to 3.14, any
changes will need to be on the UHD-3.14 branch (the maint branch for 3.14),
we won't be able to apply these changes to 3.14.1.1, as it's a tagged
release.
Regards,
Nate
Hi Rob,
One other thing, if you're not on UHD v3.15.0.0, I'd recommend to update to
it. There was some phase reset and accumulator fixes with 3.15.0.0.
https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/CHANGELOG#L44
Regards,
Nate Temple
On Mon, Jan 27, 2020 at 11:17 AM Nate Temple wrote:
Hi Rob,
You should always use a tune request with a timed command when you want to
align channels.
One thing you could test is to try using the internal LO and see if you get
different results.
Also you could try using the integer N tuning mode, but I don't think it
will make any difference for
Hi Rob, Robert, Sammy:
Generally for this type of application we would recommend the X310+TwinRx.
With the TwinRX, you'll be able to have repeatable phase offsets with a
given gain, frequency, sample rate and temperature of a device/system. The
N310 will have a 180 degree phase ambiguity due to th
I meant to include this link with regards to the same rates in my previous
email:
https://files.ettus.com/manual_archive/v3.15.0.0/html/page_general.html#general_sampleratenotes
On Fri, Jan 10, 2020 at 10:40 AM Nate Temple wrote:
> Hi Richard,
>
> To clarify, are you using a common Octoclock, wi
Hi Richard,
To clarify, are you using a common Octoclock, with the 3 X300's in the same
location, or separate locations with 3x Octoclocks? Do you have equal
length cables to the antennas and does the rest of the system match ?
What is your RX frequency ?
What daughterboard are you using?
You m
There was recently a change to the directory structure for the E300/E310s.
If you're running 3.15.0.0, this should be fixed, see the commits from ~Nov
21 here:
https://github.com/EttusResearch/fpga/commits/v3.15.0.0/usrp3
Regards,
Nate Temple
On Fri, Jan 3, 2020 at 11:17 AM Marcus Müller via US
Hi,
Just wanted to send the list a quick note that we have added an archive of
UHD manuals for all previous UHD versions, which can be found here [0].
These can be useful for reference if you're using an older version of UHD,
as the main manual [1] is built off of the master branch.
[0] - https:/
Hi Padorin,
Yes the B210 supports 2x2 @ 30.72e6, but is dependent upon your host system
and USB controllers.
You can try using sc12 OTW format which may help:
./benchmark_rate --rx_otw sc12 --tx_otw sc12 ..
Also ensure you've set your CPU governor to performance, and enabled thread
prioirty
On Wed, Dec 11, 2019 at 9:33 AM Nate Temple wrote:
> Hi Thomas,
>
> You will need to apply these changes below to the
> fpga-src/usrp3/top/x300/rfnoc_ce_default_inst_x310.v file. This will add
> additional SRAM FIFOs, which is basically what the "XGS" / SRAM image is.
> Make sure to start with th
Hi Thomas,
One option instead of using the Replay block could be to stream 2x 200e6
from your host.
On the X310, this requires using a SRAM image and DPDK. DPDK support was
added with UHD 3.14.1.0 for the X310, I'd suggest to use 3.14.1.1 at this
time though.
Some links on DPDK:
https://www.dpd
Hi Robert,
This patch/line change detailed below should resolve that issue and will be
included in the official 3.15.0.0 release:
---
usrp3/lib/rfnoc/noc_shell.v | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/usrp3/lib/rfnoc/noc_shell.v b/usrp3/lib/rfnoc/noc_shell.v
index 92
Hi Robert,
So this is a bug related to Vivado, you will need to install this linked
below patch and it should resolve it.
https://www.xilinx.com/support/answers/71898.html
Regards,
Nate Temple
On Mon, Dec 9, 2019 at 10:38 AM Nate Temple wrote:
> Hi Robert,
>
> Thanks for the bug report.
>
> I
Hi Robert,
Thanks for the bug report.
If you're just trying to use RFNoC at this point, I would recommend to
stick with the latest stable release, which at this time is v3.14.1.1.
Note, 3.14.x.x UHD will require Vivado 2017.4.
Regards,
Nate Temple
On Mon, Dec 9, 2019 at 7:33 AM Robert via USR
Hi Luke,
There is an example of setting timed commands in a custom block for the
TwinRX in gr-doa here:
https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L101-L121
You can do this with the standard UHD source/sink blocks, by first making
your flowgraph, then genera
Hi Luke,
What version of UHD are you using?
There was an issue with the DUC/DDC phase accumulator's resolution, but it
was fixed with UHD 3.14.1.0.
The threads below are were this was identified:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059914.html
http://lists.ettus
Hi Michael,
Please see this app note which covers cross compiling UHD/GR/gr-ettus.
You can treat your OOT the same as gr-ettus.
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#SDK_Setup
https://kb.ettus.com/Software_Development_
Hi Z. Cao,
What version of UHD are you running on your old E310?
Generally the max sample rate supported by the ARM is ~10 MS/s.
With regards to the sample rate error you saw when trying to run at 40
MS/s, try adding the device args: "master_clock_rate=40e6".
>Does RFNoC included in the default
Hi Bisma,
You should download the FPGA images for your installed version of UHD (with
uhd_images_downloader) and then write a new FPGA image to the E320 using
the uhd_image_loader utility.
UHD will work on Ubuntu 19.x.
Regards,
Nate Temple
On Wed, Nov 6, 2019 at 2:38 AM Bisma Amjad via USRP-use
Hi Voonna,
What is your CPU frequency?
What kind of NIC are you using?
If your NIC supports DPDK, I would recommend trying to use the DPDK
transport, but you will need to update to UHD 3.14.1.1 to support DPDK with
the X310.
https://files.ettus.com/manual/page_dpdk.html
Regards,
Nate Temple
Hi Jorn,
The process for installing Xilinx Vivado WebPACK is fairly easy.
Download "Vivado Design Suite - HLx Editions - 2017.4 Full Product
Installation" from here:
https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/archive.html
Decompress the
Hi Jeff,
That application note has not yet been posted. We hope to have it posted
soon. I've removed that section from the existing app note for now.
The main takeaways are that you should expect about half the performance as
running on bare metal when running a VM. If you're running with a B2xx
Hi,
Do you get the same result if you run the included (compiled/default)
version of rx_samples_to_file at a lower sample rate, such as:
/usr/local/lib/uhd/examples/rx_samples_to_file --args "addr=192.168.60.2"
--duration 10 --rate 1e6 --freq 100e6 --gain 10 --subdev "A:0" --file
test.sc16
What
Hi Anabel,
What parameters are you using with the rx_samples_to_file example?
Regards,
Nate Temple
On Mon, Nov 11, 2019 at 3:02 AM Anabel Almodovar via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> I am trying to make a continuous acquisition with an ettus x310 card whose
> daugh
Hi Adnan,
Sorry for the delay in response, this email fell through the cracks. Is
this still an outstanding issue for you?
Regards,
Nate Temple
On Wed, Sep 11, 2019 at 8:33 AM Quadri,Adnan via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> We were working on the Schimdl Cox and OF
Hi Jane,
What host OS are you using? What version of DPDK do you have installed?
Can you try using the latest stable release, UHD 3.14.1.1, master can be
unstable.
Regards,
Nate Temple
On Sun, Oct 27, 2019 at 10:24 AM Jane Zhang via USRP-users <
usrp-users@lists.ettus.com> wrote:
> hello, i a
Hi Rodolphe,
It is only possible to have one application "claim" the USRP at any given
time. So two instances of OAI can not run on the same device.
The max sample rate (using sc16) on 1Gb is ~ 25 MS/s. The max sample rate
(on X310) is 200 MS/s for a 10Gb link. If you have two RF DBs in a single
We are very close to releasing UHD 3.15.x.x which is going to include an
updated file system based on thud for all of the embedded USRPs (N3xx,
E320, E310). We have also been working on improving the build system and
will have a file system option that includes GNU Radio for all the embedded
devic
Hi Wangpan,
You had contacted us directly via supp...@ettus.com on this same issue,
let's continue to debug through that channel and when the issue is
resolved, I can update the mailing list with the result.
Regards,
Nate Temple
On Thu, Oct 17, 2019 at 4:55 AM 王盼 via USRP-users <
usrp-users@lis
Hi Carl,
USRP support was added with the r1595 build to SDR#.
You can most likely listen to a trunking system with a single USRP (haven't
tried it myself) as it'll have enough bandwidth to cover both the control
and voice channels.
Regards,
Nate Temple
On Tue, Oct 15, 2019 at 12:18 PM Carl MacG
Hi Daniel,
The uhd.conf file should be put at /root/.uhd/uhd.conf
You will also need to run the UHD app as root when using DPDK.
I can follow up with you offlist with some additional notes I have on
getting started with DPDK. We will be publishing a detailed app note soon
to cover the topic.
Re
Hi Jon,
If you are following this app note [0], I would recommend starting with the
release-4 image. The pre-3.15 MPM based image that has been released is
currently a "beta" release. It lacks several of the dependencies required
to build out GNU Radio. We are working on a new release and hope to
Hi David,
Can you try loading the XQ FPGA image onto the N320? When using the XG
image, only the onboard SFP 0,1 adapters are used. When using the XQ image,
two lanes of the QSFP will be used (0,1). A table showing what protocols /
ports per FPGA image can be found here [0].
[0] -
https://files.e
sers@lists.ettus.com>
> *Subject:* Re: [USRP-users] E320 unable to lock to external reference
>
> We have someone looking into this now. In the meantime, try adding the
> device arguments "clock_source=external,time_source=external".
>
> Regards,
> Michael
>
&
Hi Rob,
The N3xx (and E3xx) only support having an FFT size up to 512 due to the
page size. It'd be possible to modify the blocks to break up the FFT over
several packets but it is not currently implemented. The X310 as is
supports up to a 1024 point FFT.
Regards,
Nate Temple
On Mon, Sep 9, 2019
Hi Daniel,
As Marcus mentioned, an i3 is not ideal for streaming at such high rates.
For 200 MS/s of usable bandwidth, you'll need to stream at 250 MS/s per
channel.
A colleague has ran 2x2 @ 250 MS/s using an Intel Xeon E5-1620 v3 @
3.50GHz, and I've ran at those rates with an i9-9900x @ 4.4 G
Hi David,
The N320 has a discrete component daughterboard and does not support
setting a bandwidth filter.
The RFIC based USRPs such as the B2xx, E31x, E320 (AD9361) and N300/N310
(AD9371) support the set_rx_bandwidth API call.
Regards,
Nate Temple
On Fri, Sep 6, 2019 at 4:55 AM Truan David via
Hi Emanuel,
What ethernet controller is installed on your NUC?
lspci | grep Ethernet
Can you try rebooting the NUC, and then run a benchmark to trigger the
sequence errors, after that run:
ethtool -S
and send its output.
Regards,
Nate Temple
On Tue, Sep 3, 2019 at 1:35 AM Emanuel via USRP-
Hi Fengyang,
These are calls to the UHD API within your application.
There are several examples here [0] of using the UHD API. I would encourage
you to checkout specifically these examples [1],[2] as a starting point.
Additionally there is this app note [3] which shows how to get started with
the
Hi,
We've pushed updated flowgraphs into gr-ettus for the networked fosphor
example to fix the FIFO select and QT display issues. There is a few more
minor things fixed in them but can you please give them and try on your
system? I will try to replicate the siggen issue you ran into.
Regards,
Na
Hi Mauricio,
You could modify the rx_ascii_art_drf util if you wanted, the source is
here[0]. There is also the Python version here[1]. There is also a GNU
radio OOT, gr-specest that I would recommend to checkout [2]. I would also
encourage you to look at the rx_tool utility which can be found he
Hi,
I hope to have the E310 version posted tomorrow. Don't have a firm timeline
for the E320/N3xx version yet.
The process is mostly the same, except you should not use rfnoc-devel, but
instead use a modern UHD version such as v3.14.1.0, and then during the
cmake configuration step, pass the arg
Hi,
That application note is specific to the E310. Are you using the E320 SDK?
Did you source the OE environment setup file? (What is the output of echo
$CC)?
Also that app note is outdated, and I will be posted an updated version
soon. Another app note that covers the E320/N3xx will follow.
Reg
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
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
Hi Taylor,
The behavior of UHD selecting the antenna port for the LF/Basic boards
changed a few releases ago on the X3xx. Instead of setting a subdev spec,
you use the antenna port with the name.
https://files.ettus.com/manual/page_dboards.html#dboards_basicrx
Within the UHD Source/Sink blocks y
The RFNoC Replay block would be a good starting point, if you want to do
this all in the FPGA.
On Thu, Jul 18, 2019 at 2:04 PM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
> At the very benign 20 MS/s, I'd really say your first option is the way
> to go. The rest probably won
Hi Jason,
This might be a bug with the E320. I will need to try to recreate this
issue. I'll follow up as soon as I have more info.
Regards,
Nate Temple
On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:
> OK, we've been fighting this for a while
Hi Serge,
We are aware of this issue and have an open issue on our internal bug
tracker for it. We currently do not have any work around and hope to have a
fix for it soon.
Regards,
Nate Temple
On Thu, Jul 18, 2019 at 10:53 AM Serge Malo via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi
>
> On July 18, 2019 7:00:01 PM GMT+02:00, Nate Temple via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>>
>> Hi Andreas,
>>
>> The errors you see when loading the idle FPGA can be safely ignored and
>> are fixed in the new MPM based file system.
>&g
Hi Andreas,
The errors you see when loading the idle FPGA can be safely ignored and are
fixed in the new MPM based file system.
We have a pending update for that application note that uses modern UHD
that will be posted soon. I can follow up with you off list with the
instructions for now.
Regar
Hi Sumit,
What ethernet controller do you have in your laptop?
lspci | grep Ethernet
Regards,
Nate Temple
On Wed, Jul 17, 2019 at 9:16 AM Sumit Kumar wrote:
> Hi Nate,
>
> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
> ./benchmark_rate --rx_rate 10e6 --tx_rate 10e6 --
Hi Sumit,
Actually, I had a typo in the command, that previous benchmark_rate command
only tested RX, can you try passing the --tx_rate param and see if it will
produce sequence errors using benchmark_rate
./benchmark_rate --tx_rate 10e6 --duration 600
Regards,
Nate Temple
On Wed, Jul 17, 2019
Hi Sumit,
So it looks like you have multiple version of UHD installed:
john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
sudo ./benchmark_tx.py -f 2.45G -S 10
linux; GNU C++ version 5.3.1 20151219; Boost_105800;
UHD_003.009.002-0-unknown
john@john-Precision-M4600:
Hi Sumit,
It will take 10 minutes for that run to complete. Does it produce a report
at the end of the run?
Regards,
Nate Temple
On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar wrote:
> Hi Nate,
> No there are not. At the end of the last line, cursor keeps blinking, no
> sequence errors.
>
> john@
Hi Sumit,
If you run benchmark_rate for an extend period of time, do you see any
sequence errors?
/usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 --duration 600
Regards,
Nate Temple
On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar wrote:
> Hi Nate,
> Yes I addressed the first 2 points y
Hi Sumit,
A couple things to address:
1) Enable Thread priority scheduling on your host
Note it is throwing a warning in the output: "[WARNING] [UHD] Unable to set
the thread priority. Performance may be negatively affected."
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Too
Hi Alex,
The S is for a sequence error, which are generally a bad thing to observe.
What version of UHD are you using?
Do you have the N210 directly connected to your host? Do you have any other
networking gear in between (switch/router/hubs?)
What NIC do you have on your host machine?
Rega
Hi Jessica,
What sample rate are you trying to run at per channel?
I would suggest to use DPDK as it will remove a considerable overhead from
the Linux networking stack.
I can follow up with you off the list with some notes I have on getting
DPDK going, we have a pending app note that will be pu
Hi Jason,
I have some instructions I will send you off list for adding an additional
partition you can try. I wrote them for the E310, but have not yet tested
them on E320, however, it should be a similar process.
Regards,
Nate Temple
On Wed, Jun 19, 2019 at 9:44 AM Jason Matusiak via USRP-users
Hi Donnie,
Is your E310 a SG1 or SG3?
https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources#SD_Card_Images
Regards,
Nate Temple
On Mon, Jun 17, 2019 at 1:53 PM Donnie C via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> I'm currently trying to get the E310 to bo
Hi Nick,
This sounds like there may still be a bug in the new DDC/DUC's since the
change from CORDIC to DDSes [0]. There was a similar issue [1][2] but the
patch was merged in at 3.14.0.0 [3].
Could you try a UHD version pre-3.12.0.0 to see if it resolves the issue?
3.11.1.0 or 3.10.3.0 would be
Hi Jason,
You could try running the new 3.15 MPM based file system for the E310, but
it has some caveats, more details here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html
Regards,
Nate Temple
On Fri, Jun 7, 2019 at 12:05 PM Jason Matusiak <
ja...@gardettoengi
Hi Jason,
For what its worth, I haven't personally ran this exact combo (E310 w/ UHD
3.11 and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the
same subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into
the issue where probing in embedded mode would pickup the oth
Hi Jason,
On the E310, if you pass the device arg addr with 127.0.0.1 does it work as
expected?
uhd_usrp_probe --args "addr=127.0.0.1"
Regards,
Nate Temple
On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Darn, I was hoping that was it, but I
Hi Mark,
We just merged DPDK support for the X3xx. You can try it out if you build
the current head of master. DPDK may help with 8 channels running at 100
MS/s each.
https://github.com/EttusResearch/uhd/commits/master
https://files.ettus.com/manual/page_dpdk.html
Regards,
Nate Temple
On Wed,
Hi Chance,
What version of UHD are you using?
Could you please give the UHD branch UHD-3.10 a try with your application
to see if it makes any difference?
Regards,
Nate Temple
On Mon, Apr 8, 2019 at 8:56 AM Chance Tarver via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all,
>
> I am wo
Hi Jason,
You can disable the QT widgets (not needed on the E320 itself) by adding
the cmake flag -DENABLE_QT=OFF
Regards,
Nate Temple
On Mon, Apr 8, 2019 at 1:00 PM Nate Temple wrote:
> Hi Jason,
>
> It looks like you are missing the package: python-setuptools
>
> Note, you should not use
Hi Jason,
It looks like you are missing the package: python-setuptools
Note, you should not use rfnoc-devel, but instead use a newer version of
UHD like v3.14.0.0, and then you can enable RFNoC by adding the cmake flag
-DENABLE_RFNOC=ON
Regards,
Nate Temple
On Mon, Apr 8, 2019 at 12:34 PM Jaso
Hi Lisa,
This error usually points to a failure on the MB which requires a RMA.
If you remove your custom DB and run uhd_usrp_probe against just the MB do
you still get this error?
Regards,
Nate Temple
On Mon, Apr 8, 2019 at 9:13 AM Faller, Lisa-Marie via USRP-users <
usrp-users@lists.ettus.co
Hi Vinayak,
The INF files are only required for USB based USRPs.
If you're able to probe the device with uhd_usrp_probe.exe, you should be
good to go.
Regards,
Nate Temple
On Tue, Mar 26, 2019 at 1:58 PM VINAYAK KARANDIKAR via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello Everyone,
>
Hi Piotr,
A quick update -- we have root caused the issue and will have an update
that fixes it on the 3.14.0.0 release.
Regards,
Nate Temple
On Sat, Mar 23, 2019 at 8:14 AM Piotr Krysik via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi all,
>
> Update to the previous post. Nate Temple o
Hi Marc,
What version of UHD are you using? If you're not running with any
3.14.0.0-rcX release, can you please try v3.14.0.0-rc3 ?
Regards,
Nate Temple
On Tue, Mar 12, 2019 at 10:37 AM Marc Lichtman via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hey,
>
> I'm having issues connecting to
Hi Bob,
The _HGS images are SRAM based vs the HG image is DRAM based.
The _HGS images were removed as of UHD 3.10.x.x and you should use the _HG
image.
The _HG* images are setup for 1Gb speeds on SFP0 and 10Gb on SFP1.
The XG image is 10Gb on both SFP0 and 1.
Regards,
Nate Temple
On Mon, Mar
ng a WR-LEN in close proximity
> to the X310. Is that correct?
>
> Rob
>
> On Wed, Feb 27, 2019 at 11:45 AM Nate Temple via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Akin,
>>
>> The Octoclock-G would be suitable for this purpose, and yes, it
Hi Akin,
The Octoclock-G would be suitable for this purpose, and yes, it does
contain a GPSDO (OCXO). https://kb.ettus.com/GPSDO#GPSDO_.28OCXO.29
The Octoclock-G does not contain an antenna, you must provide one to the
GPS Antenna input (SMA).
The X3xx series do not support IEEE 1588, however, t
Hi Matthew,
We often run OAI on B2xx, X3xx and N3xx USRPs.
The best resource for getting started are OAI's getting started page and
associated wiki / tutorials.
https://www.openairinterface.org/?page_id=25
https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home
Regards,
Nate Temple
On Wed,
Hi Joshua,
Ublox has confirmed the u-blox 6 modules have been tested and there is no
issue with the 2019 GPS week number roll over event.
Regards,
Nate Temple
On Fri, Feb 15, 2019 at 2:17 PM Nate Temple wrote:
> Hi Joshua,
>
> The Jackson Labs based GPSDOs (for B2xx, X3xx and N3xx, E320) are
Hi Joshua,
The Jackson Labs based GPSDOs (for B2xx, X3xx and N3xx, E320) are all ready
for the GPS roll over event. We dont expect any issues with the JL GPSDOs
until 2028 and later. Depending upon when the units were manufactured it is
out until 2038.
I'll need to look into the Ublox on the E310
Hi Kurt,
There is work being done to convert the E310/2 to the MPM architecture, but
it is not ready for release yet.
DPDK is only supported on devices that have an additional management
interface such as the N3xx. It should work on the E320, but I have not
tested it yet. The UHD DPDK implementat
Hi Andre,
The one example I can give at this time is limited and semi-anecdotal as
I've only tested it on a single machine.
With an i7-4790k / Intel x520-DA2 and N310, to stream at full duplex, over
two channels at 125 MS/s, the lowest I can run my CPU clock freq at without
flow control errors is
Hi Robert,
Can you send the output of:
tree /sys/kernel/iommu_groups/
Do you have an external GPU installed on your system?
Regards,
Nate Temple
On Fri, Feb 8, 2019 at 9:13 AM wrote:
> Hi Nate,
>
>
>
> thanks for the quick reply. I changed the dpdk-driver and copied the
> config file to /r
Hi Robert,
Can you try adding the NIC configuration to /root/.uhd/uhd.conf instead of
/etc/uhd/uhd.conf ? You'll need to run your UHD applications as root as
well.
You will also need to change the line:
dpdk-driver=/usr/local/lib/dpdk-pmds/
to be:
dpdk-driver=/usr/lib/x86_64-linux-gnu/
You'll
Hi Andrew,
Please take note of this section of the KB with regards to FPGA
modifications: https://kb.ettus.com/X300/X310#FPGA_User_Modifications
The PCIe interface and LvFpga_Chinch_Interface cannot be modified, even if
you are not using PCIe as a transport, as it will brick the flash memory:
htt
Hi Andrew,
This is an issue we are aware of related to the RFNoC DDC/DUC blocks. We
are working on a fix and expect to have in a future release of UHD.
Regards,
Nate Temple
On Mon, Jan 28, 2019 at 10:11 AM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I have an RFNOC blo
Hi Sam,
These are all new issues that we were unaware of. I will follow up with you
off list to debug these issues through your previously sent email to
supp...@ettus.com.
Regards,
Nate Temple
On Fri, Jan 25, 2019 at 2:13 PM Samuel Prager via USRP-users <
usrp-users@lists.ettus.com> wrote:
> H
Hi Steve,
Those application notes are outdated. We are working on updating them
currently and expect to have the new versions posted soon.
I'll follow up with you off list with a set of instructions using a newer
version of UHD.
Regards,
Nate Temple
On Mon, Jan 21, 2019 at 9:43 AM Steve Clift v
Hi Luz,
You can call the api calls just as you would in C++ from the usrp object.
For example:
usrp = uhd.usrp.MultiUSRP(args.args)
usrp.set_clock_source("external")
usrp.set_time_source("external")
Regards,
Nate Temple
On Wed, Jan 16, 2019 at 2:51 PM Florez Manduca, Luz E CIV USARMY (USA
Hi Andre,
GQRX uses gr-osmosdr under the hood to interface to the USRP, the setters
and getters are there [0] to set the sources for an external ref/timing
source, but it does not parse the device arg to set them [1]. If you add
the parsing and rebuild gr-osmosdr and then GQRX, it will work.
htt
Hi Florian,
If you pass the arg "--ref external" to tx_waveforms, does it resolve this
frequency offset?
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L62
Regards,
Nate Temple
On Thu, Dec 6, 2018 at 12:22 AM Florian Kaltenberger via USRP-users <
usrp-users@lis
Hi Rob,
Thanks for bringing this to our attention. We will file an issue on our
internal bug tracker and get it resolved.
Regards,
Nate Temple
On Fri, Nov 16, 2018 at 10:41 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I am using the RFNoC radio_ctrl API with my X310 and
Hi David,
You can find the N3xx rack mount kit here:
https://www.ettus.com/product/details/n3xx-rack-mount
Regards,
Nate Temple
On Fri, Nov 16, 2018 at 8:19 AM Bengtson, David E. via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Is there a 19” Rack mount Kit for the N310 available or planne
Hi EJ,
Thanks for the detailed report. We are working on addressing these issues
and will follow up with a more detailed response soon.
Regards,
Nate Temple
On Wed, Oct 24, 2018 at 3:01 PM, EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi All,
>
> I've been working with the N
Hi Bob,
What USRP / DB are you using?
Regards,
Nate Temple
On Thu, Sep 13, 2018 at 6:53 AM, Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Running 3.13.0.0 on Windows.
>
>
>
> I have a flag in my app to enable/disable offset tuning.
>
>
>
> Application works properly an
1 - 100 of 158 matches
Mail list logo
