discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Constant carrier digital transmission


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Constant carrier digital transmission
Date: Mon, 15 Aug 2016 19:44:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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

reply via email to

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