Hi Brendan,
python-uhd is well suited for this kind of use-case and these sample
rates. python-uhd is written wholey in C++. It spawns Receive and
Transmit worker threads in the background to handle the high throughput
"pulling", "pushing" and looping of samples. So, if python-uhd can't keep
up
Hi Christian,
I’m developing applications for two different platforms at the moment:
1. HP Omen laptop, Intel Core i7-8750H CPU @ 2.20GHz × 12, 32GB RAM, 512GB SSD
2. Raspberry Pi 4 Model B, 8GB RAM, 128GB SSD
In both cases the B210 is connected to the host via USB 3.0. Each host has a
1GB RA
Hi Brendan,
What is your target sample rate and number of channels? How many
bits/sample? What kind of host are you running this on?
Thanks,
-Christian
On Thu, Apr 15, 2021 at 7:30 PM wrote:
> I should clarify: The Python API that comes with the UHD driver is not an
> option here. I have trie
I should clarify: The Python API that comes with the UHD driver is not an
option here. I have tried this, and found that while it works well for
receiving very short bursts of samples, it cannot compete with the C++ API at
high sampling rates (not surprisingly).
___
Hi there,
I am trying to measure some short bursts of Rx data with my B210 at a fairly
high sampling rate. I need to perform this operation repeatedly, ideally
several times per second. The advice I have received from Ettus is that this
task is best implemented using C++.
The problem is th
What happens if you set RX Radio "Instance Select" to 0? Also try setting
the DDC's instance select to 1.
On Thu, Apr 15, 2021 at 6:33 PM Jerrid Plymale
wrote:
> Jonathon,
>
>
>
> Yes, this error still occurs if I add a copy block between the RX and TX
> streamer blocks.
>
>
>
> Best Regards,
>
Jonathon,
Yes, this error still occurs if I add a copy block between the RX and TX
streamer blocks.
Best Regards,
Jerrid
From: Jonathon Pendlum
Sent: Thursday, April 15, 2021 3:20 PM
To: Jerrid Plymale
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] Using RFNoC RX and TX blocks in o
Hi Jerrid,
Does the error still happen when you add the copy between the RX / TX
streamers?
Jonathon
On Thu, Apr 15, 2021 at 6:01 PM Jerrid Plymale
wrote:
> Hello All,
>
>
>
> I have been running into a problem this week that I was hoping to get some
> help with. I am working on transitioning
Hi Michael,
I thought about your issue when you posted it originally and again when you
reposted, but I don't really have a good feel for what's going on. From
your last email, you mentioned the "D" message which means that UHD
detected that consecutive receive packets do not have consecutive seque
Adding to what Jonathan said, if your custom block needs to know the DDC
output rate or DUC input rate, this value will be propagated automatically
through an edge property such that when the user sets the rate for the DDC,
this rate will propagate to your custom block and you can use it as you
wis
Hi Jonathon,
I appreciate your insight here, our RFNoC block will be dropping payload data
for certain amount of time but still keeping track of the timestamp and it also
modifies the CHDR header to notify the host through the RX_streamer that do not
expect to receive data setting EOB flag and
Hi Jeff,
Several RFNoC blocks haven't been ported to GNU Radio yet, but they
are planned to be in the near future.
Jonathon
On Thu, Apr 15, 2021 at 3:48 PM Jeff S wrote:
> My current versions are:
>
> Linux: Ubuntu 18.04LTS
> GNU Radio: v3.8.2.0-102-gcc5a816b
> UHD: UHD-4.0 (e520e3ff)
>
Hi Julian,
You should not need to adjust the ce_clk rate. The AXI Stream ready/valid
handshake allows you to clock your logic at a higher rate, but still have
the correct average throughput. If your block consumes the incoming samples
faster than the DDC output sample rate, your block's logic will
Hi all,
I am designing a custom RFNoC block based on RFNoC4 video which is using the
ce_clk 200MHz, please correct me if I am wrong.
That RFNoC block will be instantiated twice, one in the RX side and the other
in the TX (the core yaml file has both instances). The receiver chain will
look l
My current versions are:
Linux: Ubuntu 18.04LTS
GNU Radio: v3.8.2.0-102-gcc5a816b
UHD: UHD-4.0 (e520e3ff)
gr-ettus: maint-3.8-uhd4.0 (1038c4ce)
The UHD and gr-ettus repositories seem to have the RFNoC blocks, in particular,
the FIR filter (the one I'm interested in). But they don't see
Has anyone had any ideas on how to address this issue?
I'm not sure if my issue is the same as Paolo is seeing or not, but after
debugging some more, I did have an additional question I was hoping someone
could help me with. As I mentioned, the data stream I'm sending to the
AXI_Wrapper seems t
I am working on some existing code of RfNoC on UHD_3.15.0 to process the
incoming rx data stream.
The CHDR wrapper/unwrapper makes use of the TLAST signal. For a stream of
continuous ADC samples, there is no obvious data block boundary such as each
line/frame commonly in video. I didn’t study t
Any updates on this? Anyone have a fix for the ftw segfaults?
Philip
On 10/2/20 7:48 PM, Jonathon Pendlum wrote:
> Hey Philip,
>
> You are not the only person to report this. I'm working on getting an
> answer, but it will take a bit longer.
>
> Jonathon
>
> On Thu, Oct 1, 2020 at 10:46 AM Phi
Hello Dylan, thanks these were the files I was looking for!
I can edit the default network config from now on.
Best,
Anthony
Le jeu. 15 avr. 2021 à 11:53, Dylan Baros a écrit :
> Hey Anthony, Try editing the files in /data/network.
> -Dylan
>
> Sent from my iPhone
>
> On Apr 15, 2021, at 4:09 A
Hello all,
I meet some streaming issues with a USRP N310 I'd like to further
investigate.
Currently I am only using a 1Gb link with the SFP0 port. I set up the
network config following this :
https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Setting_Up_a_Streaming_Connection
It
20 matches
Mail list logo
