On Thu, Apr 24, 2014 at 10:14 PM, Vanush Vaswani <[email protected]> wrote:
> Try decreasing the buffer size in gnuradio-runtime/lib/flat_flowgraph.cc > I use: > #define GR_FIXED_BUFFER_SIZE 2048 > There are a number of hooks to each block to set various values to help you control stuff, like set_max_output_buffer. See the docs for more: http://gnuradio.org/doc/doxygen/classgr_1_1block.html Just be careful using these! They are advanced functions since you're messing with the scheduler behavior. Tom > On Fri, Apr 25, 2014 at 9:08 AM, Bolin Hsu <[email protected]> wrote: > >> I found pausing the flow graph to be the wrong action for my situation. >> >> I tried to find out how many samples are in my flow graph. I inserted >> logging to the work function of two blocks in my flow graph. One is the >> signal source whose frequency is altered if a frequency shift is detected. >> The other is the last block of my flow graph. The log prints the value of >> nitems_written() of the blocks. The difference of the items written >> between these two blocks is roughly equal to the samples I lost waiting for >> the new setting to take effect. So I think the latency is the time it takes >> to drain the samples that has gone too far down the flow graph to be >> affected by the new setting. >> >> Obviously pausing the flow graph won't help. Instead, it would be helpful >> if I could speed up draining the samples that can't be affected by the new >> setting, something like flowgraph.clear_downstream(basic_block_sptr >> start_block), which discards all samples in blocks that is reachable from >> start_block's output ports according to the flow graph. The time spent on >> moving and processing useless samples could be saved. Does this idea make >> sense? >> >> Thanks, >> Bolin >> >> >> On Wed, Apr 23, 2014 at 5:11 PM, Bolin Hsu <[email protected]> wrote: >> >>> 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 >>> functorthread_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_tpb runs 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 >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
