Hello,
I would like to know if I can use the usrp x310 as an O-RU, connected to a
CU/DU via openfronthaul interface, (split 7.2x)
Best regards
Moussa
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-l
We have 1x USRP X310 SDR connected to a server running the Linux OS. We
followed the online instructions and ran the commands below to install the
latest FPGA image on the USRP. We can PING the USRP (default addr 192.168.10.2)
from the server (added static network addr 192.168.10.1). However,
U
Dear all,
I’m using USRPs X310 with integrated GPSDO. My goal is to compare the quality
of different types of local oscillators but I’m confused with the clock
reference source parameter.
When the clock reference source is specified as “internal“ will my reference be
the internal TCXO or the G
Hi all,
We plan to use a x310 with a UBX-160 and a TwinRX to realize the system of one
TX channel and two RX channels. The TX channel is provided by UBX and the two
RX channels are provided by TwinRX. Does UHD driver support this configuration?
Best regards,
Jason
_
Hi,
I am attempting to use two USRP x310 to deploy a 5G SA networking using the
openairinterface5g open-source system. However, I am experiencing a receive
overflow error when attempting to deploy both an OAI-nrUE and OAI-gNB.
The nrUE gives an *ERROR_CODE_OVERFLOW (Overflow) *warning before fai
I have some questions regarding the operation of X310.
1) How do I know if I have an internal GPSDO (we have 20 USRPs in the Lab
and I remember we bought some of them with GPSDO). I know that when I do
"uhd_usrp_probe", a device without GPSDO says "no internal GPSDO detected"
but in the absence of
Marcus:
Yes. Thanks. As I said.
Regards,
Joe
> On Jul 14, 2020, at 8:29 AM, Marcus D Leech wrote:
>
> Joe:
>
> The input levels that cause distortion vary quite a bit from daughtercard to
> daughtercard, and even within a daughtercard there will be variability
> depending on frequency.
Joe:
The input levels that cause distortion vary quite a bit from daughtercard to
daughtercard, and even within a daughtercard there will be variability
depending on frequency.
The performance data can be consulted for this:
https://files.ettus.com/performance_data/
What you’re looking for i
Arash,
Marcus L.’s response has some definitive info in the links. For example, in
the TwinRX link it is stated:
> Never apply more than +10 dBm of power into any RF input.
So there you have it. Thanks for the details Marcus.
Regards,
Joe
> On Jul 14, 2020, at 7:55 AM, Marcus D. Leech
Arash,
While Marcus’ response is certainly correct it does little in providing a
practical answer to your question.
I use an X310 with TwinRX daughterboards and have found that it is inadvisable
to use input levels to the TwinRX daughterboard greater than -30dBm because
higher levels than t
On 07/14/2020 05:53 AM, Marcus Müller via USRP-users wrote:
Hi Arash,
The input power is not defined by the motherboard (X310) you're using,
but by the analog frontend daughterboard (like TwinRX, UBX-160, SBX,…)
you've plugged in to these.
For example, see the "Care and Handling" for the SBX h
Hi Arash,
The input power is not defined by the motherboard (X310) you're using,
but by the analog frontend daughterboard (like TwinRX, UBX-160, SBX,…)
you've plugged in to these.
On 14.07.20 11:38, Arash Jafari via USRP-users wrote:
> National Instrument congratulation!! very bad documentation.
Hello everybody,
Does anybody know what is the maximum input power level of USRP-X310 in RX
modus?
National Instrument congratulation!! very bad documentation.
Kind regards,
Arash.
--
Dipl.-Ing. Arash Jafari
Phone: +43 650 844 3617
E-mail: arash.jafari.tele...@gmail.com
_
Thank you Brian! It runs fine :)
El lun., 11 may. 2020 a las 17:08, Brian Padalino ()
escribió:
> On Mon, May 11, 2020 at 6:20 AM Carlos Alberto Ruiz Naranjo via USRP-users
> wrote:
>
>> Hello,
>>
>> I'm using the USRP X310 with CBX-120. I set the radio sample rate to
>> 184.32 MHz but I have th
On Mon, May 11, 2020 at 6:20 AM Carlos Alberto Ruiz Naranjo via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> I'm using the USRP X310 with CBX-120. I set the radio sample rate to
> 184.32 MHz but I have the following message:
>
> [WARNING] [X300 RADIO] Requesting invalid sampling ra
Hello,
I'm using the USRP X310 with CBX-120. I set the radio sample rate to 184.32
MHz but I have the following message:
[WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 184.32
MHz. Actual rate is: 200 MHz.
Isn't it possible to set it to that sample rate?
Thank you.
On 03/24/2020 12:24 AM, Lukas Haase wrote:
Hi Marcus,
I would have two possible solutions but both of them are non-trivial:
1. As you say, parallelism. For each of N supported timed commands, the
decoding of the timed commands is cloned
2. If the timed commands are enough clock cycles in the f
Hi Marcus,
> Von: "Marcus D. Leech"
> On 03/23/2020 11:53 PM, Lukas Haase wrote:
> >> Von: "Marcus D. Leech"
> >> On 03/23/2020 11:08 PM, Lukas Haase wrote:
> >>> Hi Marcus,
> Von: "Marcus D. Leech"
> On 03/13/2020 10:52 AM, Lukas Haase wrote:
> > Hi again Rob,
> >
> > Yes
On 03/23/2020 11:53 PM, Lukas Haase wrote:
Hi Marcus,
Gesendet: Montag, 23. März 2020 um 23:35 Uhr
Von: "Marcus D. Leech"
An: "Lukas Haase"
Cc: "Rob Kossler" , "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on
Hi Marcus,
> Gesendet: Montag, 23. März 2020 um 23:35 Uhr
> Von: "Marcus D. Leech"
> An: "Lukas Haase"
> Cc: "Rob Kossler" , "USRP-users@lists.ettus.com"
>
> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using
On 03/23/2020 11:08 PM, Lukas Haase wrote:
Hi Marcus,
Gesendet: Freitag, 13. März 2020 um 13:29 Uhr
Von: "Marcus D. Leech"
An: "Lukas Haase" , "Rob Kossler"
Cc: "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on
Hi Marcus,
> Gesendet: Freitag, 13. März 2020 um 13:29 Uhr
> Von: "Marcus D. Leech"
> An: "Lukas Haase" , "Rob Kossler"
> Cc: "USRP-users@lists.ettus.com"
> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a
one (tested): http://paste.ubuntu.com/p/VsGRmsbZQ5/
>>>>
>>>>
>>>> Thanks for reporting your results very interesting!
>>>>
>>>> Why do you think second mode makes sense to you? (assuming you are
>>>> using timed commands to to
_USRP_Events_Using_Timed_Commands_in_UHD) I have not read about it. Can you elaborate on this?
Thanks again,
Lukas
Gesendet: Freitag, 20. März 2020 um 13:44 Uhr
Von: "Rob Kossler"
An: "Lukas Haase" , usrp-users
Betreff: Re: [USRP-users] USRP X310 ignored DSP retunin
e at that point.
Great idea with the multiply_conjugate_cc block, I haven't thought of this yet. Thank for for sending your updated code ... I will continue with that now ...
Best,
Lukas
Gesendet: Freitag, 20. März 2020 um 12:04 Uhr
Von: "Rob Kossler"
An: "L
e things are reset when streaming starts/ends but not when
>>> re-tuning?
>>>
>>> Maybe this is what Marcus was mentioning: resetting phase accumulator
>>> vs. "increment register is updated with the new phase increment"?
>>>
>>> MAYBE
;t reset anything. But still, my question is left why
>> this would result in a random phase offset between DUC and DDC.
>>
>> Thanks again!!
>> Lukas
>>
>>
>> *Gesendet:* Donnerstag, 19. März 2020 um 19:16 Uhr
>> *Von:* "Rob Kossler"
>
ator to zero and just
> timed retuning doesn't reset anything. But still, my question is left why
> this would result in a random phase offset between DUC and DDC.
>
> Thanks again!!
> Lukas
>
>
> *Gesendet:* Donnerstag, 19. März 2020 um 19:16 Uhr
> *Von:* "Rob K
On 03/19/2020 08:16 PM, Lukas Haase via USRP-users wrote:
Hi Rob,
Sorry I really should have ran the python file before uploading. The
issue was that I combined to files into one and forgot to remove the
imported file.
Here is a new one (tested): http://paste.ubuntu.com/p/VsGRmsbZQ5/
Thanks fo
ult in a random phase offset between DUC and DDC.
Thanks again!!
Lukas
Gesendet: Donnerstag, 19. März 2020 um 19:16 Uhr
Von: "Rob Kossler"
An: "Lukas Haase"
Cc: "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when
t;>>> - It also uses a custom module together with buttons and a probe
>>>> block to call functions upon clicking on a button
>>>> - The callback functions are defined in class "blk"
>>>> - The most important is
d in class "blk"
>>> - The most important is "def button_rtx_handler" on line 106
>>> which is executed when user clicks on button "Switch RTX (together)"
>>>- Again, thank you for trying this out!! If it works, would you min
nd "rf_freq"). When
>>clicking, I jump between dsp_freq=0 and dsp_freq=500e3. As to my waveform,
>> you can infer from my screenshots and code above: I am transmitting and
>>receiving a 1MHz waveform (which acts as an additional "IF stage"). The
>&
m 1MHz to DC. I use 5 MSsps
>sampling rate.
>
>
> Again, thank you SO much.
>
> Best,
> Lukas
>
>
> *Gesendet:* Donnerstag, 19. März 2020 um 10:43 Uhr
> *Von:* "Rob Kossler"
> *An:* "Lukas Haase"
> *Cc:* "USRP-users@lists.ettus.com
Uhr
Von: "Rob Kossler"
An: "Lukas Haase"
Cc: "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command
Hi Lukas,
So, the conclusion is that your Rx0-to-Rx1 relative phase is nearly constant such that it seems
ful too.
>
> In my opinion there are two options left:
> 1.) There is still a nondeterministic delay between the TX and RX timed
> commands (to my understanding, even a constant delay would result in
> coherent phase)
> 2.) While the phase accumulators in RX are set to the same values (a
Hi Marcus,
> Gesendet: Freitag, 13. März 2020 um 13:29 Uhr
> On 03/13/2020 10:52 AM, Lukas Haase wrote:
> > Hi again Rob,
> >
> > Yes, I confirm:
> >
> > 1.) Finally I get the commands to execute at the same time (TX and RX
> > individually and both at the same time)
> > 2.) Yes, the phase is ran
alues (and in TX as well), they may be set to a different, random value.
However, I don't really know how to test these.
Thanks,
Lukas
Gesendet: Freitag, 13. März 2020 um 12:27 Uhr
Von: "Rob Kossler"
An: "Lukas Haase"
Cc: "Marcus D Leech" , "USRP-us
t;Marcus D Leech" , "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a
timed command
Also, is it true that now you can successfully tune both RF and DSP at the
desired command time (but the remaining problem is that the Rx phas
t; Luke
>
>
> Gesendet: Freitag, 13. März 2020 um 11:08 Uhr
> Von: "Rob Kossler"
> An: "Lukas Haase"
> Cc: "Marcus D Leech" , "
> USRP-users@lists.ettus.com"
> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when
Great, any ideas to simplify the setup would nice. I just don't know how I
could continue to debugging the phase.
Best,
Luke
Gesendet: Freitag, 13. März 2020 um 11:08 Uhr
Von: "Rob Kossler"
An: "Lukas Haase"
Cc: "Marcus D Leech" , "USRP-users@lists.ettus.
d the PLL retuning much more challenging than the DSP
> retuning but for some reason it seems to be the opposite...
>
> Thanks,
> Lukas
>
>
>
>
> Gesendet: Freitag, 13. März 2020 um 10:07 Uhr
> Von: "Rob Kossler"
> An: "Lukas Haase"
> Cc:
"
An: "Lukas Haase"
Cc: "Marcus D Leech" , "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a
timed command
Also, is it true that now you can successfully tune both RF and DSP at the
desired command time (
ukas Haase"
Cc: "Marcus D Leech" , "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a
timed command
Lukas,
Can you confirm the exact git hash for both UHD and the FPGA image you are
using? Perhaps the easiest way is to
e/Sink). This should ensure that stream start time is
>> set! (tested)
>> - Even if not, I also used explicitely
>>tb.uhd_usrp_source_0.set_start_time(uhd.time_spec(10))
>>tb.uhd_usrp_sink_0.set_start_time(uhd.time_spec(10))
>> at the beginning of my flow graph.
10s, as expected
> - I experimented with "tx_time" and stream tags but for some reason many
> timed I get flooded with L's
>
>
> Can it be that there is another bug lurking somewhere deep in the USRP
> firmware?
>
> Thanks,
> Lukas
>
>
>
> Gesend
omewhere deep in the USRP firmware?
Thanks,
Lukas
Gesendet: Mittwoch, 04. März 2020 um 19:27 Uhr
Von: "Marcus D Leech"
An: "Rob Kossler"
Cc: "Lukas Haase" , "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when
receiving both from "TX/RX" input of each UBX-160 would be
>>> trivial: "A:0 B:0". However, how do I address "RX2"? Intuitively "A:0 A:1
>>> B:0 B:1" but as said, both "TX/RX" and "RX2" are named "0".
>>
ever, how do I address "RX2"? Intuitively "A:0
>>> A:1 B:0 B:1" but as said, both "TX/RX" and "RX2" are named "0".
>>> What would I do if I wanted to transmit from "TX/RX" of the second UBX
>>> and receive on a
n the USRP Sink: "B:0"
>> On the USP Source intuitively: "A:0 A:1 B:1" but that's wrong.
>>
>> 3.b.) In gr, there will be two multi_usrp objects: One for the receiver
>> (member variable of USRP Source) and one for the transmitter (member
>> var
quot;A:0 A:1 B:1" but that's wrong.
>
> 3.b.) In gr, there will be two multi_usrp objects: One for the receiver
> (member variable of USRP Source) and one for the transmitter (member
> variable of USRP Sink).
> Can I set up a USRP Source that has two channels where the se
One for the receiver (member
variable of USRP Source) and one for the transmitter (member variable of USRP
Sink).
Can I set up a USRP Source that has two channels where the second one is
actually a TX channel? (only used for retuning via timed commands)?
Thanks,
Lukas
Gesendet: Dienst
ecs() %
> _metadata.time_spec.get_frac_secs());
> _metadata.has_time_spec = true;
>
>
> To my understanding, gr-uhd now passes the correct timestamps on to UHD.
> However, the timed command is still ignored.
>
>
> Thanks,
> Lukas
>
>
> PS: I will attempt to use the tagged stream ..
lso, skimming the source code for the tag
processing, I am not sure if this would change anything.
Gesendet: Dienstag, 03. März 2020 um 13:25 Uhr
Von: "Sam Reiter"
An: "Rob Kossler"
Cc: "Lukas Haase" , "USRP-users@lists.ettus.com"
Betreff: Re
t;>> in parallel do the retuning.
>>> I am not too familiar with UHD on its own but I assume this would be
>>> very complicated, require multithreading etc.
>>> Do you have any demo code that could be easily modified for this
>>> scenario?
>>>
>&
cated, require multithreading etc.
>> Do you have any demo code that could be easily modified for this scenario?
>>
>> Best,
>> Lukas
>>
>>
>> Gesendet: Dienstag, 03. März 2020 um 12:08 Uhr
>> Von: "Sam Reiter"
>> An: "Rob Kossler&
Hi Marcus,
I'm pretty sure that the DDC and DUC don't have access to the MB clock and
thus have no option but to executed timed commands using the time stamp in
the sample stream.
Rob
On Tue, Mar 3, 2020 at 12:41 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 03/03/20
>
> Gesendet: Dienstag, 03. März 2020 um 12:08 Uhr
> Von: "Sam Reiter"
> An: "Rob Kossler"
> Cc: "Lukas Haase" , "USRP-users@lists.ettus.com" <
> usrp-users@lists.ettus.com>
> Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX w
On 03/03/2020 12:08 PM, Sam Reiter via USRP-users wrote:
For what it's worth, I was able to reproduce the behavior described
here, but didn't get to dig into it much. My leading suspicion would
be what Rob mentioned about timestamping. Lukas' code sets a command
time, but I'm not clear on how t
m 12:08 Uhr
Von: "Sam Reiter"
An: "Rob Kossler"
Cc: "Lukas Haase" , "USRP-users@lists.ettus.com"
Betreff: Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a
timed command
For what it's worth, I was able to reproduce the behavior des
For what it's worth, I was able to reproduce the behavior described here,
but didn't get to dig into it much. My leading suspicion would be what Rob
mentioned about timestamping. Lukas' code sets a command time, but I'm not
clear on how timestamp metadata for packets being sent to the radio are
han
I wonder if the issue is related to a missing time stamp on the baseband
samples going from GR to UHD. If the stream does not have a time stamp,
the DUC is unable to apply the timed command because the DUC does not
really know the time - it must pull the time from the streaming samples.
This is in
tion right now but my
> experience with NI RIO on Windows was very poor so I want to opt for 10Gbe
> in the long run
>
>
>
>
>
> Gesendet: Montag, 24. Februar 2020 um 13:47 Uhr
> Von: "Neel Pandeya"
> An: "Lukas Haase"
> Cc: "Ettus Mail List
rying Wheberth's auggestion right now but my
experience with NI RIO on Windows was very poor so I want to opt for 10Gbe in
the long run
Gesendet: Montag, 24. Februar 2020 um 13:47 Uhr
Von: "Neel Pandeya"
An: "Lukas Haase"
Cc: "Ettus Mail List"
Betreff: Re: [USRP
Hi Marcus,
Thank you that would be amazing!
I followed the tutorial and built everything from source:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.4 LTS
Release:18.04
Codename: bionic
$ uname -a
Linux sdr 5.3.0-40-generic #32~18
On 02/28/2020 01:01 PM, Lukas Haase via USRP-users wrote:
Hi again,
I created a minimum example (gnuradio) that shows the issue described below.
To summarize: Retuning to a different dsp frequency on an USRP X310 (+UBX160)
does not work (command ignored) ONLY if a timed command (in future is us
Hi again,
I created a minimum example (gnuradio) that shows the issue described below.
To summarize: Retuning to a different dsp frequency on an USRP X310 (+UBX160)
does not work (command ignored) ONLY if a timed command (in future is used).
The code shows it in a simple manner. Commenting out th
Hi Lukas, I use pretty much this setup (Ubuntu 18 + X310 over PCIe).
You can install kernel 4.15.0 from ubuntu repository and reinstall the
driver. It work just fine. You may also need to download some RFNoC XML
files that are missing on Ubuntu repositories (see:
https://bugs.launchpad.net/ubuntu/
Hello Lukas:
Do you have the option of using 10 Gbps Ethernet?
It will provide you the equivalent performance on the X300/X310 as the PCIe
interface.
The Intel X710-DA2 network card works very well out-of-the-box with Ubuntu
18.04 and 19.10.
Most people using Linux and GNU Radio with the X300/X
Hi Lukas. Most USRP X310 Linux users employ 10gigE to connect to the host
PC. PCIe on the USRP X310 uses a proprietary ASIC and the driver is, as
you discovered, built on an obsolete kernel. You could attempt to appeal
directly to NI for support if switching to 10 gigE isn't an option for you.
Hi,
I have used USRP X310 over PCIe and gnuradio on Windows for quite a bit. I
suffered from large connectivity issues so I wanted to switch to Linux for
quite some time. Also, I need to start modifying gnuradio/uhd source which is
even more painful in Windows.
I set up an Ubuntu 18.04 system
Try the command.
dd if=.bit of=.bit count= count=1
and then try to configure the fpga .bit
On 27/09/19 16:12, Aaron Montilla via USRP-users wrote:
> Hi,
> I am trying to set the connection between my PC and my USRP X310.
> I ran the command uhd_find_devices, and successfully it found the
> USRP
Hi,
I am trying to set the connection between my PC and my USRP X310.
I ran the command uhd_find_devices, and successfully it found the USRP.
Then I use the uhd_usrp_probe command and I had the next error:
aaron@leonard:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_
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
At the very benign 20 MS/s, I'd really say your first option is the way
to go. The rest probably won't work very well du to turn on/off
behaviour requiring you to zero pad a bit to flush your TX data chains.
You can of course also write an RFNoC block to store and generate data
in-FPGA, but really
Dear all,
I would like to periodically send a frame with an USRP X310 (frame
length: 320 samples, rate: 20 MS/s, period: 1-500 ms). However, I
struggle to find the best way to implement it. What I have tried so far:
1. Append zeros to the frame to reach the expected period. However,
this co
Hi Kevin,
I am Simona Sibio, a student in Heriot-Watt University.
I am writing to you because I read on the Ettus List some your mail
regarding the implementation thought Xilinx Vivado on the USRP.
I have experience with Xilinx Vivado but on the Ettus web site, I did not
find any demo to connect
Hi,
Thanks Nicole. We solved the problem by installing centos 7.0. It performs
a lot better with real time constraints.
Akın
4 Haz 2019 Sal 01:40 tarihinde Nicole Bienert şunu yazdı:
> Hi,
>
> I was having the same problem, but I figured it out. Shut everything down,
> then turn on the SDR fir
Hi,
I was having the same problem, but I figured it out. Shut everything down,
then turn on the SDR first and the computer second. Next type sudo
/usr/local/bin/niusrprio_pcie *stop*. Do not type start before using the
stop command. If you type start then later type stop, it still won't work.
I'm
Hi all,
I recently purchased a USRP X310, and a pair of UBX daughter boards, that I
would like to use to for waveform testing. However, I have not been able to get
basic operation on the radio working properly with GNURadio. I am able to
receive a tone when running a receiving GNURadio flowgrap
OK, so I did manage to debug it further by setting the
ENABLE_EXTENDED_ERROR_INFO flag to true. It seems like the
nirio_driver_iface::rio_ioctl function is returning 52003 error.
uhd_usrp_probe --args "type=x300,resource=RIO0,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_10580
Dear all,
I am trying to connect over PCIe to my USRP X310. I have installed the
latest drivers niusrprio-installer-18.0.0.tar.gz and I am starting the PCIe
connection with the following command:
sudo /usr/local/bin/niusrprio_pcie start
Making sure drivers are up to date...
Module nikal is up-to-
Hello,
I know that the 10GbE ethernet interface is adding an extra 500us round
trip time delay with fiber DAC. I tested it myself. 1 GbE would probably
give a similar delay as well. So do you think it would stay below our delay
budget of 250us?
Regards,
Akın
On Fri, 1 Mar 2019 00:24 Nate Temple
Hi Rob,
Yes, that's correct, you can use the WR-LEN with the X310.
Regards,
Nate Temple
On Wed, Feb 27, 2019 at 12:40 PM Rob Kossler wrote:
> Nate,
> Although the X3xx series to not natively support White Rabbit, I believe
> that they can get all of the benefits by using a WR-LEN in close
Nate,
Although the X3xx series to not natively support White Rabbit, I believe
that they can get all of the benefits by using 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,
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
Hello All,
I have a question. We want to synchronize the clock of the two USRP X310s
with a GPS or IEEE 1588 standard. I would like to synchronize the two USRPs
with each other so that the base station and user terminal would not
experience any synchronization issue. I also would like to synchron
Hallo Martin,
Concerning the vanilla UHD-example: I'm just remember, that I've
couldn't find an example on your repository, where you used multi_usrp
in combination with RFNoC. Before we used our FPGA-Image in our
CPP-Application we tested it with GNU-Radio. But there we tested just
one channel (I
Hallo Martin,
So at the moment for testing the new RFNocC-designe I've used two USRP's
x310 synchronized with a octocklock from ettus.
In our real application we operate 5 or 6 USRP's in parallel, all
connected over the 1 gigabit-ethernet to our host-machine.
The problem described happens also w
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
On Fri, Feb 22, 2019 at 6:19 PM Martin Braun wrote:
> 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.
>
So it's a forced reload of the FPGA from the onboard image. To use this in
software, I'd issue the command, then t
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
On Wed, Feb 20, 2019 at 7:45 PM Jonathon Pendlum
wrote:
> Hi Armin,
>
> You can reset X3x0 series devices via a register write with the following
> command (this is in to your UHD src directory):
> firmware/usrp3/x300/x300_debug.py --addr 192.168.40.2 --poke=0x00100058
> --data=1.
>
Can you elab
Hi Armin,
You can reset X3x0 series devices via a register write with the following
command (this is in to your UHD src directory):
firmware/usrp3/x300/x300_debug.py --addr 192.168.40.2 --poke=0x00100058
--data=1.
When you kill your app and resume, how long do you wait before restarting?
Can you
On 02/20/2019 07:50 AM, akin soysal via USRP-users wrote:
Hello,
In order to decrease the latency, I was playing around with the MTU
size setting it to 4000, 7000, 9000 and now a permanent error happens
in my server connected to USRP. I tried it with two different USRP
X310s and the problem h
Hello,
In order to decrease the latency, I was playing around with the MTU size
setting it to 4000, 7000, 9000 and now a permanent error happens in my
server connected to USRP. I tried it with two different USRP X310s and the
problem happens in both. Where does the 7972 bytes come from? Thanks.
Re
Hm, does someone know if it is possible somehow to reset the FPGA over a
register? We see, that there exists a registers for resets of different
modules (SR_SW_RST), but don't know, if we could use this over the API.
Does somewhere exist a register-map? I think that should be the basis of
every doc
On Tue, Feb 19, 2019 at 12:07 PM Armin Schmidt wrote:
> Thanks for your replay! Hm, yes I've thought also about to use
> STREAM_MODE_STOP_CONTINUOUS, but I would like to be able to restart my app
> also after a crash. Ok, it should never happen, but one can never guarantee
> that case. Do you hav
Thanks for your replay! Hm, yes I've thought also about to use
STREAM_MODE_STOP_CONTINUOUS, but I would like to be able to restart my app
also after a crash. Ok, it should never happen, but one can never guarantee
that case. Do you have an idea, how to deal with such cases? I think it's a
bug in UH
On Tue, Feb 19, 2019 at 5:42 AM Armin Schmidt via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hallo,
> We're about to migrate from multi-usrp-application with UHD 3.9 and
> custome FPGA to UHD 3.14 with RFNoC. We are using the USRP x310 with
> daughterboards ubx-160. Everything seems to work
1 - 100 of 122 matches
Mail list logo
