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 wrote
Hi John,
the one "USRP Source" with three addresses combines both X310 in one UHD
"multi_usrp". The most prominent advantage of that is that UHD will
automatically try to align the sample streams coming from the USRPs
according to the timestamps in the metadata coming from the USRPs.
But that can
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 u
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 tra
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
instal
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 get
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 on
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
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.
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
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 devices
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:
https://files.ettus.com/manual/page_transport.h
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 num_recv_fra
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
transport
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 comput
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
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
strea
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 "trouble" didn't specif
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 b
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 w
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 some
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
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 th
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 allowable
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
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
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 what
27 matches
Mail list logo
