[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

Hongwei, In addition to the PLL that tracks the external 10MHz ref to produce the internal 10 MHz ref, there are the four PLLs that track the internal 10 MHz ref to produce the four LO signals (2Tx/2Rx) as you mentioned. But, the phase variation from the LO PLLs is much less - I don't really know

[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 in m

[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

No problem. I think you will be very glad you did. With this version, some examples (such as benchmark_rate) can be used with multiple devices and external synchronization. Regarding overflows, I can tell you that when using "rx_samples_to_file" or similar programs to capture the incoming stream

[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

I am not certain, but I believe that the benchmark_rate example in UHD 3.12 does not support "sync-ing" of multiple devices. The recent versions of benchmark_rate do support this. In any case, it is not difficult to add if you want (configuring all devices to use external Ref/PPS and then resetti

[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

How about if you use an unmodified "benchmark_rate"? On Mon, Dec 18, 2023 at 11:43 AM Anabel Almodovar < anabel.almodo...@gmail.com> wrote: > Even with a single card I still get the same error. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

[USRP-users] Re: streamer error X310

Several comments: - It seems like multiple things are going on. You mentioned the original "failed to time align" error and below you mentioned 'O' and 'D'. - The time-align error I did not expect had anything to do with "performance". This seemed to me that the first packet arr

[USRP-users] Re: streamer error X310

Hmmm. I'm not sure. Here are a few comments: - Try running without "second_addr". I realize that you will need it for full rate (4 x 100MS/s for each X310), but you could run at 50 MS/s without second_addr - Try running without shared LO. I don't think you would need to physically

[USRP-users] Re: streamer error X310

Hi Anabel, In my opinion, the error you are experiencing has nothing to do with streaming performance settings (such as "performance" governor, network descriptors, MTU size, etc). The issue seems to be that the two X310 devices do not have synchronized clocks. In addition to the physical synchroni

[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 using "s

[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

:debug: UHD recv() call timed out. >> ******* MESSAGE DEBUG PRINT >> ((rate_now . 666323) (rate_avg . 1.79964e+06)) >> >> rfnoc_rx_streamer :debug: UHD recv() call timed out. >> rfnoc_rx_streamer :debug: UHD recv() c

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

cv() call timed out. > Starting stream > rfnoc_rx_streamer :debug: Sending start stream command... > OOOOOOOOOOOOOOOO > >>> 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

One more thing. One difference between 3.15 and 4.xx might be the length of FIFOs on the FPGA for buffering Tx data arriving from the host. If the 4.xx buffers are smaller, then it may be more likely for a "glitch" to occur if your host is a bit "bursty" when providing the samples. If this is tr

[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)

Yes, I believe you will need to ensure monotonically increasing times in the Radio command queue. Since we have a multi-threaded application, we cheated and simply inserted a "delay" in the thread that sets the GPIO pulse in order to ensure that the command entered the queue after all of the strea

[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

Hi Luca, I installed the latest from UHD-4.4 (as of last week). Rob On Mon, Sep 18, 2023 at 4:11 AM Bachmaier, Luca < luca.bachma...@iis.fraunhofer.de> wrote: > Hi Rob, > > > > thank you very much for putting effort into finding this bug. Since you’re > talking about recompiling UHD I’m going to

[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 snippet from the atomic_item_size property r

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

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 snippet from the atomic_item_size property resolver shows the issue. The problem is that "spp" has units of "samples" whereas "ais.get()" has units of b

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

Hi Luca, I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2 is the latest that I have used), but I have successfully used FFT lengths up to 4096. In order to do this, I had to create my own Xilinx FFT IP and I also had to separate the concepts of streaming packet length from

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

Hi Luca, A couple of things. The largest FFT size might be limited to 1024 - even with MTU=9000. I think that the maximum packet length is often 2000 or 2048 such that when you add a few header bytes, you can no longer achieve an FFT packet of 2048. Additionally, if you look in fft_block_control

[USRP-users] Re: VCO can not operate for high sample rate

Oh, I forgot to mention. With the existing Replay block, you should be able to load your FMCW waveform in device memory and play it out continuously. I don't know if the X410 has Replay memory bandwidth limitations that would restrict your ultimate FMCW bandwidth. But, you might want to try it out

[USRP-users] Re: UHD4 segmentation fault on creating rx_streamer

Hi Andrew, I see what you mean regarding the documentation comment about one streamer only. But, this doesn't make sense to me. I wonder if the documentation is in error. I always use multiple rx and tx streamers. However, I don't often destroy and recreate them on the fly. Anyway, it was my und

[USRP-users] Re: VCO can not operate for high sample rate

I think that you could implement this transmit waveform in a custom RFNoC block such that you would never have any issue with underruns. Although I don't use gnuradio myself, I believe that you could control your block easily from gnuradio. And, although this requires some FPGA programming, this

[USRP-users] Re: [EXT] Re: N310 correct choice for coherent 4 channel RX w/ 1 TX ?

Hi David, You seem to already know the essentials based on the previous comments. I have used each of the following USRPs in various 4-channel coherent experiments. I'll mention a couple of comments about each. - The X310/UBX can be phase calibrated, but it can't operate with a shared LO

[USRP-users] Re: LO carrier phase difference

On Thu, Jun 29, 2023 at 11:09 AM Marcus D. Leech wrote: > > On 29/06/2023 09:36, zhou via USRP-users wrote: > I am using X310 USRPs. I did a loopback test with this USRP, that is, Tx was > connected to Rx (with a 20dB attenuator between them). This is for checking > the channel status. > In my t

[USRP-users] Re: TwinRx in coherent setup

Is there a chance that the issue is caused by the timed commands occurring prior to the "set_rx_rate" command (as indicated in the code provided in the issue tracker)? I don't know how the DDC responds to timed commands prior to knowing its output rate. Rob On Mon, Jun 26, 2023 at 11:22 AM Marcus

[USRP-users] Re: X310 Dual 200 Msps Streaming

My own experience is that 200 S/s on two channels is very difficult to achieve from the host. Separate streamers may help, but you will likely need to move to DPDK to get the best performance. I have not tried DPDK recently, but when I tried it a few years ago, the performance was excellent, but it

[USRP-users] Re: N321 LO Distribution

Hi Michael, One calibration procedure could be that you simply add a digital phase offset to your 2nd Tx channel until your oscilloscope traces line up to your satisfaction. It would be nice if the default FPGA image included a simple Rx & Tx complex scalar for this exact purpose (inside the DDC &

[USRP-users] Re: x410 TX issues

Hi Joe, It sounds like your custom image is compatible with the Ettus example "rfnoc_replay_samples_from_file". Have you tried this with your custom image (as opposed to your custom software)? Rob On Wed, Jun 7, 2023 at 10:23 AM wrote: > Hello, > > I did run the default image and everything wor

[USRP-users] Re: N321 LO Distribution

Hi Michael, I don't have any ideas for reducing a time delay offset. But, I still wonder if the problem could actually be just a phase offset. With a relative delay of 2.5ns and a bandwidth of 4 MHz, the amount of phase variation you would see is 0.57 degrees. That is not easy to see. On the othe

[USRP-users] Re: N321 LO Distribution

Hi Michael, Either a delay offset OR a phase offset will show itself as a relative phase. In order to distinguish between a delay offset and a phase offset, your signal must have appreciable bandwidth. It appears that your signal is CW. It is entirely possible that your delay offset is zero. Do

[USRP-users] Re: N321 LO Distribution

On Thu, May 25, 2023 at 3:54 AM Michael Toussaint wrote: > > Used a single streamer and saw the delay slightly improve to between 2.5 - 3 > ns. > > Any other suggestions to improve the delay to match the results from the > knowledge base, https://kb.ettus.com/USRP_N320/N321_LO_Distribution? How

[USRP-users] Re: N320 - GPIO ATR output to TX output delay

I may be off-base here, but I thought that the GPIO control occurred from the Radio block such that a DUC group delay would not be the place to look. I am wondering if the GPIO control does not use timed commands. Instead of the automatic setting of the Tx GPIO, we have used custom GPIO with timed

[USRP-users] Re: N321 LO Distribution

On Tue, May 16, 2023 at 8:35 PM Marcus D. Leech wrote: > > On 16/05/2023 20:31, Michael Toussaint wrote: > > Hi, > > > > I am testing the LO synching on a single N321 using the 2 Tx channels > > on the N321. > > > > I have followed the LO setup steps from the knowledge base, > > https://kb.ettus.c

[USRP-users] Re: Manage multiple Tx streamers

By the way, the rx_samples_to_file.cpp example has a "multi_streamer" command line option and the example has associated functionality to implement separate streamers in the Rx direction. But, I don't think the tx examples have this option although it should be roughly analogous to the Rx case. Rob

[USRP-users] Re: Manage multiple Tx streamers

Hi David, You need to create two streamers - one with a channel list of {0} and the other with a channel list of {1}. Let me know if you have any questions. Rob On Fri, May 12, 2023 at 11:52 AM wrote: > Hi everyone, > > I need to develop a system which streams independent samples at different >

[USRP-users] Re: RFNOC Block Not found

Hi Joe, It sounds like you wrote a block controller. If not then this will need to be done. If so, then it is likely UHD is just not loading your block controller (assuming it is compiled OOT). If you set UHD_MODULE_PATH env var to point to your dynamic library, then UHD will find it (but you wi

[USRP-users] Re: Using PPS/TrigIn to collect bursts of samples in C++ UHD

Hi Joe, I don't think it's possible (without some FPGA mods) to start receiver sampling on the pulse rising edge. However, the following alternate methods are possible. - Connect your trigger signal to PPS input. Use continuous recording where your c++ just throws away all samples except th

[USRP-users] Re: configuring X410 USRP to work with higher sampling frequency/band width

On Tue, Apr 25, 2023 at 12:34 PM Marcus D. Leech wrote: > > On 25/04/2023 12:30, James Schatzman wrote: > > I don't know if this is new information but we have observed some > > additional behaviors: > > > > 1) The radio reports dropped UDP packets. Why is it dropping them? > How are you determini

[USRP-users] Re: Trouble recieving data from antenna

Could there be an issue with packet lengths? Does the "spp" from the radio need to match the "N" from the keep_one_in_N? I'm not sure one way or the other or whether the answer depends on the setting of "packet_mode / sample_mode". Which device are you using? Rob On Wed, Apr 19, 2023 at 4:16 PM

[USRP-users] Re: Trouble recieving data from antenna

Hi Joe, One thought is that the Rx Radio may never be getting the command to start streaming. Normally, this occurs by calling rx_streamer->issue_stream_cmd() which propagates from the rx_streamer block controller to the DDC block controller and ultimately to the Rx Radio block controller. If you

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

Jim, One more thought. One way to buffer data on the host side is to use OS pipes. We have used this successfully for continuous receive streaming. In /etc/sysctl.conf we set some options such as "fs.pipe-max-size" and "fs.pipe-user-pages-soft" and had separate applications - one filling the pipe

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

> > > One of the things that puzzles me is that 12.5Msps just isn't that high a > streaming rate, in fact it's totally supported over > a *1* GBit interface. > > At 12.5Msps, that buffer fills(drains) in about 2.5ms. There's plenty of > buffering on the host to buffer application scheduling >

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

Jim, Marcus, I *believe* that "skip_dram=1" will have no effect on the N310 because it does not use DRAM in the stock image (or even populate the dram-fifo RFNoC block). The definition of the stock RFNoC graph for the N310 is here

[USRP-users] Re: Halting issue with USRP socket connection - how to set SO_PRIORITY?

Hi Jim, >From a quick review of this chain, it appears your concern is for the transmit direction (hence, Underruns). Although I have never tried to run for extended periods such as you are requiring, I am reasonably confident that the issue is on the host side and not the Radio side. Some remarks

[USRP-users] Re: Integrate USRP-X410 with XL710 intel PCIe NIC card through QSFP ports

I have only used the Intel cards such as Intel XL710-QDA1 or Intel XL710-QDA2 and I think that the utility is the following: https://www.intel.com/content/www/us/en/download/18190/non-volatile-memory-nvm-update-utility-for-intel-ethernet-network-adapter-700-series.html On Tue, Apr 4, 2023 at 3:5

[USRP-users] Re: what is the purpose of issue_stream_cmd() for the rx_streamer?

If you are using RFNoC capable USRPs, it is the UHD 'block controllers' that propagate a command (or swallow it, if they want) to the next upstream block controller. Thus if you develop a custom block (and custom block controller), you can decide if/how you want to propagate properties, commands, e

[USRP-users] Re: what is the purpose of issue_stream_cmd() for the rx_streamer?

It is really the opposite, the cmd propagation flows upstream (from the rx_streamer to the DDC to the Radio). Rob On Tue, Apr 4, 2023 at 3:00 PM yan zhang wrote: > So in general, we can just issue stream cmd to one source rfnoc block and > the cmd will propagates to all down stream blocks. Is th

[USRP-users] Re: Integrate USRP-X410 with XL710 intel PCIe NIC card through QSFP ports

Unfortunately, I don't really know. I do not have an X410. However, I do have an N321 which has both a QSFP+ port and two SFP+ ports. I use the SFP+ ports with a 4x10Gb breakout cable (either fiber or copper) and the XL710 NIC. But, it is my understanding that the N321 QSFP+ port is configured to o

[USRP-users] Re: Integrate USRP-X410 with XL710 intel PCIe NIC card through QSFP ports

There is a persistent setting on the XL710 such that it can be either 40GBASE or 4x10GBASE. Intel has a utility that you can use to program this setting. Perhaps this is the issue for you? Rob On Tue, Apr 4, 2023 at 1:43 PM wrote: > Hello, > > I am trying to integrate USRP-X410 with XL710 inte

[USRP-users] Re: what is the purpose of issue_stream_cmd() for the rx_streamer?

issue_stream_cmd() tells the Rx radio to start sending samples. You typically call this as rx_streamer->issue_stream_cmd(), and then the command "propagates" to all the blocks in the graph (such as DDC and then ultimately the Rx Radio). Without this command, the Rx radio will not begin streaming s

[USRP-users] Re: B205 mini i very high lo-leakage, image rejection and aggressive DC correction.

Hi Sorin, Regarding the maximum LO offset you can use: LO-offset-max = (master_clock_rate - sample_rate) / 2; This equation ensures that your desired bandwidth (determined by sample rate), will fit within the digital stream (at rate MCR) that is supplied to the FPGA from the RF front end. So, wit

[USRP-users] Re: Wideband IQ Daughterboard

Hi Eugene, I don't know why the basic Rx has a lower frequency listed. It seems inconsistent with other notes such as the following found here Some USRP radio users elect to use an external front end providing upconversion, downconversion, ampli

[USRP-users] Re: Backpressure over Ethernet

essure? The block needs to deassert tready to tell the > stream endpoint to backpressure the streamer. > > Wade > > On Fri, Mar 24, 2023 at 9:41 AM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> I developed a custom RFNoC block and was

[USRP-users] Backpressure over Ethernet

Hi, I developed a custom RFNoC block and was testing it with a graph that was essentially: tx_streamer => myblock => rx_streamer This works fine unless I send a large number of samples, in which case bad stuff happens in terms of sequence errors, timeouts, etc (i.e., the typical streaming at hig

[USRP-users] Re: Time base error

Following up on my previous email, I found that this error was happening when I set UHD_MODULE_PATH to allow UHD to find my RFNOC library had also linked my library explicitly in my custom app. Thus, if I ran uhd_usrp_probe, everything was fine because it found my library in the defined UHD_MODULE

[USRP-users] Re: Time base error

Hi Jeff, I am getting this same error. Did you ever figure out the problem? Rob On Sat, May 22, 2021 at 5:46 PM Jeffrey P Long wrote: > I am getting some weird error about a invalid time base clock name after > starting to create my own block. I did not see this just doing the simple > pass thr

Re: [USRP-users] X310 with dual TwinRX set up

Hi Oliver, I don't have any example code to provide (and I don't use gnuradio), but I can address a couple of things: - the first step is to get all four channels recognized (as you indicated); perhaps using subdev spec "A:0 A:1 B:0 B:1" - synchronizing in time is definitely possible. From gnuradio

[USRP-users] RFNoC 4 metadata

Hi, I just modified one of my RFNoC blocks to use metadata for the first time. The following remarks identify issues I encountered along the way and some suggestions that would make things a bit easier. - You can't use axis_data (with sideband signals) if you want access to metadata. While I

Re: [USRP-users] UHD 4 "properties"

Hi, I wanted to revisit a couple of issues with UHD 4.0 properties and ask whether Ettus is planning any changes to the property architecture that would address these issues. The 2 issues are the following: - There is presently not a good way to use a property with a read-only register (whe

Re: [USRP-users] rfnoc architecture suggestions

rossbar. We definitely want to make things easier for > users. Please continue to share suggestions you have. > > Thanks! > > Wade > > On Fri, Feb 26, 2021 at 10:08 AM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> While I am a big fan of

[USRP-users] rfnoc architecture suggestions

While I am a big fan of the architectural changes to RFNoC with the release of UHD 4.0, I have a couple of suggestions for improvement. I am admittedly a novice FPGA developer so it's certainly possible that these suggestions are "easier said than done" or poor choices for other reasons. But, that

Re: [USRP-users] User register on X300 UHD 3.9

Hi Cédric, I don't fully know the answer, but if you look in the 3.9.LTS source code for examples of "publish()", "subscribe()", and "coerce()" functions. Something along the lines of grep "publish(" $(find ./ -name "*.cpp") # if you are in the host/uhd folder At this point, I think that you th

  1   2   3   4   5   >