discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Intercommunicate processes


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Intercommunicate processes
Date: Wed, 1 Aug 2012 21:10:54 -0400

On Wed, Aug 1, 2012 at 3:19 AM, Pol Henarejos <address@hidden> wrote:
> Dear Tom,
>
> Even though the loses are low, I would like to do not lose any sample. I
> implemented a sink/source block using shared memory and I can guarantee
> that there are no loses.
> However I discovered a deeper problem. There is a strange behaviour with
> hier_block2. I test the following topoly:
> A -> B -> C -> D, where B and C are sink/source blocks (using shared
> memory or udp, it does not matter, they are basic blocks). A and D are a
> CRC encoder and decoder but in a hier_block2. In more detail, in A there
> are the following connections:
> Data_Generator -> CRC_attacher -> self
> D is the reciprocal block. CRC_attacher is also a hier_block2 in the
> following way:
> self -> CRC_compute -> self
>
> Hence, I use a hier_block2 inside another one. Yes, I know I could use
> CRC_compute without being encapsulated in the hier_block2 but in the
> future will be additional blocks.
> With this topology there are CRC fails. If I use CRC_compute without
> hier_block2 all CRC decodings are ok. So it seems there is a rare
> problem with hier_block2.
> I read a similar problem in
> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-04/msg00061.html
> and therefore I put a kludge_copy after/before self connections. But the
> problem still occurs.
>
> What could it be?
>
> Thanks.
>
>
> Pol Henarejos
> Research Engineer, MSc
> address@hidden

Pol,

That's concerning.

Any chance you can produce a simple graph using existing blocks in GNU
radio to help us examine this problem?

Thanks,
Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]