Re: gr-bokehgui in the future?

[Cyrille Morin]

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
> > >
> > > Le 20/03/2023 à 15:33, Glen Langston a écrit :
> > > > Hello,
> > > >
> > > > We continued work with high schools experimenting with Radio Astronomy
> > > > using Gnuradio.   We’ve found that a simple bucket may be used
> > > > to observe our Milky Way Galaxy.
> > > >
> > > >                https://youtu.be/bH-k2hsnGa4 <https://youtu.be/bH-k2hsnGa4>
> > > >
> > > >
> > > > We’re also trying to bring all our observations on-line from across the
> > > > country.  We’ve successfully used the gr-bokehgui to translate our designs
> > > > for astronomy into versions that directly display in web browsers.
> > > >
> > > > So, We’ve got a couple questions:
> > > > 1) Are there plans for anybody to add more features to gr-bokehgui?
> > > >      We could particularly use a histogram plot.
> > > > 2) Although my designs using gr-bokehgui run fine to begin with,
> > > > These designs seem to be generating too much internet traffic and are
> > > > hanging up my network.   Is there any (known) way of reducing the data flow?
> > > > 3) It would be more convenient if the gr-bokehgui sinks matched 1-for-1
> > > > with the qt-gui sinks.
> > > >
> > > > Any forecasts for progress in this area?   One area that would be
> > > > fairly easy to update (and I hope to do so soon) is to change
> > > > the definition of the x-axis array input to the vector plot sink.
> > > > I’d prefer that, if the x-axis array only had two entries (while the
> > > > y had 1024 or 2048 values, etc), that these two x-values would be interpreted
> > > > as min and max values on the x-axis, creating the other values appropriately.
> > > >
> > > > Best regards
> > > >
> > > > Glen
> > > >
> > > >
> > > >              <https://youtu.be/bH-k2hsnGa4>
> > > > > On Apr 9, 2020, at 4:45 PM, Marcus Müller <mmueller@gnuradio.org> wrote:
> > > > >
> > > > > Dear hopefully healthiest of all SDR communities to ever graze freely on
> > > > > the airwaves,
> > > > >
> > > > > it's taken me way longer than I wanted, but after the release candidate
> > > > > finally follows release 3.8.1.0 of GNU Radio.
> > > > >
> > > > > Due to unforeseen crypto hardware trouble, and the presumably temporary
> > > > > inability to access key backups, I can't offer a release signed with a
> > > > > trustworthy key. Hopefully, we'll have that situation sorted out by the
> > > > > next release; to not cause unnecessary confusion through signatures
> > > > > nobody can verify, you'll only find signify-signed tarballs for now.
> > > > >
> > > > > Regarding what this release means, and what it is:
> > > > >
> > > > > This is a release from the GNU Radio 3.8 maintenance release series.
> > > > > 3.8 is our current stable release series, i.e. we're focused on keeping
> > > > > it running on modern systems and fixing the bugs that we've left in
> > > > > there for our own future entertainment at an earlier point ;)
> > > > >
> > > > > Feature work happens mostly on the `master` branch, which will become
> > > > > GNU Radio 3.9.0.0 at some point. We're at a point where not everything
> > > > > most users will do is 100% compatible between 3.8.* and master, so it's
> > > > > a good time to try out our master branch if you want to work on
> > > > > bleeding-edge stuff. Generally, while we, and I, dedicate very much to
> > > > > continuing support for 3.8, master (and thus, 3.9) already is more
> > > > > convenient to develop for in quite a few ways, many revolving around
> > > > > things we don't do anymore on 3.9 (Python2 compability), and are
> > > > > abandoning for something less hazardous (replacing SWIG with Pybind11
> > > > > code). Moving forward is a lot of fun! I really missed that in the 3.7 era.
> > > > >
> > > > > Best regards,
> > > > > and happy hacking!
> > > > >
> > > > > Marcus
> > > > >
> > > > > #Contributors (a.k.a. people making my maintainer heart feel warm&fuzzy)
> > > > >
> > > > > * Alba Mendez <me@alba.sh>
> > > > > * alekhgupta1441 <alekhgupta1441@gmail.com>
> > > > > * Anders Kalør <anders@kaloer.com>
> > > > > * Artem Pisarenko <artem.k.pisarenko@gmail.com>
> > > > > * Bastian Bloessl <mail@bastibl.net>
> > > > > * Brennan Ashton <bashton@brennanashton.com>
> > > > > * Chris <christopher.donohue@gmail.com>
> > > > > * Clayton Smith <argilo@gmail.com>
> > > > > * CMorin <barthy42@laposte.net>
> > > > > * Daniel Estévez <daniel@destevez.net>
> > > > > * Davide Gerhard <rainbow@irh.it>
> > > > > * Derek Kozel <derek.kozel@gmail.com>
> > > > > * duggabe
> > > > > * Glenn Richardson <glenn.richardson@live.com>
> > > > > * Grant Cox <grant.cox@deepspaceamps.com>
> > > > > * Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
> > > > > * Håkon Vågsether <haakonsv@gmail.com>
> > > > > * Igor Freire <igor.auad@gmail.com>
> > > > > * Jacob Gilbert <mrjacobagilbert@gmail.com>
> > > > > * Jan Kraemer <kraemer.jn@gmail.com>
> > > > > * japm48
> > > > > * Johannes Demel <demel@ant.uni-bremen.de>
> > > > > * Josh Morman <jmorman@perspectalabs.com>
> > > > > * karel
> > > > > * luz.paz
> > > > > * Marc L <marcll@vt.edu>
> > > > > * Marcus Müller <mmueller@gnuradio.org>
> > > > > * Martin Braun <martin.braun@ettus.com>
> > > > > * Michael Dickens <michael.dickens@ettus.com>
> > > > > * Michael Roe <mroe@cornstalk.org.uk>
> > > > > * Nathan West <nwest@deepsig.io>
> > > > > * Nick Østergaard <oe.nick@gmail.com>
> > > > > * Nicolas Cuervo <cuervonicolas@gmail.com>
> > > > > * Notou <barthy42@laposte.net>
> > > > > * Philip Balister <philip@balister.org>
> > > > > * rear1019 <rear1019@posteo.de>
> > > > > * RedStone002
> > > > > * Ron Economos <w6rz@comcast.net>
> > > > > * Ryan Schutt
> > > > > * Ryan Volz <rvolz@mit.edu>
> > > > > * Sebastian Koslowski <sebastian.koslowski@gmail.com>
> > > > > * Sebastian Müller <gsenpo@gmail.com>
> > > > > * Sylvain Munaut <tnt@246tNt.com>
> > > > > * Terry May <terrydmay@gmail.com>
> > > > > * Thomas Habets <thomas@habets.se>
> > > > > * Vasil Velichkov <vvvelichkov@gmail.com>
> > > > > * Volker Schroer
> > > > > * wcampbell <wcampbell1995@gmail.com>
> > > > > * William Barnhart <williambbarnhart@gmail.com>
> > > > >
> > > > >
> > > > > ## [3.8.1.0] - 2020-04-08
> > > > >
> > > > > ### Changed
> > > > >
> > > > > #### Project Scope
> > > > >
> > > > > - clang-tidy improvements
> > > > >    - Throw exceptions by value, catch by reference
> > > > >    - `emplace_back` where applicable
> > > > >    - `empty()` instead of `vector::size() == 0`
> > > > > - Use CMake to check for endianness instead of `BOOST_BIG_ENDIAN`
> > > > >
> > > > > #### gr-fec
> > > > >
> > > > > - Scipy becomes optional dependency (for polar channel code construction)
> > > > >
> > > > > #### gr_modtool
> > > > >
> > > > > - use Boost.UTF instead of cppunit
> > > > >
> > > > > ### Fixed
> > > > >
> > > > > #### Project Scope
> > > > >
> > > > > - FindQwt paths
> > > > > - floatAlmostEqual unittest assert function wrongly passing on sequence
> > > > > types
> > > > > - Only require boost unittest when testing is enabled
> > > > > - FindLOG4CPP typo
> > > > > - numpy.fft(pack) imports
> > > > > - several scipy imports that can be done with numpy alone
> > > > >
> > > > > #### gnuradio-runtime
> > > > >
> > > > > - block gateway shadowed system port
> > > > > - Flaky message passing unit test contained timeout (not the test's job)
> > > > > - ctrlport/`rpcaggregator` & Co: removed storage of references to
> > > > > scope-lifetime objects
> > > > > - Sine table generation python was wrong
> > > > > - `get_tags_in_range` for delay < (end-start)
> > > > > - premature tag pruning
> > > > > - release flattened flowgraph after stopping; fixes
> > > > > restartability/shutdown issues
> > > > >
> > > > > #### gr-analog
> > > > >
> > > > > - clipping in FM receiver: remove superfluous gain
> > > > > - C++ generation for multiple blocks
> > > > >
> > > > > #### gr-audio
> > > > >
> > > > > - portaudio source: lock acquisition
> > > > >
> > > > > #### gr-blocks
> > > > >
> > > > > - rotator VOLK workaround
> > > > >
> > > > > #### gr-digital
> > > > >
> > > > > - `map_bb` buffer overflow
> > > > > - `map_bb` thread safety
> > > > > - `additive_scrambler `count based reset
> > > > >
> > > > > #### gr-fec
> > > > >
> > > > > - heap corruption in `async_decoder`
> > > > > - `cc_encoder` was broken for constraint lengths > 8
> > > > >
> > > > > #### gr-fft
> > > > >
> > > > > - restore Boost 1.53 compat
> > > > >
> > > > > #### gr-qtgui
> > > > >
> > > > > - no longer requiring unnecessary key in `edit_box_msg`
> > > > >
> > > > > #### gr-uhd
> > > > >
> > > > > - fixed examples under Py3
> > > > > - multichannel objects not populating channels
> > > > >
> > > > > #### gr_modtool
> > > > >
> > > > > - wrong use of `input` -> `raw_input`
> > > > > - allow empty argument list
> > > > > - testing
> > > > > - check for and deny TSB under Python
> > > > > - QA addition bugs
> > > > > - correct path for C++ QA tests
> > > > >
> > > > > #### GRC
> > > > >
> > > > > - several issues with YAML files
> > > > > - nested objects now properly populate namespaces
> > > > > - comments now included in block bounds calculation
> > > > > - Wiki documentation link removed from OOT blocks' docs tab
> > > > > - Dragging connections to auto-hide ports works now
> > > > > - generated and re-generated several example flowgraphs
> > > > > - `bokeh_layout` module name
> > > > > - Revert toggle buttons to text entry for bool block props, allowing GRC
> > > > >    variables to be used
> > > > >
> > > > > ### Added
> > > > >
> > > > > #### Project Scope
> > > > >
> > > > > - Codec2 development branch / future compat
> > > > > - Boost 1.71 compat
> > > > > - CI now checks for formatting
> > > > >
> > > > > #### gnuradio-runtime
> > > > >
> > > > > - dot graphs now contain message edges
> > > > > - Python wrapping for blocks' `set_affinity` and `{g,s}et_alias`
> > > > >
> > > > > #### gr-uhd
> > > > >
> > > > > - UHD Filter API
> > > > >
> > > > > #### GRC
> > > > >
> > > > > - block affinity, buffer sizes available as advanced options for blocks
> > > > > - testing
> > > > > - Python snippets (please snippet responsibly!)
> > > > > - `show_id` flag added to embedded python blocks, Probes
> > > > > - global option to toggle showing of IDs
> > > > > - Help "Keyboard Shortcut" entry