Some partial answers, from memory and not necessarily correct:
On Sun, Aug 26, 2018 at 1:26 PM Kristoff <[email protected]> wrote:
> - 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.)
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
