Re: European GNU Radio Days conference YouTube streaming (Fri Aug. 30)

[Cyrille Morin]

Hi,

The afternoon session won't be streamed

Le 30/08/2024 à 15:04, MR169 a écrit :
Are the afternoon dev sessions going to be streamed or is it just this 
morning's talks?


On Fri, 30 Aug 2024 at 07:42, jmfriedt 
 wrote:


Today is the last day of the European GNU Radio days: the live stream
on Youtube will be available at
https://www.youtube.com/watch?v=JpfhgkA_nJE
starting at 9 AM CEST.

Re: gr-bokehgui in the future?

[Cyrille Morin]

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  
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  
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 intern

Re: gr-bokehgui in the future?

[Cyrille Morin]

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  
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, ver

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  
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 

Re: gr-bokehgui in the future?

[Cyrille Morin]

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  
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 
* alekhgupta1441 
* Anders Kalør 
* Artem Pisarenko 
* Bastian Bloessl 
* 

Re: QT GUI Time Sink graph refresh rate

[Cyrille Morin]

Hi Marcin,
In this graph, the Time sink waits for chunks of 100 samples to display at a 
time.
Since the Throttle is set to forward 1000 samples per second, it should be able 
to update up to 10 times per second. 

Keep in mind that this is an estimate since the Throttle block does not enforce 
its timing exactly. It depends on the size of sample blocks it operates on. 
So it could be possible that the scheduler gives it a chunk of 1000 samples at 
a time. In this case, it would forward it whole, and the Time sink would only 
display the 100 samples out of these 1000. 
If that repeats, you would only get 1 update per second.

Hope this makes sense,
Cyrille


Le 30 décembre 2021 10:38:06 GMT+01:00, "Marcin Puchlik via GNU Radio, the Free 
& Open-Source Toolkit for Software Radio"  a écrit :
>Hi Marcus,
>Thanks for your answer. Please, check out this flowgraph.
>Shouldn't the Time Sink update its graph content every second in this
>configuration?
>
>[image: image.png]
>https://gist.github.com/marcinsztajn/224ced2e1b3921aa97ef28978c1b8426
>BR,
>Marcin
>
>
>śr., 29 gru 2021 o 19:27 Marcus Müller  napisał(a):
>
>> Hi Marcin,
>>
>> only if there's no other component that limits the speed of processing.
>> For example, if
>> the samples come from an SDR, than that has a sampling rate, so there's
>> only so many
>> samples per second that can reach your sink.
>>
>>  > I noticed that when I am using
>>  > throttle block along with QT GUI Time Sink the update period is not
>> working properly (I
>>  > have to wait much longer to see the updated graph).
>>
>> That only happens when the number of samples reaching the sink isn't
>> sufficient to get one
>> full vector of samples per update period.
>>
>> Best regards,
>> Marcus
>>
>>
>>

Re: Does complex conjugate invert IQ ?

[Cyrille Morin]

Hi,

You could use a "Complex to Float" to separate the I and Q components, 
followed by a "Float to Complex", inverting the re and im inputs.



Le 13/12/2021 à 16:31, Rachida SAROUI a écrit :
Thank you for responding, but what I meant by invert is swapping the I 
and Q components of the signal.


Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau > a écrit :


Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
> Hi everyone,
>
> I need to invert the I and Q of a complex signal. Does the block
complex
> conjugate do the job?
>
> Thank you
>

Re: Combine PDU message data with stream data

[Cyrille Morin]

Hi Barry,

The way the flowgraph is right now, the vector source generates samples as fast 
as it can and it's directly treated by the EPyB and floods the buffers. When a 
pdu is to be inserted, there is already tons of filler samples to treat first 
so that greatly delays the moment you can see the pdu samples in the time sink.

You need to add a throttle block before the input to your embedded block. That 
way the input stream will have a limited sample rate and it will allow the 
samples from the pdus to be inserted in real time.

Le 20 novembre 2021 03:28:09 GMT+01:00, Barry Duggan  a 
écrit :
>My objective: In reference to the 
>https://wiki.gnuradio.org/index.php/Packet_Communications#Using_BPSK_with_Hardware_Simulation_.28version_3.9.29
> tutorial: it sends packets but has dead time in-between, which may cause the 
>BPSK receiver to lose sync. I would like to fill the time (and stream) with an 
>idle code so there is always a signal for the receiver. My latest attempt to 
>use a Python Source block didn't work out - probably a timing problem or a 
>lack of understanding of the scheduler.
>
>
>
>This Embedded Python block receives a stream input of idle bytes and a PDU 
>message input. It outputs the PDU message when received, otherwise it outputs 
>the idle bytes. However, the PDU data never appears downstream.
>
>
>
>Note: this flowgraph uses AFSK instead of BPSK, but the objective is the same.
>
>
>
>See https://pastebin.com/GJgnzjCP   Embedded Python block
>
>https://pastebin.com/C6XVsCZx   AFSK flowgraph
>
>
>
>Any help will be appreciated.
>
>
>
>---
>
>Barry Duggan KV4FV
>
>https://github.com/duggabe
Cyrille Morin 

