Hello Munir,
You are not supposed to use 'throttle' blocks if the rate of the flowgraph is
already limited by attached hardware (ex: USRP src /sink, audio source / sink).
As Derek mentioned, this is probably due to the two-clock problem of the
system. Try inserting a few seconds of delays to
>
>
> The SC12 support apparently broke at some point. I know that Michael West
> (Ettus R&D team) has been working to get it working again,
> but won't be ready for a little bit.
>
> I use SC12 myself in my lab, but I don't recall which UHD version I'm
> using in the lab, and won't be there unt
Hi Derek,
Thanks for the response. The answer to your question "Do you have a
throttle block or a piece of hardware?" is that I used USRP N200 hardware
to get data. I also placed throttle block as well. I checked on different
possible sample rate of sound card. The problem is whenever I run the sam
On 07/27/2018 12:02 AM, RizThon wrote:
I've tried with 3.12.0.0, on both Windows and Linux.
On Ubuntu 18.04, I can set num_recv_frames to what seems like any
number without getting error. I tried 128, 256, even 512 and 1024.
I do get better results than on Windows, but I'm still getting lots
I've tried with 3.12.0.0, on both Windows and Linux.
On Ubuntu 18.04, I can set num_recv_frames to what seems like any number
without getting error. I tried 128, 256, even 512 and 1024.
I do get better results than on Windows, but I'm still getting lots of
overflows.
I did try 3.13.0.0 on Window
Hi Farnaz,
A couple of remarks and questions
- Remark 1: in order to get 200 MS/s transmit streaming, you will NEED to
have the samples on the USRP. The host-to-USRP streaming does not work at
200 MS/s for the transmit case (unless something has recently changed). The
host-to-USRP max for transmit
On 07/26/2018 01:30 PM, Андрій Хома wrote:
Have you changed your cpu governor to performance?
yes
Have you tuned your network interface profile with ethtool -g?
When I work with a usrp x310 - yes
I found that maxing out that buffer size helped lots.
i playing with it
You ma
Ahh sorry dude. That is what used to happen to me before I tried the stuff
I listed. The only other thing I can thing of is maybe playing around with
MTU. I found my best performance at 4000, but I'm not sure that will help.
On Thu, Jul 26, 2018 at 11:30 AM, Андрій Хома wrote:
> Have you changed
>
> Have you changed your cpu governor to performance?
>
yes
Have you tuned your network interface profile with ethtool -g?
>
When I work with a usrp x310 - yes
I found that maxing out that buffer size helped lots.
>
i playing with it
> You may also have to manually schedule your threads if usi
Have you changed your cpu governor to performance? Have you tuned your
network interface profile with ethtool -g? I found that maxing out that
buffer size helped lots. You may also have to manually schedule your
threads if using isolcpus/numactl/taskset. I noticed that the linux
scheduler did a poo
Yes, thank you, I've tried this before: I allocated 10 or more cores purely
for the USRPs. Overflows are generally less, but when starting any
application, one or two "O" are guaranteed to be printed.
Therefore, I suggested that maybe it's a case of cache or something else.
I was playing with num_
Hi Alejandra.
The Octoclock (NI CDA-2990) user manual lives on the National Instruments
website:
http://www.ni.com/pdf/manuals/375747c.pdf
Here is the product page:
http://sine.ni.com/nips/cds/view/p/lang/en/nid/213460
-Robin
On Thu, Jul 26, 2018 at 9:18 AM, Alejandra Mercado via USRP-users <
Hi Bob. The USRP N310 Letter of Volatility lives on the National
Instruments website.
http://www.ni.com/pdf/manuals/377420a.pdf
-Robin
On Thu, Jul 26, 2018 at 8:34 AM, Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
>
>
> I was looking on the kb, but did not se
Dear USRP folks,
I've just received a CDA-2990 8 Channel Clock Distribution Accessory with
GPSDO, and I'm looking for a user's manual in
https://kb.ettus.com/OctoClock_CDA-2990
Under the Section
- *Where can I find user manuals for the OctoClock and USRP*
Here is helpful document. Sync. and
Hello,
I was looking on the kb, but did not see, is there a Certificate of Volatility
for the N310 somewhere?
Thanks,
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
What version of UHD? I’ve used SC12 myself without issue.
Sent from my iPhone
> On Jul 26, 2018, at 1:28 AM, RizThon wrote:
>
> SC12 actually gives me an error as soon as it starts streaming (with or
> without specifying num_recv_frames=44). Using the --continue option, I get
> tons of such
Dears,
To be more specific, we want to control multiple USRPs with one (remote)
computer. We would like to stream known and periodic signal from each USRP.
The sequence on each USRP is unique and is different from other USRPs.
Since the samples from each USRP are known, it would be more convenie
Make sure that you’re increasing the num_recv_frames in the device args as well
Sent from my iPhone
> On Jul 26, 2018, at 11:10 AM, Keith k via USRP-users
> wrote:
>
> How many CPU cores do you have? I've also found this a problem with multiusrp
> and high data rates. The solution for me was
When trying to set a custom register in a noc block with multiple ports, I
noticed that there is no noc script SR_WRITE that includes the port
argument. Is this on the list to be added?
Rob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://l
How many CPU cores do you have? I've also found this a problem with
multiusrp and high data rates. The solution for me was to isolate cpu cores
and then use taskset to run my program on the isolated cores. This
drastically reduced the number of overflows to almost none. This however
will probably r
Motherboard Z10PE-D8 WS
Processor Intel Xeon E5-2630V4
Sample rate - 45MHz
In general, overflows are not regular. If the computer is not touched by
any other tasks - then everything is almost fine. But you just have to try
to run some application (for example, a leafpad), but at least just browse
Depending on what your application is doing, and your sampling rate, disk
I/O can also be a major factor too.
--Neel Pandeya
On Thu, Jul 26, 2018, 19:31 Neel Pandeya wrote:
> In general, CPU clock speed is more important.
>
> What sampling rate are you using?
>
> --Neel Pandeya
>
>
>
> On Thu,
In general, CPU clock speed is more important.
What sampling rate are you using?
--Neel Pandeya
On Thu, Jul 26, 2018, 19:27 Андрій Хома via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Perhaps a dumb question: what is more critical in order to avoid buffer
> overflows ("O")? Frequency, c
Perhaps a dumb question: what is more critical in order to avoid buffer
overflows ("O")? Frequency, cache size, or something else?
I dealt with two processors
1: 2.2GHz, 25MB cache
2: 3.5GHz, 15MB cache
In both cases, I observed overflows
4х usrp b205mini, through usb3.0
Thank you, Andrei.
__
Hi Everyone,
I have created a source block with two output ports using the rfnocmodtool.
My first question concerns the implementation of the axi_wrappers: I have
inserted two axi_wrappers, one for each port (Full code below). Is there
any more preferable way to construct the axi_wrapper interfac
Hello,
I am working with the x300 and am trying to receive on both RX2 channels and
transmit on both TX/RX channels in real-time using UHD API . I am creating a
stream for each channel, set the mode to continuous, issue the stream command,
and then later issue receives (recv) and transmits (sen
Thank,
Martin.
I try and can not work!
I need to deep into now.
Best,Regards
Carry
From: USRP-users on behalf of Martin Braun
via USRP-users
Sent: Wednesday, July 25, 2018 5:34:44 AM
To: 'USRP-users@lists.ettus.com'
Subject: Re: [USRP-users] usrp e310 one tx one
27 matches
Mail list logo
