I cannot reduce the sample rate at the sink since there are additional
signals being added to the FSK. The FSK transmitter is bursty – there
will be no data for long periods of time, followed by a few bits of
E.g. a udp packet comes in and needs to be sent out. I was considering
using the gr_throttle block, but it will not give me the desired result.
Even if the throttle rate is slightly different than the actual TX rate,
the intermediate buffers will eventually either underflow (unacceptable)
or fill up, resulting in the same latency issue.
I am considering a minor change to the gr_single_threaded_scheduler such
that the min_available_space returns not the actual available space, but
min(min_available_space, max_buffer_depth), where max_buffer_depth is a
block-specific parameter. Naturally, I would rather not do major
on the runtime blocks, but I can’t think of any other solutions.
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Eric B. [email protected]
12/03/2007 12:16 PM
Eugene Grayver [email protected]
Re: [Discuss-gnuradio] Latency on TX for low data rate systems
On Mon, Dec 03, 2007 at 11:31:03AM -0800, Eugene Grayver wrote:
I have a very low data rate FSK system (<100 bps). The problem is the
enormous latency introduced by the inter-block buffers. (I am running
ms windows). The buffer granularity is apparently 64kB. I
upsample/interpolate the data to around 500 kHz before sending it to
hardware. The buffers get filled up on startup from the data source,
any new data takes forever to come out. (64k/100 = 600sec!) Is there a
way to make the inter-block buffers MUCH smaller? Or, at least make
different size depending on the actual sample rate? What other options
can anyone propose?
Under Linux (and most other systems) you can reduce the buffering
down to 4KB (the page size). The windows API we’re using only allows
us to map an area of memory on a 64KB boundary, thus the high amount
However, you may want to reduce the rate at which you’re generating
data. From your description, it sounds like you have an unthrottled
source feeding a small pipe. Are you transmitting continously or are
there bursts/packets/frames of bits?