On 09/04/2014 06:17 PM, Nick Foster wrote:
> Looks like either the syntax for instantiating multi_usrp has changed
> (seems unlikely), or a bug was introduced, likely in 7/2-7/4's recent
> gr-uhd refactoring (1eaa96b, 350d285, fe58537, 3c42e79, 691bdaa). Sorry
> I haven't gotten more specific than
Hi Marcus,
I did what you recommended for measuring latency which is defined as
followed:
"the traveling duration of a packet through blocks until some specified
processing in one block is done".
However, there are obstacles again. Firstly, how can optimize I/O buffers
of my blocks to obtain a m
The second problem I encountered that I forgot to mention is:
when I send multiple of packets from a source block to a sink block and I
measure the latency for each packet, the latency is increasing constantly
as time advances. Why is this happening?
Best,
Mostafa
On Sun, Sep 7, 2014 at 8:04 PM,
Hello,
There is a mathematical relationship in the latency time? May be there is
something related to Ethernet protocol to handle collicollisions.
El 07/09/2014 09:39, "Mostafa Alizadeh" escribió:
> The second problem I encountered that I forgot to mention is:
> when I send multiple of packets f
Hello,
I have a simple application written in Python using GNURadio. All I am
trying to accomplish is to have the USRP data be written to disk. The
application works fine when I dump data to /dev/null or run it at reduced
sampling rates. However, when I run at my desired sampling rate, I have a
On 09/07/2014 04:24 PM, Peter Witkowski wrote:
Hello,
I have a simple application written in Python using GNURadio. All I
am trying to accomplish is to have the USRP data be written to disk.
The application works fine when I dump data to /dev/null or run it at
reduced sampling rates. Howev
Try messing around with the buffer size in
gnuradio-runtime/lib/flat_flowgraph.cc
#define GR_FIXED_BUFFER_SIZE
On Mon, Sep 8, 2014 at 6:24 AM, Peter Witkowski wrote:
> Hello,
>
> I have a simple application written in Python using GNURadio. All I am
> trying to accomplish is to have the USRP da
Not sure I follow. If I have a large enough buffer, the data coming in and
the data coming out should be free of concurrency issues and should be able
to work just fine. That is, as long as the producer thread can keep adding
data to the message queue, I should be OK. If it gets locked out due to
On 09/07/2014 07:08 PM, Peter Witkowski wrote:
Not sure I follow. If I have a large enough buffer, the data coming
in and the data coming out should be free of concurrency issues and
should be able to work just fine. That is, as long as the producer
thread can keep adding data to the message q
Hi:
I am have some problems running GNURadio-Companion on my Quad-core Wandboard
(ARM 7i hf) running Ubuntu 14.04.
When I execute GNURadio-Companion I get a whole bunch of errors, here is the
last few lines:
Warning: Block validation failed:
/usr/local/share/gnuradio/grc/blocks/variable
Aditya/Martin, thanks your help, I will read these references that you
mentioned.
在 2014年09月06日 00:31, Aditya Dhananjay 写道:
Hi Tiankun,
To add on to what Martin said: In DFE, the channel state H_I on
subcarrier i is updated everytime it receives a new symbol on that
subcarrier. It doesn't rea
Harold,
I'm not using any protocol. This is just a GNURadio application.
It is important to me to know is there any way to optimize input/output
buffers of blocks to reduce latency as much as possible? Is the GNURadio
able to do so automatically?
Best,
Mostafa
On Sun, Sep 7, 2014 at 9:49 PM, Har
12 matches
Mail list logo
