# Transmitting bursts with GRC by inserting SOB and EOB **URL:** \ **Category:** GNU Radio\ **Created:** [October 20, 2014, 11:48am UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649 "2014-10-20T11:48:09Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [October 20, 2014, 11:48am UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/1 "2014-10-20T11:48:09Z")
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. ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 20, 2014, 1:42pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/2 "2014-10-20T13:42:25Z")
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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 20, 2014, 5:57pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/3 "2014-10-20T17:57:47Z")
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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 20, 2014, 11:31pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/4 "2014-10-20T23:31:39Z")
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 🙂 > > 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 😉 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](http://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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 2:41pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/5 "2014-10-21T14:41:32Z")
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. > > ☹ 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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 3:09pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/6 "2014-10-21T15:09:30Z")
> > > > > for UHD_and_ 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. ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 1:52pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/7 "2014-10-21T13:52:08Z")
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 🙂 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 😉 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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 3:18pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/8 "2014-10-21T15:18:26Z")
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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 3:57pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/9 "2014-10-21T15:57:44Z")
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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 4:53pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/10 "2014-10-21T16:53:42Z")
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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 5:09pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/11 "2014-10-21T17:09:46Z")
-----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----- ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 7:20pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/12 "2014-10-21T19:20:43Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)** ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 7:25pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/13 "2014-10-21T19:25:29Z")
-----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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) -----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----- ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 7:30pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/14 "2014-10-21T19:30:51Z")
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. ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 7:42pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/15 "2014-10-21T19:42:10Z")
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:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] > Sent: Tuesday, October 21, 2014 1:24 PM > To: Nowlan, Sean; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); Martin B. > Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by > inserting SOB and EOB ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 22, 2014, 10:05am UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/16 "2014-10-22T10:05:40Z")
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. ☹ > > > ``` > > > 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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 22, 2014, 12:13pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/17 "2014-10-22T12:13:01Z")
> 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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 21, 2014, 8:20pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/18 "2014-10-21T20:20:16Z")
> > ``` > > ################################################## > > > > ``` > > ``` > > # 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) [[mailto: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: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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:removed_email_address@domain.invalid] > Sent: Tuesday, October 21, 2014 1:24 PM > To: Nowlan, Sean; ``` [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); 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](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ``` > _______________________________________________ > Discuss-gnuradio mailing list > removed_email_address@domain.invalid > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ``` ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 22, 2014, 3:43pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/19 "2014-10-22T15:43:07Z")
> > 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 ---
**Author:** ![Frederik\_Wing](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/b5ac83/32.png) [@Frederik\_Wing](https://www.ruby-forum.com/u/Frederik_Wing)\ **Post date:** [October 23, 2014, 2:32pm UTC](https://www.ruby-forum.com/t/transmitting-bursts-with-grc-by-inserting-sob-and-eob/232649/20 "2014-10-23T14:32:18Z")
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