|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] How to "kill flowgraph" with a custom block |
Date: | Wed, 4 Jan 2017 13:54:05 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 |
Dear David, using your gr-research OOT, I was able to notice the following: It shuts down just fine! A few notes: * You're using the Qt GUI build mode, which gives you a GUI window. That GUI thread then lingers. As soon as you change your build mode to "No GUI"/"Run To Completion" in the options block, it just works as expected for me * You're using a hard-coded port of 58 in your server. That probably means you're running GNU Radio as root (because classically, normal users can't bind to sockets <1024). I changed that to 1200. * Your example grc sends the message "STOP", but you check for "stop"... so that doesn't really work. * I know this is just an example, but to point this out now: your server source should return the number of items you produced. Right now, you always fill as much buffer as there is, but you probably want to receive your UDP packet into a buffer that's stored within your class, then copy as much content of the UDP packet as fits into the output buffer `out`, and return the number of floats you've copied. Notice that UDP transports bytes, but you produce 4-Byte-floats – make sure you keep at 4B boundaries when copying. If there's less space in the output buffer than you've received via UDP (yes, that can and will happen), you need to store the remainder of that UDP data for the next call to work(). Only if that "leftover buffer" is empty you should do a `recvfrom` to re-fill that buffer. * The way you're writing your broadcaster seems to be OK. * If you're writing a network application from scratch, I'd recommend you look into using the ZMQ blocks – ZeroMQ is like sockets done right :) The architecture you'd aim for is a "ZMQ * Message Source" (with * being something like SUB or PULL, see zeromq.org for a tutorial on these types of sockets), which gives you one GNU Radio message per packet you receive. You could then have multiple of these sockets - one for control ("ZMQ * Message Source"), one for stream data ("ZMQ * Source"). The ZMQ blocks have the advantage of being able to pass tags, if you happen to connect two remote flow graphs! And: ZMQ takes care of things like flow control, even in a multi-producer/single-consumer kind of network architecture, so your GNU Radio flow graph could "slow down" whoever is sending samples in case things get congested in GNU Radio due to high load. * Nabble really seems to be making it hard for you to answer
on-list. Please simply abandon Nabble, it bears no advantage
whatsoever. You use a GMail account – it's really easy to use that
to directly subscribe to the mailing list via https://lists.gnu.org/mailman/ Best regards, Marcus On 01/04/2017 12:03 PM, David Kersh
wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |