Yes there are. I have a working flowgraph which has ofdm_serializer block as well and its all right.
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 <aghani@cttc.es> 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 <aghani@cttc.es> 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_itemsSo 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 <aghani@cttc.es> 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 <aghani@cttc.es> 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)
aghani@cttc.es | +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)
--
Armin Ghani
Research Engineer | Communication Systems Division (CSD)
aghani@cttc.es | +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)
--
Armin Ghani
Research Engineer | Communication Systems Division (CSD)
aghani@cttc.es | +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)
--
Armin Ghani
Research Engineer | Communication Systems Division (CSD)
aghani@cttc.es | +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)
Armin
Ghani
Research Engineer | Communication Systems Division (CSD)
aghani@cttc.es | +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)
