[Discuss-gnuradio] Constant carrier digital transmission

[William Harding]

I would like to implement a module which keeps a constant carrier running
and transfers packets of data at different times. In other words, using ASK
(or OOK) modulation, I would like to always be transmitting ones (carrier is
at full amplitude) except for certain periods where I will "pause" the
carrier (carrier amplitude is zero or some smaller amplitude).

How can I do this without supplying an "infinite" number of ones (with zeros
inter-weaved where I want them) in my packets? I would like to be able to
have a constant "full carrier amplitude" until I call some method like
"send_packet(data)."

Any thoughts/suggestions/examples? Corrections in my thinking?


Thanks.

[Ed Criscuolo]

Post by William Harding
I would like to implement a module which keeps a constant carrier
running and transfers packets of data at different times. In other
words, using ASK (or OOK) modulation, I would like to always be
transmitting ones (carrier is at full amplitude) except for certain
periods where I will "pause" the carrier (carrier amplitude is zero or
some smaller amplitude).
How can I do this without supplying an "infinite" number of ones (with
zeros inter-weaved where I want them) in my packets? I would like to be
able to have a constant "full carrier amplitude" until I call some
method like "send_packet(data)."
Any thoughts/suggestions/examples? Corrections in my thinking?
Thanks.

Generally, this approach is a bad idea, as it intoduces a large
dc-offset in the baseband signal. This can vastly complicate
the bitslicing needed at the receiver to reconstitute the
1's and 0's. I speak from experience, where we designed a
spacecraft comm system that included such a dc bias, and we are
suffering with the results to this day.

The usual approach to this is twofold.

First, in order to eliminate the dc-bias, you should use a randomizer
on the bitstream just before it goes to the modulator, and a matching
descrambler on the receiver.

Second, what you are really talking about is the difference between
synchronous and asynchronous protocols. In a synchronous protocol,
the link is always kept busy transmitting a bitstream, even when there's
no packet data to send. One of the most widely used synchronous
protocols is HDLC. HDLC sends a continuous stream of "flag" bytes
when there's no data to send. This allows your receiver to maintain
lock on the data clock at all times, even there's no packets.

There's an example of HDLC sink and source blocks in CGRAN, in
the GMSK Spacecraft Groundstation project. The hdlc source block
takes packets in from the network and takes care of generating
any flag bytes needed in order to produce a continuous bitstream.
The hdlc sink block does the reverse, detecting and decoding the hdlc
packets, and puting their payloads out on the network.

@(^.^)@ Ed

[Ed Criscuolo]

Would it be feasible to simply pass the desired transmit data (1?s and
0?s) to the HDLC block (which you mentioned) by just having another
method in the block, say "tx_data(char[#])," which would take in an
array of bytes; and then, after tagging on the CRC, SOF, EOF etc, go
through the array stuffing ones and zeros into the FIFO buffer? This
tx_data() function would be called in Python, in some kind of control loop.
In other words, could I do it just by calling a method to pass desired
data from the Python code?

Certainly, as long as your Python code could keep up with the datarate.
Otherwise, you'll have to call the method from C++.

Also, I am not familiar with TUN/TAP devices do you have any examples
about how this works on both ends? Or any references?

The TUN/TAP device is a pseudo ethernet device driver. To the network
stack in the kernel, it looks just like any other ethernet device. But
instead of delivering its packets to some ethernet hardware, it
instead delivers them to an application program running in user space.
Similarly, for reception, it accepts packets from a user space program
instead of from some ethernet hardware.

It can operate in one of two different modes. The a "TAP" device
deals with the raw ethernet packets. The full packet, including
all header and trailer bytes, is delivered to the application program.
Similarly, in the other direction, it is the application program's
responsibility to fabricate a complete and correct ethernet packet.

The "TUN" device takes care of the ethernet portion of the packet
and only delivers it's payload to the application program. Similarly,
in the other direction, the application only needs to provide the
payload. The "TUN" device driver takes care of encapsulating it in
an ethernet packet.

Start with http://en.wikipedia.org/wiki/TUN/TAP and follow the
reference links.

@(^.^)@ Ed

[Inspire]

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.

[Marcus Müller]

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

Post by Inspire
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

[Marcus Müller]

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

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
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>

Post by Inspire
Hello
I am relatively new to gnuradio, I have only been working with

it for 6

Post by Inspire
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

