Re: [Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR programer

[Kristoff]

Hi Kevin,


(inline comments).



On 27-08-18 02:57, Kevin Reid wrote:
> Some partial answers, from memory and not necessarily correct:
Well, they where usefull anyway, so thanks. :-)



> On Sun, Aug 26, 2018 at 1:26 PM Kristoff <address@hidden 
> <mailto:address@hidden>> 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.
Correct.

Got that to work. Thx!

But do note that  you should also use "self.set_output_multiple" to set 
the number of bits you will send into the output queue every time the 
"work" function is called.


>     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.
OK. I didn'tknow these block have control-ports. I should look into that :-)


(cut some more interesting stuff .. thx for that :-) )





>     - 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.
For some reason, tThat didn't work in my case. Returning -1 from the 
worker function did not stop the flow-graph.

I do get a lot of "U"s in the console, but the application does not stop.
No idea why this is.


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

That DID work, .. starving the output-channel did caused the osmocom 
transmitter-module to stop transmit, .. but it did not revive when I 
restarted sending data out the egress port.

In my case, it was OK as I only wanted to send one single packet, but it 
does not looks to be a sollution for just switching on and off a 
transmitter.
OK. It's good enough for what I needed it for.



> (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.)
No problem.
Thanks for your reply. It was very helpfull.


Kristoff