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