Transmitting bursts with GRC by inserting SOB and EOB

GNU Radio
1

Hello,

I am trying to implement a burst transmitter using GNU Radio Companion
and an USRP N210 with WBX board. My problem is when inserting zeros as
“gap” between the bursts the USRP is transmitting a non-neglectable
carrier signal (due to DC offset I guess?). So I want to try inserting
tx_sob and tx_eob stream tags to make the USRP shutting down the TX
chain.

For that I created a sample flow graph which creates one burst with 6
samples. The tags are inserted by a “Message Burst Source”. The
important part of the generated .py file is as follows:

    ##################################################
            channels=range(1),

self.blocks_tag_debug_0.set_display(True)
self.connect((self.blocks_vector_source_x_0, 0),
(self.blocks_message_sink_0, 0))
self.connect((self.blocks_message_burst_source_0, 0),
(self.blocks_tag_debug_0, 0))
self.connect((self.blocks_message_burst_source_0, 0),
(self.usrp_sink, 0))
Through the “Tag Debug” block I observe that the tags are set correctly
(tx_sob at sample 0 and tx_eob at sample 5). Nevertheless the USRP is
still transmitting at the carrier frequency after the actual burst is
completed. I observed that with a second USRP as receiver. It seems like
the USRP Sink is ignoring the tags.

Trying the “tags_demo” application showed the desired behaviour. No
carrier between the bursts. I checked the source code and noticed that
they are additionally assigning time stamps as tags to the samples. Is
this necessary to achieve my goal?

I am using GNU Radio 3.7.2.1 and UHD_003.005.005-0.

Any comments on this issue are highly appreciated!

Frederik.

2

A couple of comments, maybe this helps you on your tracks:

  • You’re using an ancient UHD version. Is there a reason you can’t use a
    newer one?
  • In current GNU Radio, you can use ‘length tags’ to mark bursts, if
    that’s any help.
  • You’ll know if your USRP hasn’t acknowledged tx_eob if you see 'U’s
    between bursts.

Cheers,
M

3

Thank you Martin for your fast response!

  • You’re using an ancient UHD version. Is there a reason you can’t use a
    newer one?
    I am using Ubuntu 14.04 LTS and just pulled GNU Radio and UHD from the
    packet sources. There is no newer version available. And I don’t like to
    compile myself unless it is absolutely necessary.
    I don’t think it’s because of an outdated version of UHD as the
    “tags_demo” application is working perfectly with my current version.
  • In current GNU Radio, you can use ‘length tags’ to mark bursts, if
    that’s any help.
    I tried using length tags by inserting an “Stream to tagged Stream”
    block and adding the length_tag_name property to the USRP Sink. Here is
    my sample code, now with a burst of 5 samples:
    ##################################################
    self.usrp_sink.set_gain(tx_gain, 0)
    (self.blocks_stream_to_tagged_stream_0, 0))
    self.connect((self.blocks_stream_to_tagged_stream_0, 0),
    (self.usrp_sink, 0))
    It’s not working either… I can still observe the carrier at the
    receiver.
  • You’ll know if your USRP hasn’t acknowledged tx_eob if you see 'U’s
    between bursts.
    I am getting exactly one “U”. Both for the code in my previous post as
    well as for the above one. It really seems like the USRP is not
    recognizing the stream tags.

Any further ideas? Can someone reproduce this behaviour?

Frederik

4

Hello Frederik,

On 10/20/2014 05:53 PM, Frederik Wing wrote:

Thank you Martin for your fast response!

  • You’re using an ancient UHD version. Is there a reason you can’t use a
    newer one?
    I am using Ubuntu 14.04 LTS and just pulled GNU Radio and UHD from the
    packet sources. There is no newer version available. And I don’t like to
    compile myself unless it is absolutely necessary.
    Consider it outdated. Ubuntu’s packet sources are most of the time
    horribly out of pace compared to GNU Radio’s development process.
    For UHD it’s the same. Note that Ettus ships its own Ubuntu packages for
    UHD and GNU Radio, so you can get a non-ancient version of both
    without even compiling it.
    By the way: GNU Radio is a software radio developer’s framework. You can
    do great things with it without touching a compiler, but at many points
    it becomes helpful when one can write his own C++ block, so you
    definitely need to lose your fear of compilers if you want to use GNU
    Radio to its fullest potential :slight_smile:
    I don’t think it’s because of an outdated version of UHD as the
    “tags_demo” application is working perfectly with my current version.
    … Well, my old tube radio also still works :wink:

