Re: gr-bokehgui in the future?

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