If you don't get any responses here, maybe try the discuss-gnuradio mailing
list.
--M
On Sat, Feb 1, 2025 at 5:20 AM wrote:
> Hi,
> I want to generate LoRa burst signal in USRP B205Mini. For that i am
> using GNU Radio. By default, there is no LoRa Tx and Rx blocks in that
> tool. So, I dow
Tim,
it looks like you're doing everything correctly. What's the filename of the
cal file (you can blank out the serial)?
Are you building from source? If so, can you please recompile with
cmake -DUHD_LOG_MIN_LEVEL=trace
and set the environment variables
UHD_LOG_LEVEL=trace
UHD_LOG_CONSOLE_LEV
Hi David,
and sorry for stumbling over the lack of documentation for this (fairly
new) tool. Yes, the idea is that you create the YAML. rfnoc_modtool add
will then generate the HDL, noc_shell, block controller templates, etc.
We've been internally discussing a kind of YAML creation wizard -- woul
You can theoretically connect the radio0 and radio1 I/O ports directly to
your block, and keep the ctrlport connections so that you can do tunes etc.
I would *not* recommend this. We've done loads of tests regarding
time/phase alignment on X310. If you feed data into the radio blocks with
identical
Follow these instructions:
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Downloading_the_UHD_FPGA_Images
Then these:
https://uhd.readthedocs.io/en/latest/page_usrp_x3x0.html#uhd_image_loader_tool
--M
On Mon, Jan 27, 2025 at 3:57 PM wrot
The mask affects the bits that you actually write to the attribute. In this
case:
uhd_usrp_set_gpio_attr(usrp, bank, "DDR", 1, 0x02, mboard);
...you're setting the DDR register to 0x01 and the mask to 0x02. 0x01 &
0x02 == 0, so you're not setting anything.
This works:
uhd_usrp_set_gpio_attr(usr
Dominik,
can you provide as much info as you can here:
https://github.com/EttusResearch/uhd/issues/818?
Like Marcus said, the PCIe interface is not used a lot (except by LabView
users), so if you can use 10 GbE instead I recommend doing that (that also
allows you to do 2x200 Msps streaming, if yo
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
r application is going into shutdown,
and you want to cleanly exit the transmit thread.
Side note: You don't need to specify `enable_fc` (it's on by default), and
you don't need to specify `full_packet` either (that's only relevant for Rx
raw UDP streaming).
--M
On Wed, Jan 8,
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
then something is wrong with the hardware demon. If you
cannot even connect via ssh then it is most probably an issue with the network
connection. There is a serial console available which you can use to debug in
that case. This is explained in the knowledge base article, too.
/Martin
From: Muh
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
On Fri, Nov 8, 2024 at 8:42 PM Mark Gannet wrote:
> Hi Martin,
>
> Sorry I called you Marcus earlier, I was probably thinking of Marcus of
> GNURadio. Two things:
>
That's OK, both our GNU Radio Marcuses are very smart fellas :)
1. Is it safe to assume that packets on th
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:
>
&
t 7:45 PM Mark Gannet wrote:
> Hi Martin,
>
> Sorry I should've elaborated on my purpose.
>
> I'm using a device to connect external TTL signals to the RxBasic
> daughterboard GPIO pins on chA of the x310. I'm stealing an analog channel
> on the x310 to capture
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
;t have to build your own
bitfile.
--M
On Fri, Oct 11, 2024 at 2:03 PM Jorge Chen wrote:
> Hi Martin
>
> Thank you for your reply. I understand the N310’s default Replay block has
> 4 input and 4 output ports. In my setup, I connect the tx_streamers to the
> Replay block’s input
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
and if this
would make things easier for folks, that could be something we do going
forward.
Whichever way we go -- of course you need to pull in patches from the right
kernel version. If that's something people struggle with, maybe we can make
that clearer? Just fishing for thoughts and/or su
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
"interesting" bits of the X440 are in the RFSOC, which is
> linked here:
>
> https://docs.amd.com/r/en-US/pg269-rf-data-converter/Conventions
>
> There's Martin Brauns GRCON talk here:
>
>
> https://events.gnuradio.org/event/21/contributions/392/attachments/1
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,
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:
-BC2322AEBBDE
and also, from the KB article which differentiates between different frequency
ranges.
/Martin
INTERNAL - NI CONFIDENTIAL
From: Kaya, Altug
Sent: Friday, August 9, 2024 4:59 PM
To: Martin Anderseck ; Panuski, Patrick
; usrp-users@lists.ettus.com
Subject: RE: X440 Tx and Rx Power
nd RX, but the X440 should not be
able to destroy itself even without this.
/Martin
From: Kaya, Altug
Sent: Monday, August 5, 2024 12:40 PM
To: Panuski, Patrick ; usrp-users@lists.ettus.com
Subject: [USRP-users] Re: X440 Tx and Rx Power Constraints
Hi Patrick,
Thank you for your detailed a
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
The NI-USRP configuration utility should be part of the NI-USRP tool chain:
https://www.ni.com/en/support/downloads/drivers/download.ni-usrp.html#484354
/Martin
INTERNAL - NI CONFIDENTIAL
From: Dr. Scott Best via USRP-users
Sent: Wednesday, July 24, 2024 2:03 PM
To: martin.br...@ettus.com
Cc
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
Hi Altug,
Yes, that’s it, with the extension that for all frequencies that fall into
other Nyquist zones than zone 1 we use the mix mode as you can see here:
https://github.com/EttusResearch/uhd/blob/master/mpm/lib/rfdc/rfdc_ctrl.cpp#L528-L544
/Martin
INTERNAL - NI CONFIDENTIAL
From: Kaya
t;
> What about 1) *FPGA Rx Buffer Size:*
>
>-
>
>What is the FPGA Rx buffer size on the X310?
>
>
> I honestly don't know, and I'm not an FPGA guy, so diving into the FPGA
> code likely won't enlighten eit
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
On Thu, Jul 18, 2024 at 3:06 PM Maria Muñoz wrote:
> Hi Martin,
>
> Oh! I didn't know there was a debug option. The line says this:
> [DEB] Executing the following command: /bin/bash -c ". ./setupenv.sh &&
> make X440_X4_200
> IMAGE_CORE=/home/user/rfno
ed.
--M
On Thu, Jul 18, 2024 at 11:32 AM Maria Muñoz wrote:
> Hi Martin,
>
> I had another issue once I resolved the YML problem. I start the synthesis
> with this command:
>
> rfnoc_image_builder -y x440_200_nbc_rfnoc_image_core.yml -d x440 -t
> X440_X4_200 --fpga-dir ~/rfn
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
In that case you can just do
apt install python3-ruamel.yaml
and make sure you have no other version installed.
--M
On Wed, Jul 17, 2024 at 12:22 PM Maria Muñoz wrote:
> Hi Martin,
> .
> Thanks for your answer. I will do the workaround.
> By the way, I'm using Ubuntu 20.04.
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
has a fix for this. If
not, we will need to fix this ASAP (note to myself)
Can you provide some info on your system (OS, distribution, etc.)? Many
thanks,
Martin
On Wed, Jul 17, 2024 at 11:05 AM Maria Muñoz wrote:
> Hi all,
>
> I'm trying to use the UHD 4.6 version with RFNoC
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,
Sorry, that error can mean a bunch of things. It might be faulty hardware,
unfortunately.
--M
On Fri, Jun 28, 2024 at 6:19 PM Mark Rosenbaum wrote:
> Martin,
> I actually re-ran the command you asked me too again just to make sure and
> I have a different error now!(Not sure if that&
Yeah that's probably the last resort. Just hard-code all product IDs and
whatnot until it works. Good luck!
--M
On Fri, Jun 28, 2024 at 5:52 PM Mark Rosenbaum wrote:
> Martin,
> Just tried exactly that to no avail. Gives the exact same error. Is
> there any way to maybe modi
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
I'll leave it at that. This is a good place to ask questions about these
updates -- I'll try and cover them!
Cheers,
Martin
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
1 - 100 of 475 matches
Mail list logo
