|
| From: | Cyrille Morin |
| Subject: | Re: gr-bokehgui in the future? |
| Date: | Fri, 24 Mar 2023 16:39:47 +0100 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
Hello Glen,
Yes, the gnuradio side does not compute anything graphical, which can reduce the load.
If you want to contribute some changes, you can open a pull
request that we can review together before merging.
To generate the x_axis values within the limit you want:
Say that you have defined variables with your x_min and x_max
(like x_min=1.418e9 and x_max=1.426e9), plus the vector length you
want to display (in your case vec_len=2048).
Use an import block to import the numpy library, writing "import numpy" inside of the Import parameter slot.
And with that, you can write: numpy.linspace(x_min, x_max, vec_len) inside
the X-axis values parameter field of the Vector sink.
You can always directly use the actual numbers inside of the
linspace function call, of course.
Cyrille
ps: The github link you added does not seem to lead anywhere.
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.grcOn 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! GlenOn 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
| [Prev in Thread] | Current Thread | [Next in Thread] |