I wish to report my findings on the idea of pausing the flow graph, and hope to get feedback from the experts on this list. I only started using GNU radio last month so it is likely I didn't have enough experience to understand it properly.
My understanding of the flow graph execution was a scheduler checks the blocks in a round robin fashion, and execute the work function of a block if the block can make progress. So my intention was to add functions to the scheduler to allow pause and resume from python via top block. When paused, the scheduler won't run any block's work function. I looked into the scheduler source code to find ways of implementing pause and resume. It seems very hard to pass the intention to pause or resume to the scheduler. Specifically, top_block_impl creates a scheduler_tpb, and scheduler_tpb creates a thread using the functor thread_body_wrapper. The thread_body_wrapper contains another functor tpb_container. In tpb_container's () operator, a tpb_thread_body is constructed. So the way scheduler_tpbruns a block is by creating a thread that runs the constructor of tpb_thread_body through two levels of functors. The tpb_thread_body constructor contains an infinite loop. In every iteration of the loop, the work function of the block running on the thread is called if permissible. So tpb_thread_body seems to be a good place to pause the flow graph, and I need to send the intention to pause or resume to tpb_thread_body. The intention can easily go from python to top_block to top_block_impl to scheduler_tpb. But the tpb_thread_body is created by the thread library and not readily accessible by scheduler_tpb. Furthermore, there are two level functor indirection between scheduler_tpb and tpb_thread_body. I did find two existing ways of passing information to tpb_thread_body: thread interrupt and message passing. But they don't seem to be the proper ways of sending the pause and resume information. Any suggestion is welcomed. Thanks, Bolin On Wed, Apr 23, 2014 at 8:22 AM, Bolin Hsu <[email protected]> wrote: > Hi Marcus, > > Thanks for reply. Let me try to answer the questions. > > Yes. The signal frequency shifted by +/- 5%. > > The transfer burst is constant. > > The frequency shift remains constant during a burst. So I estimate the > shift in the beginning of a burst, and fix the setting of demodulator and > resampler over the whole burst. I use FFT and interpolation to estimate the > frequency shift. > > The "estimate frequency shift then configure demodulator" approach works, > except it takes 600-700 ms for the demodulator to start outputting meaning > data after receiving correct configuration. I call this 600-700ms time the > reconfiguration latency. > > Maybe I used wrong term. By reconfiguration I mean I made two function > calls: one is the set_frequency of signal source, the other is > set_resamp_ratio of the fractional resampler. My data rate is 44.1k. So I > lost about 30k samples when I was waiting for the reconfiguration to take > effect. > > Regards, > Bolin >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
