I’m trying to use a UDP source block from a GRC-produced flowgraph.
The only thing it does is this:
gr_block_executor: source <gr_block udp_source (2)> produced no output.
We’re marking it DONE.
Which seems rather useless. How does a block get marked “done” in this
way? That block may not start
producing data for several seconds after startup, since the other end
may not have started up yet
(and the other end can’t start up until the “receiver” end is sitting
waiting on that UDP port).
Is this a known bug?
It’s on UDP port 1420, bound to the localhost eth0 address.
I can confirm using “nc” that I can receive traffic at this port on my
host–even traffic from the “sender”
side of the application (which is also a GnuRadio flowgraph, only
using a UDP sink block).
Any cluage?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Fri, Apr 9, 2010 at 19:23, Marcus D. Leech [email protected] wrote:
Any cluage?
Yes. I’ll wait to see if Eric responds, as this is his area, but in
short, the error is intentional.
Johnathan
Yes, if I remember it right the executor only checks a source for output
space and then calls work. If the work function doesn’t produce any
output it’s “broken” according to the executor code.
/Ulrika
On Fri, Apr 09, 2010 at 10:23:43PM -0400, Marcus D. Leech wrote:
I’m trying to use a UDP source block from a GRC-produced flowgraph.
The only thing it does is this:
gr_block_executor: source <gr_block udp_source (2)> produced no output.
We’re marking it DONE.
The udp source/sink needs an overhaul.
This error is triggered to indicate that the block (a source) is
returning zero, and thus is most likely spinning.
Eric
----- Original Message -----
From: “Eric B.” [email protected]
To: “Marcus D. Leech” [email protected]
Cc: “GNURadio D.ion List” [email protected]
Sent: Thursday, April 22, 2010 6:24 PM
Subject: Re: [Discuss-gnuradio] UDP source block in GRC
This error is triggered to indicate that the block (a source) is
returning zero, and thus is most likely spinning.
Whatever overhauling is done, it would nice to have the option of
treating
zero-bytes-read from gr_udp_souce as an EOF condition. A client can
then
decide whether to wait for a server or give up. (It might also be nice
to
have program access to the timeout value.)
– Don W.
On Fri, Apr 23, 2010 at 09:44:51AM -0400, Don W. wrote:
Whatever overhauling is done, it would nice to have the option of
treating zero-bytes-read from gr_udp_souce as an EOF condition. A
client can then decide whether to wait for a server or give up. (It
might also be nice to have program access to the timeout value.)
– Don W.
Hi Don,
Probably the “right answer” is to add support in the system for
sending messages to blocks when file descriptors “select” true for
read, write or exception conditions. This would remove the problem
with blocking on something that might never happen, or the current
dodgy work-around of blocking with a timeout.
Eric
On 04/22/2010 06:24 PM, Eric B. wrote:
This error is triggered to indicate that the block (a source) is
returning zero, and thus is most likely spinning.
Eric
Well, I got around this problem by using a gr.file_source instead, which
was actually a FIFO, and then
used “nc” (netcat) to grab the UDP packets.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium