Re: [Discuss-gnuradio] Block keeps buffering data

[Wolfgang Nagele]

Hi Marcus,

Thanks for the detailed response - this helped me clear a few things up.

Firstly it made me understand why GNU Radio when run with low sampling
rates (<32k) seemed to behave "erratic".

My problem was that the buffer kept being filled but my input source
block was dependent on input data that is changed over time (think
telemetry). Thus if the buffer keeps filling it basically fills with
data all of the current instant instead of the data as it changes over
time.

I have been battling with eventstream as well and it was actually
having the same issue. Now that I understood this buffering behaviour
I just had to adjust the buffer down so it would be relevant to a 1200
baud flowgraph (the standard buffer is massively too big).

Cheers,
Wolfgang


On Sun, Aug 9, 2015 at 2:38 AM, Marcus Müller <address@hidden> wrote:
> Hi Wolfgang,
>
> well, GNU Radio is not really based on a "requesting data" model -- it's
> mainly buffer driven.
> This means that as long as there's space in your block's output buffer,
> GNU Radio might (and will) call your work() function. Typical buffer
> sizes are e.g. 8192 items. So, GNU Radio uses backpressure to limit the
> rate at which things run.
> You can try gr::block::set_max_output_buffer, but please heed the
> warnings in [1]: This kind of breaks a lot of assumptions about "good"
> buffer sizes.
>
> On a different note, this sounds like a hint of architectural problem in
> your transmitter. I assume 1200 bd means that you take x bits, generate
> y symbols out of these, and package these into z samples. These z
> samples are then fed to SDR hardware, consuming at a constant sampling
> rate. Now, since the ratio of y/x is fixed, and so is the ratio z/y,
> normally the hardware sampling rate simply defines how many bits are
> consumed in a given time; GNU Radio then just makes sure this happens as
> soon as possible  (i.e. to keep the items flowing as far as possible).
> That is typically very good -- because it a) means that transmit samples
> are computed as early as possible, so that "hiccups" upstream are hidden
> by the full buffers, and b) so that the slowest part in your signal
> processing chain (which *should* be the SDR hardware) defines the speed
> at which things happen.
>
> Now, there's some cases where that doesn't apply, mainly "bursty" data
> -- I don't know whether yours is one of these, but in case it is:
> Have a look at Tim O'Shea's gr-eventstream [2]; it doesn't change the
> way GNU Radio works (ie. your buffer sizes define the latency between a
> burst of samples being injected into the otherwise continuous 0-sample
> stream and that burst reaching your SDR hardware), but it makes working
> with bursty data more intuitive and allows for non-continuous data to be
> fed into GNU Radio.
>
> Best regards,
> Marcus
>
> [1]http://gnuradio.org/doc/doxygen/classgr_1_1block.html#ae2405dc2f6c84bb8e59aab56e4ce9d84
> [2] http://oshearesearch.com/tag/gr-eventstream/
> On 08.08.2015 18:03, Wolfgang Nagele wrote:
>> Hi,
>>
>> I've written a Python block to feed some binary data into my QPSK
>> transmission. This block is supposed to grab the data according to the
>> 1200 baud rate I have set up for the transmission. Well, so I thought.
>>
>> GNU Radio keeps calling the work() function inside the block even
>> though the upstream flowgraph does not need the data yet. This results
>> in my block providing too much stale buffered data.
>>
>> Is there a way to make the block work() function only being called
>> when the connected block really requests data? I thought I could use a
>> Throttle block but that does nothing either.
>>
>> Suggestions?
>>
>> Thanks,
>> Wolfgang
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio