Re: [USRP-users] Details on how these charts were made

Mark, While I don't have recommendations for specific test instrumentation, I'd guess you could pretty easily characterize a RX gain vs frequency with a (calibrated) signal generator that is addressable over SCPI. Once you've figured out how to TX a CW at a given power level over the SCPI

Re: [USRP-users] B210 USRP object creation

Actually, I think you just need to configure and reload your udev rules as noted in this KB under “configuring USB”: https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Configuring_USB -Sam On Sat, Oct 10, 2020 at 3:20 AM David Taylor

Re: [USRP-users] B210 USRP object creation

David, To clarify, you used "write-vid" and "write-pid" arguments with UHD b2xx_fx3_utils [1] to convert your NI-2901 to a B210 using the VID and PID values found in the "About the Motherboard and Daughtercard EEPROM on USRP Devices" KB [2]. Correct? And after changing these values, you are no

Re: [USRP-users] Loading B210 firmware takes forever (i.e. hang) after installing NI-USRP driver

Kelvin, If I remember correctly, NI-USRP overwrites a handful of environment variables in Windows to point to RFNoC image paths for NI-USRP. However, I can't imagine why the B210 image would be any different between UHD and NI-USRP. You might try changing these paths to point back at the images

Re: [USRP-users] [USRP-B200] Transmitting and Receiving with two boards B200 using MATLAB

Agreed with Ron. Remove one of the 30dB pads and play around with the gain on the RX side to dial things in. You could also run a simple example of transmitting and receiving a CW between the boards. If you're not sharing a 10 MHz reference between the two, you might find that there is a slight

Re: [USRP-users] Help: How to solve the issue"At least one PLL did not lock!"

Is your program expecting you to supply an external 10MHz Reference to your N310? I'd assume that's what *set_clock_source*() is configuring. You should double-check the logs or source to be sure. I don't think that *set_clock_source* would be referencing an external LO, but if it is, make sure

Re: [USRP-users] RFNoC Replay Bloch timmed commands

Tarik, That KB is current - timed commands were added to the replay block in the last 6 months. -Sam On Thu, May 28, 2020 at 4:52 AM Emil Bjelski via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello All, > > I would like to use RFNoC Replay Block with timed commands, in order to >

Re: [USRP-users] X310: control frontend with custom RFNoC blocks

David, Do you know ahead of time what the frequency sweeps are going to be, or do you need to have your RFNoC block creating and scheduling them dynamically? If you know your frequency sweep list ahead of time, a much easier technique would be for you to send your tune requests from host to

Re: [USRP-users] Rounded FFT on USRP N210

Manav, I'll take a shot in the dark and point you toward this article I've referenced a couple times in the past: https://witestlab.poly.edu/blog/why-does-my-received-spectrum-droop-at-the-edges/ In order to decimate data, the USRP will use halfband filters for decimation factors that are a

Re: [USRP-users] E312 fails to run uhd_usrp_probe from host

Francisco, The FPGA update sounds like a good step. I also notice that the 'addr' argument you pass seems to be interpreted as a 'mgmt_addr' based on the [INFO] output. In newer embedded devices like the N3xx, I wouldn't expect you to be able to successfully run a uhd_usrp_probe over that mgmt

Re: [USRP-users] UBX 10-500 MHz Question

Bob, The 84MHz bandwidth constraint is because of the analog bandpass filter [1] on the UBX's RX signal path [2]. I'd guess that UHD will yell at you if you feed in an invalid bandwidth, but I've never tried it. If I remember correctly, you can sample at rates that aren't an even division of the

Re: [USRP-users] X310 UHD 3.15 Lockups

Ryan, In that example, line 93 sets the USRP's internal sense of time to 0.0s, after which point this sense of time ticks up. Any timed commands you issue to the USRP need to occur in the future, relative to the USRP's sense of time. In this case, you have to give a "--secs" value greater than

Re: [USRP-users] X310 UHD 3.15 Lockups

I would suspect that your setting of the time_spec with an uninitialized value could be a problem. rx_multi_samples sets up multi-channel RX with an initialized time_spec: https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/host/examples/rx_multi_samples.cpp Can you compile and run that

