Re: gr-bokehgui in the future?

[Glen Langston]

Hi Cyrille,

Thanks for your detailed response.

One thing, on the positive side, for gr-bokehgui is that the CPU load 
_decreases_
for the processor running the gnuradio code.

What may be happening is that the code on the “receive-side” may be doing 
auto-refresh
too quickly.  I’m not absolutely sure about this yet.  Still exploring.

The GUI definitely runs fine for a long while, but maybe there is some side 
effect
of the design running, like maybe a browser memory leak.

I’ve got 4 radio telescopes running the QT-GUI code.   I’ll switch one to 
BOKEH-GUI
and see how this runs.

To make the minor change I suggested, changing the X-array definition,
to "if only 2 X values, then these are the X min and X max” I would like to push
these changes back.   I guess I need your permission to push(?)
   
Thanks for your efforts.   

Glen

PS part of the reason for this was that I could never get gnuradio
to generate the X array for 2048 float frequencies (ie 1418. to 1426 (MHz))
for the vector plot.

You said this was easy, but an example would be very helpful to me.

I did push some of my gr-bokehgui using designs back.   One does not
use any SDRs, it is only a test of a certain type of signal processing.

https://www.github.com/WVRAIL/gr-radio_astro/examples/nsf/vectordemoWeb.grc     

The other designs use an SDRPlay RSP1A with 8 MHz sampling:
NsfDetect80Web.grc  NsfIntegrate80Web.grc  NsfWatch80Web.grc

> On Mar 23, 2023, at 2:32 PM, Cyrille Morin <cyrille.morin@centralesupelec.fr> 
> wrote:
> 
> Hello Glen,
> 
> I've never actually tried to monitor traffic usage of separate display 
> elements.
> But looking at the code for both the label and the textbox widgets, I don't 
> see anything that would update anything when there is nothing to update.
> So I'm not sure where that load you see could be coming from.
> 
> As for the CPU load, having plots is bound to add some processing, if only to 
> get samples, and add them to a buffer.
> If it's only widgets, it should be really low.
> 
> 
> As far as I know, bokehgui is the closest thing to a web-based alternative to 
> QT-GUI, with different plots, and the ability to control the graph with 
> widgets like buttons, sliders, ...
> I've heard of web-base waterfall systems, like 
> https://github.com/jledet/waterfall
> These seem to be quite smooth and responsive, but only plot a waterfall, 
> without widgets for control.
> 
> There was talks (that I sadly didn't follow) about future web based display 
> systems, but I don't know much about them.
> 
> I would say that the main limitation I see from using bokeh is the actual 
> display efficiency inside of the browser.
> Basically (and if I understood the issue properly), each plot updates 
> independently, and independently triggers a redraw. So you can quickly get 
> more redraw calls than the browser can handle, slowing everything down, and 
> introducing latency in the visualization.
> There might be a way to hold redraws temporarily but I would need to do more 
> research on that.
> 
> There might be more efficient libraries with better control over drawing, and 
> better suited to frequent (>20Hz) display updating.
> Apart from that, I don't really see anything that would prevent having a 
> feature set on par with QTgui.
> 
> Cyrille
> 
> Le 23/03/2023 à 17:19, Glen Langston a écrit :
>> Hello Cyrille,
>> 
>> Thanks for your email and notes on bokehgui.   I’ve partially implemented
>> you suggested fixes by reducing the plot update rate.
>> 
>> Separately, I have a GUI that only has a few, rarely changing, text values,
>> to try to completely reduce the internet load.   My suspicion is that these 
>> text displays
>> are being refreshed at some high rate, with the same values.   I don’t know
>> how to test that theory yet, but was wondering if you had any knowledge about
>> text update rates?
>> 
>> Generally I’m very happy with bokehgui, I do find a reduced
>> cpu load on the “raspberry PI” computers running as the telescope
>> data gathering role.
>> 
>> So if bokehgui is the Gnuradio “official” way forward, I’d like to help.
>> 
>> Maybe anyone in Gnuradio would like to comment on the merits of expanding
>> gr-bokehgui, versus any other web-based display approach?
>> 
>> Thanks for your efforts!
>> 
>> Glen
>> 
>>> On Mar 23, 2023, at 5:21 AM, Cyrille Morin 
>>> <cyrille.morin@centralesupelec.fr> wrote:
>>> 
>>> Hi Glen,
>>> 
>>> It seems I replied to you using the wrong email address, so it got dropped.
>>> Sorry for the delay.
>>> 
>>> Cyrille
>>> 
>>> Le 20/03/2023 à 18:49, Cyrille Morin a écrit :
>>>> Hello Glen,
>>>> 
>>>> Glad to see that you use bokehgui, and that it works for you :)
>>>> 
>>>> I do plan to continue improving the module in the future. Improving the 
>>>> waterfall sink, adding support for bokeh 3, histogram and BER sinks, 
>>>> fixing the trigger feature, ...
>>>> 
>>>> I've got a bunch of ideas but sadly I currently have quite a few projects 
>>>> stealing time at work.
>>>> So yeah, I hope to be able to get back to that in the coming months.
>>>> And any help is welcome, of course :)
>>>> 
>>>> As for the traffic, it's directly related to how many plots you have, and 
>>>> how quickly they update.
>>>> The module already transfers only the data points to plot, so it's 
>>>> difficult do really reduce the throughput (short of adding compression 
>>>> algorithms inside of the underlying bokeh library)
>>>> But if you can live with it, you could reduce the update frequency 
>>>> (increase update time), to show less points per second.
>>>> 
>>>> Regarding the vector sink, that shouldn't be very complex, I think one 
>>>> would just need to modify the .yaml file in the grc folder.
>>>> The one nice thing with the current setup is that it allows non linear 
>>>> spacing of the x values, so it's a bit more versatile.
>>>> In the meantime, you can still generate the range of values you want from 
>>>> a min and a max.
>>>> For instance importing numpy with an Import block in GRC, and using 
>>>> list(numpy.linspace(min, max, num_values)) in the x_values parameter (the 
>>>> cast to a list may not be necessary).
>>>> 
>>>> Cyrille Morin