Re: [Discuss-gnuradio] Question about basic GSR internals

[Eric Blossom]

On Sun, Aug 15, 2004 at 09:38:25AM -0700, David Beberman wrote:
> I'm currently looking through the 2.1 version of GSR.
> I want to confirm that I understand what I'm looking at.
> There is only one execution thread for a flow from source to sink(s).
> (I assume it is possible to have multiple flows set up, and each one
> would run in a different thread, but I don't have a use for that yet.)

Yes.

> I haven't looked through the flow graph sorting code, but I expect that
> the idea is to go from sinks to sources, consuming buffers upstream
> and putting the results in the downstream buffers for each block.  Thats
> what makes sense to me.

FWIW, we work from sources to sinks.

> In general, for asynchronous digital transmissions, there is usually
> some sort of preamble that the receiver can lock on to, do some
> frequency, timing, and phase recovery, and then send the rest of the
> received input on to other stages.  I would like to implement this
> within the GSR structures.

OK.

> 
> I was thinking of the following:
> 1: For each block that participates in preamble parameter recovery of 
> some kind,
> have that block be a terminating sink. 
> 2: Once such a block has completed its processing, the parameters are 
> made available
> through a global parameter block.  This could be protected with mutexes 
> for future
> multithreading operation.

I suggest thinking more along the lines of a hardware designer or
equivalently from a data-flow point of view.  Instead of having your
preamble detector be a sink, think of it as a "feature extractor".
You might want it to have a single input (the processed samples so
far), and, say two outputs.  One output might be identical to the
input stream, the other might contain status information, perhaps
a single bit per sample that indicates "preamble starts on this
sample".

Depending on your application and protocol, you might want the
preamble detector to also perform some kind of a serial-to-parallel
conversion.  E.g., stream of samples in, stream of N sample packets
out, where you form packets based on seeing the preamble.  I used this
strategy and the one above in the ATSC VSB demodulator.

> 3: Each of these blocks needs to stop receiving input after the
> required processing has completed to avoid consuming CPU cycles.  I
> can see two possibilities.  The first is to have each block return
> 0's on the forecast method.  This should stop the scheduler from
> calling the work routine.  There is still processing overhead from
> making the forecast method call.  The second approach would be to
> take the flow graph edge out of the graph completely.

  "Premature optimization is the root of all evil"

... or for the Rastafarian version:

  "Time be time.  Measure twice, cut once."


Don't worry about this until you've got it working and have measured
the real performance.  I'm a fan of oprofile (http://oprofile.sf.net)
It uses the hardware performance counters and doesn't slow your code
down.

> 4: At the end of processing an asynch frame, the system needs to be 
> reset for the next frame.
> If each block uses the forecast method to enable/disable scheduling, 
> this is an out-of-band reset
> to the blocks then.  For the second approach of changing the flowgraph, 
> the same processing
> issue exists.

If you stick with the data-flow idea, I think all of this complexity
goes away.

Eric