[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] socket puzzles

From: Bob Vincent
Subject: [Discuss-gnuradio] socket puzzles
Date: Fri, 25 Feb 2005 14:15:05 -0500

I've been looking at the single_thread_scheduler, trying to understand its behavior relative to sockets. I put in the patch on file_descriptor_source to allow partial results to return. I also sink on the transmitter to a named pipe, and source on the receiver on the same named pipe, to bypass the USRP.

When I telnet to my open source socket, I can type at it, and eventually my data comes out. The amount that comes out is a function of the number of sends I do, rather than the number of bytes in the payload. (I set the payload really low for this purpose. I find that I need to source [payload + frame header + 4] bytes to stimulate the first send.

Also find that the first thing it sends is a lot bigger (like it's clearing its throat) than one frame's worth of samples.

Once it gets to the receive side, it decodes, but the correlator produces exactly one symbol per pass (rather than noutput items if possible), so after a short while all the buffers are exahusted by it, so the receive side does single byte reads.

Finally, if I close the telnet connection on the transmitter some stuff empties out of the tx buffers. If I close the tx app, more stuff empties out of the receive named pipe.

I don't understand why it works this way.

It might help if someone could explain the operation of the scheduler. In particular I don't understand why the upstream module blocks when it could be working because the next thing is not ready to take its output.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]