Re: [USRP-users] [EXT] Re: E320 GPS staying locked?

Hey Jeff, Thanks for the detailed info. The N310 and the E320 both use the LTE-Lite from Jackson Labs for their GPSDOs, so it's conceivable that the same rework is applicable to both, but I'm not positive - I wasn't directly involved in the hardware investigation. I'll reach out to you off the

Re: [USRP-users] E320 GPS staying locked?

Hey Jeff, What type of GPS antenna are you using? 3.3V or 5V? If it's compatible with X310 & other USRPs, I would imagine you'll be good to go with the E320... Do you see the locked / unlocked status change between consecutive runs of something like gpsmon on the E320? There were some early-ish

Re: [USRP-users] Trigger Output

Hey Knut, Reading a GPIO line requires that the GPIO state be sent back to the host, processed, and then acted upon (in your case, sending a stream command to the radio). There is going to be a good amount of latency and jitter built into this. The alternative, which I would strongly recommend,

Re: [USRP-users] Can underflows in any way be bad for hardware in the long term?

Hey Francisco, Interesting question. I remember reading this when it was initially posted, giving it some thought, and promptly forgetting to respond. It's a question that is difficult to give a "yes" or "no" to. Similar to statistics, I think the answer to this question only comes by disproving

Re: [USRP-users] Synchronize USRP using Octoclock

Hey Borja, Is this still on your radar? I know that there have been a handful of timing fixes added to the 3.15-LTS branch of UHD that might be worth trying out. It could also be an issue with the example - I'm not sure I've spent much time with ./test_clock_synch, but I'd be interested in

Re: [USRP-users] *** BULK *** Re: Issues using TwinRX and x310 (phase shift)

Etienne VAILLANT, It's also worth noting that you need to do some work on the generated python flowgraph outside of GRC to ensure a consistent phase relationship between channels. Namely, you need to make sure the following criteria are met on a TwinRX system: 1. All USRPs share a common

Re: [USRP-users] Buffer clearing after error 'D' USRP N210

Ivan, To flush the RX buffer, I think your best bet is to destroy and recreate the streamer. That being said, [D]ropped packets are usually indicative of some deeper host issue. Are you able to run without dropping packets at lower rates? Sam Reiter On Mon, Feb 24, 2020 at 4:02 AM Ivan

Re: [USRP-users] USRP N310

Rob, Question for you - is your usecase one where you can simply tolerate that 180 degree ambiguity? Or do you have a routine in your code to characterize and compensate for it on each run? Sam Reiter On Tue, Mar 3, 2020 at 11:44 AM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com>

Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

Everything Rob is saying is dead on - the "sense of time" for the radio is a 64-bit counter within the radio core that other blocks (like the DDC and DUC) don't have access to. Those blocks need to derive a sense of time from the timestamps of CHDR packets passing through them. I just wrapped up a

Re: [USRP-users] USRP X310 ignored DSP retuning on TX when using a timed command

For what it's worth, I was able to reproduce the behavior described here, but didn't get to dig into it much. My leading suspicion would be what Rob mentioned about timestamping. Lukas' code sets a command time, but I'm not clear on how timestamp metadata for packets being sent to the radio are

Re: [USRP-users] X310 SFP 10G-Ethernet Interface Kit

Cherif, The recommended equivalent accessories for 10GbE can be found here: https://www.ettus.com/all-products/10gige-kit/ https://www.ettus.com/all-products/10gige-1m/ Note that there are a number of other compatible cards and cables that can be found outside of the ettus.com site as well,

Re: [USRP-users] UHD v4 Compiled

You got it. 3.9 is older and relatively simple (pre-RFNoC). It also has some latency advantages compared to modern UHD / FPGA architectures. But all things considered, 3.15.LTS is your best bet for getting started. Sam On Tue, Feb 18, 2020 at 11:40 AM wrote: > Ah, > > > > I now assume 3.15 is

Re: [USRP-users] Using DDC/DUC frequency in RFNoC

