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