On Fri, 2011-05-20 at 07:34 -0500, LRK wrote: > On Thu, May 19, 2011 at 03:34:09PM -0700, justynnuff wrote: > > > > Nick Foster-4 wrote: > > > > > > I think your transmit side is fine. The .wav source should be > > > unthrottled. The receive side is where you're going to run into trouble. > > > > Indeed you're right. Upon further research, I realised that nothing > > throttles the Tx side but the USRP. So, according to my previous math, all > > I need is 128Msam/sec / interpolation > 2.8MHz. > > Am I missing something here? The "transmitter" should be a source and > multiplier to get the carrier frequency to the USRP and throttled by > the USRP sink. There should be no underruns. The audio file should > be throttled to it's bit rate and used to modulate the "carrier". Thus > the modulation bit rate should be recovered at the demodulator in the > receiver and right to feed a soundcard. The two-clock problem should > only be between the soundcards. If there is a audio source rather than > a file, it should throttle the modulation at it's own rate.
No throttle. Rule of thumb: never use throttle on real hardware, only on flowgraphs that don't use a soundcard or a USRP or anything else that has its own clock. In this case, you upsample, not throttle, the audio to whatever you set the USRP sample rate to. The two-clock problem exists between the soundcard clock and the USRP clock, because they use separate crystals for clock generation. It won't exist on the transmit side of the flowgraph since he's using a .wav source and not the mic input. The underrun in the transmit flowgraph is due to something else, probably sample rates not being matched somewhere. You can check your receive flowgraph by writing to a .wav sink instead of an audio sink. --n > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