I'll also add in that you need to set the frequency tuning policies to POLICY_MANUAL before you can change rf_freq or dsp_freq independently. Sam Reiter On Mon, Feb 17, 2020 at 12:13 PM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Adrià, > If you are trying to use

Re: [USRP-users] UHD v4 Compiled

Simon, The current UHD 4 on master is not a released version, so be patient if you run into any snags. That being said, you should be good to compile and run on Windows. I put together a guide a little while ago for building on Windows. It will almost certainly need some massaging for 4.0, but

Re: [USRP-users] Clock Source

Simon, You should be able to call: get_clock_source() and verify that the returned value is 'external'. Sam Reiter On Fri, Feb 14, 2020 at 3:13 AM Simon G4ELI via USRP-users <

Re: [USRP-users] Frequency hopping on short time scale using DSP tuning

Hey Richard, Not sure if this is still on your radar, but I'd be curious to see the code you're using to test this. Do you update your frequency tuning policy to be DSP tuning only? If you want to pick this back up, feel free to shoot an email to supp...@ettus.com and we can do a bit of a code

Re: [USRP-users] Error "clock synchronizer offset" loading N310 rfnoc image

Rob, I'm not sure what the implications would be, but you could try recompiling UHD with an updated *trace_delay_offset* and/or *offset_error* threshold: https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/mpm/python/usrp_mpm/dboard_manager/mg_init.py#L212 I'm not sure why your custom RFNoC

Re: [USRP-users] USRP filter delay

Timestamps on RX samples are put in the CHDR Header by the Radio Core and are not changed by the DDC downstream, except for the case of interpolation / decimation. But even in this case, the remaining samples should still be repackaged with timestamps consistent with those given by the Radio Core.

Re: [USRP-users] Use most of the ddr3 space in x310

Daniel, The X310 has 1Gb of DRAM available to the FPGA. In the stock images, some of this DRAM is used for FIFOs between RFNoC blocks. If you were to replace these DRAM FIFOs with SRAM (i.e. compile the XGS image for X310), you should theoretically be able to leverage all of the X310s DRAM in the

Re: [USRP-users] using GPIO output to trigger external RF switches

Thomas, I believe I mistyped in my initial response to specify a TX rate change rather than frequency change. It might be more clear if I include some quick pseudocode describing what I'm talking about: tune_time = usrp->get_time_now() + uhd::time_spect_t(0.1) //Set a > future time to

Re: [USRP-users] Supported ethernet controllers : X300 and UBX

Santosh, That card should be fine for streaming, that controller just hasn't been explicitly tested as far as I know. Are you planning on using DPDK? Sam Reiter On Wed, Jan 15, 2020 at 12:26 PM voonna santosh via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi There, >Good morning. As

Re: [USRP-users] X310 scheduled issue_stream_cmd()

Richard, I believe what you're looking for is the depth of the command queue. For the X310, this FIFO has a depth of 16. Any command that you issue to the X310 that has a command time set will be held in this FIFO until the radio's time matches the command time, at which point the command is

Re: [USRP-users] USRP PPA for Ubuntu 19.10

Can you be more explicit about your issues building from source? The kernel panic you mentioned was on the E320 itself, and the image on the E320 fs doesn't have anything to do with UHD on your host (unless you compile it yourself). I'll let someone else comment on the PPA - it's not something I

Re: [USRP-users] Transmitting at required sampling rate than supported

The X310 is capable of 200e6 or 184.32e6 master clock rates. 184.32 / 3 = 61.44 which is close, but doesn't sound like it's exactly what you're looking for. If that doesn't work for you, then my recommendation would be for you to oversample with the X310 and then resample your data once it is

Re: [USRP-users] using GPIO output to trigger external RF switches

Thomas, To accomplish what you're talking about, I think you'd just need to use timed commands on both set_tx_rate() and set_gpio_attr(). If these are set to execute simultaneously, the GPIO line you set will go high on the same clock cycle as the LO retune. Sam On Tue, Jan 14, 2020 at 5:59 AM

Re: [USRP-users] dpdk with x300

