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 > o actual payload packets > o 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: > > > 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) > o 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] </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 >> >> <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 >> <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 >> >> <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 >>> >>> <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 >>> >>> <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 >>> >>> <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 >>> >>> <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 >>> <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 >>> <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 >> <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 >> >> <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 list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
