Or maybe the question should be like this: on which parameter to rely when making general work function, number of iput items or number of output items?
On Tue, Oct 22, 2013 at 2:20 PM, Nemanja Savic <vlasi...@gmail.com> wrote: > 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ć > -- Nemanja Savić
<<image/png>>
<<image/png>>
<<image/png>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio