[USRP-users] Re: Subject: Inquiry Regarding Maximum FPGA Buffer Capacity for Transmission on USRP X310  

A couple of questions: is this for single channel or both channels? what is your sample rate? which version of UHD? Do you happen to know if the replay block is inline with your transmit path (used as a large FIFO buffer)? Part of the motivation for these questions is that the DRAM on the X310

[USRP-users] Re: Underflow Issue During Transmission and Reception with USRP X310

I will add that if your waveform is repeating (I noticed the --repeat flag), you can alternatively use the Replay block to playout your Tx waveform. With this block you load the samples in the Replay block memory in non-realtime and then you can initiate the playout to the radio and avoid all under

[USRP-users] Re: X410 SPI clock rate

t; > Which UHD version are you using? > > I suggest opening an issue on https://github.com/EttusResearch/uhd/issues. > If you can, share your code for configuring the SPI rate and the the > oscilloscope screen shot. > > Thanks, > > Wade > > On Thu, Jun 26, 2025 at

[USRP-users] Re: X410 SPI clock rate

ould actually be (Radio_Clk / (divider + 1)) / >> 2. >> >> That seems to agree with what you're seeing? Just to confirm, can you >> share the URL for the documentation with this equation? >> >> Wade >> >> >> >> On Wed, Jun 25, 2025

[USRP-users] X410 SPI clock rate

Hi, The equation in the UHD manual for the X410 SPI clock rate is: SPI_clk = Radio_clk / (divider + 1) However, I'm seeing half of that rate if I use the function: Radio_clk = usrp->get_radio_control()->get_rate(); Note that this returns the sample rate. I'm wondering if maybe the radio clock

[USRP-users] Re: X410 100Gb link issue

don't really have an explanation why the CWDM4 model does not work in the X410. Rob On Fri, Jun 20, 2025 at 4:19 PM Rob Kossler wrote: > Hi, > I just received an X410 and I am having trouble getting the 100Gb link to > work. > >- On the workstation side, my NIC is an Intel E81

[USRP-users] X410 100Gb link issue

Hi, I just received an X410 and I am having trouble getting the 100Gb link to work. - On the workstation side, my NIC is an Intel E810 CQDA2 and I am using UHD-4.8 with Ubuntu 24.04 LTS - On the X410 side, I loaded the UHD-4.8 file system and the UC_200 FPGA image which implements 100

[USRP-users] Re: tx_offset and rx_offset parameter usage on UHD calibration utilities

Tom, The issue is that the analog bandwidth of the UBX-40 is only 40 MHz. The LO is always the center of your analog bandwidth. See this diagram. Thus your LO offset is restricted as follows: LO-offset <= (AnalogBW - SignalBW) / 2 In your case your s

[USRP-users] Re: X310 UBX Tx issues

you mentioned wbx and ubx, but each of these have 2 variants: wbx-40, wbx-120 and ubx-40, ubx-160. If you were previously using wbx-120 and you switched to ubx-40, then this would explain your problem with LO offset of 22 MHz since the analog bandwidth is only 40 MHz on this card. On Wed, Jun 11,

[USRP-users] Re: Curious energy spikes from my X310

t; to include the higher level C++ constructors. > My luck. Both issues have to do with the C API:) > Sampling rate is very important, but not useful in this case. > I leave it on auto. RF is on manual:) > > BR > Nikos > > On Fri, May 23, 2025 at 7:59 PM Rob Kossler wrote: > >

[USRP-users] Re: Curious energy spikes from my X310

io to set the LO and to the DDC to set the desired DSP frequency shift that will compensate for the LO being offset. Rob On Fri, May 23, 2025 at 12:55 PM Rob Kossler wrote: > Hi Nikos, > Although I have not used the 'c' API, it appears it can do the same thing > as the c++ A

[USRP-users] Re: Curious energy spikes from my X310

s:( > I am also looking to export as C API the tune_request(freq, lo_off) C++ > constructor. > This will mean to change code in uhd, which I will eventually have to, but > right now, > getting uhd_usrp_get_rx_lo_names() to work, is better:) > > BR > Nikos > > > >

[USRP-users] Re: Curious energy spikes from my X310

Hi Nikos, Your RF card has 120 MHz bandwidth. The strong tone you see will always be at the center. But, if your application can tolerate using an instantaneous bandwidth < 60 MHz, you can use offset tuning as Marcus mentioned. To do this you simply need to create a tune request with your desire

[USRP-users] Re: [EXTERNAL]Re: rfnoc loopback to tx ports, and other warnings

If you haven't seen it, the stock example rfnoc_radio_loopback might be helpful to look at. This should work with a stock image to show a simple loopback from Rx to Tx. If you modify freqs (ddc/duc or radio f

[USRP-users] Re: clarification of timestamp calculations

Note that every packet doesn't need to have a time stamp (assuming that the previous packet does not have EOB set). If the first packet has a timestamp and is not the final packet in a burst, then the subsequent packet will be assumed to be continuous to the previous packet such that no new timest

[USRP-users] Re: rfnoc loopback to tx ports, and other warnings

Hi Kevin, Try issuing the stream command directly on the Radio block rather than the rx_streamer. I don't know why you are getting the warnings you are getting, but trying this step might produce a different result. On another note, since you are using timed commands, there will be a time stamp i

[USRP-users] Re: Signal quality using RFNoC DUC blocks

I think that some of the convenience mechanisms that you might see in the examples (such as passing a tune request through the streamer) are likely only helpful in a "typical" graph. In your graph with 4 DUC ports connected to 1 Radio port with AddSub blocks to add the 4 DUC ports together, it is n

[USRP-users] Re: Signal quality using RFNoC DUC blocks

Have you seen these topics in the manual? tuning notes synchronizing phase On Tue, May 20, 2025 at 5:10 PM wrote: > Where can I find more info about the fine frequency t

[USRP-users] Re: [EXTERNAL] Tx example with RFNoC missing

One good place to check for how to operate with RFNoC is the source file " multi_usrp_rfnoc.cpp ". Under the hood, the multi_usrp object used by most users for a stock FPGA image implements all functionality using

[USRP-users] Re: Help with AXI-Stream Output in Schmidl & Cox RFNoC Module: deadlock when marking some samples as no valid

> > If you have any ideas or insights, I’d be happy to investigate further. > > Best regards, > Quentin > > On 4/17/25 17:58, Rob Kossler wrote: > > > Vous n’obtenez pas souvent d’e-mail à partir de rkoss...@nd.edu. Pourquoi > c’est important <https://aka.m

[USRP-users] Re: Help with AXI-Stream Output in Schmidl & Cox RFNoC Module: deadlock when marking some samples as no valid

Hi Quentin, Perhaps your issue is related to the 'length' parameter of the RFNoC packet? If you are not correcting the packet length based on the number of samples you are dropping, then you will get ill-formed packets coming out. Do you think that this could be the issue? Rob On Thu, Apr 17, 202

[USRP-users] Re: 100Gb NIC for X410

S/s aggregate) is 64 Gb/s and thus well > within the capabilities of a single 100 Gb port on either NIC ... That's > fine for an X410. For an X440 we double that to 4 GS/s aggregate, which > clearly requires 2x 100 Gb links. For this use-case the Mellanox NICs are > the way to go. >

[USRP-users] Re: [X310] set_command_time introduces unexpected delay dependent on sampling rate.

On Wed, Mar 26, 2025 at 10:43 AM Marcus D. Leech wrote: > On 26/03/2025 06:13, je.amg...@gmail.com wrote: > > > > I'm using timed commands to set the RX gain at a precise moment with > > the following command: > > > > set_command_time(md.time_spec + uhd::time_spec_t(0.02), 0); > > > > However, I

[USRP-users] Re: [X310] set_command_time introduces unexpected delay dependent on sampling rate.

On Wed, Mar 26, 2025 at 12:32 PM Marcus D. Leech wrote: > On 26/03/2025 12:09, Rob Kossler wrote: > > > > > Hi Marcus, > I think that the gain is set from the "radio" block which operates at the > master clock rate rather than the downconverted rate. It

[USRP-users] 100Gb NIC for X410

Hi, I am in the process of purchasing a 100Gb NIC for use with the X410 and have seen documentation and previous posts indicating that the ConnectX NICs are preferred. But I did note in the DPDK knowledge base article that the Intel E810 could also work. I prefer the E810 because it seems to be le

[USRP-users] Re: How to record all 4 channels from an X410

