Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

On 09/09/2017 12:16 AM, Steven Knudsen wrote: I am not sure that is an option. The TDMA scheme is such that the TX/RX to inactive time duty cycle is low. During the “inactive” time, other things are going on. I suppose maybe I could just turn the RX gain to zero (and will be anyway) But

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

I am not sure that is an option. The TDMA scheme is such that the TX/RX to inactive time duty cycle is low. During the “inactive” time, other things are going on. I suppose maybe I could just turn the RX gain to zero (and will be anyway) But what you are really suggesting is more polling vs

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

On 09/08/2017 11:53 PM, Steven Knudsen wrote: Okay, I can accept that. What it means is that since my customer has not settled on a USRP platform, I should put some checks in that enforce timing constraints. Stuff like looking at the number of samples for the max expected packet length times

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

Okay, I can accept that. What it means is that since my customer has not settled on a USRP platform, I should put some checks in that enforce timing constraints. Stuff like looking at the number of samples for the max expected packet length times the sample rate and comparing to a max

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

On 09/08/2017 11:38 PM, Steven Knudsen wrote: Let me see if I understand you correctly. Are you saying that turning on the first reception takes significant time? In my case, the receive loop is running before the scheduling starts; it just times out and spins around again. So I am not sure

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

Let me see if I understand you correctly. Are you saying that turning on the first reception takes significant time? In my case, the receive loop is running before the scheduling starts; it just times out and spins around again. So I am not sure that the receive startup is the problem. But if

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

On 09/08/2017 10:54 PM, Steven Knudsen wrote: Hi Marcus, I did rebuild LiquidDSP, though it has no dependencies on the UHD. No change in behaviour. Rather than speculate further with you (and waste your time), I pressed ahead with various avenues of investigation and appear to have had

Re: [USRP-users] B200mini scheduled RX & TX; Tx attenuated

Hi Marcus, I did rebuild LiquidDSP, though it has no dependencies on the UHD. No change in behaviour. Rather than speculate further with you (and waste your time), I pressed ahead with various avenues of investigation and appear to have had some success. What seems to be the problem is that

[USRP-users] (RFNoC) Command Sequence Number Mismatches

We have an app using RFNoC Radio blocks running on the e310 that uses a TX frequency hopping at ~70Hz and a non-hopping RX that is intermittently re-tuned every few seconds. We are experiencing an intermittent, but ultimately unrecoverable IO error when sending tuning commands to our RFNoC radio

Re: [USRP-users] UHD dropping samples running on Debian 9

Yes. We are using a N210 and the memory limits have been updated to 50M. Interesting to hear that it works with Ubuntu17, tho we would like to stick with Debian. Any other ideas or queations? Meelis 8. sept 2017 6:46 PM kirjutas kuupäeval : > The original e-mail reporting

Re: [USRP-users] [RFNoC][BLOCK DESIGN] Questions about design in RFNoC

Hi Ruben, Regarding why the "copy" block is necessary, please see the following post: https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/ Specifically, the "Addendum" section at the bottom. The E310 needs to have the TX streamer enabled explicitly if the application doesn't include a

Re: [USRP-users] B200mini & XU4 problem

I've run a simple interferometer application with a B210 on an XU4, with two channels at 15Msps. On 2017-09-08 11:23, David wrote: > Thanks Marcus, > > so doing ... benchmark_rate --args "num_recv_frames=512" --rx_rate 40e6 > > no overruns (got a couple with 256). > > I'm just trying to get

Re: [USRP-users] UHD dropping samples running on Debian 9

The original e-mail reporting "trouble" didn't specify which USRP device was involved, so in the interests of clarification and completeness, I thought that I'd interject about USB devices. Yes, the N2xx and X3xx devices use a 1GiGe (or optionally 10GiGe for X3xx) for connecting to the host

Re: [USRP-users] UHD dropping samples running on Debian 9

USRP N2xx or X3xx are network devices? On 08/09/17 16:07, mle...@ripnet.com wrote: USRP devices that are attached via USB don't use the networking stack, so tweaking network-stack kernel parameters is irrelevant. Since the USB devices use LibUSB, which is entirely user-space, the

