Hi Nick,
On 15.08.2016 19:19, Nick Foster wrote: > This is a pretty familiar problem. A lot of satcom systems require > continuous transmission when in an idle state so the receiver can use > slow (i.e., sensitive) frequency and timing estimator loops. I'm sorry > to say there's no great answer. > > But you have some options: > a) modify the HDLC block so that when work() is called, if nothing is > in the msg queue just output some fixed number of 0x7Es and sit on its > thumbs until the next call. 'doh! Could've thought of that; makes a lot of sense, here. > b) modify whatever block is generating messages so that it outputs > 0x7E frames periodically > c) modify the FPGA (or whatever DUC backend you're using) to both do > the modulating and send 0x7Es (modulated) when there's nothing coming in > > Each approach has its disadvantages: > a) because Gnuradio buffers can be quite large, you will incur a > latency penalty as GR (i.e., all of the buffers of all of the blocks > downstream of the HDLC framer) propagates your frame downstream Not if he adds the functionality to include a tx_time tag; that wouldn't /reduce/ latency, but it would allow for time-slotted transmissions! > b) message sources don't have backpressure, so this won't really work > -- either you'll underflow and interrupt your sample stream or build > up a huge stack of unsent data just as in a) > c) this is a lot of work, and requires that the whole modulator, > soup-to-nuts, is implemented in the FPGA. > > I'd start with approach a) and work your way towards c) if your > application can't handle the latency. > > --n > Best regards, Marcus
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
