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
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 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
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
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
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
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
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:
>
>
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
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
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
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 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
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
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
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
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 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
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
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 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 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 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
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
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
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
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
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
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
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 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
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 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 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.
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
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
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
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
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.
>
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
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
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
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!
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
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
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
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
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
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
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
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
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
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
;
> 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
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
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
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 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
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 Kirthana,
yes, Ettus just announced that API! For much more info, see:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-June/0
57034.html
You will need to build UHD yourself with the mentioned flags to get it.
However, it'll be a little bit harder than necessary to get it to
Hi Tarik,
I didn't try to continously stream to storage of dual-channel full-rate
X3x0 recordings myself, but I do have some experience to share;
hopefully it helps more than it scares.
* Even NVMe SSDs aren't uniform in access latency and write speed. So,
make sure your write rate is *reliably*
Dear Brad,
wiggle-ability and subsequent change of properties point to a hardware
defect.
Can you please contact supp...@ettus.com with your device's serial
number, if you have, your NI invoice number, and if possible, a closeup
photo of the soldering or the plug, whatever seems wiggly?
Thanks!
To give an uplifting spin to all this:
Now, also, although larger than the one on the B200, the B210's FPGA
isn't really large unoccupied, so the amount of logic that you could
even hypothetically put in there is limited. Why's that uplifiting?
That FPGA was chosen for the board because there's u
Hi Peter,
hm, I do agree, this sounds like it would be an absolutely reasonable
thing to do on a X310; the B210's master clock rates are way
significantly lower (especially in dual-RX mode), so my hope is that
the overwhelmingness of having software DDC is gone (or you just don't
care about it and
Hi Felipe,
which USRP are we talking about?
and: how much in advance to the time of transmission do you send your
packet to the USRP?
Best regards,
Marcus
On Mon, 2018-07-02 at 16:37 +0200, Felipe Augusto Pereira de Figueiredo
via USRP-users wrote:
> Dear All,
>
> I've got the following problem
I must admit it's been a while, but I remember building a system with
an RX/TX roundtrip time through the host of about 5ms using gigabit
ethernet and relatively small packets.
What's your interface, what's the packet size you're using, and at
which sampling rate?
Also, how often do these burst
Hi Wael,
as someone who keeps processing samples during their days, I very much
second Neel's recommendation:
From a higher-up perspective, you're trying to do high-performance data
processing with low latency restrictions.
Using a slower-than-necessary bus is a bad position to start from, and
us
Hi Walter,
allow me to quickly comment in-line:
On Thu, 2018-07-05 at 15:40 +1000, Walter Maguire via USRP-users wrote:
> Hi Derek,
> Thanks for getting back to me.
> I had a look at the gr-ettus examples covering the X3XX series.
> These all seem to use an embedded processor based UDP sink on
Hi Kevin,
"Packet Encoder" is buggy and therefore in the "deprecated" category in
GNU Radio. It's no surprise it's not working! I mean, you even get a
warning about that in the console.
So, please adhere to one of the working examples we have that don't
rely on explicitly obsolete blocks. I'd re
Hi David,
so, NUM_SAMPS_AND_DONE sounds right for this application, and pre-
determining the time at when the observation will start with time_specs
sounds absolutely like what I'd recommend.
You say there's a "delay when leaving the recv function"; I'm not quite
sure I understand what you're ref
https://files.ettus.com/e3xx_images/README
On Fri, 2018-07-20 at 13:21 +0300, Ivan Zahartchuk via USRP-users
wrote:
> Hello tell me how to update the E310 to e3xx-release-4?
> Thanks in advance.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.co
Hi Bob,
I'm not ruling out we actually are dealing with a software bug here; I
remember that exact dict from somewhere else, but I can't find it
anymore :( We might cooperate to figure this one out, however!
Since this looks like a UHD built from git, we have a lot of options.
first of all, try
Hi Arun,
in the uhd/host/examples directory, you'll find gpio.cpp !
Note that you'll need to bitbang SPI that way from the host; that can
work, but it's going to be slow.
Alternatively, if you are familiar with FPGA development, implementing
another SPI host in the FPGA should be thoroughly
Hi Sanjoy,
> ubuntu 14.04
That is ancient, and Ubuntu's LTS isn't worth the "S" they have in its
name. Don't do this to yourself. Update to the recent LTS release,
18.04.
This is really more of a general UHD question than specific to GNU
Radio – you'll probably be better off discussing this on u
Hi Mark,
eth0 is the management Gigabit management interface. As far as I know,
that won't support MTUs above 1500 – after all, it's only a management
interface, and not a high-rate data streaming interface.
You probably want to have the 8000 Byte MTU on sfp0 and sfp1; if I
remember correctly, ho
to be a little more specific: The baseband data rate of the FPGA /
AD9361 interface limits the interface to a **cumulative** 61.44 in RX.
So, no, that modification is not possible.
Best regards,
Marcus M
On Sun, 2018-09-09 at 13:37 -0700, Neel Pandeya via USRP-users wrote:
> Hello Chintan:
>
> Y
Hi Stefan,
I know it's not of great comfort when an engineer finds a problem to be
/interesting/, but yours certainly is.
So, first things first: if the computational power and memory of the
host that your USRP is connected to allows, it might be good to have a
packet capture in some kind of a rin
Hi Ryan,
hm, there's honestly quite a few things that can simply go wrong on a
demodulation/DSP/signal side of things without nothing misbehaving or
you doing any mistakes. Your single-tone test hence was very clever to
do!
So, my recommendation is this:
First of all, verify that the reception st
Hi Ge,
so, the UHD API lets you define streamers with multiple channels. Then
it's just a matter of calling send() with a list of multiple buffers to
be sent.
But: if you're new to all this, or want to use GNU Radio anyways, or
rather build DSP than writing driver interfacing C++ code:
GNU Radio'
Hi Eugene,
I'm not an expert on the PCIe transport, but as far as I can tell from
3.11.0.1's
uhd::transport::muxed_zero_copy_if::sptr make_muxed_pcie_msg_xport
the PCIe frame sizes seem to be immutable (4 kB, in fact, which,
subtracting header and dividing by sample bitwidth, leads to 1020
sampl
Hi Stefan,
so I've talked to our main software sustainance hero, and we rather
quickly came to the conclusion that it's pretty likely you should move
on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are you
building from source, or are you using binary packages?
Best regards,
Marcus
Well, there *is* a bit of history on these package sizes. Now, having
had frequent communication with you: 4kB is an effect of system page
sizes. For more detail, see x300_impl.hpp's comments on
X300_PCIE_RX_DATA_FRAME_SIZE. But: you're right, this is a communicated
transport property, but since yo
Hi Brian,
thanks! Quick update first: raised the CMakeLists omission internally,
should be fixed soon, far as I can tell.
Best regards,
Marcus
On Mon, 2018-09-24 at 14:52 -0400, Brian Padalino via USRP-users wrote:
> I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the
> installa
Hello Brian,
so, the power-of-two FIFO sizes pretty much happen because you can only
divide addresses by full bit prefixes. That seems to be reflected in
noc_shell.v; not quite sure how deep the changes would have to go to
get rid of that restriction.
Best regards,
Marcus
On Mon, 2018-09-24 at 1
Hi Guangyao,
boost is a very large C++ project which isn't part of UHD, but a
dependency.
In case you're looking for documentation of anything in the boost::
namespace, https://www.boost.org is the place to look.
Usually, you wouldn't interact with the threading within UHD. What is
the specific t
Hm, there's beauty to that, but also there's beauty in not letting the
oscillator drift of indefinitely after you've locked once.
So, the classical fastlock at startup/loss of reference lock, and then
increasingly reduced loop filter bandwidth would probably be even
better.
But that means relativel
Hi Mitch,
this is but a shot in the blue, but:
How you're setting the device clock to 0? set_time_now() or
_next_pps(), or _unknown_pps()?
Best regards,
Marcus the other
On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-users
wrote:
> I've used both 3.10.3 and 3.14 (latest git master
Hi Rob,
it's been a while, but I've played around with an overlap-save FFT
filter in RFNoC. Sadly, I didn't keep the code myself, but I think I
can get it if I ask the right people; it's been my first stumblings in
RFNoC ... so, not quite sure how much help the code would be. Wouldn't
write the sa
Hi Jason,
I'd agree, it'd be desirable if the block accepted messages; after all,
that'd be a good, threadsafe thing to have.
I'll be on a flight, and don't have an RFNoC device on me (I know, a
shame), so I won't be able to test, but adding a message handler to
rfnoc_generic_impl.cc should invol
Hi Jason,
I was about to write code, but then realized: gr-ettus' Block impl
already has what you need, the message port "rfnoc", which'll accept
messages in the PMT dict format. You can extract the shape of
information you need to send in from the tags in
uhd_rfnoc_ddc.xml.
I'm attaching what I
Shoot, there goes my hypothesis!
But: how much time do you leave between set_time_now and then using md
in a send() call? Maybe the setting happens concurrently...
Best regards,
Marcus
On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:
> Hi Marcus,
>
> I use set_time_now(). For my proj
Hi Vladica,
did you try the 3.13 release line, too? This might either solve your
issue or at least help us narrow down reasons. I don't think we'll put
out 3.10.X.X and 3.11.X.X releases for ever, since they're not the
current release branch.
Best regards,
Marcus
On Wed, 2018-09-26 at 14:18 +020
OK, this is alarming; could you be as nice as making a minimum piece of
code that we can run locally to reproduce? I must admit I'm more or
less in an international flight boarding line, so I might not be able
to look at this for the next 72h.
Best regards,
Marcus
On Sun, 2018-09-30 at 18:34 -0400
Hey Corey,
yep, when updating your UHD you also need to update your fpga-src
submodule; `git submodule update`. If you have changes you want to
preserve: Standard git methods apply; just make a branch in the fpga-
src submodule to contain your changes, then update the submodule, then
merge in your
Works!
Don't forget that PPS accuracy of a GPS receiver is theoretical best-
case some 50 ns; in reality, things can get a little worse than that.
Best regards,
Marcus
On Tue, 2018-10-09 at 09:32 +0200, Stephan Esterhuizen via USRP-users
wrote:
> Hi All,
>
> I'm looking at using multiple B210s
Hi Mitch,
where/how do you create the rx_streamer, and which otw / cpu format
does that use?
Best regards,
Marcus
On Thu, 2018-10-11 at 11:53 -0400, Mitch Grabner via USRP-users wrote:
> I'm doing a loopback to check which sample a certain signal level is
> found. I'm transmitting in the main th
Hi J. Jeffson,
to answer quickly: see below.
On Fri, 2018-11-30 at 11:36 +0800, 蒋逸凡 via USRP-users wrote:
> Hi all
> I'm trying to use USRP X Series (2943/2954) in my project. I
> want to try 122.88MHz sampling rate, but ettus.com says that only
> 200MHz and 184.32MHz and the corresponding
UHD is installed on your computer. You hence *can* check the UHD
version that you've installed.
On Fri, 2018-11-30 at 09:33 +, Koyel Das (Vehere) via USRP-users
wrote:
> I am attaching the .grc file. I have installed gnuradio in windows.
> Our USRP has gone for repair so can't check the UHD ve
oh wow, that's interesting, though I have little idea how to
reconciliate storage backpressure with dropping out of networking.
My best guess is that the storage system pushing back on too much data
somehow causes additional CPU load (especially: interrupts/context
switches), and that worsens the s
Why did you change the GCC to the ancient 4.8? How did you do that?
Best regards,
Marcus
On Tue, 2018-12-04 at 14:15 +0800, Philip_liu via USRP-users wrote:
> Hi all,
>
> I download and update all the dependency packages base on
> ubuntu 18.04LTS,but the UHD cannot compile successful
201 - 300 of 365 matches
Mail list logo
