Ah! Thank you so much Marcus! I've managed to
transplant this correction into my bigger flow graph and now
everything works as intended.
>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.
Yes, that isn't a
coincidence but I did not know that users cannot bind to
ports <1024 without root. I'll play with that.
> 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.
Yeah I'm pretty confused
with how this works to be honest. The serverSource block is
literally just to parse a "stop" command, otherwise it
should remain dormant, listening for that packet. How would
I go about stopping it from writing to the buffer? It's just
wasted processing.
> The way you're writing your
broadcaster seems to be OK.
Excellent :)
> 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.
I'll definitely investigate
this - thank you.
I suppose a final question
is, how do I kill the QtGUI thread if I do want a GUI?
Many thanks,
David