Interesting!
What's your Vivado version?
On 20 May 2018 13:44:28 GMT+02:00, Artyom Asadchy wrote:
>Hello, Marcus.
>Yes. this is the unmodified image. I clone it from
>https://github.com/EttusResearch/fpga, checkout to rfnoc-devel (in my
>case
>commit d1d683bcd87bd3cea56f9654152b53e4830db612), tha
Hi Rob,
Often you can get around a complex solution with a little hack:
I presume you want a "thin connection, lesser CPU" computer ("Smarts") to
control the USRP, while you want a beefy machine ("Beef") to capture the stream.
At least for the X310, it works to use a static route on Smarts that
Hello Artjom,
Is this the unmodified image? The error basically complains about too much
logic to put on the FPGA, and that doesn't happen with our stock images. How
are you building this?
Best regards,
Marcus
On 19 May 2018 20:16:40 GMT+02:00, "Артем Асадчий via USRP-users"
wrote:
>Hi every
Hi Risa,
the chances of us getting mad are extremely slim :)
I presume you've already made progress in this; if not: what line exactly does
your debugger say your segmentation fault happens? If you haven't worked with a
debugger before (in your case, probably gdb), it's a skill that pays to le
Hi Miguel,
I'm definitely not an expert on windows software building, but "the libuhd
environment" actually sounds like it is what you want to build. You probably
shouldn't try to link your build of libuhd against our build.
Best regards,
Marcus
On 14 May 2018 06:16:12 GMT+02:00, Miguel P via
Hi Keith,
in principle, you could continue using the multi_usrp in **one** of the
processes. The real problem stems from the question of who inherits the sockets
(in the case of network USRPs), the USB handles, or kernel ring buffer handles.
In the end, only one process might react to packets co
Go Harfan,
It is internally assumed that a streamer during its life time has a fixed
number of streams. What sampling rate are we talking about? Is continuity for
the other channels a concern? What is the time scale we're switching channels
on an off?
Best regards,
Marcus
On 16 May 2018 13:02:
Hello Alice,
I'm myself not aware of an existing project (maybe I just forget, though) which
puts a microblaze into an rfnoc block, but:
Why not? You can put anything that you can instantiate in verilog into a block;
I'd presume you might want to add a bus-independent clock to drive your
proces
Hi Kunal,
How did you install UHD? is there a chance you've got conflicting uhd
installations, or updated parts of your system since you've built UHD yourself
(if you did that)?
Best regards,
Marcus
On 17 May 2018 17:08:43 GMT+02:00, kunal sankhe via USRP-users
wrote:
>Hi,
>
>I am trying to
Dear Ishai,
convert the taps to integers. This typically involves scaling with a
power of two (pick one that would allow the matching signal to stay
within numerical limits of your internal stream format) and rounding.
No magic involved here :)
Best regards,
Marcus
On Tue, 2018-05-01 at 14:31 +00
Ah! The situation is different then!
Chances are that the same bandwidth will still fit through USB2, and
since USB3 is backwards compatible: You don't even have a problem :)
Just connect your B200 as you did your HackRF.
Note that full-duplex might need more USB bandwidth than half, but I
guess
Hi Brian!
It probably won't work great: since USB and ethernet are fundamentally
different, the round-trip delay won't be of any fun, and I really don't
see why you should spend your money on a network-connected USB3 hub
(wasn't even aware something like that existed!) to couple a computer
with US
One time long ago, a friend of mine wrote a tool necessary to
compensate for the TX / RX delay in USRP radar applications.
What he basically did was test the delay of crosstalk.
Best regards,
Marcus
On Sat, 2018-04-28 at 16:39 -0400, Marcus D. Leech via USRP-users
wrote:
> There's no example code
Dear Kazem,
did you run the commands as specified in the error message?
Best regards,
Marcus
On Sat, 2018-04-28 at 22:14 +0800, kazem chm via USRP-users wrote:
> Good day dear Sir,
> I am a new user of Ubuntu and USRP. I'm trying to connect my PC to
> USRP N200, but I have encountered the error
Dear Girolamo,
it's not really clear which examples you're referring to; twice as much
as the newest revision of the E310 (if I remember correctly) doesn't
even come with any way to output audio anymore.
Maybe you're looking for our guide on how to get started using the
embedded device E310? That
Hi Yichao,
Sorry, this is probably my fault. I apologize – I'm not quite sure how
to help you most efficiently right now.
I remember this being a relatively involved issue; just from reading
your second-to-last email on this list, this becomes clear.
I'm still a bit confused about the time synchro
Does the error also occur with a stock FPGA image?
On Sun, 2018-03-18 at 16:19 +, Snehasish Kar wrote:
> > does the error occur exactly in the "make" call, or in the
> > get_device3
>
> It occurs in the make.
>
> > call, or somewhere else?
> > What is your UHD version? Are you running the rig
Hi ben,
also, no USRP can directly deal with a sampling rate as low as 48 kHz –
you'll first have to resample to a rate that your USRP can deal with.
In case of the N210, these frequencies are integer fractions of 100 MHz
i.e. 100 MHz / N, with the restriction that N be an integer 3 < n <=
128 , a
Dear Shehasish,
Marcus Leech already responded to your last mail.
We can't help you without all your code, especially whatever sets up
"args2954R".
Best regards,
Marcus M
On Sat, 2018-03-17 at 06:22 +, Snehasish Kar via USRP-users wrote:
> hello
>
> On trying to use an multi usrp shared p
Dear Sailor Jerry,
I'm not sure I'm following here: The 10 MHz connector is hardware-wise
connected only to inputs, not to anything that can output anything;
compare the schematic[1] on page 1. So, I'm pretty certain your device
can't be condigured to have the 10 MHz connector be an output for
any
To expand on that: I might be overusing this figure but:
If your b_sample is sufficiently smaller than the E310's maximum analog
bandwidth (to be exact, smaller than half of 56 MHz, ie. smaller than
28 MHz, which it better be, because the storage nor network on the E310
really isn't up to working
Hi Joseph,
to avoid confusion, I'll directly comment within your text:
On Thu, 2018-03-01 at 16:03 +, Stern, Joseph via USRP-users wrote:
> I wanted to gain a general understanding of the process,
> specific to our B200mini hardware, so my approach understandably
> seems like the Y and not the
Hi Ivan,
no, I haven't used pysdruhd myself, ever. But might I interest you in
Ettus' own prerelease UHD Python API:
https://kb.ettus.com/UHD_Python_API
Best regards,
Marcus
On Sat, 2018-02-24 at 20:24 +0200, Ivan Zahartchuk via USRP-users
wrote:
> Hello. Prompt please, you used a package pysdru
Hi Jason,
this just means that the loader can't even open the file you specified.
It looks like you're missing the leading "/" of the absolute path
you're specifying.
Best regards,
Marcus
On Fri, 2018-02-23 at 13:46 -0500, Jason Meyer via USRP-users wrote:
> Hi,
>
> I am trying to build a cust
Hi Evan,
you simply install the USRP Hardware Support Package (as you did), and
then you are displayed this license agreement which applies to you
automatically. You are now able to use USRPs with Matlab! There's no
further steps you need to take.
Best regards,
Marcus
On Sat, 2018-02-24 at 17:39
Hi Raphael,
don't think switching from GNU Radio to directly talking to UHD will
change much – the GNU Radio USRP Sink is pretty much a thin wrapper
around UHD.
You might have already said that, but I can't find in this email chain:
What's the daughterboards you're using in your TX USRP N210?
Tha
Dear Raphael,
> Don't you think that 40-60ms is a bit long fot the amplifier to shut
down
I didn't say it was the amplifier shutting down. I supposed it was the
DC offset cancellation!
Your recording is very interesting. I assume the "spike" you see
happens exactly when you turn on the transmi
To expand on that: timed commands do exist for all things that the FPGA
can control – that is: start/stop of sampling, DSP offset tuning,
antenna switching, GPIOs etc.
They do not work for anything that happens on the AD9361 (analog
tuning, gain control,…), because that thing itself isn't controlla
Hi Roman,
sorry for the delay in getting back to you:
Regarding the power consumption: I don't have the Odroid XU4 PCB layout
files, but assuming that you need to crank out let's say 1.6 A in sum
through the USB3 connectors, don't forget that connector resistances,
fuse/power monitoring shunts a
Dear Ali,
as you've noticed, the dB scale in digital samples just means "relative
to an arbitrary value", and not "relative to a milliwatt". I think
we've talked about that before?
So, in any reasonably constructed signal chain, distortion would start
to appear close to 0 dB Full-ADC-Scale. So al
Hi Navin,
I thought someone had replied to you, but it seems I was mistaken.
Sorry!
So what you're seeing is that your USRP disappears from your USB port.
That's almost certainly a problem with your virtualizer. I don't
recommend using a B-series device in a VMware VM. The USB handthrough
overhe
Hi Tim,
You used the wrong device. Burn to the device as whole, not to a
partition.
Best regards,
Marcus
On Wed, 2018-01-31 at 11:39 -0700, Tim Sapio via USRP-users wrote:
> Hello USRP-users,
>
> I have hit a snag uploading the images required to make my USRP2
> function. I will give a brief d
Hi Sumit,
my first reaction would be to just merge the two flow graphs and do the
collision in software – 100% isolated from changing environments and
such.
From a hardware perspective: you can use the PPS input on the B210 to
set a synchronous time and then trigger transmitting on time stamps.
Hi Tarik,
that REF out port is the 10 MHz clock, and you can choose the internal
GPSDO as clock source[1]. Same goes for the PPS out port.
Theoretically, you could "daisy-chain" your USRPs, but I wouldn't
generally recommend that (we haven't characterized delay, and also, if
you can, always avoid
Snehasish,
no.
Best regards,
Marcus
On Mon, 2018-02-12 at 11:03 +, Snehasish Kar via USRP-users wrote:
> Hello
>
> Is it somehow possible to add more than 10 gnu-radio blocks in
> uhd_image_builder.
>
> BR
> Snehasish
>
> ___
> USRP-users mail
Dear Xingjian,
that won't be possible as is – the tuning happens in the AD9361, and
the FPGA communicates with that over a serial link. There's timing
accuracy requirements that we can't meet over that serial link, so
that's why Ettus' AD936x-based device can't support timed commands on
the analog
Hi Kasper,
SIMD is fine and all, for sample processing in the end (for example, to
convert the samples from on-the-wire format to something your CPU can
calculate with), but it's really no "fix it all" for this kind of
thing:
Significant workload is handling the fact that your USB controller has
Hi!
This might really be the fact that the amplifier takes some time to
shut down. This, paired with the possibility of TX/RX crosstalk might
be a contributing factor: That might actually change the DC offset on
the receiving side, and trigger the step response of the DC offset
cancellation (which
Hi Raphaël,
not quite sure I get your problem, but this is rather hard to debug
without knowing exactly what your transmitter does.
For example, if you transmit something that isn't zero-mean, then the
DC offset cancellation *in* the receiving end would start to cancel
out. As that cancellation i
Dear Snehasish,
it seems you forgot to include a problem statement, so it's kind of
hard to help you. Please elaborate on what works/doesn't work.
Thank you,
Marcus
On Thu, 2018-02-08 at 11:00 +, Snehasish Kar via USRP-users wrote:
> Hello
>
> I am trying to use rfnoc with gnuradio, I find
Hi Brandon,
As this isn't really a GNU Radio question, I'm including the usrp-users
mailing list; if you could follow up there (you'll need to sign up
first[1]), that would help us keep the lists clean :)
So, there's a lot of things that might or might not be right here; I'm
picking my "most lik
Hi Alejandro,
so, if you want to process streams of data, Matlab alone really isn't
the way to go, if you ask me. With simulink, you might put your matlab
code into a processing block and stream your data through that. The
SDRu toolbox that Mathworks offers has USRP support, so you wouldn't
need G
Dear Bakshi,
this error is from UHD, not GNU Radio; an appropriate mailing list
would be usrp-users (in CC:).
Please follow up *there* with information on which USRP you're using,
what you're doing, and the full console output (not just the error).
Best regards,
Marcus
On Tue, 2018-01-09 at 02:
Ha! That image looks very much like a copy of an image I did a couple
of years ago to explain offset tuning :D
Anyway, you're still not answering my core question. I can't help you
if you don't do that, and since you're only repeating what you've
already said, I'm afraid that means that we've come
U, marking that as a bug. It's a bit late here, can't test myself,
but can you add "--slot A" to the command line arguments?
Best regards,
Marcus
On Tue, 2018-01-02 at 14:45 -0800, Steven Chen wrote:
> Hi Marcus,
>
> Running both of those commands returns this:
>
> linux; GNU C++ version 5.
Hi Claude,
happy new year to you, too!
So, indeed, this is a bit of a hard problem.
So, which other commands are we referring to? The digital tuning
happens within the DDC RFNoC block; there should be synchronicity.
Generally, the fact that these FIFOs are strictly ordered, of very
finite depth
Hi,
so, thinking about this:
I'd hate to be wrong here; so, could you run
usrp_burn_db_eeprom --unit rx
and
usrp_burn_db_eeprom --unit tx
with either version of UHD?
Thank you
Marcus
On Tue, 2018-01-02 at 10:29 -0800, Steven Chen wrote:
> Hi Marcus,
>
> 1. In the previous version (3.10.0
Hi Steven,
to answer your question as quickly as possible:
1. Since 3.10.2 and your new version, a revision check was added to the
source code (I just found out; the magic I did was running `git diff
release_003_010_002_000..298a13 db_ubx.cpp` in the right directory). I
preliminarily blame that.
Hi Steven,
I don't see how the issue is resolved with the previous UHD version –
the daughterboard still has ID 0x and isn't recognized.
So, this is most likely a connection problem. Properly (but carefully)
reseat the daughterboard, and make sure it's properly screwed into
place.
If that do
Dear Jose,
what Jeff says is right.
As background info:
the diagram you're referring to depicts a USRP2 or N2xx.
The 40 MHz low pass filter is a *baseband filter*. It's part of one of
the 40 MHz-bandwidth daughterboard (WBX,SBX,CBX). You could draw a
vertical line between these filters and the D
Hi Claude,
there's only one FIFO per radio.
"Tags" is a GNU Radio concept. GNU Radio's USRP blocks take these tags
and messgaes, and issue UHD tune_request.
So, yes, in the end, there's only one way to tune, and that goes
through a FIFO.
Best regards,
Marcus
On Thu, 2017-12-21 at 11:35 +0100,
Dear Alejandro,
my guess is that you use an old version of UHD. Which version are you
using?
Best regards,
Marcus
On Thu, 2017-12-21 at 18:28 +0100, ALEJANDRO BLANCO PIZARRO via USRP-
users wrote:
> Dear community,
>
> I am trying to capture IQ samples with a USRP x310 with 2 twinRXs
> using th
Hi Ivan,
what's your sampling rate, what is the bandwidth of the signal you're
interested in?
Best regards,
Marcus
On Fri, 2017-12-22 at 14:10 +0200, Ivan Zahartchuk via USRP-users
wrote:
>
> Hello. Please tell me how to remove the constant component in the
> USRP N210 SBX.
> I was recommended
Yes:
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html#a41
9f5d60d9ca48d162c4001f79511c85
Compare the get_mboard_sensor method that's wrapping through GNU Radio
SWIGging UHD's own method:
https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a2d
3c327bcb83fd274e05
Hello Javier,
the "slantedness" of the constant frequency tone (the fact that it's not
a perfect circle) looks like quite a bit of IQ imbalance to me – how
many samples are those? What frequency did you work with?
The other two graphs, based on the const freq graph, look familiar – one
"swing" ha
Dear Hojoon,
the B200 can't go that far down in frequency, so 3 MHz is impossible.
But let's say you want to do 300 MHz.
You say "phase is 60°", but phase is always *relative* to something. So,
your question only makes sense in conjuction with another wave or
theoretical source of time.
> But,
Hi Bahkshi,
just for understanding purposes: are the TX and the RX antenna on the _same_
USRP?
Generally, I'd like to recommend you take this discussion to the usrp-users
maling list (in CC:), because it's not really related to GNU Radio.
Best regards,
Marcus
On 2017-10-26 07:45, Bakshi,
Hi Nirmala,
On 22.10.2017 18:22, Nirmala Soundararajan via USRP-users wrote:
> Hi Marcus,
>
> I have no idea why you said that but I certainly did not mean to
> directly take the values that Marcus L mentioned and straight away add
> it in my report!. Since I am just learning about SDR, I just wan
Hi!
So, you'll need to be a little more specific than "it didn't work". How
did you configure your random source? Did you use pulse shaping?
There's quite a bit, even to an OOK transmitter, that one can vary and
do right or wrong. With the info you're giving, I'm afraid it's
impossible to help yo
Niemals,
> The "faintest reasonable signal level" that a typical SDR can process!
> (Typically around -120 to -130 dBm).!
no! You can process much weaker signals, too, given enough processing gain.
Marcus was just giving an example. Whether you can "see" what is in the air
depends on the
Hi Oliver,
yep, GNU Radio is just discrete signals, just like in an FPGA – but with
software buffers between software functions :)
That especially means that this is all complex baseband – so, to
represent 20 MHz (= 0.5 MHz · 40), i.e. -10 to +10 MHz, you just need a
sample rate of 20 MS/s.
6MS/
Dear Kai,
to answer your explicit question first:
> I assume that the drifting effect is caused by lost or added samples
> on the Tx side.
> Are my assumptions about the expected behavior correct?
unless you're seeing "U" on the console, no, that's not the case:
there's no lost samples.
If it w
Hi Nirmala,
I'm confused, so what *calibrated measurement device* did you use to get
"-80 dbm to -100 dbm"? As Marcus L has pointed out, the values you get
from the USRP are *not* relative to a physical unit.
Please simply don't think the plots that *any* software gives you have
something to do w
Dear Jon,
that first link points to your own GMail account. We can't do anything
with that, I'm afraid.
Please find the email you're referring to, cite it directly, or link to
it on http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
Thank you!
Marcus M
On 20.10.2017 03:20, liu Jong v
Hi Oliver,
even just considering the time it takes to synthesize a single image for
the B200's FPGA, not counting time needed to learn where to put your
Verilog: Avoid doing things in the FPGA as far as possible. The 20
minutes it costs to go through the first two or three chapters of the
GNU Radi
Hi!
No, sorry, no Virtualization experience with Virtual Box myself – but:
May I assume you're running Windows as the Host on that Surface? I
vaguely remember at least one case, where a windows USB host controller
driver update helped solve a virtualization-related issue, where USB
devices where "
Hi Andrew,
Your English is extremely fine, don't apologize!
270 MS/s is really *a lot* of data. You'd need a very capable computer
even when just handling that amount of data internally, but with
USB-connected devices, you also get a lot of interrupt handling. That
will put additional load on you
>
> Tellrell
>
>
> On Sunday, October 8, 2017 11:38 AM, Marcus Müller via USRP-users
> wrote:
>
>
> Hi Tellrell,
> we should probably change the manual to say "If you're not using
> NetworkManager, do …".
> If you're actually using NetworkManage
Hi Kevin,
it gets even a bit more complicated: While the samples coming out of the
ADS62P4 are pretty raw (though that thing can FIR filter things itself,
but IIRC we don't do anything fancy there), the AD9361 does have a
multistage DSP chain – so, the bitwidth coming out of the AD936x might
not b
Hi Oliver,
haven't quite thought through an understanding of what you're currently
doing, but:
Since the FPGA image already comes with a convenient-to-use DUC – why
not just produce a constant, and tune digitally to a non-zero frequency?
That way, the CORDICs inside the duc_chain will simply gene
Hi Shoor,
instead of doing the build with our Makefile system, you can[1] also
generate a ISE project (.xise) that you can load in ISE, and build using
ISE:
make PROJECT_ONLY=1 {yourtarget}
In my experience, if anything, this doesn't change the build times
drastically, even for minor modificatio
Though I'd really like to point out that different power supplies react
differently to varying load – if your power supply tends to overshoot on
voltage on a load change, be a bit careful to not put a 20V spike on the
input all too often. We've seen devices fail due to overstressed input
caps, when
Hi Tellrell,
we should probably change the manual to say "If you're not using
NetworkManager, do …".
If you're actually using NetworkManager inside that VM (chances are
high!), instead of trxing to "sudo ifconfig…", just set up your network
interface to a static IP Address with the right subnet t
Sure, just use
serial=xxx
as device address. You can find out the serial numbers of your USRPs with
uhd_find_devices.
Note that the USRP is full duplex, so you don't even need two b200mini to
simultaneously RX and TX.
Best regards,
Marcus
On 5 October 2017 8:59:35 PM GMT+02:00, Duixian L
Dear Ivan,
please understand that both my insight on what goes wrong as well as my
capability to make your application work through emails is limited.
Anyway, you already got a few hints that you did not respect.
* Don't use multiprocessing.Process
* Don't try to constantly reset the metadat
behave as intended (i.e., as a
> pair of wireless CPEs, such as Ubiquiti Nanostations, to give an
> example).
>
> On Tue, Oct 3, 2017 at 8:59 AM Marcus Müller via USRP-users
> mailto:usrp-users@lists.ettus.com>>
> wrote:
>
> Sorry, I still d
gt; the only modifications comparing to the vanila example - Clock/Time
> sources - I changed to Default instead of O/B GPSDO.
>
> -- Vladimir
>
> On Tue, Oct 3, 2017 at 4:57 AM, Marcus Müller via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi Vladi
Sorry, I still don't understand – what circle are we talking about?
On 03.10.2017 06:50, seah chong wrote:
> sorry about that, the coverage networking is weak. IP Address PC A is
> 192.168.10.1 netmask 255.255.255.0. what i means with Omnidirectional
> is actually the communication between the US
Hi Vladimir,
synchronization is usually among the most CPU-intense things a receiver
does (only, if at all, contested by channel decoding for complex codes).
So, the 100% CPU utilization don't sound totally unreasonable, depending
on your system.
That being said, I don't want to rule out bugs, bu
Hi Ivan,
since you send the first samples with a timestamp of one, this is not a
good idea:
On 02.10.2017 21:46, Ivan Zahartchuk via USRP-users wrote:
> metadata.time_spec = lib.types.time_spec(0)
That basically forces the next packet to have 0 timestamp, i.e. to be
more than 1s too la
Hi Daniel,
I'm a bit confused by your wording:
you say you set the clock source to O/B GPSDO and unknown PPS; but PPS
has nothing to do with the clock source, but with the timing source. Can
you confirm that both the time source and the clock source are set to
the GPSDO?
Also, you say you see a
Hi Hafiz,
this is a GNU Radio question, and not directly related to USRPs. I'd
recommend you address this to the discuss-gnuradio list, to which you
can sign up on [1], instead.
Best regards,
Marcus
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 02.10.2017 08:39, Hafiz Hashim I
Marcus is right, but: Also, what is to be clarified? 20 dBm (or 10 dBm)
is way more than 0dBm, true, but when would you ever expect a receive
antenna to generate 1V, if you're not standing right next to a massive
broadcast transmitter, or radar transmitter, or put your WiFi antenna in
a microwave o
Dear Seah,
please avoid sending the same mail 4 times; that certainly doesn't
increase the usability of the mailing list.
So, what's your own PC's IP address? is it in the same subnet?
I don't understand what you mean with
> will communicate within omnidirectional
Could you elaborate?
Best re
Hi Steve,
yes, nonlinearities in amplifiers would be my interpretation, too. But
I'd suspect that these might be (also) happening on the RX side – what's
your gain there? What's the attenuation?
My further approach would be:
1. Get the CBX performance data from [1]
2. From that, read/estimate ma
Dear Oz,
what's the different numbers you get?
Also note that it's actually easier for us to read when you just copy
and paste the text instead of making a screenshot. Thanks!
Best regards,
Marcus
On 09/21/2017 07:12 PM, Osvaldo Alcala (Ozzie) via USRP-users wrote:
>
> Hi, I’m running with t
Dear Kobayashi-san,
You want to make sure the size of the network packets is as large as
possible to reduce overhead; UHD will print out the information of how
many bytes are in a single packet during initialization. You might need
to tell Linux that it needs to use a larger MTU (8000B should work
Snehasish,
you're far too unspecific. What does "using a RFNOC block" mean? Which
block? Whose block is that? What's the block's ID, is it correctly set?
Does it come with a working block control class? Does the block work in
test benches?
Best regards,
Marcus
On 09/19/2017 01:18 AM, Snehasi
Hi Rini,
you can use both TX chains with different signals, of course! In fact,
you can't use them with the same signal at all; you'd need to send the
same signal to the USRP twice if you wanted to have the same waveform on
both channels.
> This would mean creating two USRP devices on 2 separate
Dear Sarah,
with 50 dB attenuation in place, you'll definitely want some gain!
Best regards,
Marcus
On 09/18/2017 02:36 PM, Sarah Tran via USRP-users wrote:
>
> Hello!
>
>
>
> I am trying to use 2 N210's connected by a MIMO cable to execute the
> uhd example program txrx_loopback_to_file. I
Hey Rob,
so, it's probably the good ol' radar bandwidth conundrum: For good range
resolution, you'd typically want high TX and RX bandwidth, but at least
on TX, it feels kinda bad to stream a full 200MS/s to the USRP, just to
be able to turn a sine wave on and off again within a few nanoseconds.
A
phase shift == multiply with unit-circle complex number. I think you can
work up from that realization!
Best regards,
Marcus
On 09/18/2017 04:08 PM, Snehasish Kar via USRP-users wrote:
>
> Hello
>
>
> I just need to perform a phase shift. Is there any alternate of rotator?
>
>
> BR
>
> Snehasis
Hi Ben,
that's the old multi-clock problem we've been talking about multiple
times – it's hard to even define what the "correct" clock is, so you
usually just settle on recovering the transmitter clock and, if you were
doing this in hardware, would derive the audio DAC's clock from that.
In a so
ception that all 4 ports can be used as RX at a time!
>
>On Fri, Sep 15, 2017 at 6:23 PM, Marcus Müller via USRP-users <
>usrp-users@lists.ettus.com> wrote:
>
>> A single B210 has exactly two hardware receive channels. So, I'm
>afraid
>> that no software update ev
A single B210 has exactly two hardware receive channels. So, I'm afraid
that no software update ever will change that!
Best regards,
Marcus
On 09/15/2017 02:41 PM, Sumit Kumar via USRP-users wrote:
> Hi,
>
> Apology if this is a redundant question.
>
> With the latest UHD version, is it possi
You'll need an antenna that works for exactly the band that you want to
observe, but if you happen to have one, you can receive a known signal.
For example, if you're in possession of a 900 MHz band antenna, you
might look for 2G signals.
If you have an antenna that works around 100 MHz, look for
Hi Snehasish,
knowing the roll-off of the halfband filters in the USRP, this is rather
surprising. So, my best guess is that there's might be a problem with
your software, but I can't really assess that.
Best regards,
Marcus
On 09/13/2017 12:41 PM, Snehasish Kar via USRP-users wrote:
I have
;
>
> I have noticed that IQ will stream from unpopulated daughtercard
> slots... Is this expected?
>
>
> In testing my app I have only 1 card per x310, yet I got 2x100 MSA
> streams from a single device...
>
>> On September 13, 2017 at 4:55 PM Marcus Müller via USRP-user
I'd actually recommend doing `uhd_usrp_probe --tree` and figure out
which value you need from that. We don't actually guarantee the
stability of the output of the plain-text uhd_usrp_probe.
Best regards,
Marcus
On 09/13/2017 10:01 PM, Marcus D. Leech via USRP-users wrote:
>
> You could run uhd_u
What exactly do you want to vectorize?
Best regards,
Marcus
On 09.09.2017 12:44, David via USRP-users wrote:
>
> Thx for the info.
>
> Do you think there would be any mileage in using the GPU for that, it
> should vectorise quite well?
>
> I' know nothing about the GPU, only done some simple Cud
201 - 300 of 365 matches
Mail list logo
