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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
