Re: QT GUI Time Sink graph refresh rate

[Marcin Puchlik]

Dear Cyrille and Marcus

Thanks for your answers.

Cyrille: I get that there is no exact timing and the refresh rate on the Time Sink block can deviate from one second (in this particular example) but what is the margin? Now, in this configuration it takes apx 10 seconds to refresh the graph on the Time Sink, is this correct observation? How exactly does the Throttle block behave then (assuming no timing)?

Marcus: YES! Great! Now, the Time Sink behaves as expected! But let me understand what happened:

- sampling frequency: 1000

- maximum number of output items for the Throttle block (during a call to work): 1000/100 = 10

- update period for the Time Sink: 1

- number of points for the Time Sink: 100

In this configuration now, the Time Sink receives the data at a proper speed and is able to refresh the graph at a rate 1 (one time per second). Can you tell me the rationale for this? Can we say how often the work function is called when there is the Throttle in the flowgraph? Simple calculations would help. 

BR, 

Marcin

czw., 30 gru 2021 o 15:28 Marcus Müller <mmueller@gnuradio.org> napisał(a):

Ah, by the way, could you try the following dirty hack:

1. Copy the generated update_period.py file.
2. Find the place where self.blocks_throttle_0 = ... is done
3. after that, insert
self.blocks_throttle_0.set_max_noutput_items(int(samp_rate/100))

and report whether that works?

Best regards,
Marcus

On 30.12.21 13:54, Marcus Müller wrote:
> Exactly! Chances are even that the Throttle regularly sees very large input blocks, e.g.
> 8192 items at once, and then decides to sleep for loooooong before telling GNU Radio it's
> done copying the input to the output.
>
> Best regards,
> Marcus
>
> On 30.12.21 12:32, Cyrille Morin wrote:
>> Hi Marcin,
>> In this graph, the Time sink waits for chunks of 100 samples to display at a time.
>> Since the Throttle is set to forward 1000 samples per second, it should be able to
>> update up to 10 times per second.
>>
>> Keep in mind that this is an estimate since the Throttle block does not enforce its
>> timing exactly. It depends on the size of sample blocks it operates on.
>> So it could be possible that the scheduler gives it a chunk of 1000 samples at a time.
>> In this case, it would forward it whole, and the Time sink would only display the 100
>> samples out of these 1000.
>> If that repeats, you would only get 1 update per second.
>>
>> Hope this makes sense,
>> Cyrille
>>
>>
>> Le 30 décembre 2021 10:38:06 GMT+01:00, "Marcin Puchlik via GNU Radio, the Free &
>> Open-Source Toolkit for Software Radio" <discuss-gnuradio@gnu.org> a écrit :
>>
>>     Hi Marcus,
>>     Thanks for your answer. Please, check out this flowgraph.
>>     Shouldn't the Time Sink update its graph content every second in this configuration?
>>
>>     image.png
>>     https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426
>>     <https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426>
>>     BR,
>>     Marcin
>>
>>
>>     śr., 29 gru 2021 o 19:27 Marcus Müller <mmueller@gnuradio.org
>>     <mailto:mmueller@gnuradio.org>> napisał(a):
>>
>>         Hi Marcin,
>>
>>         only if there's no other component that limits the speed of processing. For
>>         example, if
>>         the samples come from an SDR, than that has a sampling rate, so there's only so
>> many
>>         samples per second that can reach your sink.
>>
>>           > I noticed that when I am using
>>           > throttle block along with QT GUI Time Sink the update period is not working
>>         properly (I
>>           > have to wait much longer to see the updated graph).
>>
>>         That only happens when the number of samples reaching the sink isn't sufficient to
>>         get one
>>         full vector of samples per update period.
>>
>>         Best regards,
>>         Marcus
>>
>>
>>