[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] UHD stream tagging

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] UHD stream tagging
Date: Sun, 09 Feb 2014 20:27:24 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 02/08/2014 02:37 PM, Price, Nathan D. (S&T-Student) wrote:

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.


Discuss-gnuradio mailing list

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]