Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Thank you all for your postings! I really appreciate your help in solving my problem. 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. I tried with bursts of 500 and even 50k. Same result as before, the carrier is still there. :-( ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 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? 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)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? 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 you’re 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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: ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 self.f_center = f_center = 1.47e9 ## # Message Queues ## blocks_message_sink_0_msgq_out = blocks_message_burst_source_0_msgq_in = gr.msg_queue(2) ## # Blocks ## self.usrp_sink = uhd.usrp_sink( device_addr=device, stream_args=uhd.stream_args( cpu_format=fc32, 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,1,1,1,1,0), False, 1, []) self.blocks_tag_debug_0 = blocks.tag_debug(gr.sizeof_gr_complex*1, , ); self.blocks_tag_debug_0.set_display(True) self.blocks_message_sink_0 = blocks.message_sink(gr.sizeof_gr_complex*1, blocks_message_sink_0_msgq_out, False) self.blocks_message_burst_source_0 = blocks.message_burst_source(gr.sizeof_gr_complex*1, blocks_message_burst_source_0_msgq_in) ## # Connections ## 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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: ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 self.f_center = f_center = 1.47e9 ## # Message Queues ## blocks_message_sink_0_msgq_out = blocks_message_burst_source_0_msgq_in = gr.msg_queue(2) ## # Blocks ## self.usrp_sink = uhd.usrp_sink( device_addr=device, stream_args=uhd.stream_args( cpu_format=fc32, 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,1,1,1,1,0), False, 1, []) self.blocks_tag_debug_0 = blocks.tag_debug(gr.sizeof_gr_complex*1, , ); self.blocks_tag_debug_0.set_display(True) self.blocks_message_sink_0 = blocks.message_sink(gr.sizeof_gr_complex*1, blocks_message_sink_0_msgq_out, False) self.blocks_message_burst_source_0 = blocks.message_burst_source(gr.sizeof_gr_complex*1, blocks_message_burst_source_0_msgq_in) ## # Connections ## 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. 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 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Hello Marcus, thank you very much for your hints! - 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 :) 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
On 21.10.2014 13:47, Frederik Wing wrote: Hello Marcus, thank you very much for your hints! - 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 :) 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. :( 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 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
- 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:) 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. :( 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? 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
On 10/21/2014 03:53 PM, Frederik Wing wrote: 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? 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gd 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]
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_sink_impl.cc#L659
On 21.10.2014 15:53, Frederik Wing wrote:
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
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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:
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
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
-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:
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:
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
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-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 Discuss-gnuradio@gnu.org
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-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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:mar...@hostalia.de]
Sent: Tuesday, October 21, 2014 1:24 PM
To: Nowlan, Sean; discuss-gnuradio@gnu.org; Martin Braun
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB
and EOB
-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:
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:
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
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-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 Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURparAAoJEAFxB7BbsDrLiT8H/0qUJ6qkMEgWdp7q1eKTr3Bm
hq4P6pIAXxXkmIRWVy+pn2uZ2zunvv0/2e/NcE4RMppuxTlT8HvjeKb0aKDMIxE2
spVqN/nuue5JSRAbQJIvI69jJytGgqzxvjY2EyWHSZPKtXB3Hc5a/PoMGY3EZb45
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üller [mailto:mar...@hostalia.de]
Sent: Tuesday, October 21, 2014 1:24 PM
To: Nowlan, Sean; discuss-gnuradio@gnu.org; Martin Braun
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.
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:
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
___ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
##
# Variables
##
self.tx_gain = tx_gain = 15
self.samp_rate = samp_rate = 20
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?
2) 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?
3) 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=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Marcus Müller
Sent: Tuesday, October 21, 2014 1:41 PM
To: discuss-gnuradio@gnu.org
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üller [mailto:mar...@hostalia.de]
Sent: Tuesday, October 21, 2014 1:24 PM
To: Nowlan, Sean;
discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org; Martin Braun
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
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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 On 10/20/2014 11:43 AM, Frederik Wing wrote: 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: ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 self.f_center = f_center = 1.47e9 ## # Message Queues ## blocks_message_sink_0_msgq_out = blocks_message_burst_source_0_msgq_in = gr.msg_queue(2) ## # Blocks ## self.usrp_sink = uhd.usrp_sink( device_addr=device, stream_args=uhd.stream_args( cpu_format=fc32, 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,1,1,1,1,0), False, 1, []) self.blocks_tag_debug_0 = blocks.tag_debug(gr.sizeof_gr_complex*1, , ); self.blocks_tag_debug_0.set_display(True) self.blocks_message_sink_0 = blocks.message_sink(gr.sizeof_gr_complex*1, blocks_message_sink_0_msgq_out, False) self.blocks_message_burst_source_0 = blocks.message_burst_source(gr.sizeof_gr_complex*1, blocks_message_burst_source_0_msgq_in) ## # Connections ## 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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: ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 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. Any further ideas? Can someone reproduce this behaviour? Frederik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
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 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 ## # Variables ## self.tx_gain = tx_gain = 15 self.samp_rate = samp_rate = 20 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. Any further ideas? Can someone reproduce this behaviour? Frederik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
