Re: [Discuss-gnuradio] Constant carrier digital transmission

[Inspire Me]

Hi Nick / Marcus

Great discussion, obviously this issue has been solved before, as mentioned in the 2009 discussion the GMSKSpacecraftGroundstation project (  https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation ) seems to have solved it. I acknowledge that gnuradio has moved on, but I would like to see how it was solved and possibly adapt it to the current gnuradio. Is there anyway to get access to the code ? I am stuck at the moment. 

The only idea I have is to impelement a source block with very small buffers to feed into the Tx Chain and some sort of switch to toggle between data stream and flag stream based on a message / tag from up the chain. 

Nick can you elaborate on the modification of the Work() function. I thought this was scheduled only when sufficient data is in the Input buffer ? Is there a way to have this execute more often or when no data exists in the input buffer ? Is there a way to implement a switch block that monitors input streams and efectively switches the output stream such that it is not blocked waiting for input from one of the streams ?

Once again thank you for the help

Kind Regards

Frank

On 16 August 2016 at 03:14, Marcus Müller <address@hidden> wrote:

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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio