By the way, if RFNoC 4 is what you're interested in, the current master branch
of
gr-ettus, GNU Radio 3.8 and UHD 4.x are what you're aiming for!
On 04.03.21 22:08, Jeff S via USRP-users wrote:
> I'm getting ready to help someone install code and I'm seeing conflicting
> things
> regarding GNU
Hi Jeff,
GNU Radio 3.7 is legacy; you want to use GNU Radio 3.8 or 3.9.
gr-ettus is only fully compatible with GNU Radio 3.8, and much better supported
under
that. That settles that. Use GNU Radio 3.8! (GNU Radio 3.7 really slows you
down at this
point: Python2, all kinds of legacy Qt problems
SP tuning. I have gone through Piotr’s implementation, but was not able to
> understand
> how he was maintaining the time synchronization based on GNURadio work
> function.
>
>
>
> Regards
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=55098
Hi Snehasish,
you're not actually using timed commands, so there's no exact timing involved.
Your usleep
doesn't make much sense either, you shouldn't let your PC sleep while the
analog chain
tune, but instead already issue the next timed command. In this situation, I
also would
*not* tune the
You're right. The whole point of the TwinRX boards is to give you coherent
channels, and
you can build a coherent 4-channel *receiver*.
However, TwinRX can't transmit, so for 4×4 MIMO, you'll need something else.
Since there's
no dual-transmit-channel daughterboards, you'll need to coordinate th
;
> labuser@EttusDevel4:~/rfnoc/src/gr-ettus/build-arm$ which cmake
> /home/labuser/rfnoc/oe/sysroots/x86_64-oesdk-linux/usr/bin/cmake
> labuser@EttusDevel4:~/rfnoc/src/gr-ettus/build-arm$ cmake --version
> cmake version 3.15.3
>
> CMake suite maintained and supported by Ki
Hi Dennis,
that's probably not the case here but I've seen similar with installations
where older CMake with newer CMake libraries were present (or vice versa). What
does `cmake --version` say?
Don't have an E310 SDK at hand to check myself, but when you run `which cmake`,
is that the cmake you
Hi Cédric,
not that hard: you need an instance of settings_register, which you connect to
the
appropriate settings bus.
It's probably easiest if you look through the FPGA code matching your version
of UHD
(check out the UHD source repository, `git checkout` the tag that corresponds
to the UHD
Dear Ofer,
You're right, the get_mboard_sensor is a property of the multi_usrp class and
logically
doesn't "map" to the device3 class.
I don't have an ultimately good solution, here, to be honest. As a ugly yet
functional
workaround:
auto sensor_values =
my_device3_sptr->get_tree()->acces
Dear Mr. Askar,
you can get the detailed names of the available gain elements of every device
by calling
auto gain_names = my_multi_usrp->get_rx_gain_names();
and then do something fun like:
for(const auto& gain_name : gain_names) {
auto gain = my_multi_usrp->get_rx_gain(gain_name);
st
Hi Jeff,
thanks for clarifying!
Yes, that should work. Also, your GR version definitely has support for SOB/EOB.
Generally, I'd expect this to work; only misconception I see is that the Sink
doesn't
start sending when it sees the EOB; it starts sending at SOB, and stops
expecting and
sending s
Hi Jeff,
which version of GNU Radio are you using? Judging by the looks of your flow
graph it's the
(now legacy) 3.7, but *if* I remember correctly (it's really been a while), the
SOB/EOB
functionality appeared *somewhen* in 3.7.x; it might be worth trying your exact
same
application in GNU Rad
A classic here would be if there was a network-attached USRP that is
also found by your PC, and then used without you noticing. Could that be
the case? What do you use in the "device address" field of the UHD USRP
Sink?
Best regards,
Marcus (the other)
On 15.01.21 09:28, Marcus D. Leech via USRP
If you have access to the UHD API, the property tree entry is
/mboards/0/link_max_rate.
So, something like
auto value =
my_usrp_object->get_tree()->access("/mboards/0/link_max_rate")
will give you the maximum rate you can transport through your USB link.
Maybe that's actually what you're looking
yep, excellent diagnosis!
so, make sure you've hidden/removed all UHD 3.15 before rebuilding GNU
Radio against UHD 4.0.
Best regards,
Marcus
On 13.11.20 22:11, Dustin Widmann via USRP-users wrote:
> Hi Jerrid,
>
> Your gnuradio is built against UHD 3.15 instead of UHD 4.0. You'll
> probably nee
Hi!
a) please do tell your administation that this happens to you. Often,
closed tickets are a currency in which improvement is measured, and
honestly, I don't see why it's you spending time working around that to
open an obviously non-malicious link on a PC on which you're allowed to
read and sen
Your virtualizer needs to support Jumbo frames for any reasonable packet
rate. You saying the MTU being at most 1500 means that either your
network hardware can't do Jumbo frames (unlikely, in 2020), or that
you're not passing through your network properly into the VM.
You'll want to investigate t
Hi James,
re:stm32 image:
um, if you want to modify the source code, binaries won't help you. If
there's nothing you want to modify, you don't need to flash, either.
Since these images are nearly impossible to break, and non-trivial to
flash without dedicated programmers/connectors, what's the u
wow, doesn't at the very least that Schmitt trigger kind of worsen the
phase cleanliness, seeing it's a temperature-dependent active part?
On 01.09.20 18:16, Marcus D. Leech via USRP-users wrote:
> On 09/01/2020 12:15 PM, Christopher Flood wrote:
>> I have not looked at the output spectrum of the
Dear Benjamin,
I'm sorry this lay dormant for so long:
Generally, all standards-compliant 10GBase-* SFP+ transceivers are usable
with the USRP X3xx and N3xx series – these ports are directly attached to
an ethernet MAC on the FPGA, and that's really not picky.
30 m sounds like like 10GBase-SR over
Don't know your receiver and your Implementation in detail, but isn't
that PBCH a little strong? you're probably "screaming" at your receiver
so loudly that it drastically distorts the receive signal. Try with
lower gain.
On 29.07.20 17:17, Prasad wrote:
> Hi Muller,
>
> Just a quick question.
>
fArray[i*2] are the I components,
fArray[i*2+1] are the Q components,
exactly as you'd get with a (libc or C++ std::) complex.
Best regards,
Marcus
On 21.08.20 15:51, Nate Young via USRP-users wrote:
> Hi All.
>
> I am using a Linux based host with b205mini and have a question on the
> orderin
Hi!
What kind of USRP, which version of UHD are you using?
Last thing looks like a device brownout. If you're using a B-series
USRP, try with the external power supply. If that helps, your USB port
provides too little power. Also try with a different PC, some PCs have
known-to-be-bad USB host con
Dear George,
On 05.08.20 21:25, George Smith via USRP-users wrote:
> After reading and doing the official /Getting Started with RFNoc Development
> guide/, I implemented my own VHDL/Verilog files and adapted the corresponding
> XMLs for GNURadio and UHD-Integration.
Nice!
> Furthermore I chang
Does removing and adding the chipscope again help, and making sure
you're really using all the channels that your chipscope implementation has?
Best regards,
Marcus
On 28.07.20 08:17, Jayant Chhillar via USRP-users wrote:
> Hi everyone,
> I am trying to generate a bitstream for X310 board with t
Hi Vikas,
the ZPU dissector shouldn't help you (IIRC, there's no DUDEBRO protocol
between host and B2xx). However, yes, the RFNoC dissector is what has
become of the CHDR dissector.
When I look at your screenshot, it looks to me as if Wireshark wasn't
told to actually decode the packets as RFNoC.
Hi Koyel,
I'm sorry if I'm repeating myself. I see this seems hard to believe, but:
we really can't tell you. We don't know how well your system performs.
Best regards,
Marcus
On 25.07.20 13:32, Koyel Das (Vehere) wrote:
> Hi Marcus,
>
> “as to your previous questions regarding "will my compute
Hi Koyel,
> Will there be packet drops if USRP source is set at 32 bit complex
float in grc when receiving at 100 MSPS each from two channels?
as to your previous questions regarding "will my computer be able to
keep up": We can't tell you how fast your computer and storage is.
Anyway,
> I am u
Hi Cherif,
On 24.07.20 11:33, cherif chibane wrote:
> BTW, what is the real function og GR-Ettus?
If you're asking this, you don't need it!
gr-ettus (the capitalization matters) is a GNU Radio out-of-tree module
which you need if you want to develop GNU Radio applications that
involve custom RFN
I?
>
> Get Outlook for iOS<https://aka.ms/o0ukef>
>
> From: USRP-users on behalf of Marcus
> Müller via USRP-users
> Sent: Friday, July 24, 2020 2:32:20 PM
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] 4 channel
Hi Koyel,
The NI 2955 (hardware-wise: an X310 with TwinRX daughterboards) can be
used with modern GNU Radio.
I'd think you'll be most happy with installing Ubuntu Linux 20.04LTS,
from which
`sudo apt install gnuradio`
will give you a working GNU Radio, and a matching UHD.
(Don't follow any other
This has not overly much to do with that being done with GNU Radio: If
your machine is fast enough, yes. If not, no.
Instead of the overhead of a file on a RAM disk, simply use a vector
sink, at least if you're using modern GNU Radio (3.8): Use the "reserve
memory" field with enough space to recor
ah perfect!
Re: post modifications
If you like GRC code generation, you will love Python snippets, which
allow for code insertion in the generated GRC file for exactly these
kinds of things.
On 23.07.20 15:50, Marcus D. Leech via USRP-users wrote:
> On 07/23/2020 06:13 AM, Marcus Müller via U
7;t just manually generate a sync pulse. But
> if I can find a device that works reliably I may switch to that. Thanks
> for the explanation and ASCII schematic.
>
> Cheers
> Johannes
>
> [0] https://files.ettus.com/manual/page_gpsdo_x3x0.html
> [1] https://files.ettus.com/man
Hey,
On 23.07.20 11:44, Johannes Demel via USRP-users wrote:
> Hi Marcus,
>
> I tried to improve the situation. I had another look at [0,1].
>
> From [1] (N310 manual)
> "[..] which can both be used as time- and clock references. The GPSDO
> will function as a reference even when there is no GPS
Hi Johannes,
let me increas Marcusness of this by ~3dB.
On 23.07.20 09:29, Johannes Demel via USRP-users wrote:
> I don't have a PPS signal readily available. Would a 10MHz reference
> suffice as well?
Nope, that doesn't set a time register. You don't actually need a pulse
per second – you need
Hi Cherif,
this is typically an issue encountered if you didn't install the blocks
into a directory GNU Radio companion looks into.
Make sure that you've used `-DCMAKE_INSTALL_PREFIX=` with a prefix that
contains a path that GNU Radio looks into; GRC prints the paths into the
console when it's st
Hello Prasad,
I second everything Marcus L said, and will add:
In your first email you said this is about the UE.
UE (user equipment) are normally things like phones. These don't have
any great clocks of their own. They derive their clocks from that of the
network.
Sure, for prototyping, reduci
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.
You should technically be able to do that, but it really doesn't sound
wise to do that without containerizing your file systems. Then, it
should be no problem at all.
Note that *running* more than one version at the same time is something
different. Generally, again, should work with differen logi
Hi Benjamin,
https://files.ettus.com/b2x0_enclosure/ has the dimensional drawing of
the B210. You'll find the Molex Part Nr. 87831142 in there; the Molex
page lists mating connectors for various applications:
https://www.molex.com/molex/products/part-detail/pcb_headers/0878311420
Note that you're
Hi Seshan,
um, this is a bit awkward, but you wrote an email with "internal use
only" to a public mailing list.
Now, it's public, and due to how email works, that can't be reversed; so
I might as well answer!
On 17.06.20 06:08, Seshan Govender via USRP-users wrote:
> We have recently purchased a
Nabble is **not** affiliated with Ettus. They just copy the mailing list
into their own archives without asking us, and make it look like a forum.
It's not.
It's our mailing list, so please ditch Nabble.
Since your email reached this mailing list, you're successfully
subscribed! Congratulations!
Hi Christian,
never run UHD as superuser, there should not be a reason for this that
you can't work around.
Changing the user normally doesn't preserve environment, so, as the
error message suggests, you'll have to explicitly set UHD_RFNOC_DIR.
Best regards,
Marcus
On 08.06.20 15:31, Christian
To answer your question in my own words:
On 28.04.20 13:51, Philip Balister wrote:
> Is there a setting you can tweak to change this behavior?
is sneakily answered by:
>> Note that the software is a bit tight on space on the Attiny88 – so
>> maybe try to avoid integrating too many features witho
Hey Joshua,
the firmware can be found in the UHD source code repo under
firmware/e310/battery. If I remember correctly, you'll need avr-gcc,
avr-libc and avrdude (the latter only for flashing using the `make
install` target).
Note that the software is a bit tight on space on the Attiny88 – so
may
Hi Bob, hi Sam,
top of my head, UBX-160 doesn't even have adjustable bandwidth
(basically, of the modern devices, only AD9xxx-based systems have). So,
yeah, you'll always get a two-sided84 MHz analog bandwidth (that's how
you get 160 MHz in complex baseband). You'll notice when oversampling at
200
so something is off
> globally in the firmware or the timer register that drives it.
> -Ian
>
>> On Jan 6, 2017, at 6:55 AM, Marcus Müller via USRP-users
>> wrote:
>>
>> Hi Vladica,
>>
>> err, that's a strange problem; are you sure you want to ch
Hi Rodolphe,
> I am completely lost.
Yep, USB does that to you, occasionally...
So, anyways, probably not at all your fault. If you can, make sure
you've got the latest firmware for your laptop.
Personally, I'm kinda lazy, so I prefer to first check whether there's
things that are easy to updat
Hi Damon,
sorry, that wasn't my intention :( But let me make it better!
My current guess is that UHD's DPDK transport gets confused and tries to
use the wrong network card. Luckily, we can try to work around that:
uhd_find_devices --args=use_dpdk=1,addr=192.168.60.2,dpdk_mac=XYZ
where XYZ would
So, investigations so far show you might
1. have a version of libssl that is so old that it tries to use SSL3
(instead of TLS1.0 or later) to talk to the server; rightfully,
files.ettus.com:443 doesn't support that
2. you might per chance have installed a package that overrides
python-requests' de
Hey Basse,
while I can't reproduce, I can verify that there indeed seems to be a
slight problem with the OCSP verification. We'll look into this.
Best regards,
Marcus
On 20.03.20 01:42, Basse Ang wrote:
> hi Marcus,
>
> Thank you for your reply.
>
> this is the output:
>
> Please run:
>
>
Hi Damon,
this sounds like DPDK is working, but something's not 100% correctly
configured. What does your dpdk-ipv4= line say?
Best regards,
Marcus
On 16.03.20 20:03, guowang qiu via USRP-users wrote:
> Hi everyone,
>
> I am trying to connect my notebook to X310 with a thunderbolt 3 to
> 10GNB
Hi Basse,
knowing our downloader, this is very likely a problem on your side: Is
it possible you have a HTTP proxy set up that does SSL tunneling, but
you've forgot to install the CA certificate, so that you don't trust
your own proxy?
Can you share the full output of
echo "http_proxy ${http_pro
ilto:usrp-users@lists.ettus.com>
> <mailto:usrp-users@lists.ettus.com
> <mailto:usrp-users@lists.ettus.com>>> a écrit :
> >
> > Hi,
> >
> > be also sure to plug the cable firmly on both
> > ends. I've
us.com>> a écrit :
>
> Hi,
>
> be also sure to plug the cable firmly on both
> ends. I've seen it more than once with a cable
> "half-plugged" and then it becomes usb2, not usb3.
>
> My 2 cents.
>
> Regards,
> Cédr
Hi Rodolphe,
first of all, check whether you're actually dealing with a USB3 port. I
know, sounds strange, but if it's not blue and doesn't have more than
four visible contacts, it's not standard-compliant USB3. The fact that
it's attached to a xHCI doesn't itself mean it can do USB3.
Then, I can
Ah, my bad, I was assuming you had a 10GBase-T SFP+ module. Sorry for
the confusion.
On Tue, 2020-02-04 at 09:26 +0100, Olivier Ravard via USRP-users wrote:
> Le 03/02/2020 à 17:45, Marcus D. Leech via USRP-users a écrit :
> > On 02/03/2020 06:36 AM, Olivier Ravard via USRP-users wrote:
> > > The g
Hi Olivier,
all this is basically standard Ethernet, so it *should* work.
Do the link indicator LEDs on the USRP blink?
Best regards,
Marcus
On Mon, 2020-02-03 at 12:14 +0100, Olivier Ravard via USRP-users wrote:
> Hello,
>
> Is it possible to connect a X300 device to a 10Gb/s BaseT network
> us
Hi Subu,
when exactly does the panic occur?
Best regards,
Marcus
On Mon, 2020-01-06 at 11:12 +, Subu Rama via USRP-users wrote:
> I have a kernel panic on the E320 with the most recent release
> v3.15.0.0
> (I used the most recent mender process).
>
> Details on E320 to be used in the test s
Ah, wonderful :)
that should be a git repository, so `git describe` typically delivers a
string that is "last tag on the current branch - commits since then -
gCommit Hash", typically.
Best regards,
Marcus
On Fri, 2020-01-03 at 19:27 +, Jerrid Plymale wrote:
> Hey Marcus,
>
> Thanks for you
Hi Jerrid,
could you check /home/ck/rfnoc/src/uhd-fpga/usrp3/top/e300/Makefile
exists?
My uhd-fpga directory has that; I think yours *should*. Which version
of the uhd-fpga repo are you using?
Best regards,
Marcus
On Fri, 2020-01-03 at 15:43 +, Jerrid Plymale via USRP-users wrote:
> Hey All
Hi Varban,
On Tue, 2019-12-31 at 21:27 +0200, Varban Metodiev wrote:
> Hi Marcus,
>
> I am doing something like a PWM over radio. I need to measure the
> length of the pulse that is being received. My Verilog module does
> this and outputs a 16-bit variable that stores the samples count
> present
Hi Varban,
not quite sure I understand what you want:
The B2xx series only has the streamers it has, so you can either get
the DDC output, or the output of your module, not both (unless you
somehow interleave them, and then on the host deinterleave them).
Also, unless latency is an important cons
Hi Roma,
I must admit that this kind of multi-core libusb handling wasn't one of
the original design goals.
Essentially, it **could** work with little code modification to NOT
reuse the same libusb context (on anything but Windows, at least), but
the fact that we cache the libusb context certainly
Hi Snehasish,
Custom or stock FPGA image?
Is upgrading your UHD an option?
Best regards,
Marcus the second
On Sun, 2019-12-22 at 16:51 +, Snehasish Kar via USRP-users wrote:
> Hello Marcus
>
> I am running at a sample rate of 2e6. What I am doing is tuning the
> usrp and streaming samples
Hello Jerrid,
huh, a cursory glance tells me this is in the generated IP cores, i.e.
not even in UHD code itself.
I've not encountered that before; maybe there's a half-built IP core
still present in the source tree? You can get that really pristine by
cd uhd-fpga; git clean -xdf
Best regards,
M
Hi Varban,
just a transient observation: your $PATH contains *a lot* of redundant
ISE paths, as if some script kept recursively sourcing the xilinx
settings. How are these set? Do you have a specific shell that you
prepare for synthesis?
Best regards,
Marcus
On Fri, 2019-12-27 at 12:47 +, Var
Hi Baroch,
oh, that's interesting and I must admit I don't really know where to
start looking into this, but let's take this top-down:
How are you setting the gain, and how are you doing the capturing?
My gut feeling tells me there's something in UHD not handling multi-
channel gain setting right,
size, the rate of pulsation changes.
> > Also,
> > you don't see this on a real spectrum analyzer, even an inexpensive
> > one.
> >
> > Ron
> >
> > On 12/21/19 09:25, Marcus Müller via USRP-users wrote:
> > > Just to rule out interferer
Just to rule out interferers:
* the stripes go away when you turn of the USRPs?
* Also, the stripes aren't there, either, when you use the Lime on the
same 1.011 GHz frequency, exactly?
My suspicion is that this is mostly USB3 emissions (those could be, but
not necessarily are, happening through
Hello Padorin,
both are pretty good; the presentation can't fully represent the
differences; the UBX alone costs about as much as an B210, and you'll
need an X310 and two UBX to have as many channels as the B210, so
there's a solid factor in price and size and weight and power
consumption that goe
Hi David,
the version string printed by benchmark_rate shows that you've also got
an old UHD 3.10.3.0 installation on your system.
Make sure there's only one installation of UHD.
Best regards,
Marcus
On Thu, 2019-09-19 at 16:55 -0400, David Smay via USRP-users wrote:
> Hello,
>
> I recently
Hey Keith,
I quite enjoyed your email :) May I ask what the individual added SMAs
do?
I like the vertical mounting, and the additional LEDs :)
Best regards,
Marcus
On Mon, 2019-09-16 at 18:04 +, Keith k via USRP-users wrote:
> Hey all
>
> I thought I would offer a break from the endless bu
Dear David,
I've seen that happen on specific Ubuntu versions, where they somehow
missed to clean up / mark conflict between CMake 2.x packages and newer
CMake (I'm perpetually disappointed by Canonical). Make twice as sure
that you only got one CMake installed - if this is actually Ubuntu,
"apt s
Hi Josh,
maybe https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
is of relevance to you?
Best regards,
Marcus
On Wed, 2019-09-11 at 10:50 -0400, Josh via USRP-users wrote:
> Hello,
>
> I'm looking to transmit a wideband signal from an X310 at 100 MSPS,
> so I'll start by posing
Thanks! I'm always curious about how our hard- and software
infrastructure is being used!
By the way, in case you want to test a verilog SVD implementation
within a signal processing framework: Bowen Hu did a very interesting
Google Summer of Code project this year, in which he made it possible
to
Hi Daniel,
i3 doesn't sound like the processor family of choice here; a few more
cores can't hurt. Basically, assume one CPU core per stream for the
wire- to CPU-format conversion, plus a bit of demand for someone
handling OS/network card interrupts.
What're you doing with the samples afterwards?
Hello Adnan,
I'm currently not aware of anyone doing that.
However, since one of the typical applications of beefier FPGAs is math
accelerators for linear algebra problems, it's more than likely someone
did in fact implement an SVD before, and you might just need to connect
it to a nocshell to ma
You can!
If you're using GRC to design your GNU Radio system, it's the "Clock
Rate" property of the UHD USRP Source / Sink blocks; if you're directly
coding, you want to call set_clock_rate() before doing anything else,
or supplying "master_clock_rate=184.32e6" with your device address.
Best rega
No, it doesn't have to, as I've explained: I don't know what A is, but
if A is leading to saturation or even clipping, and 8 is, too, then you
see no change in amplitude.
Best regards,
Marcus
On Wed, 2019-08-07 at 12:41 +0430, hossein talaiee wrote:
> Dear Marcus,
>
> I use the same signal for N
Dear Paul,
I'd recommend taking this to the USRP-users mailing list (in CC), since
it's not really GNU Radio-related.
Since that clock rate setting doesn't really "exist" until the device
is operating, you can't query that from any program than the program
currently using the USRP (but that progr
Hi Thomas,
The switching **should** be really smooth! Also, it shouldn't confuse
either USB end to stop working.
But since we're really debugging this by now, this would be reasonable
to check, yes. Do you happen to have an oscilloscope?
By the way, does the device work with the Vcc-cut USB cable
Dear Edwin,
this usually fails because the USRPs reply with a "where are USRPs
broadcast" from uhd_find_devices with a "here I am broadcast", and
often, these get caught in the firewall or don't get routed through
e.g. NAT.
Since you're using a VM: the X300 can push through a WHOLE lot of data
pe
Hi Thomas,
let me quickly address a few of these issues
On Tue, 2019-08-06 at 15:40 +0200, Thomas Fabricius via USRP-users
wrote:
> Hi,
> we have a number b210s that has USB detect problems. We have
> equipment where the power can suddenly disappear, and then the system
> does not come up right an
Dear Hossein,
the B200 does NOT have a TX power control that would compensate that.
Are you perhaps either not changing A very much, or are you perhaps
clipping? Driving your B200's TX amplifier into saturation would of
course mean that you'd not see much of signal power reduction when
reducing s
From the PCIe-8371 card documentation:
> > What connectors do the NI MXI-Express x4 copper cables use?
> The NI MXI-Express x4 copper cables use x4 PCI Express connectors.
> For more information about these connectors, visit Molex at
> www.molex.com and search for x4 PCIe iPass.
Best regards,
Ma
Dear Zhao,
even with an active antenna, GPS signal power is usually below noise
floor. You can't "see" GPS without processing ain.
so, none of this is surprising.
Best regards,
Marcus
On Mon, 2019-07-29 at 14:40 -0400, Xu, Zhao via USRP-users wrote:
> Hello,
>
> I have been struggling with try
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
No. You'd need to rebuild it from source.
On Wed, 2019-07-17 at 16:27 -0400, Saeid Hashemi via USRP-users wrote:
> Can I modify it to link against the current version?
>
> On Tue, Jul 16, 2019 at 5:18 PM Marcus D Leech <
> patchvonbr...@gmail.com> wrote:
> > Yes so it’s very likely a compatibilit
Hi Ivan,
now you've got two Marcuses having told you that the Python API is not
the way to go; I'm afraid that means that for the time being, I'll have
to remind you that, albeit being a mighty and complex programming
language, C++ will be the language of choice. UHD comes with quite a
few ready-t
Hm, if you have to provide a uniform interface, but need to use
different versions of UHD underneath: What about simply building two
identical libraries that use the two necessary versions of UHD, and
only runtime-link (plugin-style) either shared object at run time,
depending on which USRP you nee
Hi!
Network mode on E310 was highly undesirable (reliable rates below
2MS/s) and not compatible with RFNoC, and hence has been disabled in
recent versions of UHD. I've always considered Network Mode on the E310
to be a testing tool, not something you'd want to do for streaming, to
be completely ho
Hello Andre,
I suspect three things being at work here:
1. Spurs from the mixer / synthesizer: Plot the |FFT|² (i.e. simply
play back the file through a Qt GUI frequency sink) with a high FFT
length. Do you see peaks in there? With the PSD (assuming the signal is
WSS) being both the Magnitude squ
Hm, are you 100% sure that you really received as many samples as you
ordered before?
On Sun, 2019-05-12 at 12:41 +0300, Ivan Zahartchuk wrote:
> Good morning. Thanks for your answers, I fixed the record in the data
> array. But it did not help me. But I noticed that everything works
> for me whe
Ah, I see you think that this burst can't be too hard on your computer,
because it arrives "at once"? That's not the case.
On Sun, 2019-05-12 at 01:18 +0200, Marcus Müller wrote:
> Um, sorry, I don't understand your sentence. Of course we have to
> care
> about these samples. Otherwise, we get an o
Um, sorry, I don't understand your sentence. Of course we have to care
about these samples. Otherwise, we get an overflow. That is literally
what overflow means: Samples not getting received by the program using
UHD in time before a buffer overflows.
On Sat, 2019-05-11 at 22:29 +0300, Ivan Zahartc
I'm not quite sure how you come to the conclusion that we wouldn't be
tied to system performance in that case: that number of samples still
needs to be received by the software running on the computer.
Best regards,
Marcus
On Sat, 2019-05-11 at 20:39 +0300, Ivan Zahartchuk wrote:
> Thanks for the
Dear Ivan,
On Sat, 2019-05-11 at 20:00 +0300, Ivan Zahartchuk wrote:
> Sorry I did not specify. When working with the start_cont mode with a
> frequency of more than 5 MHz, I have an overflow error.
Which probably happens due to the inefficient way you handle the data;
your program simply is too
Dear Ivan,
it's not clear what you've modified. I'm not aware of any UHD function
that restricts any frequency to 5 MHz.
Could you elaborate on which code you're basing this on?
Also, while I really like the Python interface, if you're really after
high-rate sampling, it might simply not be the o
1 - 100 of 365 matches
Mail list logo
