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

[Tom Hendrick]

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