On 20/04/2023 10:30, ja...@gardettoengineering.com wrote:
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
This question straddles the boundary between UHD and Gnu Radio.
In Gnu Radio tags arrive with an offset value that tells you which
sample within the buffer that was handed to you by the
scheduler the tag applies to. If you aren't accounting for that,
this may be the cause of the occasional confusion?
I'd suggest clarifying the tag behavior on the Gnu Radio mailing list.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
