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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
