Re: [Discuss-gnuradio] How to "kill flowgraph" with a custom block

[David Kersh]

Dear Marcus,

So, I'm very unfamiliar with what message connections are so we'll go with a no. I'll describe exactly what I've done and perhaps we can workout where I've gone wrong.

I have constructed a flowgraph which contains 5 blocks total. Two of them are custom ones I've managed to hack together.

1) Options block (default)

2) Variable block (default)

3) An OOT UDP Broadcast block written in Python. No inputs or outputs.

This block has been written to send out a UDP packet to a piece of hardware. This block does exactly what I want it to do and does every inside of the __init__ method. It simply utilises the socket library and sends a packet using .sendto(MESSAGE, (UDP_IP, UDP_PORT)). I'm quite new to UDP programming work so I wonder if the fact I haven't closed the socket is a problem. Another issue I'm starting to wonder is that I removed this block's inputs and outputs from the XML, but haven't changed anything in the python code. the general_work method still takes (self, input_items, output_items). Is there a name for blocks which have no inputs / outputs? This could be an issue.

4) An OOT UDP Server block written in Python. One output

This block was made with gr_modtool as a source. The purpose of this block is to read incoming packets and kill the flowgraph upon receiving a "stop" command. In the __init__ method, .bind((UDP_IP, UDP_PORT)) is called, setting up the server. The work method gets blocked as the block waits for an incoming packet with the .recvfrom method (but I don't think this should be an issue). I finally have an if statement which returns -1 should "stop" be received.

5) A null sink.

I suppose this could be anything.

Hopefully this reply isn't an incoherent mess and you understand what I'm trying to accomplish. Having written this, I am wondering if the fact that my UDP Broadcast block still wants to take input and output, but isn't is the issue.

Many thanks

David

On Mon, Dec 19, 2016 at 5:34 PM, Marcus Müller <address@hidden> wrote:

Hey David,

no, more bleeding edge than 3.7.10.1 wouldn't sound recommendable.

At the moment, I don't have much idea what could be wrong with your UDP-based source. What else is in the flow graph, or is it just the null sink? Any message connections?

Best regards,

Marcus

On 19.12.2016 16:59, David Kersh wrote:

Dear Marcus,

Excellent news!

I've just installed 3.7.10.1 and my flow graph still doesn't appear to end (but my UDP server block stops because it won't receive anymore packets after returning -1). Currently I have a basic flowgraph which has my server block running alongside a symbol noise source and frequency visualisation sink.

Do you recommend using one of the bleeding edge releases?

Many Thanks

David

On Mon, Dec 19, 2016 at 1:08 PM, Marcus Müller <address@hidden> wrote:

Hi David,

that worked :)

yep, returning -1 (which is the magical value for "there's nothing coming anymore, you can shut down") would normally end a flow graph.

However, we've had (still have) problems with the shutdown logic, but people recently patched a lot of things – so whatever you do, please make sure you're using the current release of GNU Radio. Which is it that you're currently using?

Best regards,

Marcus

On 19.12.2016 12:45, David Kersh wrote:

Hello all, 

I've created a custom out of tree source block which listens for UDP packets and does different things depending on the received packet. It is connected to a NULL sink because I haven't quite worked out how to make a standalone UDP Server (and I've found the tutorials to be very confusing unfortunately). 

When the packet is "stop", I would like the flowgraph to be stopped. I've seen from researching different forums that if -1 is returned, the flowgraph is supposed to stop but I only find that this stops my block from running, the rest of the flowgraph continues running. 

Is there not a simple command which I can use to kill the whole flowgraph? 

An alternative solution I tried to implement was to access these values using a vector sink block and the .data() method from the top_block.py

This didn't seem to work correctly as Python's UDP calls block.

Thank you, hopefully I've made this post properly. I'm quite new to programming with GNURADIO.

David

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio