Re: [Discuss-gnuradio] Unknown cause of Latency with USRP

[Tom Hendrick]

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. 

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