Re: [USRP-users] B200mini & XU4 problem

Thanks Marcus, so doing ... benchmark_rate --args "num_recv_frames=512" --rx_rate 40e6 no overruns (got a couple with 256). I'm just trying to get a feel of what is possible with this processor, Cheers Dave On 08/09/17 15:58, mle...@ripnet.com wrote: I've found that altering

Re: [USRP-users] UHD dropping samples running on Debian 9

USRP devices that are attached via USB don't use the networking stack, so tweaking network-stack kernel parameters is irrelevant. Since the USB devices use LibUSB, which is entirely user-space, the transport parameters here should be investigated:

Re: [USRP-users] UHD dropping samples running on Debian 9

could you explain why please? On 08/09/17 15:55, Marcus D. Leech via USRP-users wrote: This is presumably a network-attached USRP (N2xx or X3xx)? Otherwise, network parameters are irrelevant. On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote: Hello, We lately bought 2 new NUC

Re: [USRP-users] B200mini & XU4 problem

I've found that altering num_recv_frames in the device args to be helpful on XU4--try 128 or 256 On 2017-09-08 10:34, David via USRP-users wrote: > Just tried out a USB3 powered hub, to power the b200. > > The XU4 wouldn't boot powered from the hub (2A max), but powered from it's > own supply

Re: [USRP-users] UHD dropping samples running on Debian 9

This is presumably a network-attached USRP (N2xx or X3xx)? Otherwise, network parameters are irrelevant. On 2017-09-08 10:25, Meelis Nõmm via USRP-users wrote: > Hello, > > We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), installed > Debian 9 on it and tested Gnuradio on it.

Re: [USRP-users] UHD dropping samples running on Debian 9

network buffer size? Should be... # sysctl net.core.rmem_max net.core.rmem_max = 5000 On 08/09/17 15:25, Meelis Nõmm via USRP-users wrote: Hello, We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), installed Debian 9 on it and tested Gnuradio on it. At first we installed

Re: [USRP-users] UHD dropping samples running on Debian 9

We use several NUC6i7KYK units without any issues. They run Ubuntu 17.04 On Fri, Sep 8, 2017 at 10:29 AM Meelis Nõmm via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), > installed Debian 9 on it and tested Gnuradio

Re: [USRP-users] B200mini & XU4 problem

Just tried out a USB3 powered hub, to power the b200. The XU4 wouldn't boot powered from the hub (2A max), but powered from it's own supply (4A) and the B200mini powered from the hub all seems OK, no device errors, fscks on reboot, etc. :-) :-) So, using "benchmark_rate --rx_rate 40e6", I

[USRP-users] UHD dropping samples running on Debian 9

Hello, We lately bought 2 new NUC devices (a NUC7i7BNH and a NUC6i7KYK), installed Debian 9 on it and tested Gnuradio on it. At first we installed via apt-get. We saw some drops in the gnuradio-companion and had issue with setting the real-time priority, so we removed it from the system and

[USRP-users] [RFNoC][BLOCK DESIGN] Questions about design in RFNoC

Hi everybody, We are working in a PRBS Generator and the idea is to make it works with the RFNoC structure. But we are having some troubles and need some help on it. Could you please clarify this four points? : 1. Trying to understand the functionality of a RFNoC Generator, we were trying to

Re: [USRP-users] Porting from x86 to armv7 (Ettus E310) - performance issues

I'm not feeling the same guilt, Philip, so I'll just go ahead and "complain" about ARM :D So, the ARM/Thumb instruction sets don't come with a Modulo instruction; Hence, "a%b" very likely is implemented as a-⎣a/b⎦·b And integer division often takes multiple cycles, and even more so, can take 4

Re: [USRP-users] Error using coder.internal.errorIf (line 8) The input signal must be complex.

Hi Nur Qalbi, with that info, we can't really infer what's wrong with your Matlab program. You'll have to give a more comprehensive error description, and that means you'll probably have to investigate some more on your own. Apologies, Marcus On 08.09.2017 04:07, nur qalbi via USRP-users