- Can somebody explain how to implement a source-block using
embedded-python?
In the code I have now, it is implemented as a sync-block, taking in a
signal from a signal-generator block, but that is probably (surely!) not
the correct way to do this.
A source block is just a block with no inputs. I haven't yet tried it in Python but it should be simply specifying in_sig=[] in the __init__. This means that your work function will be called repeatedly rather than only when input data is available.
I did notice that the signal-generator blocks that exists in GRC do have
a input-port that is greyed-out and not connected. I probably need to
implement something simular.
No, gray ports in GRC are message ports for receiving control messages. It is a separate additional feature of that block and not one you have to implement.
- How do you interface your embedded-python code with variables that
change during run-time? (e.g. a variable mapped to a GUI slider).
How does the embedded-python program known when a variable has changed?
The GRC XML file which describes your block to GRC specifies what to do when one of its parameters have changed. GRC then generates code which, when a GRC "variable" or GUI control changes, tells all the blocks that need to know. This looks like, for example,
<callback>set_center_freq($center_freq)</callback>
That element in a GRC file means that whenever the parameter center_freq has changed — which might be due to any number of variables, since GRC allows input of expressions — GRC will ensure that the block's .set_center_freq() method is called with the new value. center_freq must have been defined in a <param> element elsewhere in the file.
- Basically, a pocsag paging-message is a packet, not a continuous stream.
It is possible to create a source-block that creates a stream of a
limited length and then stop the execution of the graph?
There are two things you can do depending on what you need.
You can return -1 from the work function to indicate you are done. This propagates to downstream blocks, and causes the top_block.wait() call that exists in most GR programs to stop waiting and return, but it can instead choose to (reconfigure and) restart the flow graph if you have an application where that makes sense.
If you mean you want to pause work and resume when the next packet comes along, then your source should just block until more data is available. You might need to pad the output with zeroes at the end to ensure the packet isn't cut off by sitting in partial buffers.
(I haven't worked with the second approach, so there might be other caveats, and there may be better tools — my work with GNU Radio has been primarily analog/continuous receiving rather than transmitters/transceivers using packets.)