Lorenzo, Since we started this thread, we've published a DPDK-specific app note. At this point, I'd recommend you start the DPDK install process from scratch using this guide: https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD Best, Sam On Fri, Jan 10, 2020 at 5:15 PM Minutolo, Lorenzo

Re: [USRP-users] Regarding N321 shutdown

Milind, You should run that command when you're ssh'ed into the device or have a serial session open. That command won't affect the N321 if it is simply run from a host terminal (I'd imagine it will just shut down your host). Connecting via SSH:

Re: [USRP-users] Run time issue with 3.14.1.1 (X300 with UBX)

Santosh, Could you send the output of *ip a* On you machine with the X300 connected? Sam On Fri, Jan 10, 2020 at 9:16 AM voonna santosh via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi There, >I have just updated to 3.14.1 and experiencing the following issue. The > system

Re: [USRP-users] GPIO Example Failure on N310

Jeff, I'd say it's worth trying. Do you currently have any cabling or external connections to your GPIO port? Sam Reiter Ettus Research On Mon, Jan 6, 2020 at 6:27 PM Jeff S wrote: > Sam, > > Everything was downloaded from the images_downloader. I have not modified > the FPGA image or any of

Re: [USRP-users] X310 GPIO Ettus Code Example Question

Jeff, Yes. For ATR to put that line high on TX, the value should be 1 as you noted. Sam Reiter Ettus Research On Tue, Jan 7, 2020 at 1:12 PM Jeff S via USRP-users < usrp-users@lists.ettus.com> wrote: > Relating to the description of the GPIO: >

Re: [USRP-users] Fwd: dpdk-test does not work

Akin, I'd recommend you check out our DPDK setup guide - hot off the presses: https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD Sam Reiter Ettus Research On Wed, Jan 8, 2020 at 10:52 PM akin soysal via USRP-users < usrp-users@lists.ettus.com> wrote: > > > -- Forwarded message

Re: [USRP-users] UHD RFNoC Update

Hey Rob, We're working on updating our RFNoC materials on kb.ettus.com currently. This RFNoC specification should be a good supplement in the meantime: https://files.ettus.com/app_notes/RFNoC_Specification.pdf Sam On Tue, Jan 7, 2020 at 9:32 PM Rob Kossler via USRP-users <

Re: [USRP-users] GPIO Example Failure on N310

Jeff, Follow-up on this. I ran the GPIO example on my N310 with 3.14.1.1 (g0347a6d8) and all GPIO tests passed. Are your FPGA image and UHD release modified? Sam Reiter Ettus Research On Fri, Jan 3, 2020 at 2:01 PM Sam Reiter wrote: > Hey Jeff, > > Could you give this a shot on 3.15.0.0 and

Re: [USRP-users] dpdk with x300

That should be fine. Looking over those screenshots again, you'll need to change your dpdk driver path in uhd.conf. Here's what the uncommented parts of uhd.conf should look like for 17.11: [use_dpdk=1] dpdk-mtu=9000 dpdk-driver=/usr/lib/x86_64-linux-gnu/dpdk-17.11-drivers/ dpdk-corelist=1,2,3

Re: [USRP-users] E320 1GMgmt vs SFP-1G data streaming ethernet ports

> > Issue #1: > I sometimes see messages such as: > root@ni-e320-31BB638:/data/network# [ 340.972102] cros-ec-dev > cros-ec-dev.0.auto: Some logs may have been dropped... > I've seen this before on certain host machines, but I've never actually seen dropped logs. I'm not sure what the cause

Re: [USRP-users] dpdk with x300

Lorenzo, What version of DPDK are you using? Sam Reiter Ettus Research On Fri, Jan 3, 2020 at 8:20 PM Minutolo, Lorenzo via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi All, > I'm using an x300 connected via a Intel X710 to a machine running Ubuntu > 18.04. I'm using the recently

Re: [USRP-users] TwinRX RX1 LO1 occasionally at wrong frequency

Daniel, This is tricky. Not only have I never seen this issue, but it sounds like it happens intermittently for you as well. If this is something you're still running into, I'd encourage you to email me at supp...@ettus.com directly. We can cover some additional troubleshooting and potentially

Re: [USRP-users] DPDK runtime error

