On Thu, Jan 9, 2025 at 10:14 AM Cédric Hannotier via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 2025-01-07 11:29 +, Per Zetterberg wrote:
> > Thanks Cédric!
> >
> >
> > Now I get a signal from both USRPs, great!
> >
> > I still get get the below error. Maybe it doesn't matter
> >
Hi Namira,
you should be fine with Windows 11. In general, people around here prefer
Linux (especially when you start adding your own software on top of UHD),
and there is more experience with Linux. But if you're more proficient with
Windows, it's also fine.
--M
On Mon, Jan 13, 2025 at 8:57 PM
On Fri, Jan 10, 2025 at 6:19 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Perhaps the graph is not really created until you call get_tx_stream()
> such that you need to pass the argument to this call??
>
That's right, this is a stream arg, not a device arg. See here:
https
Hi Neal,
for continuous streaming, don't use EOB. Just always include timestamps.
I'm not sure right now on adjacent bursts, you're probably right, but
they're the wrong tool here anyway.
There is, however, no limit on burst sizes. That means if your application
is running for days, and let's ass
On Tue, Dec 24, 2024 at 1:19 PM wrote:
> Hi, I successfully managed to implement the example block.
> Now, I would like to create my own example block. I'm working on the
> master version, as per your recommendation.
> Is there any documentation available for this process?
>
Hi,
on master branc
There is another scenario where you can S's, which is when using bad
network cables (this is most often a problem with cheap optical fibers).
On Sun, Jan 5, 2025 at 11:57 PM Marcus D. Leech
wrote:
> On 05/01/2025 17:19, cjohn...@serranosystems.com wrote:
> >
> > I hope everyone had a good holida
Some more comments:
- S means "sequence error", which means packets were lost somewhere between
your host and the USRP. "L" means late, which just means that your packet
didn't reach the radio in time.
- If you are using a default X310 image, then the corresponding YAML is
this:
https://github.com
Hi Tim,
thanks for submitting the bug report as well as sending this email. Makes
it easier for us to track things.
Out of curiosity, have you tried setting the last line (for the ATR_XX
attribute) to HIGH as well? If you're only doing TX, then it shouldn't
matter but it's just another data point
Hey David,
this looks like you've gotten pretty far on a sophisticated project! I
have a few observations:
- At first glance, your C++ looks correct.
- I would expect samples to arrive at your block synchronously based on
that. However, maybe I'm forgetting something that would cause the outputs
Hi,
we've been making a lot of improvements to the RFNoC tooling recently, so
if you can, I recommend you update as much as you can (if you can, go to
HEAD of master branch, if not, at least go the latest release). Note that
rfnoc-example is now called rfnoc-gain. We've been testing this build for
On Thu, Dec 12, 2024 at 6:53 PM Yan, Bixing (UT-EEMCS)
wrote:
> Hi,
>
> I am using USRP X440 to build a wireless communication prototype. The host
> PC is equipped with i9-14900K and I am trying to use two transmit channels
> and two receive channels of the USRP simultaneously. I feed two generat
Just as a side note, when you run recv() and send() from different Python
threads, the underlying C++ code that gets into will release the Python
GIL, which allows for true concurrency even with thread vs. multiprocessing.
--M
On Thu, Dec 12, 2024 at 1:51 PM Pedro Vieira wrote:
> Hi Tim, What e
Hi Tim,
The recv() call will return if an EOB is detected, or there's a jump in
timestamps. In other words, using recv(), the only option you have is to
receive bursts one-by-one. As you've probably noticed, you can only return
one metadata object per receive call (hence the discontinuity; the rec
On Thu, Dec 12, 2024 at 6:23 AM Nidhi Panda
wrote:
> Thank you so much for your response. We have tested the
> "rfnoc_radio_loopback" cpp example and it works fine. Just that I am not
> good with cpp that's why I wanted to do this with either python or GNU
> radio. GNU radio also includes an exam
Tom,
some pointers:
- I recommend using timed streaming for both Tx and Rx. You will get a more
deterministic time offset.
- I think you're not accounting for phase offsets as well as time offsets.
Your two signals do look similar -- maybe plot the envelope instead of the
real part. Also, you can
Hi Seppo,
hard to say why the USRP isn't showing up on the PCIe bus. I've only ever
used the official NI PCIe extension card (
https://www.ettus.com/all-products/pcie-kit/), in principle, I don't see
why your card wouldn't work, but it's not something we can help with,
unfortunately.
BTW, if you
On Fri, Dec 6, 2024 at 4:53 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
>
> On Fri, Dec 6, 2024 at 9:44 AM Rob Kossler wrote:
>
>>
>> You might want to look at the Ettus c++ example "rfnoc_radio_loopback".
>> You could also try just running it. Note that it does not incl
Hey Nidhi,
are you able to run the rfnoc_radio_loopback example? It skips the DmaFifo
(which is not present in default bitfiles) but otherwise does the same. It
documents all the common pitfalls of creating loopback apps (like calling
enable_rx_timestamps(), and using back-edges).
Once that work
Hi Eugene,
check out our knowledge base: https://kb.ettus.com/X440#100_Gigabit_Ethernet
We validated streaming at full rate (this means both 8x500 Msps and 2x2000
Msps) with the system above. It's still tough: You need DPDK, and grease
every bolt in the system. Much more than capture/replay isn't
Hi Will,
hui is right. If you want any pins to be high, then mask & value must be
non-zero. Is it possible that you assume that the value only applies to the
mask bits? Because they don't. In you example, this line:
usrp->set_gpio_attr("FP0", "OUT", 1, (1<<1));
will not do anything because 1 & (
Hey Jason,
With current UHD I have no suggestion other than what Marcus wrote. But I
took a peek into our code; the X3x0 actually initializes in parallel
(unless you disable that), but our MPM devices (which includes N320) don't.
I can see how this is annoying, especially since N320 initializes lo
Hi Muneer,
many thanks for sharing this! This could be a very useful tool. I hope
people find it useful.
--M
On Fri, Nov 15, 2024 at 11:37 AM Muneer Al-Zubi
wrote:
> Dear USRP Community,
>
> I have developed a flexible and easy-to-use benchmark module that can
> evaluate the over-the-air perfo
On Sat, Nov 9, 2024 at 12:47 PM Nidhi Panda
wrote:
> Hello all,
>
> I am using USRP n300 board. I have tested Rfnoc TX radio and RFNoC Rx
> radio chain separately. But when we try to run both the chain at the same
> time TX does not seem to work. Any suggestion what might went wrong in this.
>
W
iasing filters get
disabled. But you could use the Keep-one-in-N block in its stead. Bonus
feature: This saves some FPGA resources and decreases build times.
--M
> Thanks,
> Mark
>
> On Fri, Nov 8, 2024 at 1:37 AM Martin Braun
> wrote:
>
>> Hey Mark,
>>
>> that a
ll probably hardcode the divide of the radio clock. The end
> goal will be to use the control plane to pass the decimation factor to a
> counter so that the divide can adjust depending on the sampling rate.
>
> Mark
>
>
>
>
> On Thu, Nov 7, 2024, 5:06 AM Martin Braun wrote:
>
&
ought right now is that I need to clock the GPIO pins into a generic
> FIFO at the DDC rate with my own clock, connect that to the NOC shell and
> let the NOC shell unload the FIFO when the axis data plane is ready. Does
> this seem like a path forward? I'm glossing over a ton of the i
Sorry if unclear, I meant hard to debug just by looking at this screenshot.
--M
On Wed, Nov 6, 2024 at 10:17 AM Martin Braun wrote:
> Hey Marino,
>
> sorry, this is really hard to debug. I recommend adding lots of logging
> output in your block controller, starting with th
Hey Marino,
sorry, this is really hard to debug. I recommend adding lots of logging
output in your block controller, starting with the top of the constructor.
You can also recompile UHD to run with TRACE level logs enabled, and post
another screenshot of that here, maybe that'll help us narrow it
Actually, UHD 4.4 happens to support whatever DPDK version Ubuntu 18.04
ships. We support a reasonable range of DPDK versions (not too many, but
more than one) and when we released UHD 4.4, our internal test machines
were still running Ubuntu 18.04.
However, we didn't use the same NIC so there may
Hey Mark,
maybe I'm being dense, but I don't understand what it is that your GPIO
pins are supposed to be doing when your system is done. Can you elaborate?
--M
On Wed, Nov 6, 2024 at 1:56 AM wrote:
> Hi everybody!
>
> I’ve written an RFNOC block that assigns the daughterboard rx GPIO pins to
This is because a peek command will always wait unti it's finished, whereas
the other commands ("poke" commands) will stack in the command FIFO. If you
add the blue lines (the set_command_time() is redundant BTW) then the call
will wait until all the previous GPIO commands are finished, then it wil
On Thu, Oct 31, 2024 at 3:25 PM wrote:
> I didn’t quite resolve this, but I think I narrowed it down to some bug
> when switching between DPDK and non-DPDK drivers... I also switched back to
> the default HG image for troubleshooting. After I bind the vfio-pci driver,
> rebinding the i40e driver
The code is hard to read in the formatting that came through. But some
comments:
- start_of_burst is not actually required, that's true. It's a remnant from
the past.
- You don't send a zero after EOB, rather, you need to attach the EOB to
something. In your example, you could also attach EOB to th
Tim,
you can attach a stream tag to the sample on which the GPIO should go high
or low. The tag key should be "tx_command". The PMT format is the same as
if you were sending a message to the block. Tags get processed first
(before samples). That does mean that you need write to a block that checks
Hi,
can you provide some more info? What you're doing makes sense and is the
right approach. Are you using a regular UHD streamer? Are you using the
replay_capture.py example to get started?
-M
On Wed, Oct 23, 2024 at 6:33 AM hui cj wrote:
> Hello everyone!
>
> Given the limitation that I can
Hi Nidhi,
I was able to reproduce this error. It looks like running the equivalent
graph on the command-line example rfnoc_rx_to_file works; I'm not sure
what's up here.
If you like, you can report this on the github.com/ettusresearch/uhd issue
tracker, then you'll see what progress we make on th
If your input power doesn't vary a lot, and you can simply find a good gain
point that doesn't saturate any AGCs, then no RFNoC is required. That's
probably the easiest way. Adding an RFNoC block is not easy if you're doing
it for the first time, and you need some FPGA development experience. Of
co
I'm one of the 99% and I didn't even bother to Google what a Dicke
radiometer is. Nor do I have even half of Marcus' RF and RA knowledge.
But I know a thing or two about RFNoC. Here's what I gather from your email:
- You are capturing a radio signal from some source
- You are also generating a clo
Hi Nidhi,
X300 and X310 work the same way. In your YAML, put back some of the things
you commented out. You need at least one SEP that has the control flag set
to true. I recommend just removing the DDCs/DUCs and keeping the radios,
then add your FFT block.
--M
On Mon, Oct 14, 2024 at 9:42 AM Ni
Hey Steve,
It's difficult to do a full diagnosis here without any additional info. In
UHD 3, we used that bit to clear/flush blocks, so I'm guessing that's what
you're doing too.
You might not need the pipeline FIFOs. That's because we separated the
stream endpoints from the blocks and made the n
Are you trying to reach the N3xx? Because it shouldn't be findable by an
unqualified uhd_find_devices call if it is reachable via DPDK.
uhd_find_devices will only find DPDK-reachable devices if you specify the
full address.
--M
On Thu, Oct 10, 2024 at 3:16 PM Houshang
wrote:
> Hello
> I hereby
On Fri, Oct 11, 2024 at 6:13 AM Piotr Krysik wrote:
> Regarding ‘kas’ command - that works well with the ‘zeus’ branch of
> meta-ettus (used up to UHD 4.6). But when I switched to more recent
> ‘kirkstone’ branch - it stopped. Probably some changes are needed in
> that command. I would guess kas
Hey Piotr,
it took me a bit to respond because this is tricky question. And I still
don't have a great answer, but I also don't want to let you hang.
A few thoughts:
- Maybe you just want to write an RFNoC block that drops samples in a
regular pattern for you. That way you wouldn't rely on timed
o you think this approach might help?
>
> Any further suggestions would be greatly appreciated!
>
> Thanks!
> Jorge
>
> On Wed, Oct 9, 2024 at 3:53 PM Martin Braun
> wrote:
>
>> Jorge,
>>
>> for 4x4 mode, you need 4 ports, not 8. If you configure the replay bl
play_Block
> [2]
> https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#How_do_I_add_the_Replay.2FDMA_FIFO_block_to_my_FPGA_image.3F
>
>
> Thanks,
> Jorge
>
>
> Martin Braun 於 2024年10月4日 週五 下午11:41寫道：
>
>> Mark the last connection as a back-edge (
&g
Hi,
you can modify the existing e310 YAML files (under fpga/usrp3/top/e31x) to
add blocks, but be advised that the E310 FPGA is pretty small and you may
not fit everything.
--M
On Sun, Oct 6, 2024 at 7:29 PM wrote:
> I am looking for some e310 yaml examples to build custom fpga images, for
> a
Hey Steve,
the manual page that Marcus linked to is the right place to look. There's
also the example "remote_rx.py" that shows how to do this with a MultiUSRP
API.
Maybe this recipe helps you:
1. Write your RFNoC application as if you were streaming to the UHD host
(i.e., a standard RFNoC RX str
Mark the last connection as a back-edge (
https://uhd.readthedocs.io/en/latest/classuhd_1_1rfnoc_1_1rfnoc__graph.html#ab4cca8d99af451a9b9c5757af2b66ffa,
see also
https://uhd.readthedocs.io/en/latest/page_properties.html#props_graph_resolution_back_edges
).
--M
On Fri, Oct 4, 2024 at 4:39 PM hui c
OK here's some actual content for this thread outside of chatting about the
build system.
Pulling in features from the Xilinx fork to our X4xx kernel sources isn't
something we've had any kind of eye on, but it's interesting and we're
curious to see how this goes. It's something we'd like to see y
Be advised that bad configurations of kernel and/or FPGA (or device tree
info) can lead to boot loops which are pretty annoying to auto-fix.
--M
On Thu, Oct 3, 2024 at 6:21 PM mruane--- via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Piotr,
>
> This was especially important when dealing
Hey all,
thanks for the feedback on our build system. Mike, I'm glad to hear you
weren't put off by the `rfnoc_image_builder` workflow on top of make (I
assume you've been using that given the UHD 4.7 dependency?) and it's nice
to hear you've been successful building stuff.
I had actually checked
Hey Ryan,
Chris' solution will get you running. If you're feeling adventurous, we've
actually done a lot of work on rfnoc_image_builder since the release, so
the master branch version of UHD has a fix for this issue (no need to
downgrade ruamel.yaml), but of course it requires building UHD from so
It's the latter. As you can see, physical pin 1 for example is +3.3V, and
not a data pin (and then you need to shift the rest up).
--M
On Mon, Sep 30, 2024 at 4:05 PM Will Haftel via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Yes, I was measuring the pins with an oscilloscope while the
This looks fine. Two questions:
- Have you double-checked the pin mapping? (
https://uhd.readthedocs.io/en/latest/page_usrp_x3x0.html#x3x0_hw_gpio)
- Are you querying this during operation of your app, or do you let the app
terminate and then measure voltages?
--M
On Fri, Sep 27, 2024 at 8:59 PM
.com/schematics/x4x0/
>
> And of course, all the FPGA code is published in the GIT repo that you get
> UHD source code from.
>
>
> --
> *From:* Martin Braun
> *Sent:* Tuesday, August 27, 2024 3:45 AM
> *To:* Olo
> *Cc:* usrp-users
>
On Tue, Aug 27, 2024 at 11:34 AM Olo via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Thank you for your response and for confirming the general approach to the
> configuration. I have a couple more questions related to RFNoC,
> particularly about buffer size in SEP (Stream Endpoints) and IP
On Mon, Aug 26, 2024 at 7:14 PM Olo via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Thank you for your detailed responses to my previous questions. I
> appreciate the information provided about the limitations and potential
> issues related to FFT size and TwinRX configuration.
>
> However,
If you had a polyphase channelizer on the FPGA, that would be an efficient
solution to your problem, but there's no such block as part of UHD itself.
There have been channelizer blocks written in the wild, but that would be
something you'd have to figure out.
--M
On Tue, Aug 27, 2024 at 7:17 AM O
It's the former. More specifically, if your TX data has a time stamp, then
it will only switch over when the desired TX time is reached and the packet
actually goes out to the DAC.
--M
On Wed, Aug 14, 2024 at 3:04 AM Sathish, Aditya wrote:
> Hello,
>
>
>
> I am trying to perform spectrum sensin
Also, did you build a bitfile that includes the keep-one-in-N block?
--M
On Thu, Aug 15, 2024 at 10:08 PM Marcus D. Leech
wrote:
> On 15/08/2024 15:52, Ekin Su Sacin wrote:
>
> Hi all,
>
> I am working with USRP X310. I am trying to adjust the 'N' value for the
> KeepOneInN block but am encount
Hey Steve,
yeah you can lock two E320s to the same frequency reference. You can even
do the same for the time. The phase offsets will not be consistent between
runs or power cycles, but they shouldn't drift a lot (this is not a metric
that we have characterized though).
--M
On Thu, Aug 15, 2024
Hey Saulo,
we're currently only supporting RFNoC blocks that ship with recent UHD
versions. That block is from a UHD 3.* version.
Your build will most likely have more warnings/errors further up, maybe
there's an unconnected wire or something.
Best of luck,
--Martin
On Mon, Aug 5, 2024 at 9:55
If you don't need GNU Radio, you can run rfnoc_radio_loopback, which is an
example shipped with UHD.
--M
On Wed, Jul 31, 2024 at 1:01 PM Maria Muñoz wrote:
> Hi,
>
> I'm trying to run a gnuradio graph with Rx to Tx rfnoc radios in uhd 4.6
> new installation, but I'm having the following error:
Hi Tim,
the N230 is unsupported and EOL, so you won't get a lot of help. Just some
comments:
- You need UHD 3.15; don't try it with UHD 4. You'll probably need to build
it yourself.
- If uhd_fft works, that's good news. Device is probably fine.
- If gqrx doesn't work, maybe you have several versi
There's no WG image for N310. You can run `make help` in the
fpga/usrp3/top/n3xx directory to see available targets.
--M
On Tue, Jul 23, 2024 at 9:21 PM Giuseppe Santaromita <
giuseppe.santaromi...@gmail.com> wrote:
> Thanks. And so are WX and WG two different version of FPGA?
> Il 23/07/2024 20
Check this out:
https://github.com/EttusResearch/uhd/blob/master/host/examples/rfnoc-example/icores/x310_rfnoc_image_core.yml#L16-L35
Unit is bytes. You can try and increase it but you might have to remove
stuff from the design.
Note that I think of them as "tx buffers" (because streamer -> SEP -
Hi Emre,
you can skip Vitis and focus on Vivado for the FPGA builds. For software,
check out the examples in UHD. In fact, you should definitely get familiar
with UHD in general before trying to understand any of the lower-level
details. Check out kb.ettus.com as a place for better introduction
ma
It depends on the frequency you chose. UHD will switch between modes based
on the center frequency you choose (and the DAC rate).
--M
On Mon, Jul 22, 2024 at 6:13 PM Kaya, Altug
wrote:
> Dear USRP Mailing List Members,
>
>
>
> I would like to design a RF Front-End for the X440. I will limit the
Hi Marino,
you can use --ignore-warnings for this case. We have a fix in the pipeline
for this issue.
An explanation: There's nothing broken here, but we've added a *lot* more
checks to rfnoc_image_builder in the latest version of UHD, and we've made
it harder to accidentally build broken designs
Hi,
yes, you can, but keep in mind that switches can be additional causes for
packet loss/reordering/other things, and potentially add latency. For 10
GbE you typically have a managed switch, and you should be able to
configure it (e.g., some switches have a configuration for maintaining
packet or
/home/user/rfnoc/gr_ettus/rfnoc-nbc_v2/rfnoc/fpga/rfnoc_block_nbcv2/Makefile.srcs
has everything you expect to be there?
>
> I'll take a look at the 4.7 version as suggested.
>
Thanks -- but don't throw away your 4.6 stuff yet, depending on how much
work the transition is.
--M
A, block, and icore folders to include my
> block code. Add to the fpga/Makefile.srcs all the vhdl/verilog sources for
> my FPGA code.
> 3) Build my block
> 4) Move to the icore folder of my block and run the rfnoc_image_builder
> command.
>
> Is there something that I'm mis
Quick update for the wide world: This bug was not fixed in 4.7, but a fix
is on the way.
--M
On Wed, Jul 17, 2024 at 12:05 PM Martin Braun
wrote:
> Hey Maria,
>
> thanks for reporting this issue. Some pointers:
> - As a workaround, you can install ruamel.yaml 0.17. I don&#x
>
> Kind Regards,
>
> El mié, 17 jul 2024 a las 12:07, Martin Braun ()
> escribió:
>
>> Quick addendum: If you do update to 4.7, you will need to update some
>> image core files, because we changed stuff for X410 and X440. Best to go
>> back to the YAML file
Quick addendum: If you do update to 4.7, you will need to update some image
core files, because we changed stuff for X410 and X440. Best to go back to
the YAML files we provide in-tree and add your OOT blocks to those.
--M
On Wed, Jul 17, 2024 at 12:05 PM Martin Braun
wrote:
> Hey Ma
Hey Maria,
thanks for reporting this issue. Some pointers:
- As a workaround, you can install ruamel.yaml 0.17. I don't know how you
installed it before, but you can do `pip install "ruamel.yaml<0.18.0"` if
you used pip before.
- I need to double-check this, but I think UHD 4.7 has a fix for this.
Hi marino,
can you please share some details about how you installed UHD, and what
kind of system you have? If you run python3 -c "from uhd.imgbuilder import
grc", does that work? Is grc.py in
/usr/local/lib/python3/dist-packages/uhd/imgbuilder/ ?
We've done most of the testing on Ubuntu, but we
Check this out:
https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/top/x400/dts
The .dts files in there are no longer used with the most recent released
(and we might delete them); they get auto-generated by the RFNoC image
builder. But they're still accurate.
Most GPIOs that map into th
Hi Chris,
thanks for reporting back! mingw is not one of the compilers we test with
(it's not so long ago that it didn't even support std::thread and couldn't
compile UHD at all).
But this fix is something we can add permanently to UHD. In fact, I think
this include should come first in all the
This was the link I meant to paste:
https://github.com/EttusResearch/uhd/issues/764
On Mon, Jul 1, 2024 at 2:23 PM Martin Braun wrote:
> Erm, yes -- we managed to ship a version of rfnoc_image_builder in UHD 4.7
> which doesn't render well on dark-themed terminals. Out of all the bu
usResearch/uhddev/pull/7239
--M
On Tue, Jun 25, 2024 at 12:39 PM Martin Braun
wrote:
> Hi all,
>
> As you may have seen from the 4.7-RC1 release announcements, we have a
> bunch of updates to the RFNoC image builder. I would like to provide some
> context around those.
>
> First,
#x27;s good or bad though.) The
> new error is actually my original error I was trying to fix which got me
> into this whole mess. The message is "Error: RuntimeError: fx3 is in state
> 5". Any idea where to go from here?
> --
> Mark
> ------
>
; I may be wrong.
> --
> Mark
> ----------
> *From:* Martin Braun
> *Sent:* Friday, June 28, 2024 11:42 AM
> *To:* Mark Rosenbaum
> *Subject:* Re: [USRP-users] Bricked B210 due to wiped EEPROM
>
> Try specifying absolutely everything on the command li
Hi Mark,
b2xx_fx3_utils --init-device is your friend. After you run that, you can
run `usrp_burn_mb_eeprom` again to configure serial number etc.
--M
On Thu, Jun 27, 2024 at 8:45 PM Mark Rosenbaum wrote:
> Hi All,
> I was recently working on fixing an issue with my B210 and accidentally
> re-f
On Wed, Jun 26, 2024 at 6:52 AM Olo via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I understand that each TwinRX daughterboard provides two independently
> tunable channels, each capable of 80 MHz bandwidth. With two TwinRX
> daughterboards installed, I should be able to achieve a total of
This is a shortcoming in the example -- we try and not cover all cases to
make the examples not too bloated, but sometimes you have these corner
cases.
The reason is, the example only tunes the radio block, not the DDC block.
In a multi_usrp application, UHD would do that for you (which is what
rx
On Wed, Jun 19, 2024 at 8:37 AM Olo via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
> When I execute the following command:
> ./benchmark_rate --args="addr=,second_addr="
> --channels *"0,1,2,3"* --rx_rate *100e6* --duration 30
>
> am I testing a combined bandwidth of 4x100 MHz, which totals
Hi Dennis,
we are using kas 4.0 for development.
--M
On Mon, Jun 24, 2024 at 4:10 PM Dario Pennisi wrote:
> Hi,
> i just realized a new version of meta-ettus using
> kirkstone/uhd-4.7/gnuradio 3.10 has been released and wanted to give it a
> go but i'm struggling to fund the right version of k
Hi all,
As you may have seen from the 4.7-RC1 release announcements, we have a
bunch of updates to the RFNoC image builder. I would like to provide some
context around those.
First, we are not yet ready to ship a new version of RFNoC modtool. With
the deprecation of gr-ettus as the way to ship th
Hi Piotr,
thanks a lot for posting your solution! We will need to go back and verify
that this example works on all USRPs, not just X310.
--M
On Mon, Jun 17, 2024 at 7:24 PM wrote:
> Ok. I know what was stopping the RFNoC flowgraph after correction of the
> clock. I was setting SPP (samples-pe
Hi,
The plan (TM) is to move gr-ettus into gr-uhd, and there have been several
PRs submitted (and many of them already merged), all into main branch.
We'll be backporting to the 3.10 branch, so a future stable release of GNU
Radio 3.10 will include those changes. Long-term, we plan to retire
gr-et
https://bugs.kde.org/show_bug.cgi?id=450416
Martin Braun changed:
What|Removed |Added
Summary|Dragging in documents will |Dragging in documents will
https://bugs.kde.org/show_bug.cgi?id=450416
Martin Braun changed:
What|Removed |Added
Summary|Dragging in documents will |Dragging in documents will
https://bugs.kde.org/show_bug.cgi?id=450416
Bug ID: 450416
Summary: Dragging in documents will lock old documents so no
actions can be performed until application switch
Product: krita
Version: 5.0.2
Platform: Homebrew (mac
Jim,
just a quick follow-up. There was indeed a bug with the lo-lock sensors
which was fixed in
https://github.com/EttusResearch/uhd/commit/f36c267fc9ca908032fb719ec318c142636f
(see also https://github.com/EttusResearch/uhd/issues/534). Both the name
mismatch (lo_lock vs. lo_locked) and the la
Can you try running this in a REPL to see what the return value of
firdes.lowpass(...) is?
--M
On Tue, Jan 25, 2022 at 2:03 AM Michelle wrote:
> hello,
>
> I'm using a FIR filter and I have the error : "Param - Taps(taps):
> Expression None is invalid for type'complex_vector'."
>
> my taps is :
Hi Katja,
I was trying to figure out where that comes from. Maybe this is the key:
https://packages.ubuntu.com/jammy/libuhd-dev
This page is telling me that libuhd-dev recommends gnuradio-dev (not that
it depends on it). Maybe your script is also working on recommended
dependencies? Have you trie
Ali,
most of the time, these types of applications require the RX to be on
permanently (unless you know exactly when you're expecting packets), and
the TX only when you're transmitting packets.
In GNU Radio, this is simply achieved by using a USRP Sink and Source,
respectively. The USRP Source (R
Ali,
most of the time, these types of applications require the RX to be on
permanently (unless you know exactly when you're expecting packets), and
the TX only when you're transmitting packets.
In GNU Radio, this is simply achieved by using a USRP Sink and Source,
respectively. The USRP Source (R
Christoph,
we have occasionally heard about this issue. Can you please open an issue
on https://github.com/EttusResearch/uhd/issues. The more data we have on
this, the better. It's possible this may affect other USRPs, too.
--M
On Fri, Nov 26, 2021 at 9:10 AM Christoph Schultz (Riedel) <
christo
1 - 100 of 2917 matches
Mail list logo
