[prev in list] [next in list] [prev in thread] [next in thread]
List: gnuradio-discuss
Subject: Re: [Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR progra
From: Kristoff <kristoff () skypro ! be>
Date: 2018-08-30 19:02:44
Message-ID: 71be3a19-14fa-eb8d-638a-4e48c82eb9e1 () skypro ! be
[Download RAW message or body]
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 <kristoff@skypro.be
> <mailto:kristoff@skypro.be>> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic