Hi Eric, 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 data. 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 a min(min_available_space, max_buffer_depth), where max_buffer_depth is a block-specific parameter. Naturally, I would rather not do major surgery on the runtime blocks, but I can't think of any other solutions. Thanks, Eugene. ________________________ Eugene Grayver, Ph.D. Aerospace Corp., Sr. Eng. Spec. Tel: 310.336.1274 ________________________ Eric Blossom <[EMAIL PROTECTED]> 12/03/2007 12:16 PM To Eugene Grayver <[EMAIL PROTECTED]> cc [email protected] Subject Re: [Discuss-gnuradio] Latency on TX for low data rate systems On Mon, Dec 03, 2007 at 11:31:03AM -0800, Eugene Grayver wrote: > Hello, > > 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 in > 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, and > 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 them > 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 of buffering. 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? Eric
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
