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

[Frederik Wing]

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

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