[Top][All Lists]

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

[Discuss-gnuradio] Question about basic GSR internals

From: David Beberman
Subject: [Discuss-gnuradio] Question about basic GSR internals
Date: Sun, 15 Aug 2004 09:38:25 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114

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.)

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.

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.

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.
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. I have to look through the flow graph sorting code to see how much extra processing this
might entail.

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.

I haven't looked into the gr_block_detail code yet. May understand things better after reading that.

Please let me know if I'm somewhat on the right track.


David Beberman

reply via email to

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