Hello guys again! Based on Martins suggestion and Marucs' explanation I copied some principles from sync_interpolator and situation looks much better. I used function set_output_multiple and set_relative rate and now the outcome of calling forecast function is much better. For example, for symbol rate of 10k and sampling rate of 500k i get following:
ninput_items_required 8, noutput_items 4000 ninput_items_required 4, noutput_items 2000 ninput_items_required 2, noutput_items 1000 ninput_items_required 1, noutput_items 500 ninput_items_required 8, noutput_items 4000 And as u can see it always offers integer multiple of samp_rate/sym_rate. The problem comes now when i run the flowgraph with vector source that repeats the pattern. After calling forecast program executes work function but it provides me 32768 input samples which is of course silly: work function, ninput: 32768, noutput: 4000 I don't really get what might be a problem, cause when vecotr source doesn't repeat the patern everything is fine. Thank you and best Nemanja On Mon, Oct 21, 2013 at 4:36 PM, Marcus Müller <mar...@hostalia.de> wrote: > Hm, I don't know why this should really happen before your source's work > function is called. > But basically, maybe this is part of GNU Radio trying to figure out how to > assign buffers; I haven't dived very deep into that aspect of the runtime. > However, since your forecast told GR that you're able to produce samples > without input, I could imagine that your work gets scheduled simultaneously > with those of your sources. > To circumvent that, just don't lie ;) and tell the scheduler that you need > input to produce output. > > Greetings, > Marcus > > On 20.10.2013 13:11, Nemanja Savic wrote: > > Thank you Marcus very much. I would like to ask some more questions. > For me it looks like the problem is at very begining when source has not > produced any output, and it looks like forecast of my block is called > before the work functino of the source? How should one cope with this? By > checking if required number of input samples is zero and solving that case? > How is that ensured for interpolator. > > Thanks and kind regards, > Nemanja > > > On Sat, Oct 19, 2013 at 10:35 AM, Marcus Müller <mar...@hostalia.de>wrote: > >> Hi Nemanja, >> >> Considering following flowgraph, assume your block is A, and assume all >> blocks work with the same itemsize. >> [image: $\fbox{\textrm C}\rightarrow\fbox{\textrm >> B}\rightarrow\fbox{\text{\textbf{A}}}\rightarrow\fbox{\textrm D}$] >> >> good question, but basically, when running, when A is done with a run of >> work, it's thread notifies blocks "upstream" (B in this case) that it has >> consumed [image: N] input items, making that space available for new >> output; GNU radio then calls forecast of B with a noutput_items [image: >> M_i = floor( 2 ** ( floor(log_2 N) - i) <= N, i in {0,1,...,floor(log_2 N) >> +1}] to fill that space. However, if the upstream block B needs more >> input items than C has provided, GNU Radio will repeatedly reduce the >> number of samples it asks for until B needs less or equal samples as C has >> produced. >> >> In your case, this only happens for 0 output items; thus your >> general_work gets called with 0 input items, as Martin already stated. >> So what happens then? Since A has not provided any more output items for >> the blocks downstream, D can't do anything that it has not already been >> doing. The downstream part of the flowgraph stalls. Upstream part: Since >> GNU Radio has not been able to supply you with more than 0 input items, we >> can assume that the upstream part of the flowgraph is stuck, or done. >> Therefore, execution ends here. >> >> Greetings, >> Marcus >> >> >> >> On 10/18/2013 03:19 PM, Nemanja Savic wrote: >> >> Thank you Martin, I will try with the sync_decimator, but it is also >> important for me to unterstand what's happening here. >> So, I have vector source -> throttle -> fsk_modulator -> scope sink. >> Vector source generates 8 symbols. From where scheduler starts, from >> source or from the sink? And why it didn't stop for any value before 0? >> What should I add into general block to avoid this? >> >> Thank you >> >> >> On Fri, Oct 18, 2013 at 2:59 PM, Martin Braun (CEL) <martin.br...@kit.edu >> > wrote: >> >>> On Fri, Oct 18, 2013 at 02:32:48PM +0200, Nemanja Savic wrote: >>> > The body of my forecast function is: >>> > >>> > ninput_items_required[0] = noutput_items * d_sym_rate / >>> d_sampling_freq; >>> > printf("ninput_items_required %d, noutput_items %d\n", >>> ninput_items_required >>> > [0], noutput_items); >>> >>> If d_sym_rate and d_sampling_freq are integers, integer division will >>> cause ninput_items_required to be zero for small values of >>> noutput_items. >>> >>> > when i run execution, the output is following: >>> > >>> > ninput_items_required 8, noutput_items 4096 >>> > ninput_items_required 4, noutput_items 2048 >>> > ninput_items_required 2, noutput_items 1024 >>> > ninput_items_required 1, noutput_items 512 >>> > ninput_items_required 0, noutput_items 256 >>> > ninput: 0, produced: 0 >>> > >>> > The last line of the output comes from general_work function and >>> prints number >>> > of input items and number of produced output samples. >>> > >>> > Can somebody explain me why forecast is called 5 times, till number of >>> input >>> > items reach 0, and after that nothing is possible in work function, >>> cause it >>> > won't enter the loop since ninput_items = 0; >>> >>> Depending on the state of the buffers, the scheduler calls forecast() >>> until it finds a value of ninput_items_required that works (it tries to >>> process as much as possible). In your case, there is probably some >>> situation where the input buffer is not full. >>> The way you've set up forecast(), the scheduler will eventually find out >>> that it doesn't need any items to produce at least 256 output items. So >>> it calls work() with no input data, expecting 256 output items. >>> But since you can't produce anything without input, nothing happens. >>> >>> It seems like what you want is a sync_decimator, got a gr::block. This >>> means you set relative_rate in the ctor and don't need to handle all of >>> this >>> yourself. Make sure you don't set relative_rate to zero, again! >>> In a sync_decimator, you won't need forecast() at all and your work >>> function is much simpler. The scheduler will also never try to call a >>> sycn_decimator w/o input. >>> >>> MB >>> >>> -- >>> Karlsruhe Institute of Technology (KIT) >>> Communications Engineering Lab (CEL) >>> >>> Dipl.-Ing. Martin Braun >>> Research Associate >>> >>> Kaiserstraße 12 >>> Building 05.01 >>> 76131 Karlsruhe >>> >>> Phone: +49 721 608-43790 <%2B49%20721%20608-43790> >>> Fax: +49 721 608-46071 <%2B49%20721%20608-46071> >>> www.cel.kit.edu >>> >>> KIT -- University of the State of Baden-Württemberg and >>> National Laboratory of the Helmholtz Association >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> Nemanja Savić >> >> >> _______________________________________________ >> Discuss-gnuradio mailing >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > Nemanja Savić > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Nemanja Savić
<<image/png>>
<<image/png>>
<<image/png>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio