Hello,
I resurrect this old thread because I'm almost exactly in the situation
described below by Matt but I have an hard time to come up with a solution.
I'm working with an N210. In my application I generate a modulation
signal that is sent to a system and the response of the system is
demodula
On 17.10.2014 18:58, John Malsbury wrote:
2. We tried several "clever" (ha) methods to select the desired
stream. Most of them revolved around the concept of
summering/xoring streams after multiplying or and'ing the streams
according to which stream we wanted (operand = 1 if we want
Yes, there were multiple issues in the thread, and what I said only applies
to TX. Certainly on the receive side there should be no latency issues, as
every block should do all computations they can on whatever data they
receive, since that is exactly what is tripping up the TX guys :)
Matt
On F
Matt,
BTW - in this particular case, this was *all* in the receive direction -
its a lowrate demodulator. So I was a bit surprised to see the issue at
all - 'cause I've never seen such high latency on a receive flowgraph. We
have a "closed" loop approach to managing transmit latency through the
We see this issue a lot with applications that only transmit, and which
transmit continuously. The problem is that you end up generating samples
far in advance of when you really know what you want to transmit, because
there is no rate-limiting on the production side.
Some general principles -- L
So... there were actually several contributors to this long latency. Some
of it was related to GNU Radio's inner workings, some were external. With
all of the "external" things removed, there was still 1+ minute of latency
at low bitrates.
I thought I would share my findings, for the sake of ge
Is there something i can force on a per block basis in 3.6? Is there some
trickery in the forecast function I might use?
On Oct 10, 2014 6:40 PM, "Ed Criscuolo" wrote:
> On 10/10/14 9:15 PM, John Malsbury wrote:
>
>> Sounds dangerous if you also happen to have very high throughput
>> application
On 10/10/14 9:15 PM, John Malsbury wrote:
Sounds dangerous if you also happen to have very high throughput
applications to run? Am I wrong?
Yes, it was a fine line between getting it small enough for acceptable
latency while still maintaining enough throughput to not overrun.
Fortunately for
Sounds dangerous if you also happen to have very high throughput
applications to run? Am I wrong?
On Fri, Oct 10, 2014 at 5:59 PM, Ed Criscuolo
wrote:
> Yep, that was me. I was getting to pipe-in with the same suggestion.
>
> @(^.^)@ Ed
>
>
>
> On 10/10/14 8:20 PM, Vanush Vaswani wrote:
>
>>
Yep, that was me. I was getting to pipe-in with the same suggestion.
@(^.^)@ Ed
On 10/10/14 8:20 PM, Vanush Vaswani wrote:
I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
flat_flowgraph.cc.
This is rega
I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
flat_flowgraph.cc.
This is regarded as a dodgy hack by all the GR developers here, but it
worked for me (and I read the article on latency). I believe the guy
wh
Hey John,
I am way out of my depth here, but while working on a custom python block
the other day, I saw some weird behavior in 3.7.5 that was similar.
Setting the global max output had no effect, but setting the just-upstream
block(s) min/max output buffer size(s) low fixed my apparent slowliness
Default scheduler.
tb.start(1024), with different values, etc, etc.
Most of the downstream blocks are stock GNU Radio blocks - a delay block
(max delay is 1 sample), logical operators, etc. I guess I'll add some
printf debugging?
-John
On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller
wrote:
Hi John,
On 10.10.2014 19:33, John Malsbury wrote:
> Toward the end of the receive chain, there are a multitude of blocks that
> are used for Viterbi node synchronization. I've found that the number of
> blocks in series (3-5), combined with the low datarates at this point in
> the flowgraph, lead
I thought I would join the list of people emailing the list this week about
obscure issues with ancient versions of GNU Radio.
I have a flow graph that needs to operate at a variety of datarates from a
few kbps to about 1 Mbps. Due to the potential for very wide frequency
errors, we still have to
15 matches
Mail list logo
