UHD stream tagging

GNU Radio
1

Hello,

I’m working on project in gnuradio, in which I’m trying to toggle onand
off the transmission from the USRP. After much research, Ilearned this
was done by tagging the first sample of a transmissionwith “tx_sob” and
the last sample with “tx_eob” (there was also a"tx_time" tag, but I
found the former option more convenient). Iwrote a custom block that
periodically tags segments out of continuousstream of data as a proof of
concept; however, the transmissionremains continuous as if there were no
tag. I’ve checked with the tagdebugging block to ensure my block
acutally generates tags. My flowgraph is simply: file
source(repeat)->custom tagging block->pskmod->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

2

I tried a similar thing but got the same result as you did!

Would love to get some help. Anybody?

3

The burst tagging won’t cause the USRP to stop transmitting – it tells
the
USRP not to expect any more samples, but any delay logic must be
implemented in your code.

On Sat, Feb 8, 2014 at 12:14 PM, Miki Lustig - KK6MRI
<[email protected]

4

Someone correct me if i’m wrong, but the PSK mod won’t propagate stream
tags.

5

You can also do precisely timed burst to stream conversion in
pure-software which is a bit more portable
For one example of how to do this using gr-eventstream tools see the
transmitter in

-Tim

6

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

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

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 :slight_smile: ) 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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium