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

[Josh Blum]

On 03/01/2012 11:14 AM, George Nychis wrote:
> A quick question on how the trigger works in UHD.  I have some basic code
> integrated with the help of your suggestions.
> 
> Burst tagger port 0 is the raw complex sample stream.  Burst tagger port 1
> is the trigger.  Let's say the raw complex sample stream has an outgoing
> packet.  I'm assume that I change the value on port 1 that corresponds to
> the first sample of the preamble to a value of '1': which is the trigger
> like "hey, here is the start of the burst!"  My question is, for *all*
> indexes on port 1 that correspond to samples in the packet on port 1,
> should those also be of value 1?  Or only just the first sample?  What
> about the last sample?
> 
> Just trying to understand exactly how the trigger works.
> 

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

> 
> On Mon, Feb 27, 2012 at 9:12 PM, Josh Blum <address@hidden> wrote:
> 
>>
>>
>> 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
>> and
>>> 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.
>>
>> -Josh
>>
>