Florian, DPDK 18.11 is not supported on UHD 3.x. You'll need to use DPDK 17.11. Sam Reiter Ettus Research On Mon, Dec 23, 2019 at 9:51 AM Florian Kaltenberger via USRP-users < usrp-users@lists.ettus.com> wrote: > Dear all, > > we have finally managed to set up UHD (3.15) with DPDK (18.11)

Re: [USRP-users] Cannot update FPGA image on USRP E320

Hey Subu, I'd suspect that the MPM versioning is the issue here. You can manually compile and install MPM on your E320, or you can simply reflash your SD card with the latest SDimg. Based on when this was posted vs when v3.15.0.0 was tagged, I'd guess you're working with a release candidate and

Re: [USRP-users] GPIO Example Failure on N310

Hey Jeff, Could you give this a shot on 3.15.0.0 and let me know the results? Based on that output, the issue looks confined to ATR but it's not something I've seen reported up to this point. If 3.15.0.0 shows this issue as well, I'll reproduce it on my end and get a bug filed. Sam Reiter Ettus

Re: [USRP-users] DPDK build with N310

Akis, With UHD 3.14.1 you need to run DPDK 17.11 http://files.ettus.com/manual_archive/v3.14.1.0/html/page_dpdk.html Best, Sam Reiter Ettus Research On Fri, Dec 20, 2019 at 9:53 AM Akis Kourtis wrote: > Hello Sam, > > > > We are using the DPDK 19.11, and UHD 3.14.1. > > The hardware setup

Re: [USRP-users] DPDK build with N310

Hey Akis, What version of DPDK are you using? What version of UHD do you have on the host? I'm not sure that mode of failure is something I'd chalk up to the DPDK install. Could you give some detail on your config file, DPDK install version(s), and hardware setup as well? Best, Sam Reiter

Re: [USRP-users] E312 RX_B issue

Isaac, What version of UHD are you using to elicit this behavior? Sam Reiter Ettus Research On Mon, Dec 9, 2019 at 9:21 PM Beeman, Isaac L. via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello group, > > > > I have run into an issue with the RX_B port (channel 1) on the E312 that I >

Re: [USRP-users] Pulsations on a QPSK transmission

Just to be clear, you see these pulsations when transmitting with a b205mini, but *not* with the b210? Is the b205mini a bare board or an industrial model with a case and aluminum heat sync? Sam Reiter Ettus Research On Wed, Dec 11, 2019 at 11:48 PM Геннадий Казачёк via USRP-users <

Re: [USRP-users] set_tx_freq is not functioning properly

Does something like tx_waveforms[1] output a signal at the expected frequency? What are you using to measure the frequency output? With respect to the 10MHz, this is the frequency of signals used to discipline the internal timebase to an external source. I wouldn't expect artifacts from this

Re: [USRP-users] Crash detected - X300

Santosh, Does this error occur with a shipping example like "tx_samples_from_file"? If the answer is yes, I'd recommend upgrading UHD to a more recent version. Not sure what your versioning constraints are, but I'd recommend the tag "v3.14.1.1" - this is the current release of UHD. If the

Re: [USRP-users] Time Synchronized Transmit with 2 USRPs

Hasan, Are the USRPs sharing any kind of timing / clocking signals? Typically we would recommend that you share a reference clock and PPS clock across all devices, and from there you'd just need to coordinate timed commands. With timed commands in UHD, you can tell each USRP to reset its internal

Re: [USRP-users] Error message: UHD: 1

Lukas, You can test your hardware and software stack by running a couple UHD shipping examples. Check out the examples here: https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio You can also recompile UHD with the logging level set to trace in your CMAKE flags:

Re: [USRP-users] GPIOs timed commands

I believe this will work. It should just be a matter of setting the command time before you send over a usrp->set_gpio_attr() Sam Reiter Ettus Research On Thu, Dec 5, 2019 at 2:34 AM Emanuel via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi everybody, > > > > could the GPIOs, e.g., on a

Re: [USRP-users] transmitting on two channels with replay block

