[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.
Thanks,
David Beberman
- [Discuss-gnuradio] Question about basic GSR internals,
David Beberman <=