Hello Fabian, Commands which are late will be executed anyways and return the error notification which you are seeing. Commands after it are also executed. Depending on your application it is often possible to structure the commands such that get_time_now only needs to be called in the beginning and the act of receiving can be used to keep track of the device time. The TwinRX fast frequency hopping example does this, allowing for continuous and stable frequency hopping and burst receiving at a very high rate.
Regards, Derek On Thu, Jun 7, 2018 at 12:12 PM, Fabian Schwartau via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi everyone, > > I am currently working with timed commands to perform synchronized > reception of multiple channels. As the timing is quite critilical I would > like to use quite low delay I add to usrp->get_time_now() for the next > command(s). However, sometimes it happens (even with quite high values like > 20ms) that I get an late command error when reading the data from the > stream. I guess this can happen from time to time if the thread was > interrupted by the OS to do other stuff. And this is not a problem, if it > happens just from time to time. But I don't know how to handle the problem. > Is the command that was too late executed anyway? What about the commands > after that? > Is there is simple way to get in a clean state after receiving this error? > Like delete all commands in the queue and clear all buffers? > > I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are > synchronized over all boards. > > Best regards, > Fabian > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
