You put
numpy.linspace(x_min, x_max, vec_len)
in the "X-axis values" parameter field of the Bokeh GUI Vector sink
block in GRC.
Import is done with an "Import" block
Cyrille
Le 24/03/2023 à 17:21, Glen Langston a écrit :
Hi Cyrille,
Thanks for your quick reply.
I’m afraid I’m missing something fundamental.
Where do you put these lines? In which block?
Thanks
Glen
I’m working to document vectordemoWeb.grc
mentioned below. This works pretty well and does lots of plotting.
On Mar 24, 2023, at 11:39 AM, Cyrille Morin<cyrille.mo...@centralesupelec.fr>
wrote:
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.
Le 24/03/2023 à 16:02, Glen Langston a écrit :
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.mo...@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,
likehttps://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.mo...@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