Thomas, Upon further investigation, we may be running up to a practical limit of a single CHDR interface rather than an issue with your code. A single replay block servicing two radios will have a max (theoretical) rate of 187.5 MSPS on either channel. This means that you might be able to squeeze

Re: [USRP-users] transmitting on two channels with replay block

Thomas, I'd need to set it up on my end, but I believe you can TX two distinct waveforms from a single replay block instance. You'd need to make sure that your adding your data to the buffer in separate locations and at an address that is a multiple of 8 bytes (which it looks like you're doing

Re: [USRP-users] USRP X3x0 FPGA source (LV)

Wheberth, The source code for any of the NI-USRP side of things is locked down. Even if I thought is was something that would be useful in this case (I'm still not convinced it would be), it's not something I'm at liberty to release. However, from your email, it sounds like the main hesitation

Re: [USRP-users] USRP X3x0 FPGA source (LV)

Wheberth, What you're trying to do sounds possible, but I think you're approaching it the wrong way. When you use the USRP with a default FPGA image (usrp_x310_fpga_HG.lvbitx), you just get the HG image that you can interface with using the NI-USRP driver in LabVIEW. In that case, everything you

Re: [USRP-users] GPIO ATR signals

Keith, If I'm understanding your question correctly, the answer is yes. ATR is set up to allow a GPIO pin to vary its state based on whether a channel of the radio is transmitting or receiving. You can set this per-pin and per-channel. You can also use GPIO without tying it to ATR at all. Here's

Re: [USRP-users] questions about uhd-dpdk with n310

Panny Wang, That's about the expected behavior currently. From the test benchmarks that we have published, 3x3 @122.88 is not something that has been sustained without some kind of flow control issue. If you want to explore building a system to move towards this, I would recommend that you start

Re: [USRP-users] questions about uhd-dpdk with n310

Panny Wang, The cpufreq-info looks good, but the ifconfig at the bottom is a bit confusing with what you've sent over up to this point. Can you send the exact ./benchmark_rate command that you're using (with all args included) to produce the output you sent over initially? The MPMD info in the

Re: [USRP-users] questions about uhd-dpdk with n310

Hey Panny Wang, You're correct, you should specify a second address with addr/second_addr, rather than addr0/addr1 - my bad. [1] Assuming you're using both 10GbE links correctly, my next step would be to investigate the processor you're using. Something with a higher clock speed is generally

Re: [USRP-users] questions about uhd-dpdk with n310

Panny Wang, I notice that you're only specifying a single streaming address in your call to benchmark rate, implying that you're only leveraging a single 10GbE link. You can specify "addr0=,addr1=" in your device args. Best, Sam Reiter SDR Applications Engineer Ettus Research On Wed, Oct 30,

Re: [USRP-users] X310 over PCIe not found in Ubuntu 18

Would you be able to try shifting this card to another PCIe slot in your machine? I'm also interested in knowing what other PCIe devices you have connected to the computer. It might be worth making the X310's PCIe link the only connection, at least for testing purposes. Sam On Wed, Oct 23,

Re: [USRP-users] [usrp-users] E320 Multi TX Stream Operation in GR 3.8 stops during configuration of the USRP sink

Alex, I suspect this is something specific to GNU Radio 3.8, but it's not something I've seen up to this point. To help narrow down the problem, could you run your test flowchart on GNU Radio 3.7 and report back the results? Sam On Tue, Oct 22, 2019 at 8:11 AM Alexander W via USRP-users <

Re: [USRP-users] E310 LO offset problem

Does that "ghost" signal change offset as you increase and decrease your sample rate? -Sam On Tue, Oct 22, 2019 at 2:16 AM Skorstad,Jørn via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi list, > > > > I am writing a C++ software which will scan through a given frequency > range and

Re: [USRP-users] TwinRX and UBX under same multiUSRP object on X310s

Carlos, You're correct that currently we can't currently use a TwinRX and a UBX in the same chassis without running into sample rate / tick rate conflicts. I would guess that this would extend to a chassis with UBX boards and a chassis with TwinRX boards if they're encapsulated in the same

Re: [USRP-users] E310 packet size

Hey Jorn, get_max_num_samps() is "Get the max number of samples per buffer per packet." [1]. I haven't dug into it, but I'd guess that this is something that's dictated by your data type and your NIC's MTU. Does that return value change when you adjust your host side MTU? -Sam [1]

Re: [USRP-users] tx_time, L, & USRP

Hey Jason, Are you making sure that you're setting your TX time tag to be 2 seconds ahead of the USRP's sense of time? A late packet means that the time a packet should be executed on has already passed (as far as the USRP is concerned). You can use calls like: get_time_now()

Re: [USRP-users] X310 Temperature Range

Arun, Sorry for the confusion. The X310 uses a commercial grade XC7K410T with a temperature range of 0-85C. Sam On Tue, Oct 15, 2019 at 10:11 PM Arun kumar Verma wrote: > Hi Sam > > Thanks for the information. My only doubt is about the FPGA. FPGA is > industrial grade or Commercial grade ?

Re: [USRP-users] USRP B210 ERROR

Khizar, Is this still an issue for you? There's an important step in the UHD install process to allow USB devices to be used by non-root users: https://files.ettus.com/manual/page_transport.html#transport_usb_udev Let me know if this does the trick. Sam On Tue, Sep 24, 2019 at 1:10 AM Khizar

Re: [USRP-users] X310 Temperature Range

Hey Arun, The temperature range for the X310 and the TwinRX is noted as 23 +/- 3 C. This is meant to convey that the device is intended for indoor lab use and has not been thoroughly tested in extreme environments like you've mentioned. You're also correct that you'll see device performance

Re: [USRP-users] Fwd: Error handling D when reading data USRP N 210

Ivan, Thanks for sending that along. From a software perspective, what parameters do you input to your attached code to run it? I'm trying to understand the data rates you're trying to sustain over the NIC you have. I've been combing through this past USRP-users thread for some additional

Re: [USRP-users] Error handling D when reading data USRP N 210

What hardware are you using on the host side? Specifically, I'm interested in CPU, RAM, and NIC. Sam Reiter On Tue, Oct 8, 2019 at 6:22 AM Ivan Zahartchuk via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello. When I read data from the board, error D periodically passes. It > leads to

Re: [USRP-users] Detection of USRP X310

Saimanoj, Depending on which red lights you're talking about, that's not necessarily indicative of an issue. Can you tell me a bit more about what was going on when you had the issue? Were you trying to write an FPGA image to the device, or did it just die out of nowhere? Additionally, I'd like

Re: [USRP-users] USB devices not working with recent UHD drivers on Windows systems

Jakub, If you specify: uhd_find_devices.exe --args type=b200 Do you still see it hang? Sam On Fri, Aug 30, 2019 at 11:06 AM Jakub Rybka wrote: > Hello Sam, > >rolling back to libusb 1.0.21 does indeed make things work better, but > I must say far from perfect. > >

Re: [USRP-users] USB devices not working with recent UHD drivers on Windows systems

Hey Jakub, Thanks for the additional details. I can confirm that I've seen some suspicious behavior from with UHD 3.14.1.0 binary on my machine since you sent this in. It seems like libusb 1.0.22 causes crashing behavior with uhd_find_devices. I rolled this back to libusb 1.0.21 and things seem

Re: [USRP-users] e320 GPIO pinout

Aaron and Robin, There is some clean-up taking place on the E320 schematic before it will be made publicly available. I'd expect that we'll have the schematic published to kb.ettus.com/E320 in September. In the meantime, don't hesitate to reach out to supp...@ettus.com if there's any information

Re: [USRP-users] USB devices not working with recent UHD drivers on Windows systems

Jakub, I'll look into this. The issues you're reporting with the binary are probably what I'll want to try to reproduce first. Can you be more specific as to the behavior of your system during the crash you're reporting? Screenshots would be useful if there are dialogs present during / after the

Re: [USRP-users] UHD Python API on windows

Hey Kevin, Not sure if this is still on your radar, but the binary packages for Windows should always install Python headers [1]. Would you be able to provide some more detail regarding what you're struggling with? [1] https://files.ettus.com/manual/page_python.html - Sam On Fri, Aug 16, 2019

Re: [USRP-users] A Question about Synchronization

Let's keep the usrp-users list included on these communications -- there are plenty of folks far more experienced than myself who may have valuable input. Why don't we look at this from the standpoint of your requirements. What is your end goal with synchronizing your two devices? Do you need

Re: [USRP-users] 答复: 答复: 答复: N310 "Bad CHDR or packet fragment" Problem

This thread died out with a rollback to 3.14.0.0 recommended. The issue at hand is a mismatch between the MTU settings on the host machine and the radio. Here are the steps to manually correct the MTU with 3.14.1.0: 1. Check your host's MTU with ifconfig. Over 1GbE, your interface should have an

Re: [USRP-users] 答复: 答复: N310 "Bad CHDR or packet fragment" Problem

Can you post the output of *ifconfig* on your system? Sam Reiter SDR Support Engineer Ettus Research On Thu, Jul 25, 2019 at 7:40 PM 汤 飞 wrote: > Thanks! > > I am learning to use RFNOC to integrate a baseband. So I used PyBOMBS to > create the environment. The automatically installed UHD

Re: [USRP-users] 答复: 答复: N310 "Bad CHDR or packet fragment" Problem

Found the offending commit and reported the issue. It also looks like adding *recv_frame_size=1476* explicitly to the device arguments cleared things up on my N310 running 3.14.1.0. Let me know if this does / doesn't work for anyone. Sam Reiter SDR Support Engineer Ettus Research On Thu, Jul

Re: [USRP-users] 答复: 答复: N310 "Bad CHDR or packet fragment" Problem

Follow up on this thread. I ran my N310 with a 1GbE link and was able to reproduce the "Bad CHDR or packet fragment issue". It seems specific to N3xx RX over a 1GbE link on 3.14.1.0. I didn't spend a ton of time trying to find a workaround on 3.14.1.0, but rolling back to 3.14.0.0 cleared the

Re: [USRP-users] UHD not showing USB version through which my X310 is connected

Rodolphe, The X310 can operate over three protocols: 1Gb Ethernet, 10Gb Ethernet, or PCIe. The only way I could see USB coming into play would be with something like a USB to RJ45 adapter to connect to your host. In this case, the X310 and UHD would not be aware of the fact that USB is in use --

Re: [USRP-users] Detection of USRP X310

When you plug in either link, do you see the LEDs on the SFP ports illuminate? You may have bricked the X310 if these ports are unresponsive. Here's a *discovery* guide that might be helpful: https://kb.ettus.com/Troubleshooting_X300/X310_Device_Discovery_Issues Here's a *recovery* guide if that

Re: [USRP-users] N310 "Bad CHDR or packet fragment" Problem

If you're connected over a 10GbE link, make sure to set your host's MTU appropriately. I set mine to 9000. Sam Reiter SDR Support Engineer Ettus Research On Fri, Jul 19, 2019 at 2:21 AM 汤 飞 via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, all, > > When benchmarking my N310, I keep

Re: [USRP-users] UHD still errors after build installation

Bernd, I'm adding the usrp-users mailing list back to this conversation as someone may have more insight on this than I do. I was able to reproduce your CMake output by removing the Entry Values for *LIBUSB_INCLUDE_DIRS *and *LIBUSB_LIBRARIES. *If, in your CMake Entries, these have a big

Re: [USRP-users] UHD still errors after build installation

I agree with Marcus as I ran into this recently myself. Make sure you're running Visual Studio as an Administrator before attempting to install. Sam Reiter SDR Support Engineer Ettus Research On Sun, Dec 16, 2018 at 2:13 PM Marcus Müller via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi

Re: [USRP-users] Question B210 installation of C++ driver under Visual Studio 2017

Just to tack onto this, I'm wrapping up an update to the "Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows " KB to reflect use with Win10 and VS2017.

Re: [USRP-users] Hello,

Hey Brais, Check out this thread: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-May/052761.html It looks like the PLL mechanism used to discipline the onboard oscillator results in enough phase noise to preclude its implementation in a MIMO setup. At least in a setup that

  1   2   >