> 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 <mleech@ripnet.com<javascript:_e({}, 'cvml', 'mleech@ripnet.com');>
>>> 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment