[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Expected behavior during underruns

From: Thomas Tsou
Subject: Re: [Discuss-gnuradio] Expected behavior during underruns
Date: Tue, 14 Dec 2010 21:00:32 -0500

On Tue, Dec 14, 2010 at 6:34 PM, Josh Blum <address@hidden> 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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]