Moses, software doesn't run at fixed rates. Instead, you keep track of how many samples you've transmitted. If you're underrunning, then your software design is slower than the hardware clock of your USRP. In your case, you're also not signaling an "end of burst" (also you're copying fcpxIQ instead of passing a reference, and the clear() call at the end seems misplaced).
I recommend you familiarize yourself with the UHD examples, such as tx_waveforms. They will get you started. From there, you can take your lessons learned and integrate them into your software. Cheers, M On Thu, Jan 6, 2022 at 4:17 PM Moses Browne Mwakyanjala <[email protected]> wrote: > Hi everyone, > I'm experimenting with a C++ standalone USRP transmitter using the > function shown below. The data is generated by another function called > Modulate() which "posts" the modulated IQ samples to this function. The > transmitter works very well for burst transmissions (individual packets). I > was wondering how to do transmission in a continuous way. I mean, the > Modulate() function depends on the CPU clock while the actual transmission > is dictated by the rate of the USRP. I did try to send blocks of samples > (10,000) continuously and the USRP was reporting underruns. How do I make > sure my functions run at the same rate as the USRP? > > voidUSRPDriver::TransmitIQ(std::vector<std::complex<float> > fcpxIQ){ > //assert(1 ==0); > if(m_bDeviceUp){ > if(DEBUG) > std::cout << "USRPDriver::" << __func__ << "Transmitting IQ Frame > Size = " << fcpxIQ.size() << std::endl; > // setup metadata for the first packet > uhd::tx_metadata_t md; > md.start_of_burst = false; > md.end_of_burst = false; > md.has_time_spec = false; > md.time_spec = uhd::time_spec_t(1.5); > // the first call to send() will block this many seconds before > sending: > double timeout = 10.0; // timeout (delay before transmit + padding) > tx_stream->send(&fcpxIQ[0], fcpxIQ.size(), md, timeout); > fcpxIQ.clear(); > } > } > > > Regards, > > > Moses. >
