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 <sdtom...@yahoo.com> 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 <j...@ettus.com> > *To:* discuss-gnuradio@gnu.org > *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 Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