Martin went through some work improving the uhd blocks in GNU Radio
recently. You’ll greatly profit.

And: seriously, please use something recent. Using an old version makes
it really hard to get qualified help!
Also, all the tutorials on gnuradio.org of course revolve around recent
versions, so if you want to learn GNU Radio,
you should learn it with a modern base.

  • In current GNU Radio, you can use ‘length tags’ to mark bursts, if
    that’s any help.
    I tried using length tags by inserting an “Stream to tagged Stream”
    block and adding the length_tag_name property to the USRP Sink. Here is
    my sample code, now with a burst of 5 samples:
    The GNU Radio doxygen contains documentation for the current GNU Radio
    build, containing the newly available message passing functionality.
    Maybe that’s of interest to you!

Greetings,
Marcus

5

On 21.10.2014 13:47, Frederik Wing wrote:

Consider it outdated. Ubuntu’s packet sources are most of the time
After some hours of compiling time I could finally update GNU Radio to
Debug Block I see tx_sob+tx_eob and the Length Tag, respectively. They
all seem to be at the right place and have the right value.
:frowning: ok, so we see something that looks like significant LO leakage.

You can use offset tuning, by specifying a tune request instead of
simply a target frequency f_t. By doing so, you instruct the USRP to
tune the oscillator of the daughterboard to some frequency f_LO, and let
the FPGA shift the resulting signal to baseband by a second frequency
f_FPGA, so that f_LO+f_FPGA = f_t.

You thereby would move the LO leakage out of your desired signal. Would
that help you?

Greetings,
Marcus

6

for UHDand GNU Radio, so you can get a non-ancient version of both

I don’t think it’s because of an outdated version of UHD as the

You can use offset tuning, by specifying a tune request instead of
simply a target frequency f_t. By doing so, you instruct the USRP to
tune the oscillator of the daughterboard to some frequency f_LO, and let
the FPGA shift the resulting signal to baseband by a second frequency
f_FPGA, so that f_LO+f_FPGA = f_t.

You thereby would move the LO leakage out of your desired signal. Would
that help you?

Thanks for this suggestion. It would be a workaround to the actual
problem. And if there is no other way I have to do so.

I cannot believe that there is no solution to it since the “tags_demo”
application shows that it is indeed possible. :-/

Frederik.

7

Hello Marcus,

thank you very much for your hints!

without even compiling it.
By the way: GNU Radio is a software radio developer’s framework. You
can do great things with it without touching a compiler, but at many
points it becomes helpful when one can write his own C++ block, so you
definitely need to lose your fear of compilers if you want to use GNU
Radio to its fullest potential :slight_smile:

After some hours of compiling time I could finally update GNU Radio to
version 3.7.6 and UHD to 003.008.

I don’t think it’s because of an outdated version of UHD as the
“tags_demo” application is working perfectly with my current version.
… Well, my old tube radio also still works :wink:

Unfortunately, even with the newest version the USRP is still
transmitting its carrier over the air. I tried both with the Message
Burst Source as well as with the Stream to Tagged Stream Block combined
with setting a Length Tag name in the USRP Sink. With the Tag Debug
Block I see tx_sob+tx_eob and the Length Tag, respectively. They all
seem to be at the right place and have the right value.

The Length Tag should arrive properly at the Sink. I checked by changing
the tag’s name at the Stream to Tagged Stream Block to something stupid
and finally got an “tG” printed out.

Another interesting observation:
I don’t get the “U” underrun output if I use a larger number of samples
for my burst (in Vector Source). Even with only Vector Source and USRP
Sink (no blocks in between) I don’t get any “U” printed. I tried that
with 500 samples.

