discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] synchronization throughout flowgraph


From: Vincenzo Pellegrini
Subject: Re: [Discuss-gnuradio] synchronization throughout flowgraph
Date: Wed, 11 Mar 2009 23:45:28 +0100

Crystal clear.. :-)

thank you Tom

2009/3/11 Tom Rondeau <address@hidden>
On Tue, Mar 10, 2009 at 6:48 AM, Vincenzo Pellegrini <address@hidden> wrote:
> ThanksĀ  Tom,
>
> I had looked at it.
> I still have a question.
>
> It looks to me like the blocks down the line receive data from the upper
> ones and do noting with that data (so the state of block's local variable is
> frozen) but, I mean, there still is data flowing in and out those blocks.
>
> Is this assumption right?
>
> thanks
> again
>
> vincenzo

Yes, data still flows into the blocks. But, we tell the scheduler that
we have consumed all of the incoming data, but we do not produce any
output data unless the signal line has triggered. This, then, drops
the data from the incoming stream. So data can flow all day long and
be ignored until the trigger line goes high.

Tom



>
> 2009/3/9 Tom Rondeau <address@hidden>
>>
>> On Sun, Mar 8, 2009 at 8:20 PM, Vincenzo Pellegrini <address@hidden>
>> wrote:
>> > Hi everybody,
>> > just a very simple question:
>> > is there a clean way in GNURadio to do this
>> >
>> > source-->block1-->block2
>> >
>> > where:
>> > source sends let's say some gr_complex
>> > block 1 looks for some synchro signal within the flow
>> >
>> > block2 does absolutely nothing (i.e. does not process zeors or anything,
>> > simply it is frozen) untill block1 says: "well your frame starts here"
>> > and
>> > delivers a vector for block 2 to work upon.
>> >
>> > It would be great if any body who's been doing this sort of things could
>> > provide some pointer to start from.
>> >
>> > thank you all
>> >
>> > vincenzo
>> >
>> > PS.
>> > If this is not a sane way to arrange a flowgraph for doing
>> > syncronization,
>> > please point me to the sane way... ;-)
>> > Maybe I should only use stream-oriented blocks that decide what to do
>> > and
>> > when, just based on some block internal state?
>>
>> Look at the OFDM code. We did something similar where the data went
>> out port 0 and a flag signal out of port 1. The other guys down the
>> line would not do anything until they saw the flag signal go high.
>>
>> Tom
>
>
>
> --
> Vincenzo Pellegrini
>



--
Vincenzo Pellegrini

reply via email to

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