Hi John, Did you see this link ? Rob On Tue, Mar 18, 2025 at 10:49 AM Mann, John - 0662 - MITLL wrote: > I am trying to create a simple gnuradio-companion flowgraph that uses a > Multi-USRP block to record all 4 ch

[USRP-users] Re: X310 transmit multi streams on single radio channel

One more thing. I would start as small as possible. Just add one addsub block and one null src sink and see if you can get it working with 2 tx streams. On Fri, Mar 14, 2025 at 10:06 AM Rob Kossler wrote: > > On Fri, Mar 14, 2025 at 5:57 AM wrote: > >> Thank you for your an

[USRP-users] Re: X310 transmit multi streams on single radio channel

On Fri, Mar 14, 2025 at 5:57 AM wrote: > Thank you for your answer, > > I’m following your directions and I’m creating the yaml file with the > relevant elements in it, however since it is the first time that I create > such a file I’m facing some difficulties: > > -The 4 port DUC will need 4 new

[USRP-users] Re: X310 transmit multi streams on single radio channel

Hi John, I think you will need to build your own RFNoC image, but you could probably do it with stock blocks such that you don't need to develop a new block. If you built a 4-channel DUC with each input tied to an SEP (as you suggested) and each output tied to inputs of AddSub blocks. You would nee

[USRP-users] Re: OFDM Reciever chain on USRPx310

Hi Quentin, I don't know what OFDM blocks are available. But, regarding your questions about getting started with RFNoC, you will want to use the RFNoC Specification document along with reviewing the XML blocks that Ettus developed for the various included blocks such as FFT, FIR, SplitStream, etc.

[USRP-users] Re: strange behavior related to gain

With an FMCW radar and a matched filter, the leakage signal will be at a different range (close to zero range) than the targets. So, you could just ignore this range region of your results. But, if the leakage signal is strong enough to either saturate the A/D or to cause the corresponding range

[USRP-users] Re: strange behavior related to gain

If you are using timed commands and if you can verify that the tx-to-rx synchronization is consistent every time, perhaps you could measure the leakage signal (with attenuators connected to the RF ports) and then simply subtract this signal from your over-the-air measurements. This method of leaka

[USRP-users] Re: High power TX/RX same antenna

If you are using TDD, you may need a T/R switch to switch out your receiver during transmission. If you are using FDD, you may need a diplexer. Rob On Mon, Feb 17, 2025 at 11:20 AM Stuart Austin < saus...@criticalsoftwaresystems.com> wrote: > Can you just add more attenuation between the output o

[USRP-users] Re: synchronization betwen TX and RX

Hi Michał, You will need to use timed commands for both the tx and rx. And, you will need to do more than just set them both to start at zero. Instead you need to read the current time (get_time_now), add an offset, and then set the "start_time" for both tx and rx equal to the current time plus off

[USRP-users] Update for AN-956, OAI Ref Arch 5G ?

I am wondering if there is an update in the near future for AN-956, OAI Reference Architecture for 5G and 6G Research with USRP. If there is anything presently in draft form, I am wondering if you would be willing to share it prior to release. I am just starting to work with OAI software and I no

[USRP-users] Re: Underflow reported on first packet