Has anyone ever succeeded in transmitting proper bursts with a GRC flow
graph? Or at least on Python level? I really feel desperate right now…

  • In current GNU Radio, you can use ‘length tags’ to mark bursts, if
    that’s any help.
    I tried using length tags by inserting an “Stream to tagged Stream”
    block and adding the length_tag_name property to the USRP Sink. Here is
    my sample code, now with a burst of 5 samples:
    The GNU Radio doxygen contains documentation for the current GNU Radio
    build, containing the newly available message passing functionality.
    Maybe that’s of interest to you!

That’s definitely an interesting feature. But first of all I’d like to
make sure that transmitting bursts works as expected before making other
improvements in my transmitter chain.

Frederik

8

Hi Frederik,
On 21.10.2014 14:56, Frederik Wing wrote:

I cannot believe that there is no solution to it since the “tags_demo”
application shows that it is indeed possible. :-/
that makes the two of us! I didn’t get that when using tags_demo, you’re
not seeing the carrier that you use tags_demo; as far as I understood,
your application does exactly the same, sending bursts with sob/eob
tags?

Greetings,
Marcus

9

Hi Marcus,

I cannot believe that there is no solution to it since the “tags_demo”
application shows that it is indeed possible. :-/
that makes the two of us! I didn’t get that when using tags_demo, you’re
not seeing the carrier that you use tags_demo; as far as I understood,
your application does exactly the same, sending bursts with sob/eob tags?

That’s right. tags_demo works perfectly. No carrier in between the
bursts.
The flow graph I posted before sends exactly one burst with SOB and EOB
tags. The only difference to tags_demo I could recognize so far is that
I don’t assign time stamps to the samples. But this shouldn’t be a
problem, should it?

Frederik

10

On 10/21/2014 03:53 PM, Frederik Wing wrote:

I don’t assign time stamps to the samples. But this shouldn’t be a
problem, should it?

Hm, it might. Give it a shot – there might be some interaction between
the way GNU Radio handles the time spec and what UHD expects.

To reiterate on an earlier part of this thread, if you only see a single
‘U’, then GNU Radio/UHD are respecting the eob/sob tags, albeit in a
slightly buggy way (there should be no U). If the tags weren’t
respected, you’d see lots and lots of U’s between bursts. Although this
might also be related to the time stamps.

Cheers,
M

11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gooood question.
The corresponding lines look something like [1] (while iterating over
the tags in the current set of items):

BOOST_FOREACH(const tag_t &my_tag, _tags) {
…
else if(pmt::is_null(_length_tag_key)
&& pmt::equal(key, SOB_KEY)) {
if (my_tag.offset != samp0_count) {
max_count = my_tag_count;
break;
}
// Bursty tx will not use time specs, unless a tx_time tag is also
given.
_metadata.has_time_spec = false; //(wut)
_metadata.start_of_burst = pmt::to_bool(value);
}

… and that (wut) might be a bug, because it implies that, if the
stream has both a time tag and a sob tag, the question whether the tx
metadata has a time tag depends on in which order these tags are
sorted on the the tag storage multimap. Which might be random, because
tags are sorted only by tag offset.
@Martin: is there a reason that this is explicitely set to false here,
or can one just fix this by deleting a line?

Cheers,
Marcus

[1]

On 21.10.2014 15:53, Frederik Wing wrote:

bursts. The flow graph I posted before sends exactly one burst with

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
=V3EN
-----END PGP SIGNATURE-----

12

From Marcus:

… and that (wut) might be a bug, because it implies that, if the stream has
both a time tag and a sob tag, the
question whether the tx metadata has a time tag depends on in which order these
tags are sorted on the the
tag storage multimap. Which might be random, because tags are sorted only by tag
offset.
@Martin: is there a reason that this is explicitely set to false here, or can
one just fix this by deleting a line?

This appears to be handled correctly. Given the same tag offset, the
order of tx_time vs. tx_sob tags should not matter. If tx_time is found
first, it sets found_time_tag=true and _metadata.has_time_spec=true
(lines 652 & 653). Then _metadata.has_time_spec is overwritten in the
tx_sob check (line 665) with ‘false’, but is set back to ‘true’ in line
743 due to found_time_tag being true.

  if (found_time_tag) {
    _metadata.has_time_spec = true;
  }

If instead tx_sob is found first and tx_time second, then the time spec
will also be set in line 743. So the question is whether setting
_metadata.has_time_spec=false is really necessary. I’d say it’s worth
keeping in case the user doesn’t always want to use tx_time stamps. The
user may want to schedule some bursts but force others to transmit as
soon as possible while still using the ATR functionality of the USRP.

I know all this logic can be hard to follow, but it has to handle so
many different cases and possibly span many calls to work and tag_work.

From Frederik:

Unfortunately, even with the newest version the USRP is still transmitting its
carrier over the air. I tried both with
the Message Burst Source as well as with the Stream to Tagged Stream Block
combined with setting a Length Tag
name in the USRP Sink. With the Tag Debug Block I see tx_sob+tx_eob and the
Length Tag, respectively. They all
seem to be at the right place and have the right value.

The Length Tag should arrive properly at the Sink. I checked by changing the
tag’s name at the Stream to Tagged
Stream Block to something stupid and finally got an “tG” printed out.

It should be mentioned that there are two burst tag interfaces that
cannot be mixed. if a Length Tag Name is specified to the constructor,
all tx_sob and tx_eob tags will be ignored in tag_work to ensure the
interfaces are mutually exclusive. If no Length Tag Name is specified,
then tag_work will search for tx_sob/tx_eob tags and won’t look for
length tags.

Sean

On 21.10.2014 15:53, Frederik Wing wrote:

bursts. The flow graph I posted before sends exactly one burst with

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
=V3EN
-----END PGP SIGNATURE-----

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

13

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Sean,

aaah good catch! Yes, that’s right; sob is safe.

Cheers,
Marcus

On 21.10.2014 19:19, Nowlan, Sean wrote:

the order of tx_time vs. tx_sob tags should not matter. If tx_time
setting _metadata.has_time_spec=false is really necessary. I’d say

Unfortunately, even with the newest version the USRP is still

Hi Marcus,
burst with SOB and EOB tags. The only difference to tags_demo I
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
mailing list [email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJURparAAoJEAFxB7BbsDrLiT8H/0qUJ6qkMEgWdp7q1eKTr3Bm
hq4P6pIAXxXkmIRWVy+pn2uZ2zunvv0/2e/NcE4RMppuxTlT8HvjeKb0aKDMIxE2
spVqN/nuue5JSRAbQJIvI69jJytGgqzxvjY2EyWHSZPKtXB3Hc5a/PoMGY3EZb45
hZ+mYN0z6JpUhRlozinTkkRI3D/P38dubx5YXTSbzCthEt2BMMInS+FEpiH42KrI
rKP7ywwqL0O6TFvFMlOqn9hNzJKP+PFvoJQbuH3zJSItIeRbyIth6QwERNh8Pg0H
3U19h6Y7ejnh+G8UOSOdxnlsoLHzwloYEvUb1cvBbhKeyDd4Dng8DwPa+Q6T0qo=
=vsQm
-----END PGP SIGNATURE-----

14

I’m concerned that the problem Frederik is observing has to do with the
very short burst he is sending, something like 5 samples. I suspect this
requires 1 call each to work and tag_work per 5 sample burst, which
seems like an awful lot of context switching and overhead.

15

Sean,

interesting point.

Frederik,

How does your carrier look when you send bursts of >500 samples?

Greetings,
Marcus

On 21.10.2014 19:29, Nowlan, Sean wrote:

I’m concerned that the problem Frederik is observing has to do with the very
short burst he is
sending, something like 5 samples. I suspect this requires 1 call each
to work and tag_work per 5 sample burst, which seems like an awful lot
of context switching and overhead.

-----Original Message-----
From: Marcus M?ller [mailto:[email protected]]
Sent: Tuesday, October 21, 2014 1:24 PM
To: Nowlan, Sean; [email protected]; Martin B.
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by
inserting SOB and EOB

16

Thank you all for your postings! I really appreciate your help in
solving my problem.

On 21.10.2014 19:29, Nowlan, Sean wrote:

I’m concerned that the problem Frederik is observing has to do with the very
short burst he is sending, something like 5 samples. I suspect this requires 1
call each to work and tag_work per 5 sample burst, which seems like an awful lot
of context switching and overhead.

I tried with bursts of 500 and even 50k. Same result as before, the
carrier is still there. :frowning:

     self.f_center = f_center = 1.47e9

                     channels=range(1),

“packet_len”)

There are a few things to consider with this flowgraph (as posted):

1)Your vector source is set to /not/ repeat. After your flowgraph
terminates, is that when you observe the LO still running?

