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 >> <mle...@ripnet.com<javascript:_e({}, 'cvml', 'mle...@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
