Re: [Discuss-gnuradio] UHD stream tagging

[Marcus D. Leech]

On 02/08/2014 02:37 PM, Price, Nathan D. (S&T-Student) wrote:
> Hello,
>
> I'm working on project in gnuradio, in which I'm trying to toggle on and off the transmission from the USRP.  After much 
> research, I learned this was done by tagging the first sample of a transmission with "tx_sob" and the last 
> sample with "tx_eob" (there was also a "tx_time" tag, but I found the former option more convenient). 
>  I wrote a custom block that periodically tags segments out of continuous stream of data as a proof of concept; however, 
> the transmission remains continuous as if there were no tag.  I've checked with the tag debugging block to ensure my 
> block acutally generates tags. My flow graph is simply: file source(repeat)->custom tagging block->psk 
> mod->multiply const->uhd sink.
>
> Reading in the archive, I haven't found reference to success much success with 
> the streaming API. I would love the community's input on this problem.
>
> Thanks,
> Nathan
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
The basic issue is that TX_EOB doesn't mean what you think it means -- 
it's mostly just a way to let the hardware know not to expect any more
  samples.

In particular, it doesn't cause the TX synthesizer to shut-down because 
many folks what phase-continuity across multiple bursts, so the synthesizer
  is left running, and if you have non-zero samples still flowing after 
TX_EOB, there'll still be stuff coming out the TX port.

The main "disconnect" is that GNu Radio is a streaming architecture, and 
UHD supports that, but also supports a much-richer interaction model
  that doesn't really fit "perfectly" with Gnu Radio, so gr-uhd does 
the best job it can.  Many folks who want to do stuff with UHD that doesn't
  fit the Gnu Radio model use UHD directly (a significant fraction of 
Ettus customers do things this way).  While UHD has "grown up" alongside
  Gnu Radio, its architecture and interaction model aren't necessarily 
a "fits like a glove" thing.

I'd suggest looking at the tx_bursts.cpp example in the UHD examples to 
see how bursts are managed.  In particular, the hardware itself can't
  really "know" what your channel access model is, so it's up to you to 
crank the TX gain down to zero, and stop sending samples after a
  TX_EOB, if that's what you want to happen.

Something that I recall getting discussed (and perhaps Martin can chime 
in here, since I think gr-uhd is you baby now :) ) was to have gr-uhd
  start dropping incoming samples on the floor when it receives a 
TX_EOB tag, and go into a "waiting for further instructions" mode, in 
particular
  perhaps waiting for a TX_SOB.  But in concert with that the app 
really needs to crank down the TX gain, and insert zeros if it isn't 
going to
  stop sending samples.  This can be hard to orchestrate within the 
confines of GRC, but in the full-fledged expressiveness of the Python or C++
  APIs to Gnu Radio, it should be fairly easy.





--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org