On Tue, Dec 14, 2010 at 6:34 PM, Josh Blum <[email protected]> wrote: > >> Our observations shows also that the usrp2 doesn't drop any samples >> when an underrun occur. If we drop samples at the host, can we get a >> continous stream of sample at 25Msamp/s that is synchronous? What is >> your maximum continous bandwidth? >> > > Underflows occur on transmit, nothing can drop because this is a lack of > samples.
If I understand correctly, the transmit situation that Patrik describes is behaviour _after_ the underflow. For a continuous stream, the effect to subsequent samples is an added time offset - equal to the duration of the underflow - relative to the original start of the stream. For certain real-time applications, paired spectrum TDMA for example, this makes underruns devastating. In these cases, samples that were supposed to be transmitted when the underrun occurred, but didn't for whatever reason, are irrelevant and need to be dropped rather than transmitted best effort. AFAIK, the only way to currently handle this is to catch the underrun at the host and drop a handful of packets so that the next start-of-burst reaches the USRP2 ahead of the deadline. >> I've been looking in the source code and tried to find out where to >> implement the sample dropping. My thoughts so far is that it should >> be somewhere in vrt_packet_handler.hpp and/or io_impl.cpp in the send >> functions and get_send_buffs function. >> > > Is there something that you think the streaming API is missing please > let me know. I think you can accomplish what you need with the API > without modifying the underlying implementation. I agree. Poking around the guts is a bad place to start and unnecessary. The OpenBTS USRP2 implementation uses get_time_now() to resync the host when an underrun occurs. Obviously, you shouldn't bother sending a packet if the difference between usrp time and the transmit timestamp is negative or near zero. http://github.com/ttsou/openbts-uhd/blob/master/public-trunk/Transceiver/UHDDevice.cpp Thomas _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