Hi Eugene, Is it possible that the overflow occurs because of the previous command still being in the queue such that at 30 seconds it starts streaming with nothing to catch it? Rob On Mon, Jan 20, 2025 at 6:26 PM Eugene Grayver wrote: > Hi, > > Using UHD4.6.0 on ubuntu 22.04 with X310 (same iss

[USRP-users] Re: X310 Bursts/Buffering with Timestamp data

Interesting. I would have expected approximately 125K packets could be stored in this FIFO given that it is 1GB and the packet size is perhaps 8000 bytes. The DRAM memory is equally divided up in order to support multiple channels with a FIFO for each channel. This memory allocation algorithm is b

[USRP-users] Re: X310 Bursts/Buffering with Timestamp data

Perhaps the graph is not really created until you call get_tx_stream() such that you need to pass the argument to this call?? On Thu, Jan 9, 2025 at 10:24 PM wrote: > Hi Rob and Team, > > I enabled the streamer=replay_buffered option as shown below. However, I > did not notice any difference, a

[USRP-users] Re: X310 Bursts/Buffering with Timestamp data

Hi Neal, I want to modify what I previously said about DRAMFIFO. In recent UHD versions, the Replay block has taken on the functionality of what used to be the DRAMFIFO (i.e., the Replay block can act as a FIFO using the onboard RAM). There is apparently a tx_streamer stream arg "streamer = replay

[USRP-users] Re: X310 Bursts/Buffering with Timestamp data

The X310 buffering depends on whether or not you are using the DRAMFIFO as part of the RFNoC flow. If so, then this buffer alone is 1GB, I think (250 MSamps). But, you can't use this if you are running two channels at 200 MS/s, because the DRAM bandwidth is not sufficient. If you are running the

[USRP-users] Re: Fw: Re: Issue with Starting Transmitter on USRP N300 without Using Streamers

Hi Nidhi, It seems you are connecting things correctly - I'm not sure why you are getting that error. Rob On Fri, Dec 13, 2024 at 4:48 AM Nidhi Panda wrote: > > -- > *From:* Nidhi Panda > *Sent:* Friday, December 13, 2024 11:14 AM > *To:* Rob K

[USRP-users] Re: Issue with Starting Transmitter on USRP N300 without Using Streamers

As a test case, perhaps try a graph where the Tx and Rx channels are not the same. On Thu, Dec 12, 2024 at 7:04 AM Nidhi Panda wrote: > Tried the way you suggested. Still getting same error. Please check if > it's correct. > > > -- > *From:* Martin Braun > *Sent:* Th

[USRP-users] Re: Issue with Starting Transmitter on USRP N300 without Using Streamers

On Fri, Dec 6, 2024 at 9:44 AM Rob Kossler wrote: > > > On Fri, Dec 6, 2024 at 6:27 AM Nidhi Panda > wrote: > >> I am currently working with a *USRP N300 device with uhd 4.7 and gnu >> radio v3.11.* I have created a simple loopback configuration in which >> the

[USRP-users] Re: Issue with Starting Transmitter on USRP N300 without Using Streamers

On Fri, Dec 6, 2024 at 6:27 AM Nidhi Panda wrote: > I am currently working with a *USRP N300 device with uhd 4.7 and gnu > radio v3.11.* I have created a simple loopback configuration in which > the data flows through the following blocks: > Rx_Radio > DDC > DMAFifo > DUC > Tx_Radio. > However,

[USRP-users] Re: Assistance with RFNoC and TwinRX Configuration in Custom FPGA Image

On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech wrote: > On 26/08/2024 10:21, Rob Kossler via USRP-users wrote: > > Hi Olo, > On one point regarding an FFT length of 8192, there is likely an issue > with using the Ettus FFT block. In the past (I haven't checked recentl

[USRP-users] Re: Assistance with RFNoC and TwinRX Configuration in Custom FPGA Image

Hi Olo, On one point regarding an FFT length of 8192, there is likely an issue with using the Ettus FFT block. In the past (I haven't checked recently), this block was limited to a maximum FFT size of 1024 because the entire FFT had to fit in one packet where the maximum packet payload was about 20

[USRP-users] Re: X310 Buffers - 200Msps

Hi, regarding FPGA Rx buffer, I am wondering if you can use the DRAM as a buffer (e.g., host_tx => dram => duc => radio_tx). As far as I remember, you can't use the DRAM as a FIFO if you are running 2 channels both at 200 MS/s. The DRAM FIFO bandwidth is insufficient. But, if your data rate is le

[USRP-users] Re: Recording and playing back RF Activity

On Tue, May 21, 2024 at 9:34 PM Marcus D. Leech wrote: > > On 21/05/2024 21:05, Hamid Niknami wrote: > > Thank you for your reply. REgarding the write speed, I assume that fast SD;s > should be able to easily do that: > > The NVMe Gen4 x4 interface delivers extreme performance of up to 7,500MB/s

[USRP-users] Re: Sharing one UHD device across multiple hosts

On Sun, May 5, 2024 at 4:47 PM Marcus D. Leech wrote: > > On 05/05/2024 16:00, Marcus Müller wrote: > > That alternate streaming target functionality re-emerged in later UHD > > versions for RFNoC-supported devices. > Is there an example of this somewhere? I only vaguely remember seeing > this...

[USRP-users] Re: Freq synchronization between two X310s

34:15 BST, Marcus D Leech < > patchvonbr...@gmail.com> wrote: > > > It’s also why you can’t get tight instantaneous phase alignment between > two GPSDO devices even when on the same antenna. > > Sent from my iPhone > > On May 1, 2024, at 2:12 PM, Rob Kossler wrote:

[USRP-users] Re: Freq synchronization between

The 10 MHz ref supplied to each X310 device is used in a PLL in each device to obtain the 10MHz ref used for that device (and for disciplining the various LOs on the device). Thus, there is a relative phase "wobble" between the 10MHz ref signals used on each device as each PLL continuously adjusts

[USRP-users] Re: Unbalanced power among antennas in X410

The plot is titled "Real". If this is simply the real component of a complex signal, then it is not possible to know the magnitude. If there is a phase shift, then the power may have shifted into the "Imag" component. Instead, plot the abs if you are interested in only power differences among chann

[USRP-users] Re: Extending duration of high-rate captures with the X410

I think I am mistaken. If you are only streaming a single channel, the --multi_streamer option will likely not change a thing. I was assuming you had multiple channels. Rob On Tue, Mar 12, 2024 at 5:40 PM Rob Kossler wrote: > Your mount command with tmpfs looks correct. Here is what mine is

[USRP-users] Re: Extending duration of high-rate captures with the X410

Your mount command with tmpfs looks correct. Here is what mine is in my /etc/fstab file (with 264GB avail RAM) tmpfs /media/ramfolder/ tmpfs rw,nosuid,nodev,size=200G 0 0 You might want to try rx_samples_to_file with the --multi_streamer option. I expect you will get better performance. Als

[USRP-users] Re: Extending duration of high-rate captures with the X410

Hi Zack, I would not count on equal performance between saving to a RAM file system versus allocating your own buffers, but I don't know the reason. I think it is worth a try to configure as large a RAM file system as you can and run rx_samples_to_file (which will not create large RAM buffers). Pl

[USRP-users] Re: Extending duration of high-rate captures with the X410

So, if benchmark_rate can run successfully, maybe try rx_samples_to_file with saving the dev/null or with saving to files in a RAM file system. This will limit your capture depth to the size of the RAM. If this works, then it is a challenging issue to save to permanent storage. Perhaps DPDK will wo

[USRP-users] Re: Extending duration of high-rate captures with the X410

Hi Zack, I don't know the answers to your issues, but I'm wondering if you can just use benchmark_rate rather than your custom code to evaluate performance. If benchmark_rate can't run at the rate you want, it is unlikely that your custom code will succeed. Rob On Mon, Mar 11, 2024 at 2:35 PM wro

[USRP-users] Re: X310

The IP address of 192.168.10.2 and the MTU size of 1472 indicate that your link is a 1Gb link. The max rate this can support is 25MS/s. You will need to connect at 10Gbe if you want to run at 100MS/s. Rob On Wed, Mar 6, 2024 at 2:31 PM White, Joshua J < jjwh...@riversideresearch.org> wrote: > The

[USRP-users] Re: OFDM signal transmission by x310 presents a peak

This link indicates that the antenna ports are to remain unconnected. Since there is no internal loopback path, I believe that the calibration algorithm utilizes the "leakage" signal which is apparently strong enough such

[USRP-users] Re: Multiple Streamers

Hi Zach, There can definitely be multiple tx streamers (& rx streamers). Take a look at the Ettus rx_samples_to_file example which does this with rx streamers. You are probably doing everything right already. The documentation might be just poorly worded such that maybe it should say that you can

[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?

But it should. This is basic functionality that is completely broken. The commit to fix it is simple. On Fri, Feb 9, 2024 at 10:06 AM Marcus D. Leech wrote: > On 09/02/2024 09:07, Rob Kossler via USRP-users wrote: > > This is fixed in 4.5 and 4.6. Are you able to switch? > Rob

[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?

This is fixed in 4.5 and 4.6. Are you able to switch? Rob On Fri, Feb 9, 2024 at 5:04 AM wrote: > Hi, > > I am facing the same problem. > > I am on a Linux machine and hardware is an X300 with a UBX160. > > When I am above 500 MHz the actual carrier freq becomes about 2000 MHz > smaller. > > I

[USRP-users] Re: Align multi-channel captures with different rx_stremers

On Tue, Feb 6, 2024 at 5:50 PM wrote: > > It’s an estimated difference using a GPS SDR I have access to, not the > timestamps in the metadata. > > I just tired choosing different sampling rates, it seems like when I use > pairs of sampling rates corresponding to odd divisions of the master clock

[USRP-users] Re: Align multi-channel captures with different rx_stremers

You mentioned a difference of 732ns. Is this a measured difference or is this the difference in the timestamps contained in the metadata for the 2 streams? On Tue, Feb 6, 2024 at 5:23 PM wrote: > If I do thing concurrently (same thread, same rx_streamer) would that > solve the timing issue? For

[USRP-users] Re: Getting Dropped packets

On Wed, Jan 24, 2024 at 2:43 PM Marcus D. Leech wrote: > > On 24/01/2024 13:00, jmalo...@umass.edu wrote: > > > > Hello, > > > > > > I currently have an application where I am burst receiving(about 80 > > micro per milli second) with the ettus X410 at the full sample rate > > across 4 channels. I

[USRP-users] Re: Getting "S" error when using dpdk and replay block

Hi Joe, The "S" errors imply that the receiver of a packet has detected that incoming packets are out-of-sequence. Each successive packet is sequentially numbered so if everything goes well, the receive side should receive the packets in sequential order. If you are sending from your host to the

[USRP-users] Re: Bug/problem aligning PPS to samples

Hi Eugene, Are you expecting that the RF output (for Tx case) should be synced to the PPS "at the RF output connector"? It is my understanding that the sync occurs at some place in the FPGA logic for the "radio" block. There will be delay as this goes through D/A and RF chain. Same in reverse for

[USRP-users] Re: streamer error X310

the OS version with Ubuntu 22.04 and UHD to version > 4.5.0. Although I get overflows I no longer get the error I had before. > > I appreciate your help. > > Regards, > Anabel > > El mié, 20 dic 2023 a las 15:55, Rob Kossler () escribió: > >> I am not certain, but I be

[USRP-users] Re: Benchmarking x410 with Mellanox with DPDK

Hi Joe, Perhaps you need a different "mgmt_addr" and "addr"? I seem to recall that it was necessary to have a management address that was the typical RJ45 and then a data streaming address that went to the high speed IO. My memory is for the N series USRPs - I have no experiment with the X410. Ro

[USRP-users] Re: streamer error X310

gt; error.[00:00:04.993254D] Detected Rx sequence error.[00:00:04.993310] > Detected Rx sequence error.D[00:00:04.993366] Detected Rx sequence > error.DD[00:00:04.993411] Detected Rx sequence error.[00:00:04.993465] > Detected Rx sequence error.D[00:00:04.993521] Detected Rx sequence &

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph.

OK. So, the error you get with "uhd_image_loader" is caused by a "bad build" that occurs if the option DRAM=1 is not included when using the Replay block. I do not know why that the build itself does not fail, but that is the case. Thus, you still don't have a valid FPGA build for the E310 with th

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph.

Hi Muhammad, Originally, you had some build errors such that the design "didn't fit" on the FPGA. How did you fix these? From previous experience, I discovered that it was necessary to use the option DRAM=1 when building the E31x with the Replay block. I see that in your YML, this option is incl

[USRP-users] Re: Error: RuntimeError: Failure to create rfnoc_graph.

Hi, Can you attach the YML file you are using to build the image? Also, I notice that you are trying to load a file out of the "../top/e31x/build-E310_SG3/" folder rather than the "../top/e31x/build/" folder. At the conclusion of the build, the outputs are copied into the "build" folder. I doubt t

[USRP-users] Re: streamer error X310

mestamp match could not be determined.D[ERROR] > [STREAMER] The receive packet handler failed to time-align packets. 1002 > received packets were processed by the handler. However, a timestamp match > could not be determined.^CReceived 15208 samples in 6.703929 > seconds29.8325 Msp

[USRP-users] Re: streamer error X310

n 'O' and 'D'. > > From what I understand the program is set up for a single channel, so I > need to modify it to get more than one. > > Thank you in advance. > > Regards, > Anabel > > El vie, 15 dic 2023 a las 15:39, Rob Kossler () escribió: >

[USRP-users] Re: streamer error X310

ied the streamer, the pointer buffer, and added writing files. > > my line is > *$sudo ./rx_samples_to_file_v1 > --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=9" > --subdev="A:0 A:1 B:0 B:1&

[USRP-users] Re: streamer error X310

irty_ratio=80; > sudo sysctl -w vm.dirty_background_ratio=50*), but I still get the same > problem. > > Regards, > Anabel > > El jue, 14 dic 2023 a las 15:38, Rob Kossler () escribió: > >> Hi Anabel, >> How are you sync-ing the clocks on the two units? Do you hav

[USRP-users] Re: streamer error X310

Hi Anabel, How are you sync-ing the clocks on the two units? Do you have an external PPS source and are you configuring both devices to use this external source? Finally, do you have the ability to upgrade your OS and your UHD versions? There aren't many user's that are using UHD 3.12 so if you ha

[USRP-users] Re: Read user registers with RFNoC

Take a look at the block controller for the UHD example "gain" block found here . Note how this block doesn't even bother with creating a property. Instead there is simply a set and get function

[USRP-users] Re: Read user registers with RFNoC

Yes, I think that moving out of gnuradio - at least temporarily - is a good idea. Once you have the block working directly with UHD, it will make the transition to gnuradio easier. That said, I did take a quick glance at gnuradio and noticed that the rfnoc_ddc class has a function "set_freq" and I

[USRP-users] Re: Error while running command "rfnoc_image_builder -y ./e310_rfnoc_image_core.yml"

Wade, With current versions of the replay block supporting a FIFO mode, is there any reason why Ettus does not include a statically linked Replay block as part of the default image for the E310? Rob On Tue, Dec 12, 2023 at 2:18 PM Rob Kossler wrote: > A while back, I built an E310 image us

[USRP-users] Re: Error while running command "rfnoc_image_builder -y ./e310_rfnoc_image_core.yml"

A while back, I built an E310 image using "static" linking. This allowed me to include a 2 channel replay block with a 2 channel radio. The yml may require an update or two to work with the current UHD version, but see if you can build an image with static links. Keep in mind that with static lin

[USRP-users] Re: Read user registers with RFNoC

Hi Maria, The UHD "register_property" callback function (in this case a lambda function that calls peek) only gets executed when the "dirty" property gets marked "clean". Otherwise, if you query the property when it is already considered "clean" by UHD, it simply returns the current property value

[USRP-users] Re: Read user registers with RFNoC

Hi Maria, I don't know the exact problem, but I want to mention that UHD "properties" can behave in unexpected ways. In my opinion, they are not well suited to providing a changing property value if UHD is unaware that a change has occurred. The UHD "get" function of the property does not execute u

[USRP-users] Re: RFNoC: RX & TX triggering for RFNoC block only flowgraph

Hi Xianglong, The thread you provided is pretty old. On recent UHD versions (including 4.4), it is possible to work directly without the splitstream block (i.e., Radio-Rx => custom block => Radio-Tx). You may need to handle time stamps - if your Radio-Rx is inserting time stamps, they will by def

[USRP-users] Re: X310/UBX Tx tuning issue introduced UHD 4.4?

. Leech wrote: > On 13/11/2023 22:29, Rob Kossler via USRP-users wrote: > > Hi, > I am having an issue with successfully tuning the frequency for the Tx > side of an X310/UBX and it appears to me that a bug was introduced in UHD > 4.4 (I haven't checked more recent versions, but

[USRP-users] X310/UBX Tx tuning issue introduced UHD 4.4?

Hi, I am having an issue with successfully tuning the frequency for the Tx side of an X310/UBX and it appears to me that a bug was introduced in UHD 4.4 (I haven't checked more recent versions, but I expect that they are also affected). The issue is that when you request a frequency such as 2450 M

[USRP-users] Re: RFNoC Loopback with stream from host

22 > > Best regards and thank you very much for your help > Philipp > > [1] > https://github.com/gnuradio/gnuradio/blob/5dc195b0195e8a073b7f7c1ffd6c8c36d3bb0bd2/gr-uhd/lib/rfnoc_rx_radio_impl.cc#L164 > > [image: grafik] > -- > *From:* Ro

[USRP-users] Re: RFNoC Loopback with stream from host

cv() call timed out. > Starting stream > rfnoc_rx_streamer :debug: Sending start stream command... > OOOOOOOO > >>> Done > > > > -- > *From:* Marcus D. Leech [mailto:patchvonbr...@gm

[USRP-users] Re: RFNoC Loopback with stream from host

Hi Philipp, 1. Delaying the Rx Radio start time should be relatively easy to do. While I don't know how to do this from gnuradio, I do it all the time using UHD from C++. Perhaps you will have to modify the GRC generated python to do it rather than do it from GRC - not really sure. 2. Flushing the

[USRP-users] Re: X310 Appears Laggy Using UHD 4.5

samples. If this is true, then perhaps you could build a custom X310 image with larger buffers. On Thu, Sep 28, 2023 at 3:26 PM Rob Kossler wrote: > Hi Anna, > I do not have a response to your direct question regarding performance. > However, I have a suggestion that may make the perfor

[USRP-users] Re: X310 Appears Laggy Using UHD 4.5

Hi Anna, I do not have a response to your direct question regarding performance. However, I have a suggestion that may make the performance irrelevant. The X310 image comes with a Replay block that accesses the DRAM chip for storage. Given that you are sending a repeatable waveform, you should ha

[USRP-users] Re: 10Gb Eth to X310 via PCIe Card Expansion Systems

On Wed, Sep 27, 2023 at 5:47 PM Marcus D. Leech wrote: > On 27/09/2023 05:15, Olo via USRP-users wrote: > > Hello, > I want to connect X310 with my laptop through 10Gb eth connection and I > want to ask: > >1. If *Intel* *X710* (Dual 10Gb card) with *Sonnttech Echo Express SE >I* (PCIe Ca

[USRP-users] Re: TX Streamer Send Time

On Mon, Sep 25, 2023 at 9:26 AM Marcus D. Leech wrote: > On 25/09/2023 08:57, Devin Kelly wrote: > > Hello, > > I have an application where I’m sending many short bursts to a USRP B210 > using uhd::tx_streamer.send() (link below) and I occasionally set the PPS > time to 0 using set_time_last_pps.

[USRP-users] Re: Toggling a panel GPIO at a specific time (via RFNoC or otherwise)

tions to avoid that case. > > > > Thanks again, > > -David > > > > > > *From:* Rob Kossler > *Sent:* Thursday, September 21, 2023 4:26 PM > *To:* David Raeman > *Cc:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Toggling a panel GPIO at

[USRP-users] Re: Toggling a panel GPIO at a specific time (via RFNoC or otherwise)

Hi David, It may be the case that this functionality already exists in the radio block such that you don't need a custom block. The function radio_control->set_gpio_attr() respects the command time. Here is a portion of one of my applications that outputs a gpio pulse after a specified delay rela

[USRP-users] Re: RFNoC: strange behavior of FFT block

mpiling UHD I’m going to assume you installed UHD from > source. Which exact version did you build and install? I remember running > into problems I couldn’t solve when installing the branches UHD-4.3 und > UHD-4.4 from source. > > > > Regards > > Luca > > > &

[USRP-users] Re: RFNoC: strange behavior of FFT block

On Thu, Sep 14, 2023 at 5:43 PM Marcus D. Leech wrote: > On 14/09/2023 17:40, Rob Kossler wrote: > > Hi Luca, > The problem with FFT lengths > 256 is an Ettus bug in > "rfnoc_rx_streamer.cpp" (also an issue in "rfnoc_tx_streamer.cpp"). The > following s

[USRP-users] Re: RFNoC: strange behavior of FFT block

lueError: samples per package must not be smaller than atomic > item size > > > > Additionally, I’m very much interesting in how you created your own FFT IP > in Xilinx and separated the parameters. I would be happy to get some > information from you. > > Have you tried spp=f

[USRP-users] Re: RFNoC: strange behavior of FFT block

e fft_size to just 512, I also get the error about the atomic item size > mentioned below. I keep wondering why that is. > > > Regards > > Luca > > > > *Von:* Rob Kossler > *Gesendet:* Mittwoch, 6. September 2023 21:29 > *An:* Marcus D. Leech > *Cc:* Bach

  1   2   3   4   5   6   7   8   >