Post by Inspire
the exact issue with our implementation in GNURadio. I need to

send out

Post by Inspire
continuous flags when no messages are in the queue but

immediately (within a

Post by Inspire
few flags) switch to sending data when a message arrives. I have

gone

Post by Inspire
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

Post by Inspire
stream of Flags given that gnuradio buffers up and schedules

transmission

Post by Inspire
based on buffers. I am also struggling with how to do the

switching between

Post by Inspire
streams.
I know 2009 was a long time ago, but any help would be greatly

appreciated.

Post by Inspire
The mentioned source code example or any other example code

would be of

Post by Inspire
great benefit as GNURadio documentation is confusing and some times
non-existent.
Kind Regards
Frank
--

http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html
<http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html>

Post by Inspire
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>

[Inspire]

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] <

Post by Marcus Müller
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
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
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]

Post by Marcus Müller
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

Post by Inspire
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

Post by Inspire
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

Post by Inspire
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

Post by Inspire
based on buffers. I am also struggling with how to do the switching

between

Post by Inspire
streams.
I know 2009 was a long time ago, but any help would be greatly

appreciated.

Post by Inspire
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.co

m/Constant-carrier-digital-transmission-tp27764p61217.html

Post by Inspire
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
http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-
transmission-tp27764p61221.html
To unsubscribe from Constant carrier digital transmission, click here
<http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=27764&code=aW5zcGlyZTgyMDBAZ21haWwuY29tfDI3NzY0fC0xNTU4Nzk3Mjg5>
.
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: http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61222.html
Sent from the GnuRadio mailing list archive at Nabble.com.

[Marcus Müller]

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

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
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
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>

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]
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>

Post by Inspire
Hello
I am relatively new to gnuradio, I have only been working

with it for 6

Post by Inspire
weeks.
I came across your posts from march 2009 relating to

continuously

Post by Inspire
transmitting 0x7E's when no messages are present in the

queue. I am facing

Post by Inspire
the exact issue with our implementation in GNURadio. I need

to send out

Post by Inspire
continuous flags when no messages are in the queue but

immediately (within a

Post by Inspire
few flags) switch to sending data when a message arrives. I

have gone

Post by Inspire
looking for the HDLC Source code spoken about but have not

found it.

Post by Inspire
Q1. How was this solved ?
I am struggling with getting my head around how to ensure

the continuous

Post by Inspire
stream of Flags given that gnuradio buffers up and

schedules transmission

Post by Inspire
based on buffers. I am also struggling with how to do the

switching between

Post by Inspire
streams.
I know 2009 was a long time ago, but any help would be

greatly appreciated.

Post by Inspire
The mentioned source code example or any other example code

would be of

Post by Inspire
great benefit as GNURadio documentation is confusing and

some times

Post by Inspire
non-existent.
Kind Regards
Frank
--

http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html
<http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html>

Post by Inspire
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>

Post by Inspire
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
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus Müller]

Yep, next (==what becomes 3.8) fixes that spinning.

Post by Marcus Müller
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
* 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
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

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
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
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>

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]
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>

Post by Inspire
Hello
I am relatively new to gnuradio, I have only been working

with it for 6

Post by Inspire
weeks.
I came across your posts from march 2009 relating to

continuously

Post by Inspire
transmitting 0x7E's when no messages are present in the

queue. I am facing

Post by Inspire
the exact issue with our implementation in GNURadio. I

need to send out

Post by Inspire
continuous flags when no messages are in the queue but

immediately (within a

Post by Inspire
few flags) switch to sending data when a message arrives.

I have gone

Post by Inspire
looking for the HDLC Source code spoken about but have not

found it.

Post by Inspire
Q1. How was this solved ?
I am struggling with getting my head around how to ensure

the continuous

Post by Inspire
stream of Flags given that gnuradio buffers up and

schedules transmission

Post by Inspire
based on buffers. I am also struggling with how to do the

switching between

Post by Inspire
streams.
I know 2009 was a long time ago, but any help would be

greatly appreciated.

Post by Inspire
The mentioned source code example or any other example

code would be of

Post by Inspire
great benefit as GNURadio documentation is confusing and

some times

Post by Inspire
non-existent.
Kind Regards
Frank
--

http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html
<http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html>

Post by Inspire
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>

Post by Inspire
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
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Nick Foster]

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

Post by Marcus Müller
Yep, next (==what becomes 3.8) fixes that spinning.
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
- 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
[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
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]

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
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
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]

