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

[Frederik Wing]

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