[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gr-bokehgui in the future?
From: |
Glen Langston |
Subject: |
Re: gr-bokehgui in the future? |
Date: |
Fri, 24 Mar 2023 11:02:48 -0400 |
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
- gr-bokehgui in the future?, Glen Langston, 2023/03/20
- Message not available
- Re: gr-bokehgui in the future?, Cyrille Morin, 2023/03/23
- Re: gr-bokehgui in the future?, Glen Langston, 2023/03/23
- Re: gr-bokehgui in the future?, Cyrille Morin, 2023/03/23
- Re: gr-bokehgui in the future?,
Glen Langston <=
- Re: gr-bokehgui in the future?, Cyrille Morin, 2023/03/24
- Re: gr-bokehgui in the future?, Glen Langston, 2023/03/24
- Re: gr-bokehgui in the future?, Cyrille Morin, 2023/03/24