Thank you Marcus, that is helpful. I have restricted my testing to just an N320, and only freq changes for now. I have run across something else that is odd though (but has major ramifications for my blocks). Most of the time there are no drops and everything is fine, but here is an example of what I occasionally see:
* I have an N320 running at 100Msps at freq X, all is running smoothly * I issue a freq change command, and based on time tags, see that it occurred 10.2s after the last time tag (for example) * When I see the new time tag, I count the number of samples between them as see that I have 1020.2e6 samples * But if I compute what I would have expected, it should be 1020e6 samples * That means that I have more samples than I would have expected (200 in this example). I didn't drop samples, I gained some? That doesn't seem right. A third anomaly I see is that I go through the steps above, but compute that I am missing 7 samples. But if I am watching the screen, I don't see any overflows printed. Since it is such a small number, it makes me feel like it is a rounding error somewhere. But if I make that assumption and ignore it, what is the threshold for when it is no longer rounding errors, but is an actual drop? Is there any way to get the O/D flags into the stream from the USRP source block within gnuradio? TIA
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
