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

[Philip Balister]

On 02/28/2012 11:51 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.

tunnel.py should be burned at the stake :)

This flow graph creates more bad press for gnuradio than anything else
in the world.

A good GSoC project would be to re-implement the flow graph in a real
grc flow graph and add all the cool new features in gnuradio to it.

Philip

> 
> I'm trying to do my fair share of research here and tackle it. If what you
> say is true, Marcus, the control I need is over the TX chain.
> 
> I did a bunch of reading through the UHD docs here:
> http://files.ettus.com/uhd_docs/doxygen/html/annotated.html
> 
> I see various controls using tx_streamer and tx_metadata_t to use tags to
> control samples to be part of a burst. Like, marking the start and end of
> my TX burst of samples which can construct a packet.
> 
> No prob, I can do that. But it seems like there needs to be some sort of
> UHD stream command which turns the TX chain in to an "on-demand" chain and
> not continuously streaming. On the other hand, I would like RX to be
> continuous.
> 
> I see the RX control to specify stream controls here:
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html
> 
> That is clearly documented as control of samples to the host to be
> continuous or not.
> 
> 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.
> 
> On Sunday, February 26, 2012, Marcus D. Leech wrote:
> 
>> **
>> On 02/26/2012 08:54 PM, George Nychis wrote:
>>
>>
>>
>> On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech 
>> <address@hidden<javascript:_e({}, 'cvml', 'address@hidden');>
>>> wrote:
>>
>>>  On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
>>>
>>> Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I
>>> do, is to start both the flowgraphs, and just listen for packets.
>>>
>>>  In which case, the TX side is running--even if you aren't sending any
>>> *data* bits, it's still transmitting, and blocking the receiver.
>>>
>>> You'll have to get more sophisticated about half-duplex flow management,
>>> using tagging to tell UHD to turn on/off the TX side.
>>>
>>> Josh probably has better words of wisdom on this than I.
>>>
>>
>>  Hi Marcus,
>>
>>  I'm working with Apurv, so I'm going to chime in here :)
>>
>>  I tried doing some searching on the mailing list, but I wasn't really
>> able to find much on this.  I also thought that auto tr would handle this.
>>  I found a post from Josh on the mailing list that said Auto TR is always
>> enabled in UHD.
>>
>>  http://www.ruby-forum.com/topic/1527488
>>
>>
>>   Yes, it is enabled in UHD.  But since Gnu Radio is a *streaming* model,
>> you need to take special measures to control TX from within a
>>   Gnu Radio flow-graph.  YOu need to insert a tag in the stream to control
>> the transmitter, otherwise, you'll be continuously streaming.
>>
>> What you do is insert a burst-tagger into your stream, and set it to send
>> the appropriate tags for UHD into the stream using the trigger
>>   input.  I just can't off the top of my head, remember what those stream
>> tags are at the moment.  But the basic issue is that Gnu Radio
>>   uses a streaming model, and while UHD itself (at the C++ level) has
>> fine-grianed control over transmitter functions, etc, gr-uhd doesn't
>>   directly expose any of that, because there's just not mechanism within
>> Gnu Radio to expose that stuff.  The stream tagging, however,
>>   does allow you to control the transmitter state.  In the particular case
>> of the XCVR2450, the hardware is physically incapable of
>>   TX and RX at the same time.
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio