Please help me out with udp_sink

Hi all,

My system is jaunty, and installed gnuradio3.2.2 from binary package.

I’m trying to send captured data to network via UDP or TCP/IP,
(from/to localhost, for the start)

but the (signal source -> UDP sink) reports ‘connection refused’ error
for both cases(UDP and TCP).

I’d appreciate your help on this issue.

I know that it’s more related to the networking issue, but asking you
guys hoping that someone might have gone through this issue.
(I know a little bit on Ubuntu, but not very much on networking issue.)

As of now, I did not modify anything on network configuration since the
clean installation of Jaunty.

but the (signal source -> UDP sink) reports ‘connection refused’ error
for both cases(UDP and TCP).

I would say that there is no one listening at whatever ip:port you are
trying to send data to. Make sure that there is some sort of daemon
responding to requests there.

Jason

Thanks to your comment, I don’t have that error.
But still have some steps to go.

What I have is that

  1. from_udp.py (udp_source --> audio_sink)
  2. to_udp.py (signal source --> udp_sink)

when I start 1 and then 2, I have error as below:

ece$ python ./from_udp.py
gr_block_executor: source <gr_block udp_source (3)> returned 0 from
work. We’re marking it DONE.

Thanks in advance.

Jason U. wrote:

but the (signal source -> UDP sink) reports ‘connection refused’ error
for both cases(UDP and TCP).

I would say that there is no one listening at whatever ip:port you are
trying to send data to. Make sure that there is some sort of daemon
responding to requests there.

Jason

Thanks to your comment, I don’t have that error.
ece$ python ./from_udp.py
gr_block_executor: source <gr_block udp_source (3)> returned 0 from
work. We’re marking it DONE.

I’m pretty sure the ‘were marking it DONE’ only comes up when a source
fails, and then it is killed by the controller. So the source is
killed, and no longer responding to the port, hence the ‘connection
refused’ at the sink.

As to why the source is failing, I don’t really know; from what I
understand the ‘were marking it done’ error comes from the controller
that wires things together in gnuradio; I don’t think it’s specific to
that block; I think someone else will have to weigh in on why it’s
happening.

On Wed, Jul 22, 2009 at 07:45, Yc Park[email protected] wrote:

ece$ python ./from_udp.py
gr_block_executor: source <gr_block udp_source (3)> returned 0 from
work. We’re marking it DONE.

This is essentially a bug in the design of gr.udp_source() that sort
of worked okay back in the single-threaded scheduler days, but not now
with the multi-threaded scheduler. Basically, returning 0 samples
from a source block work function will cause the scheduler to
immediately call it again, resulting in 100% utilization of a
processor core until the source block can produce data. The
thread-per-block scheduler enforces this now by terminating the block.

The fix is fairly easy (the original problem returning 0 was supposed
to solve can be fixed in another way), but not sure when it can be
done.

A work around is to open the network socket in Python, then pass the
file descriptor to gr.file_descriptor_source(item_size, fd).

Johnathan

Ok, John,

Thanks to your help, I feel that I’m getting closer…

So I looked up for a code to open a tcp socket and setup a simple code
for it, of course not working…

< server >
1 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
2 host = ‘’ # can leave this blank on the server side
3 port = 1234
4 s.bind((host, port))
5 tcp = gr.file_descriptor_source(pkt_size, s) # (pkt_size,fd) park
6 sink = audio.sink(sample_rate)
7 self.connect(tcp, sink)

< client >
1 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
2 host = ‘’ # can leave this blank on the server side
3 port = 1234
4 s.bind((host, port))
5 tcp = gr.file_descriptor_sink(pkt_size, s) # (pkt_size,fd) park

6 src0 = gr.sig_source_f (sample_rate, gr.GR_SIN_WAVE, 350, amplitude)
7 thr = gr.throttle(gr.sizeof_float, sample_rate)
8 self.connect(src0, thr, tcp)

Sorry to bother you again, but
any recommendations would help me a lot.

Johnathan C. wrote:

On Wed, Jul 22, 2009 at 07:45, Yc Park[email protected] wrote:

ece$ python ./from_udp.py
gr_block_executor: source <gr_block udp_source (3)> returned 0 from
work. �We’re marking it DONE.

This is essentially a bug in the design of gr.udp_source() that sort
of worked okay back in the single-threaded scheduler days, but not now
with the multi-threaded scheduler. Basically, returning 0 samples
from a source block work function will cause the scheduler to
immediately call it again, resulting in 100% utilization of a
processor core until the source block can produce data. The
thread-per-block scheduler enforces this now by terminating the block.

The fix is fairly easy (the original problem returning 0 was supposed
to solve can be fixed in another way), but not sure when it can be
done.

A work around is to open the network socket in Python, then pass the
file descriptor to gr.file_descriptor_source(item_size, fd).

Johnathan

Hi
I am using GRC, but i would like to add modules that i make and also
hierarchical modules.
How can i go ahead and add modules of my choice?


View this message in context:
http://www.nabble.com/Please-help-me-out-with-udp_sink-tp24605485p24630416.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Thanks to everybody.
Now I know how to make connections.
Though slow, I feel that I’m moving forward.

Johnathan C. wrote:

On Wed, Jul 22, 2009 at 17:17, Yc Park[email protected] wrote:

5 �tcp = gr.file_descriptor_source(pkt_size, s) # (pkt_size,fd) park

The item size should be set to the type of samples you are pushing
through the socket. In this case, they are from gr.sig_source_f, so
it should be gr.sizeof_float.

Also, consider using a UDP socket instead of TCP. You likely don’t
want or need the retransmission capability of TCP in this context.

Johnathan

On Fri, Jul 24, 2009 at 12:01 AM, Yc Park[email protected] wrote:

Thanks to everybody.
Now I know how to make connections.
Though slow, I feel that I’m moving forward.

No problem, good job getting your first project going.

Jason

On Thu, Jul 23, 2009 at 10:15 AM, udadidd [email protected] wrote:

Hi
I am using GRC, but i would like to add modules that i make and also
hierarchical modules.
How can i go ahead and add modules of my choice?

You can read all this here
http://gnuradio.org/trac/wiki/GNURadioCompanion.
The wiki index is a useful resource
http://gnuradio.org/trac/wiki/TitleIndex

Karthik

On Wed, Jul 22, 2009 at 17:17, Yc Park[email protected] wrote:

5 tcp = gr.file_descriptor_source(pkt_size, s) # (pkt_size,fd) park

The item size should be set to the type of samples you are pushing
through the socket. In this case, they are from gr.sig_source_f, so
it should be gr.sizeof_float.

Also, consider using a UDP socket instead of TCP. You likely don’t
want or need the retransmission capability of TCP in this context.

Johnathan

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs