From: Josh Blum <address@hidden>
To: Tom Hendrick <address@hidden>
Cc: "address@hidden" <address@hidden>
Sent: Thursday, January 24, 2013 2:36 PM
Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
On 01/24/2013 04:07 PM, Tom Hendrick wrote:
> Thank you Matt and Josh for the suggestions.
>
> When I look at the output of the RF connector with an oscilloscope,
> when there are underruns the signal is randomly broken up with gaps
> even though I am flushing out data packet by packet to GNURadio. Is
> adding an SOB and EOB tag to the burstthe only way to fix the
> breaking up of the signal? The underrun messages themselves do not
> bother me.
>
In a bursty transmission like this, underflow messages can only be fixed
by setting EOB. When an underflow happens, the USRP remains in transmit
state for some time window rather that switching at the EOB. If you are
relying on some sort of antenna switching, then this could be an issue
if you are receiving from the same device.
> I thought the underruns from the USRP would happen only between
> sending
packets so there would only be random gaps in the signal
> between the packets not inside the packet itself. What I'm seeing is
> random gaps inside of the data blocks of a packet causing detection
> issues on the receiver side. Without the underruns I don't see this.
> I will look into the SOB and EOB tags as suggested but thought I
> would ask if the behavior I saw was expected.
>
The underflows should only happen in places where the device is starved.
So probably in between packets of data from your source. So I wouldnt
expect random gaps in the middle of useful data.
-josh
> Thank you, Tom
>
>
>
> ________________________________ From: Josh Blum <
address@hidden> To:
> Tom Hendrick <
address@hidden> Cc: Matt Ettus <
address@hidden>;
> "
address@hidden" <
address@hidden> Sent:
> Wednesday, January 23, 2013 1:52 PM Subject: Re: [Discuss-gnuradio]
> Unknown cause of Latency with USRP
>
>
>
> On 01/23/2013 02:29 PM, Tom Hendrick wrote:
>> Hello Matt, I went back and tried your suggestion of setting the
>> transmitter at 50kbps and keeping the ffmpeg stream at 45 kbps.
>> This actually gets rid of almost all the latency buildup however
>> the problem is that the transmit GRC script running the USRP is
>> now consistently giving underruns
errors. This is causing the
>> received video signal to have a lot of distortions.
>>
>> It seems like the video stream rate has to be lower than the
>> transmit/receive rate like you suggested but then this causes a
>> problem because the USRP seems to not get the samples fast enough
>> to avoid underruns. I'm not sure if there even is a solution to
>> this that I could easily implement with GRC.
>
>
> In this case you are sending finite bursts of samples. A burst
> should end with an of burst tag when its known that there are no more
> samples available (for example). This tell the USRP TX machinery not
> to expect more samples, otherwise, it generates an underflow
> message.
>
> Technically GRC is agnostic to this because its just connections.
> The block feeding the gnuradio stream should probably be
generating
> this. There is an example of this in the pre-cog link I sent you
> (does it in python). Also, c++ example:
> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++/
>
> -josh
>
>>
>> Thanks again, Tom
>>
>>
>>
>>
>> ________________________________ From: Tom Hendrick
>> <
address@hidden> To: Matt Ettus <
address@hidden> Cc:
>> "
address@hidden" <
address@hidden>;
>> "
address@hidden" <
address@hidden> Sent: Wednesday, January 23,
>> 2013 10:40 AM Subject: Re: [Discuss-gnuradio] Unknown cause of
>> Latency with USRP
>>
>>
>> Hello Matt, The ffmpeg encoder is set to 45 kbps bitrate and the
>> transmitter/receiver is set to about 45 kbps as well. The ffmpeg
>> encoder doesn't converge at 45 kbps exactly, but it comes close.
>> The signals are sampled at a pretty high rate of 500 kHz and the
>> GRC scripts resample at 1 MHz so the USRP is run at 1MS/s rates.
>> Thank you, Tom
>>
>>
>>
>>
>> ________________________________ From: Matt Ettus <
address@hidden>
>> To: Tom Hendrick <
address@hidden> Cc: "
address@hidden"
>> <
address@hidden>; "
address@hidden"
>> <
address@hidden> Sent: Wednesday, January 23, 2013 10:34
>> AM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with
>> USRP
>>
>>
>>
>>
>> What is the bit rate of the source and what is the bit rate of the
>> data transmission?
>>
>> Matt
>>
>>
>>
>> On Wed, Jan 23, 2013 at 10:32 AM, Tom
Hendrick
>> <
address@hidden> wrote:
>>
>> Hello Josh,
>>> The transmitter sends data when there is enough to fill a
>>> packet. The packets are flushed about every 200msec consistently.
>>> The ffmpeg encoder seems to have a continuous output that is
>>> pretty steady since it is encoding webcam images at a pretty
>>> reasonably constant bitrate with the settings I applied.
>>>
>>> When I look on the oscilloscope output of the USRP tx board, the
>>> stream shows no gaps or pauses at all and the packets look
>>> spaced properly in time as if I had written the transmitter
>>> output directly to a file.
>>>
>>> Are the solutions you recommended something I can try
>>> implementing with
GRC (for instance throttle or the gr_block
>>> api)? Making the external modulator/demodulator work in a burst
>>> type mode is something I probably don't know how to do. I know
>>> how to run the
>> modulator/demodulator code but I didn't develop it. The only thing
>> I can think of adjusting is the amount of data blocks inside a
>> packet. I can increase or reduce that number and that would
>> increase/decrease the time duration between flushing of packets.
>>>
>>> Thanks very much for your help, Tom
>>>
>>>
>>>
>>>
>>>
>>>
>>> ________________________________ From: Josh Blum <
address@hidden>
>>> To:
address@hidden Sent: Tuesday, January 22, 2013
>>> 10:54 PM Subject: Re: [Discuss-gnuradio] Unknown cause of Latency
>>> with USRP
>>>
>>>
>>>
>>>>
>>>> I appreciate any advice. I'm out of ideas and have searched a
>>>> lot on latency related to GNURadio and most of the latency
>>>> I've read up on seems to be in the microsecond to millisecond
>>>> ranges.
>>>>
>>>> Thanks very much, Tom
>>>>
>>>>
>>>
>>> Does the application that produces transmit samples send bursts
>>> of samples only when there is data to send, or is the
>>> transmitter always being fed?
>>>
>>> I ask because gnuradio can potentially have a lot of
buffering,
>>> and if your transmit app is producing continuous samples or
>>> producing samples faster than the rate consumed, the buffering
>>> will just become full, and it will take buffer_size/sample_rate
>>> seconds to see a change occur through the pipeline.
>>>
>>> If this is the issue, I recommend some kind of bursty
>>> transmission. Some neat examples of this in precog
>>>
https://github.com/jmalsbury/pre-cog/wiki>>>
>>> If you need to continuously transmit, you might want to maintain
>>> a window of buffering where the application throttles back
>>> production of samples. One way to do this would be to simply use
>>> the consumption of rx samples to throttle the production of tx
>>>
samples.
>>>
>>> Another alternative would be to use the gr_block api to shrink
>>> the buffer size of each block in the transmit chain -- to
>>> minimize the capability of gnuradio buffering data -- if the app
>>> must rely on backpressure from gnuradio
>>>
>>> -josh
>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
address@hidden >>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>>
>>>
>>> _______________________________________________ Discuss-gnuradio
>>> mailing list
address@hidden >>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>
>>>
>>>
>>> _______________________________________________ Discuss-gnuradio
>>> mailing list
address@hidden >>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>
>>>
>>
>>
>>
>> _______________________________________________ Discuss-gnuradio
>> mailing list
address@hidden >>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>