The serializer needs fft_len items (complex samples) io_signature::make(1, 1, sizeof(gr_complex) * fft_len)
at a time. The buffer size is based on the atomic type (complex). The framework doesn't actually know anything about vectors underneath, so it needs fft_len complex items at a time on the input. Aren't there working examples of ofdm in the code tree? On Thu, Sep 16, 2021 at 10:51 AM Armin Ghani <[email protected]> wrote: > Well for other blocks its in number of items. Items can be vector or other > data types including complex, float etc. So in this case 240 is too much > data if we consider it in number of items unit. > > I changed it o the number but the same error is printed out. > > It really strange why the block ofdm_serializer needs such amount of items > because considering 1 ofdm symbol packet size it only needs 1 item at > input. But it asks for 270 items. > On 16/9/21 16:27, Jeff Long wrote: > > The value is in bytes. Set it to something like 1048576 (2^20). > > On Thu, Sep 16, 2021 at 9:25 AM Armin Ghani <[email protected]> wrote: > >> I tried to change minoutbuf size of the block before block >> ofdm_serializer_vcc to 241 (I set 241 because 240 produces error so I >> concluded that final size is N-1). The error vanished but a new one is >> produced: >> >> set_min_output_buffer on block 36 to 241 >> thread[thread-per-block[36]: <block ofdm_serializer_vcc(30)>]: Buffer too >> small for min_noutput_items >> >> So the question is what Buffer is exactly refered to in this message? How >> is that to increase that buffer? >> On 16/9/21 14:04, Jeff Long wrote: >> >> maxoutbuf mean that the buffer can be no bigger than x, minoutbuf means >> it can be no smaller. Changing minoutbuf on every block should be the same >> as changing GR_FIXED_BUFFER_SIZE. >> >> On Thu, Sep 16, 2021 at 7:04 AM Armin Ghani <[email protected]> wrote: >> >>> Thanks Jeff for your reply. >>> >>> Yes, I just changed the values again right now but nothing changed. I >>> set minoutbuf value from 1 to 10000 increasing 10 times more each time. >>> >>> I dont know exactly why you suggested minoutbuf to be changed because >>> what I understand is that block ofdm_serializer_vcc needs amount of >>> input which is more than what shceduler can supply. Since number of input >>> needed comes from number of output items to be produced, I dont get why >>> minoutbuf is needed to be changed. If we want to make change to have lesser >>> number of input items needed so we need to limit maxoutbuf instead. That >>> makes more sense. >>> On 16/9/21 12:22, Jeff Long wrote: >>> >>> Have you tried changing the minimum output buffer on either the block or >>> the one before it? This can be done in the block parameters under the >>> advanced tab. There is no reason to redefine GR_FIXED_BUFFER_SIZE, just >>> change it where necessary. Buffers are on the output of each block. >>> >>> On Thu, Sep 16, 2021 at 5:44 AM Armin Ghani <[email protected]> wrote: >>> >>>> Dear community >>>> >>>> I've been tackling to fix below scheduler error which it fails to >>>> allocate buffer for blocks: >>>> >>>> ched: <block ofdm_serializer_vcc (22)> is requesting more input data >>>> than we can provide. >>>> ninput_items_required = 960 >>>> max_possible_items_available = 127 >>>> If this is a filter, consider reducing the number of taps. >>>> >>>> I'm curious to know how to mitigate such error. This issue has been >>>> covered very few but one of the workaround would be to change >>>> GR_FIXED_BUFFER_SIZE as much as the error disappears but this is not a good >>>> solution since it leads to scheduler sample propagation delays. I welcome >>>> every effective and reliable solution despite of being difficult to >>>> implement and etc. >>>> >>>> Below there are a few solutions that came to my mind but none of them >>>> are final solutions: >>>> >>>> - Trying to change GR_FIXED_BUFFER_SIZE. This leads to path delays >>>> which prevents flow graph to run smoothly >>>> >>>> - Trying to remove extra blocks. This is not so effective >>>> >>>> - Simplifying block implementation specially those which are >>>> implemented in hier-block approach by writing c++ code instead. This is >>>> also not so effective >>>> >>>> - dividing top-block into smaller top-blocks with fever blocks. Not >>>> helpful >>>> >>>> I'll be more than happy to hear you back. >>>> >>>> Regards. >>>> >>>> >>>> -- >>>> >>>> Armin Ghani >>>> >>>> Research Engineer | Communication Systems Division (CSD) >>>> >>>> [email protected] | +34 93 645 29 08 (2143) >>>> >>>> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) >>>> >>>> Av. Carl Friedrich Gauss, 7 - Edifici B4 - PMT >>>> >>>> 08860 - Castelldefels (Barcelona, Spain) >>>> >>>> www.cttc.cat >>>> >>> -- >>> >>> Armin Ghani >>> >>> Research Engineer | Communication Systems Division (CSD) >>> >>> [email protected] | +34 93 645 29 08 (2143) >>> >>> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) >>> >>> Av. Carl Friedrich Gauss, 7 - Edifici B4 - PMT >>> >>> 08860 - Castelldefels (Barcelona, Spain) >>> >>> www.cttc.cat >>> >> -- >> >> Armin Ghani >> >> Research Engineer | Communication Systems Division (CSD) >> >> [email protected] | +34 93 645 29 08 (2143) >> >> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) >> >> Av. Carl Friedrich Gauss, 7 - Edifici B4 - PMT >> >> 08860 - Castelldefels (Barcelona, Spain) >> >> www.cttc.cat >> > -- > > Armin Ghani > > Research Engineer | Communication Systems Division (CSD) > > [email protected] | +34 93 645 29 08 (2143) > > Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) > > Av. Carl Friedrich Gauss, 7 - Edifici B4 - PMT > > 08860 - Castelldefels (Barcelona, Spain) > > www.cttc.cat >
