[Top][All Lists]

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

Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
Date: Mon, 05 Mar 2012 19:39:17 -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

Sorry, I dont know anything about the burst tagger. But I can tell you about the stream tags that I guess burst tagger is producing. Basically in the gnuradio framework, arbitrary metadata can be associated with a sample, aka sample tags. When the scheduler calls work in the uhd sink block, work looks for any start/end of burst tags and timestamp tags. UHD sends packets of samples into the USRP. Each packet can have metadata associated with it (burst flags, times). The job of the work function is to slice the stream up such that the tag metadata gets setup to go out with the metadata for the packet of samples. So burst tagger should only be causing 1 start of burst tag and 1 end of burst tag. The start of burst is sort of optional as far as the hardware cares. Mostly, you want to communicate end of burst when there will be no more data. -josh
The way the burst-tagger appears to work is that it watches the trigger input, and when that trigger input changes state, it inserts the
   tag corresponding to the new state into the stream.

That sounds *almost* like what is needed, except that in a GRC flow-graph, data will continue to flow after the EOB tag has been
  inserted, which won't really make things happy.

On 02/27/2012 05:30 PM, George Nychis wrote:
It's be good if you can chime in here, Josh :)

It seems like this is something that should be fixed about tunnel.py in
future GNU Radio releases for use with UHD.

Like removing it altogether :-)

That is clearly documented as control of samples to the host to be
continuous or not.

Basically, RX is intended to work on a continuous streaming model, which
is why stream command inst swigged up. The start()/stop() methods are
actually the ones issuing the command.

When and if the pmt based message passing gets merged, i was going to
implement control messages to deal with streaming, possibly other
things. This lets you tie the uhd source block into a control plane.

As is stands now, i guess someone could just forward the stream command
stuff, so long as the work() function knew to block when there is
definitely not supposed to be samples. That way you avoid the scheduler
marking the block done on a timeout.

However, I don't see that same control for the TX stream. Tx_metadata_t
t_streamer control the bursts, but don't seem to control the overall
stream? Maybe I am missing something.

You can use stream tags to control start/stop of burst and transmit
times. See the usrp sink header or the tags demo in gr-uhd.

Now that being said, the framer blocks in tunnel.py could be more
intelligent and properly shutoff streaming (aka end a burst) when there
is no data. That way you avoid underflow when there isnt a continuous
supply of data to modulate.


Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

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