I set the flow graph to “Prompt for Exit”. After the burst has been sent
I still see the carrier. So the LO is still running. After hitting Enter
to stop execution the carrier disappears.

2)Youre essentially sending a very short rectangular pulse modulated
onto a carrier, which in the frequency domain would look like a sinc
function centered at the carrier. Is this what you want, or are you just
experimenting with the burst interface?

It’s just for testing purpose.

3)Is there a reason your burst pulses need to contain so few samples?

There is no reason. As said before, even with far more samples the
behaviour remains the same.

Could you provide some information about what youre trying to do in
your end application?

My goal is to implement a spectrum sensing algorithm which evaluates the
characteristics of channels in a certain bandwidth. Based on the result
of that algorithm a channel is chosen in which a burst is being
transmitted. This is done repeatedly. The problem is that the presence
of the transmitter’s carrier appears as a spike in the spectrum and
influences the algorithm.

Off course there are workarounds like offset tuning proposed by Marcus.
I could also change the TX frequency right after the burst has been sent
to something outside the band. But that seems to me as a “quick and
dirty” solution which I am trying to avoid.

Frederik

17

important part of the generated .py file is as follows:

    # Message Queues
            cpu_format="fc32",

blocks.tag_debug(gr.sizeof_gr_complex*1, “”, “”);
##################################################
the USRP Sink is ignoring the tags.
Frederik.

Good news everyone, I finally found something!

When setting the TX gain in the flow graph above to something less than
5.8 (I tried 0 to 5.7) the carrier disappears. If I choose 5.8 or higher
the carrier is visible. And it’s not just that it is attenuated by the
decreased output gain. There is a difference of 30dB at the receiver
USRP if I change from 5.7 to 5.8.

I found out by analysing the “tags_demo” application. They are not
specifying any gain. I added a call to set_gain in the source code and
observed the same behaviour as in my flow graph. There seems to be a
magic boarder at 5.8dB.

Can anyone explain this to me? Is it bug in UHD or the USRP firmware?

Frederik

18 
     ##################################################

     # Variables

     ##################################################

     self.tx_gain = tx_gain = 15

     self.samp_rate = samp_rate = 200000

     self.f_center = f_center = 1.47e9

     self.device = device = "type=usrp2"

     ##################################################

     # Blocks

     ##################################################

     self.usrp_sink = uhd.usrp_sink(

             device_addr=device,

             stream_args=uhd.stream_args(

                     cpu_format="fc32",

                     length_tag_name="packet_len",

                     channels=range(1),

             ),

     )

     self.usrp_sink.set_samp_rate(samp_rate)

     self.usrp_sink.set_center_freq(f_center, 0)

     self.usrp_sink.set_gain(tx_gain, 0)

     self.usrp_sink.set_antenna("TX/RX", 0)

     self.blocks_vector_source_x_0 =

blocks.vector_source_c((1,)*5, False, 1, [])

     self.blocks_stream_to_tagged_stream_0 =

blocks.stream_to_tagged_stream(gr.sizeof_gr_complex, 1, 5,

“packet_len”)

     ##################################################

     # Connections

     ##################################################

     self.connect((self.blocks_vector_source_x_0, 0),

(self.blocks_stream_to_tagged_stream_0, 0))

     self.connect((self.blocks_stream_to_tagged_stream_0, 0),

(self.usrp_sink, 0))

It’s not working either… I can still observe the carrier at the receiver.

  • You’ll know if your USRP hasn’t acknowledged tx_eob if you see 'U’s

between bursts.

I am getting exactly one “U”. Both for the code in my previous post as

well as for the above one. It really seems like the USRP is not

recognizing the stream tags.

There are a few things to consider with this flowgraph (as posted):

  1.  Your vector source is set to /not/ repeat. After your flowgraph

terminates, is that when you observe the LO still running?

  1.  You're essentially sending a very short rectangular pulse

modulated onto a carrier, which in the frequency domain would look like
a sinc function centered at the carrier. Is this what you want, or are
you just experimenting with the burst interface?

  1.  Is there a reason your burst pulses need to contain so few

samples?

Could you provide some information about what you’re trying to do in
your end application?

Sean

From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] On
Behalf Of Marcus M.
Sent: Tuesday, October 21, 2014 1:41 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by
inserting SOB and EOB

Sean,

interesting point.

Frederik,

How does your carrier look when you send bursts of >500 samples?

Greetings,
Marcus

On 21.10.2014 19:29, Nowlan, Sean wrote:

I’m concerned that the problem
Frederik is observing has to do with the very short burst he is
sending, something like 5 samples. I suspect this requires 1 call
each to work and tag_work per 5 sample burst, which seems like an
awful lot of context switching and overhead.

  >

  > -----Original Message-----

  > From: Marcus M. [mailto:[email protected]]

  > Sent: Tuesday, October 21, 2014 1:24 PM

  > To: Nowlan, Sean;

[email protected]mailto:[email protected]; Martin B.

  > Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC
  by inserting SOB and EOB

  >

Hi Sean,

aaah good catch! Yes, that’s right; sob is safe.

Cheers,
Marcus

On 21.10.2014 19:19, Nowlan, Sean wrote:

From Marcus:

… and that (wut) might be a bug, because it implies that, if the
stream has both a time tag and a sob tag, the question whether the tx
metadata has a time tag depends on in which order these tags are
sorted on the the tag storage multimap. Which might be random,
because tags are sorted only by tag offset.
@Martin: is there a reason that this is explicitely set to false
here, or can one just fix this by deleting a line?

This appears to be handled correctly. Given the same tag offset, the
order of tx_time vs. tx_sob tags should not matter. If tx_time is
found first, it sets found_time_tag=true and
_metadata.has_time_spec=true (lines 652 & 653). Then
_metadata.has_time_spec is overwritten in the tx_sob check (line
665) with ‘false’, but is set back to ‘true’ in line 743 due to
found_time_tag being true.

if (found_time_tag) { _metadata.has_time_spec = true; }

If instead tx_sob is found first and tx_time second, then the time
spec will also be set in line 743. So the question is whether setting
_metadata.has_time_spec=false is really necessary. I’d say it’s worth
keeping in case the user doesn’t always want to use tx_time stamps.
The user may want to schedule some bursts but force others to transmit
as soon as possible while still using the ATR functionality of the
USRP.

I know all this logic can be hard to follow, but it has to handle so
many different cases and possibly span many calls to work and
tag_work.

changing the tag’s name at the Stream to Tagged Stream Block to
something stupid and finally got an “tG” printed out.

It should be mentioned that there are two burst tag interfaces that
cannot be mixed. if a Length Tag Name is specified to the constructor,
all tx_sob and tx_eob tags will be ignored in tag_work to ensure the
interfaces are mutually exclusive. If no Length Tag Name is specified,
then tag_work will search for tx_sob/tx_eob tags and won’t look for
length tags.

Sean

That’s right. tags_demo works perfectly. No carrier in between the
Discuss-gnuradio Info Page

  > _______________________________________________

  > Discuss-gnuradio mailing list

  > [email protected]<mailto:[email protected]>

  > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
19

samples. The tags are inserted by a “Message Burst Source”. The

    ##################################################
        stream_args=uhd.stream_args(
    self.blocks_tag_debug_0 =
    # Connections

completed. I observed that with a second USRP as receiver. It seems like

I found out by analysing the “tags_demo” application. They are not
specifying any gain. I added a call to set_gain in the source code and
observed the same behaviour as in my flow graph. There seems to be a
magic boarder at 5.8dB.

Can anyone explain this to me? Is it bug in UHD or the USRP firmware?

Frederik

And now the problem is finally solved.

The cause for it was a defective WBX board. I replaced it with a new one
and now everything works!

Again, thank you all for your productive hints and explanations!

Frederik

20

On 10/22/2014 03:38 PM, Frederik Wing wrote:

And now the problem is finally solved.

The cause for it was a defective WBX board. I replaced it with a new one
and now everything works!

Again, thank you all for your productive hints and explanations!

Phew, I was just about to set up the whole thing in my lab. Good
discussion, though! Glad you have it sorted out.

Cheers,
M