Error when increasing spreading factor.

tapparelj / gr-lora_sdr

This is the fully-functional GNU Radio software-defined radio (SDR) implementation of a LoRa transceiver with all the necessary receiver components to operate correctly even at very low SNRs. This work has been conducted at the Telecommunication Circuits Laboratory, EPFL.

https://www.epfl.ch/labs/tcl/

GNU General Public License v3.0

650 stars 67 forks source link

Error when increasing spreading factor. #87

Closed rachase closed 5 months ago

rachase commented 5 months ago

When I try to bump up the spreading factor to 12, I keep getting this error.

block_executor :error: sched: <block frame_sync (5)> is requesting more input data  than we can provide.  ninput_items_required = 16392  max_possible_items_available = 8191  If this is a filter, consider reducing the number of taps.

I can play around with the sample rate and other params and get ninput_items_required to be < 8191, but I have a hard time picking up the LoRa packets. Is this a mem error, any suggestions?

tapparelj commented 5 months ago

Hello @rachase, this error message just says that the buffer between the PlutoSDR Source and Frame sync is too small to contains the minimum number of samples that the Frame sync requires to start processing something (i.e. one entire LoRa symbol plus a few extra samples for time synchronization). You can ask for a minimum buffer size under the advanced tab of a block by setting the parameter minoutbuf. Setting this parameter in the PlutoSDR Source to int(2*(sf+1)samp_rate/bw) should fix it.

rachase commented 5 months ago

I set the min output buffs as you suggested, still getting the same error. I also tried making them even bigger (below). Do you think the 8191 has something to do with the linux kernel? Max queue / buffer size perhaps?

header_decoder :info: set_min_output_buffer on block 1 to 65536
frame_sync :info: set_min_output_buffer on block 4 to 131072
fmcomms2_source :info: set_min_output_buffer on block 9 to 65536
block_executor :error: sched: <block frame_sync (4)> is requesting more input data  than we can provide.  ninput_items_required = 32784  max_possible_items_available = 8191  If this is a filter, consider reducing the number of taps.
Press Enter to quit:

tapparelj commented 5 months ago

8191 is the default buffer size. So it looks like the min buffer size request is not taken into account. A quick search hint that there is a problem with the buffer allocation for the plutosdr source.

Can you try to add a Add Const (with constant 0) just after the source and set the min output buffer option in that block instead as a potential work around?

rachase commented 5 months ago

Worked! You are my hero.