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. 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 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 On Mon, Aug 15, 2016 at 8:57 AM Marcus Müller <[email protected]> wrote: > Yep, next (==what becomes 3.8) fixes that spinning. > > > > On 15.08.2016 17:35, Marcus Müller wrote: > > Hi Frank, > > Are you suggesting that I send a SOB tag along with the Flag 0x7E (1 > byte) and the radio will continuously output 0x7E's until I send an EOB ? > > Whatever "flag 0x7e" is, no, that's not how it works. You specify a > transmit time at the start of your burst, and that's the time that the USRP > will start transmitting the burst. You need to supply the samples that it > will transmit. Setting another tx_time later on will define a "stop and > wait for that time to come before continuing to transmit". > Note that I have no actual clue of HDLC; I was presuming it was a very > packet-oriented thing? > > > The project I am on is a cubesat project and the team working on the > cubesat have stipulated that to maintain lock on the signal, when not > transmitting data the ground station transmitter (my work) is to send > continuous HDLC Flags. So regardless of my view I need to somehow meet this > requirement. > > That conflicts with my impression that HDLC is a packet format with > sufficient framing? Because then I don't really see a possibility of > "continuous HDLC flags"; just closely enough timed HDLC frames that help to > maintain channel state information on the ground, right? > > In that case, I'd expect that these "keepalive" frames are just a special > kind of data frame, and you'd basically have a timer somewhere that runs > out occasionally, initiating a frame transmission if it does, and that gets > reset to 0 every time a frame was sent; or something similar. > > Sorry for taking up so much of your time. Your assistance is appreciated. > > Hey, sorry if I sometimes come across a little harsh :) I was just really > confused by the whole aspect of that obsolete thread. > > So, let's give a quick overview of what I understand, so that we have a > good base for discussion: > > - You're implementing the satellite-side end of a HDLC comms line > - You'll have two types of packets > - actual payload packets > - packets only meant to keep sync with the ground station > > So, the current situation is this: > > Assuming you want some kind of GMSK modulation, this would "work" for you: > > > [image: flowgraph excerpt] > > so what happens here is > > > - The message strobe generates a message every 500 ms containing a > pair with an arbitrary value in the first element (the HDLC framer demands > this, but doesn't use it), and a byte vector (ascending values) in the > second element. > - The HDLC framer has a message port, which means it can > asynchronously get messages (asynchronous to the work() ) function; every > time the work() is called, the HDLC framer checks the new-style message > queue (that's a bit different from the old-style messgae queues you'll find > in old GNU Radio). Sadly, in GNU Radio's current version (3.7) this means > that it "spins"; but that should, as far as I can tell, change with 3.8. > (I'm testing this right now) > - if there's a message in the queue, get it, turns it to a HDLC > frame, and adds an output stream tag to the first produced sample > telling > the downstream blocks "hey, here starts a frame of N items" > - the GMSK modulator takes one item and turns that into 8 complex > samples (hence the "tagged stream multiply length tag" block – the length > tag doesn't reflect the correct length anymore) > - The USRP sink has been set to "wait for a frame (tagged stream > block) tag" mode, and will send a burst of specified sample number upon > receiving an appropriately named tag > > > Best regards, > Marcus > > On 15.08.2016 13:34, Inspire wrote: > > Hi Marcus > > Thank you for the response. I will take your advice and go over all the > tutorial information again as well as [2] & [3]. > > However I have completed the tutorial's and for the most part understand > the information. Admittedly I am still struggling with the use of stream > tag's, I have gone back over the tutorial on stream tags multiple times and > whilst I understand how to create stream tags and their propagation, I > haven't really grasped how and when to use them. I have also read [2] but > don't really understand how this will help me. > > Please excuse my lack of understanding. Are you suggesting that I send a > SOB tag along with the Flag 0x7E (1 byte) and the radio will continuously > output 0x7E's until I send an EOB ? > > The project I am on is a cubesat project and the team working on the > cubesat have stipulated that to maintain lock on the signal, when not > transmitting data the ground station transmitter (my work) is to send > continuous HDLC Flags. So regardless of my view I need to somehow meet this > requirement. > > Sorry for taking up so much of your time. Your assistance is appreciated. > > Kind Regards > Frank > > > > On 15 August 2016 at 20:24, Marcus Müller-3 [via GnuRadio] <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=61222&i=0>> wrote: > >> Hi Frank, >> >> really, with the advances of the drivers and hardware capability and the >> changes in GNU Radio architecture, your problem isn't that comparable to >> the problem in 2009; again, please don't rely on Nabble posts; Nabble is >> just a mirror of the GNU mailing list archives (and adds some kind of forum >> infrastructure), and it has been down lately for quite some time. I don't >> trust it, personally, and usually urge people to directly sign up to the >> mailing list and use the official archives; so here's the link to the >> official mailing list archive's thread: >> >> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00552.html >> >> Anyway, let us really discard the idea of describing your problem in >> terms of a problem from 2009; that just makes things more complicated, >> because then I'd have to explain what happened to GNU Radio in the last >> seven years, and why Ettus N210 & B210 driven via gr-uhd isn't like a USRP1 >> driven via libusrp. What you're really asking is analogous to "my 2012 >> Ferrari won't start; I found this 1920 Ford Model T hand crank start >> discussion, but I can't find the hand crank in my Ferrari's trunk". Things >> simply don't work like that anymore. >> >> So, this has really become much easier: The USRP sink reads stream tags, >> which can contain a start-of-burst, and a end-of-burst info; the N210 and >> B210 USRPs (unlike what was available in 2009) keep an internal device >> time, so that they can even be used to transmit samples at a specified >> time, without having to continuously send before that time. >> >> It's important to understand the concept of stream tags to work with this >> (that concept wasn't around in 2009 in the shape that it's built into GNU >> Radio since roughly 2011), so I'm referring you to the official GNU Radio >> tutorials [1]. >> >> Chapter 5 should explain Tags and Message Passing, but the tutorial >> chapters built atop of the previous ones, so I'd recommend starting with >> the first and working to the fifth; you will be rewarded with being able to >> fully understand Chapter 6, which is about interfacing what you've built in >> chapters 1-4 with real USRP hardware, and with an instant understanding of >> [2], the documentation of how to send "bursty" samples to the USRP via >> stream tags! >> >> For a demo of how to use stream tags to tune at a specific time and >> annotate, see [3]; if you run that as >> >> ./freq_hopping.py -r 2.5e5 -N 10000 -t 500 -f 2.4e9 -c 100 -d 2.5e6 -v >> >> with your B210 attached, you should see its TX LED blink *exactly* twice >> per second. >> >> Best regards, >> >> Marcus >> [1] http://tutorials.gnuradio.org >> [2] http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html >> [3] >> https://github.com/gnuradio/gnuradio/blob/v3.7.10.1/gr-uhd/examples/python/freq_hopping.py >> >> On 15.08.2016 13:07, Inspire Me wrote: >> >> Hi Marcus >> >> My apologies if I posted incorrectly, I am new to this. Thank you for >> responding. >> The posts I was referring to are >> http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-td27764.html >> >> >> I do understand that things have moved on since 2009. I was hoping to >> have a look at the code mentioned in the post for the >> GMSKSpacecraftGroundstation. >> https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation I >> have not been able to find it. I was wanting to see how it was done. >> >> I have the almost the identical situation described in the post. I was >> thinking I need a Flag Source feeding some sort of switch logic that checks >> if no message is present on the data stream input and then selects the flag >> input, sends one flag; repeats check and send until a data arrives on the >> data stream input. >> >> We are currently using Ettus N210 & B210 hardware. I have a Tx chain >> working except for the flag stuff. For testing I have Mux'd in a vector of >> flags (0x7E) and can successfully talk to the receive end. >> >> Any help would be greatly appreciated. >> >> Kind Regards >> Frank >> >> >> On 15 August 2016 at 20:29, Marcus Müller <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=61221&i=0>> wrote: >> >>> Hi Frank, >>> >>> **which** post from March 2009? Would you happen to have a mailing list >>> archive [1] link (please don't use Nabble). >>> >>> At any rate, what applied 7 years ago regarding messages will probably >>> not apply now, anymore. >>> >>> I think it would be very worthwhile if we didn't discuss this based on >>> something from 2009; what program/flowgraph/python script are you >>> specifically looking at? >>> >>> Best regards, >>> Marcus >>> >>> >>> [1] >>> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/index.html >>> On 15.08.2016 10:41, Inspire wrote: >>> > Hello >>> > >>> > I am relatively new to gnuradio, I have only been working with it for 6 >>> > weeks. >>> > >>> > I came across your posts from march 2009 relating to continuously >>> > transmitting 0x7E's when no messages are present in the queue. I am >>> facing >>> > the exact issue with our implementation in GNURadio. I need to send out >>> > continuous flags when no messages are in the queue but immediately >>> (within a >>> > few flags) switch to sending data when a message arrives. I have gone >>> > looking for the HDLC Source code spoken about but have not found it. >>> > >>> > Q1. How was this solved ? >>> > >>> > I am struggling with getting my head around how to ensure the >>> continuous >>> > stream of Flags given that gnuradio buffers up and schedules >>> transmission >>> > based on buffers. I am also struggling with how to do the switching >>> between >>> > streams. >>> > >>> > I know 2009 was a long time ago, but any help would be greatly >>> appreciated. >>> > The mentioned source code example or any other example code would be of >>> > great benefit as GNURadio documentation is confusing and some times >>> > non-existent. >>> > >>> > Kind Regards >>> > Frank >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>> http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html >>> > Sent from the GnuRadio mailing list archive at Nabble.com. >>> > >>> > _______________________________________________ >>> > Discuss-gnuradio mailing list >>> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=61221&i=1> >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=61221&i=2> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [hidden email] <http:///user/SendEmail.jtp?type=node&node=61221&i=3> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the discussion >> below: >> >> http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61221.html >> To unsubscribe from Constant carrier digital transmission, click here. >> NAML >> <http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > > ------------------------------ > View this message in context: Re: Constant carrier digital transmission > <http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61222.html> > Sent from the GnuRadio mailing list archive > <http://gnuradio.4.n7.nabble.com/> at Nabble.com. > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > 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
