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?
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?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.
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:
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 RegardsFrank
On 15 August 2016 at 20:24, Marcus Müller-3 [via GnuRadio] <[hidden email]> 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 RegardsFrank
On 15 August 2016 at 20:29, Marcus Müller <[hidden email]> 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
> [hidden email]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
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
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
View this message in context: Re: Constant carrier digital transmission
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