Re:VectorSourceBlock-GRC

[Cyrille Morin]

Hello Isaac, 

Adding a delay block set to at least 24 could indeed allow you to see your 
square signal.
But you can also solve the cause of the issue:
By default, the time sink I assume you are using, is set to display 1024 
samples at a time. So it waits for that amount of samples before plotting 
anything. In your case, you are generating only 1000 samples, so the time sink 
is stuck waiting for the last 24.
The delay block, as part of its operation, starts by outputting samples with 0s 
 according to its delay setting, so you can create the 24 you are missing that 
way.
You can also set your time sink to display just 1000 samples, and you should 
see just what you generated.

Hope that was clear,
Cyrille

Le 30 septembre 2021 08:36:34 GMT+02:00, "dominik.walach" 
 a écrit :
>
>   Hello Isaac,
>
>   The solution is quite simple, just add a delay block to the flowgraph (see 
> the attachment). Vector Source pushes all the samples at the beginning faster 
> than Time Sink can even display it.
>
>   Best,
>
>   Dominik
>   Od "Discuss-gnuradio" 
> discuss-gnuradio-bounces+dominik.walach=pekasat@gnu.org
>   Komu discuss-gnuradio@gnu.org
>   Kopie
>   Datum Wed, 29 Sep 2021 17:25:04 -0500
>   Předmět VectorSourceBlock-GRC
>   Hello
>   I'm Isaac. I'm trying to produce a 1KHz square signal for only one period. 
> So I decided to do it with the vector source block (500 ones and 500 zeros). 
> But when I run it with the option repeat = No, I only see zero. When I put 
> repeat=yes, I see the square but continuous, not only one period.
>   ¿What am I missing? Any help or advice is welcomed.
>   Regards
>   Isaac T.

Cyrille Morin 

Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)

[Cyrille Morin]

Hi Luke,

I've had this issue before.

The problem is that the Function Probe block is not actually a block, 
it's just a way to write code directly into the top_block python file, 
and do the top_block object is the one calling the block you want, which 
is not an issue since, it knows them, it created them.


Now, whatever block you create doesn't have reference to the other 
blocks, and I could not find a way to give it to them directly, so what 
I found is to give the top_block object to yours, and also the name of 
the block(s) you want, and call them with getattr(top_block_object, 
wanted_block_name).whatever_function() . It needs to be the name used 
for the exact block you want, not the type, you can find it in the id 
field in the parameters, or by reading the top_block file.


The other issue is the fact that, with an embedded block, when you save 
it, GRC creates an instance of the object automatically with the default 
parameters, possibly to find out its signature and be able to display it 
properly. But, at that point, the top block object doesn't exist, so the 
execution will stop and GRC will complain.


If you work with an OOT python block, you won't have this issue, but if 
you really want to stick with embedded, I've done that too:


If the constructor is not the function that gets the top_block as input, 
but another function (not called in the init phase), you can have it be 
called by a function probe (the frequency doesn't need to be high) and 
put "self" as argument. Then you can use it to call whatever in your 
function, or even store it in your block object for later use.


This is really hacky, and there may be a better way to do it but I 
couldn't find at the time, and it works without issue.


Tell me if this was not clear, or if you need example code.

Cyrille

Le 21/02/2020 à 00:24, Lukas Haase a écrit :

Hi,

I am using the "Embedded Python Block" to create a simple controller that 
controls my USRP Source/Sink blocks.
These blocks support a message interface but unfortunately this is pretty 
useless except for the simplest applications (I need to control advanced tuning 
with timed commands, GPIO ports etc).

Hence I need to call the methods of these objects directly but I need a 
reference to them inside my custom block.
Within my python block I cannot reference the parent blocks, hence I need to 
pass a reference to these two objects via the constructor (and parameters).
Basically I want to do the same as parameter "Block ID" from the block "Function 
Probe" does.

What is the best way to implement this?

Thanks,
Luke






PS: Example:

class blk(gr.sync_block):  # other base classes are basic_block, decim_block, 
interp_block
 def __init__(self, sample_rate=1.0, usrp_source_block=''):  # only default 
arguments here
 """arguments to this function show up as parameters in GRC"""
 gr.sync_block.__init__(
 self,
 name='Controller',   # will show up in GRC
 in_sig=[np.float32],
 out_sig=[np.float32]
 )
 # if an attribute with the same name as a parameter is found,
 # a callback is registered (properties work, too).
 self.sample_rate = sample_rate
self.usrp_source_block = usrp_source_block

# here I want to execute for example
self.usrp_source_block.set_gain(5.0)

When I then create an USRP Sink object with ID uhd_usrp_sink_0 and enter as 
parameter I get the error:

Param - Usrp Source Block(usrp_source_block):
Value "uhd_usrp_sink_0" cannot be evaluated:
name 'uhd_usrp_sink_0' is not defined