On 02/08/2014 02:37 PM, Price, Nathan D. (S&T-Student) wrote:
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
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
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
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
stop sending samples. This can be hard to orchestrate within the
confines of GRC, but in the full-fledged expressiveness of the Python or
APIs to Gnu Radio, it should be fairly easy.
Shirleys Bay Radio Astronomy Consortium