Post by Marcus Müller
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

Post by Inspire
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

Post by Inspire
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

Post by Inspire
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

Post by Inspire
stream of Flags given that gnuradio buffers up and schedules

transmission

Post by Inspire
based on buffers. I am also struggling with how to do the switching

between

Post by Inspire
streams.
I know 2009 was a long time ago, but any help would be greatly

appreciated.

Post by Inspire
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
--

http://gnuradio.4.n7.nabble.com/Constant-carrier-digital-transmission-tp27764p61217.html

Post by Inspire
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
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Marcus Müller]

Hi Nick,

Post by Nick Foster
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.
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.

Post by Nick Foster
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
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!

Post by Nick Foster
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

[Inspire Me]

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

Post by Marcus Müller
Hi Nick,
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.
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
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Ed Criscuolo]

In a GnuRadio block that is derived from a "sync" block, the number of
input and output items are the same, so the work function is supplied
with a single value called "nitems". The normal control flow of a
typical work function uses a loop that iterates over nitems, taking
one item from the input(s) buffer(s) and producing one item into the
output buffer. This process repeats until all input items are consumed
and all output buffer item spaces are full. The work function then
returns a value of "nitems" to indicate to the scheduler how many items
were consumed and produced.

But it is perfectly legal for the loop in the work function to terminate
early, in which case it should return the number of items
_actually_ processed. The scheduler will take care of keeping track
of the partial buffers and no data will be lost. But performance
will be reduced.

GnuRadio blocks are timing agnostic. They run as fast as they can,
and process an entire buffer's worth of items (typically 64K items)
per call to the work function. This is done to improve throughput.
Timing only happens when your bitstream meets up with a hardware
device, like a USRP. But as long as the _average_ throughput is
fast enough to keep up with the hardware, everything is fine.
The amount of CPU processing "headroom" determines how far you can
degrade a block's average throughput without creating underruns.

This level of understanding is fundamental to writing any GnuRadio
blocks, so you really should take the time to play with it and get
to know it.

Here is a snippet of VERY OLD code for example only. It that always
runs "nitems" times. When idle (ie - no hdlc packets available), it
produces 64k bits (8k of flags) on every invocation! This results in a
large latency when a packet finally does come along.
It should be modified to break the loop on the second fifo empty
test and return "i" instead of "nitems"

int
sc_hdlc_router_source_b::work (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
unsigned char * outbuf = (unsigned char *) output_items[0];
int i;

// Loop until the requested number of output stream bytes have been
generated
for(i=0; i<noutput_items; i++)
{
if (d_fifo.empty())
{
// Process a single incoming packet on the tun/tap pseudo
network device
// by bitstuffing it, encapsulating it in an MPoFR frame, and
pushing
// it into the bit_buf fifo.
encapsulate_incoming_packet();
}

// If bit_buf fifo is still empty, push a FLAG into it
if(d_fifo.empty())
{
push_flag();
}

// Output a bit from the bitbuf in the low-order bit of the output byte
outbuf[i] = d_fifo.pop();
}

return noutput_items;
}


@(^.^)@ Ed

Post by Inspire
Hi Ed
Thank you for the response.
I like the idea of the second option. Could please expand the
explaination. I am new to gnuradio and don't yet fully grasp how the
scheduler works in detail. How do you terminate the work function early
and ensure the single 0x7E gets streamed immediately to the modulator so
that we don't get under runs. How quickly will the work function be re
executed by the scheduler ? As fas as CPU is concerned, I have a machine
with 16 cores ( 32 threads). I am not concened if one thread is consumed
by this. Could you send me a snippet of the work function you implemented.
Your assitance is much appreciated.
Kind Regards
Frank
Hi Frank,
I'm the author of the GMSK Spacecraft Groundstation project you
referenced. Been on vacation for the last 2 weeks without internet,
so I'm just seeing this.
it, there were no tags or messages, so everything related to
PDU-like behavior had to be implemented in a single C++ block. Now,
packets can come in as PDUs, and get converted into a bitstream in a
single, much simpler block.
As for the issue of putting HDLC flag octets out back-to-back as the
"idle" pattern between frames, I had tried two different solutions,
one of which Marcus touched upon.
First approach was to simply reduce the buffer size of all blocks by
recompiling GnuRadio with the appropriate global constant reset to a
smaller value. This has significant impact on overall performance,
but because our data rate was modest (only a few hundred Kbits/sec)
and we had some wicked fast hardware (for the times!) we were able
to get this to work, reducing the added latency of outbound packets
from over ten seconds to only a few seconds. This was OK for our
particular requirements, but not for a general purpose system. It
was an easy but VERY brute-force solution.
Later, I modified the block to to implement a solution similar to
Marcus' "Option A". Every time the block's work function was entered,
it checked for an available packet (I was using sockets, but modern
GnuRadio would use PDUs and message queues). If a packet was available,
it would be bitstuffed and the bitstream written to the output
buffer. This would continue until either no more packets were
available, or the
output buffer reached capacity. If there were NO packets available
when the work function was called, it would put a SINGLE 0x7E (that
is, a bitstream of eight bits) on the output buffer and terminate
the work function early, returning only the numbers of bits actually
produced.
This is perfectly allowable, but it will result in the block consuming
a large amount of CPU when generating idle flags. At least this
solution only effects a single block instead of all the blocks.
If the resulting CPU usage is too high, it could be reduced, at the
cost of adding latency, by outputting 2 or more flags at a time.
Hope this helps.
@(^.^)@ Ed
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
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation>
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation
<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
Hi Nick,
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.
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
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>

[Ed Criscuolo]

Hi Ed
Much appreciated. You mentioned latency due to queued flags. This has
potential to cause us issues. I was wondering if it is possible to build
a block as a sort of switch that takes input from the standard HDLC
Framer but executues continuously, ie once every symbol period T=
n*(1/(9600*4), it would check to see if any items are in the input
buffer and if not push nFlags out (n being small), boost sleep for on
n*symbol period and repeat. I know this would be highly inefficient but
given it will be a very basic block it would only execute for a fraction
of the symbol time. The other option was to have a seperate thread in
the block for sending the flags which runs independent of the Work
function and use a semaphore to enable / disable the sending of flags..
Your thoughts and insight would be valuable.

Again, I repeat that GnuRadio blocks are timing agnostic. You cannot
"pace" the bitstream in real-time by the use of "sleeps".

You need to write a block that has NO bitstream inputs, and one
bitstream output. This is known as a "source" block. In addition
it should have a message port for receiving HDLC frames. As in
the example I showed you, this new block should check the message
port for an HDLC frame, bitstuff it into the output bitstream, and
repeat this until either the message port is empty or the output
buffer is full. If the message port is empty on the initial entry
to work, output a single FLAG worth of bits and exit, returning a
value of 8.

Q.I thought I read that the schedular only schedules work function when
there is input data to process. In other words if no input is available
then the work function would not be scheduled. Is this correct ? If not
where can I find more information on the scheduler. I have read material
available online including (
https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d0863397/543aee20e4b09162d0863578/1380223973117/gr_scheduler_overview.pdf
)

The scheduler will schedule a block to run if there is input available
AND the output buffer is available. That is, all of the immediately
downstream blocks have indicated that they have consumed the data.
This is called backpressure. In the case of a source block, there
are no inputs, and the block is run whenever the output buffer space is
available.

Once again thank you for spending time helping.

No problem. I believe you said you're doing a CubeSat application?
On small satellites, often the best approach to this problem is to
use an HDLC framer chip, which does all this for you and produces
a simple bitstream with flags and frames all in their proper places.
This bitstream is then straightforward to handle and send to a modulator.

One last note. Keep the discussion on-list so others may benefit
(do a "Reply All" instead of a "Reply", otherwise it just comes to me).

@(^.^)@ Ed

Kind Regards
Frank
In a GnuRadio block that is derived from a "sync" block, the number of
input and output items are the same, so the work function is supplied
with a single value called "nitems". The normal control flow of a
typical work function uses a loop that iterates over nitems, taking
one item from the input(s) buffer(s) and producing one item into the
output buffer. This process repeats until all input items are consumed
and all output buffer item spaces are full. The work function then
returns a value of "nitems" to indicate to the scheduler how many items
were consumed and produced.
But it is perfectly legal for the loop in the work function to
terminate early, in which case it should return the number of items
_actually_ processed. The scheduler will take care of keeping track
of the partial buffers and no data will be lost. But performance
will be reduced.
GnuRadio blocks are timing agnostic. They run as fast as they can,
and process an entire buffer's worth of items (typically 64K items)
per call to the work function. This is done to improve throughput.
Timing only happens when your bitstream meets up with a hardware
device, like a USRP. But as long as the _average_ throughput is
fast enough to keep up with the hardware, everything is fine.
The amount of CPU processing "headroom" determines how far you can
degrade a block's average throughput without creating underruns.
This level of understanding is fundamental to writing any GnuRadio
blocks, so you really should take the time to play with it and get
to know it.
Here is a snippet of VERY OLD code for example only. It that always
runs "nitems" times. When idle (ie - no hdlc packets available), it
produces 64k bits (8k of flags) on every invocation! This results in
a large latency when a packet finally does come along.
It should be modified to break the loop on the second fifo empty
test and return "i" instead of "nitems"
int
sc_hdlc_router_source_b::work (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star
&output_items)
{
unsigned char * outbuf = (unsigned char *) output_items[0];
int i;
// Loop until the requested number of output stream bytes have
been generated
for(i=0; i<noutput_items; i++)
{
if (d_fifo.empty())
{
// Process a single incoming packet on the tun/tap pseudo
network device
// by bitstuffing it, encapsulating it in an MPoFR frame,
and pushing
// it into the bit_buf fifo.
encapsulate_incoming_packet();
}
// If bit_buf fifo is still empty, push a FLAG into it
if(d_fifo.empty())
{
push_flag();
}
// Output a bit from the bitbuf in the low-order bit of the output byte
outbuf[i] = d_fifo.pop();
}
return noutput_items;
}
@(^.^)@ Ed
Hi Ed
Thank you for the response.
I like the idea of the second option. Could please expand the
explaination. I am new to gnuradio and don't yet fully grasp how the
scheduler works in detail. How do you terminate the work function early
and ensure the single 0x7E gets streamed immediately to the modulator so
that we don't get under runs. How quickly will the work function be re
executed by the scheduler ? As fas as CPU is concerned, I have a machine
with 16 cores ( 32 threads). I am not concened if one thread is consumed
by this. Could you send me a snippet of the work function you implemented.
Your assitance is much appreciated.
Kind Regards
Frank
Hi Frank,
I'm the author of the GMSK Spacecraft Groundstation project you
referenced. Been on vacation for the last 2 weeks without internet,
so I'm just seeing this.
it, there were no tags or messages, so everything related to
PDU-like behavior had to be implemented in a single C++ block. Now,
packets can come in as PDUs, and get converted into a bitstream in a
single, much simpler block.
As for the issue of putting HDLC flag octets out
back-to-back as the
"idle" pattern between frames, I had tried two different solutions,
one of which Marcus touched upon.
First approach was to simply reduce the buffer size of all blocks by
recompiling GnuRadio with the appropriate global constant reset to a
smaller value. This has significant impact on overall performance,
but because our data rate was modest (only a few hundred Kbits/sec)
and we had some wicked fast hardware (for the times!) we were able
to get this to work, reducing the added latency of outbound packets
from over ten seconds to only a few seconds. This was OK for our
particular requirements, but not for a general purpose system. It
was an easy but VERY brute-force solution.
Later, I modified the block to to implement a solution similar to
Marcus' "Option A". Every time the block's work function was entered,
it checked for an available packet (I was using sockets, but modern
GnuRadio would use PDUs and message queues). If a packet
was available,
it would be bitstuffed and the bitstream written to the output
buffer. This would continue until either no more packets were
available, or the
output buffer reached capacity. If there were NO packets available
when the work function was called, it would put a SINGLE 0x7E (that
is, a bitstream of eight bits) on the output buffer and terminate
the work function early, returning only the numbers of bits actually
produced.
This is perfectly allowable, but it will result in the block consuming
a large amount of CPU when generating idle flags. At least this
solution only effects a single block instead of all the blocks.
If the resulting CPU usage is too high, it could be reduced, at the
cost of adding latency, by outputting 2 or more flags at a time.
Hope this helps.
@(^.^)@ Ed
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
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation>
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation>>
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation>
<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/GMSKSpacecraftGroundstation
<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
Hi Nick,
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.
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
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>

[Inspire Me]

Hi Ed

I have the continuous Flags working thanks to the information
and explanations. I owe thanks to you and to Nick and Marcus for the help.
End the end it was quite simple to modify the current HDLC Framer to output
flags when there are no messages in the queue.

Kind Regards
Frank




On 17 Aug 2016, at 1:20 pm, Ed Criscuolo-3 [via GnuRadio] <

Hi Ed
Much appreciated. You mentioned latency due to queued flags. This has
potential to cause us issues. I was wondering if it is possible to build
a block as a sort of switch that takes input from the standard HDLC
Framer but executues continuously, ie once every symbol period T=
n*(1/(9600*4), it would check to see if any items are in the input
buffer and if not push nFlags out (n being small), boost sleep for on
n*symbol period and repeat. I know this would be highly inefficient but
given it will be a very basic block it would only execute for a fraction
of the symbol time. The other option was to have a seperate thread in
the block for sending the flags which runs independent of the Work
function and use a semaphore to enable / disable the sending of flags..
Your thoughts and insight would be valuable.

Again, I repeat that GnuRadio blocks are timing agnostic. You cannot
"pace" the bitstream in real-time by the use of "sleeps".

You need to write a block that has NO bitstream inputs, and one
bitstream output. This is known as a "source" block. In addition
it should have a message port for receiving HDLC frames. As in
the example I showed you, this new block should check the message
port for an HDLC frame, bitstuff it into the output bitstream, and
repeat this until either the message port is empty or the output
buffer is full. If the message port is empty on the initial entry
to work, output a single FLAG worth of bits and exit, returning a
value of 8.

Q.I thought I read that the schedular only schedules work function when
there is input data to process. In other words if no input is available
then the work function would not be scheduled. Is this correct ? If not
where can I find more information on the scheduler. I have read material
available online including (
https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/

543aee1fe4b09162d0863397/543aee20e4b09162d0863578/
1380223973117/gr_scheduler_overview.pdf

)

The scheduler will schedule a block to run if there is input available
AND the output buffer is available. That is, all of the immediately
downstream blocks have indicated that they have consumed the data.
This is called backpressure. In the case of a source block, there
are no inputs, and the block is run whenever the output buffer space is
available.

Once again thank you for spending time helping.

No problem. I believe you said you're doing a CubeSat application?
On small satellites, often the best approach to this problem is to
use an HDLC framer chip, which does all this for you and produces
a simple bitstream with flags and frames all in their proper places.
This bitstream is then straightforward to handle and send to a modulator.

One last note. Keep the discussion on-list so others may benefit
(do a "Reply All" instead of a "Reply", otherwise it just comes to me).

@(^.^)@ Ed

Kind Regards
Frank
On 17 August 2016 at 11:59, Ed Criscuolo <[hidden email]
In a GnuRadio block that is derived from a "sync" block, the number of
input and output items are the same, so the work function is supplied
with a single value called "nitems". The normal control flow of a
typical work function uses a loop that iterates over nitems, taking
one item from the input(s) buffer(s) and producing one item into the
output buffer. This process repeats until all input items are consumed
and all output buffer item spaces are full. The work function then
returns a value of "nitems" to indicate to the scheduler how many items
were consumed and produced.
But it is perfectly legal for the loop in the work function to
terminate early, in which case it should return the number of items
_actually_ processed. The scheduler will take care of keeping track
of the partial buffers and no data will be lost. But performance
will be reduced.
GnuRadio blocks are timing agnostic. They run as fast as they can,
and process an entire buffer's worth of items (typically 64K items)
per call to the work function. This is done to improve throughput.
Timing only happens when your bitstream meets up with a hardware
device, like a USRP. But as long as the _average_ throughput is
fast enough to keep up with the hardware, everything is fine.
The amount of CPU processing "headroom" determines how far you can
degrade a block's average throughput without creating underruns.
This level of understanding is fundamental to writing any GnuRadio
blocks, so you really should take the time to play with it and get
to know it.
Here is a snippet of VERY OLD code for example only. It that always
runs "nitems" times. When idle (ie - no hdlc packets available), it
produces 64k bits (8k of flags) on every invocation! This results in
a large latency when a packet finally does come along.
It should be modified to break the loop on the second fifo empty
test and return "i" instead of "nitems"
int
sc_hdlc_router_source_b::work (int

noutput_items,

gr_vector_const_void_star &input_items,
gr_vector_void_star
&output_items)
{
unsigned char * outbuf = (unsigned char *) output_items[0];
int i;
// Loop until the requested number of output stream bytes have
been generated
for(i=0; i<noutput_items; i++)
{
if (d_fifo.empty())
{
// Process a single incoming packet on the tun/tap pseudo
network device
// by bitstuffing it, encapsulating it in an MPoFR frame,
and pushing
// it into the bit_buf fifo.
encapsulate_incoming_packet();
}
// If bit_buf fifo is still empty, push a FLAG into it
if(d_fifo.empty())
{
push_flag();
}
// Output a bit from the bitbuf in the low-order bit of the output byte
outbuf[i] = d_fifo.pop();
}
return noutput_items;
}
@(^.^)@ Ed
Hi Ed
Thank you for the response.
I like the idea of the second option. Could please expand the
explaination. I am new to gnuradio and don't yet fully grasp how the
scheduler works in detail. How do you terminate the work function early
and ensure the single 0x7E gets streamed immediately to the modulator so
that we don't get under runs. How quickly will the work function be re
executed by the scheduler ? As fas as CPU is concerned, I have a machine
with 16 cores ( 32 threads). I am not concened if one thread is consumed
by this. Could you send me a snippet of the work function you implemented.
Your assitance is much appreciated.
Kind Regards
Frank
On 17 August 2016 at 02:00, Ed Criscuolo <[hidden email]
<mailto:[hidden email]>
Hi Frank,
I'm the author of the GMSK Spacecraft Groundstation project you
referenced. Been on vacation for the last 2 weeks without internet,
so I'm just seeing this.
it, there were no tags or messages, so everything related to
PDU-like behavior had to be implemented in a single C++ block. Now,
packets can come in as PDUs, and get converted into a bitstream in a
single, much simpler block.
As for the issue of putting HDLC flag octets out
back-to-back as the
"idle" pattern between frames, I had tried two different solutions,
one of which Marcus touched upon.
First approach was to simply reduce the buffer size of all blocks by
recompiling GnuRadio with the appropriate global constant reset to a
smaller value. This has significant impact on overall performance,
but because our data rate was modest (only a few hundred Kbits/sec)
and we had some wicked fast hardware (for the times!) we were able
to get this to work, reducing the added latency of outbound packets
from over ten seconds to only a few seconds. This was OK for our
particular requirements, but not for a general purpose system. It
was an easy but VERY brute-force solution.
Later, I modified the block to to implement a solution similar to
Marcus' "Option A". Every time the block's work function was entered,
it checked for an available packet (I was using sockets, but modern
GnuRadio would use PDUs and message queues). If a packet
was available,
it would be bitstuffed and the bitstream written to the output
buffer. This would continue until either no more packets were
available, or the
output buffer reached capacity. If there were NO packets available
when the work function was called, it would put a SINGLE 0x7E (that
is, a bitstream of eight bits) on the output buffer and terminate
the work function early, returning only the numbers of bits actually
produced.
This is perfectly allowable, but it will result in the block consuming
a large amount of CPU when generating idle flags. At least this
solution only effects a single block instead of all the blocks.
If the resulting CPU usage is too high, it could be reduced, at the
cost of adding latency, by outputting 2 or more flags at a time.
Hope this helps.
@(^.^)@ Ed
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

<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/

GMSKSpacecraftGroundstation>

<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/

GMSKSpacecraftGroundstation

<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/

GMSKSpacecraftGroundstation>>

<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/

GMSKSpacecraftGroundstation

<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/

GMSKSpacecraftGroundstation>

<https://moo.cmcl.cs.cmu.edu/trac/cgran/wiki/

GMSKSpacecraftGroundstation

<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
<[hidden email]
<mailto:[hidden email]>
<mailto:[hidden email] <mailto:[hidden email]>>
<mailto:[hidden email]
<mailto:[hidden email]>
<mailto:[hidden email]
Hi Nick,
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.
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
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
[hidden email] <mailto:[hidden email]>
<mailto:[hidden email] <mailto:[hidden email]>>
<mailto:[hidden email]
<mailto:[hidden email]>
<mailto:[hidden email] <mailto:[hidden email]>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>
_______________________________________________
Discuss-gnuradio mailing list
[hidden email] <mailto:[hidden email]>
<mailto:[hidden email] <mailto:[hidden email]>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
_______________________________________________
Discuss-gnuradio mailing list
[hidden email] <mailto:[hidden email]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<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-tp27764p61256.html
To unsubscribe from Constant carrier digital transmission, click here
<http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=27764&code=aW5zcGlyZTgyMDBAZ21haWwuY29tfDI3NzY0fC0xNTU4Nzk3Mjg5>
.
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>