Hi Marcus,

I have run some comparison tests between the C++ and Python versions of
"benchmark_rate", using a high sampling rate in order to force some
overruns.

It appears that both versions are detecting & reporting overrun events
correctly.  However, when it comes to the number of dropped samples, the
Python version always returns zero for the number of dropped samples.

Do you have any idea why this is the case?  Is the resolution of the timer
less fine-grained in the Python implementation perhaps?

Thanks,
Brendan.




On Tue, Apr 13, 2021 at 11:05 PM Marcus D Leech <patchvonbr...@gmail.com>
wrote:

>
>
> Sent from my iPhone
>
> On Apr 13, 2021, at 3:05 AM, brendan.horsfi...@vectalabs.com wrote:
>
> 
>
> Hi All,
>
> I am using a Python script to capture a short burst of rx samples from my
> B210. The script is based heavily on the Ettus example “benchmark_rate.py”,
> with a couple of additional tweaks I took from the Ettus GitHub repo (
> https://github.com/EttusResearch/uhd/blob/master/host/python/uhd/usrp/multi_usrp.py
> ).
>
> In my script I am calling my rx sampling function repeatedly using a “for"
> loop. Any errors that occur during sampling are stored in a
> uhd.types.RXMetadata() object, just like in the original Ettus script.
>
> Here’s the strange part:
>
> While the script is running, the letter ‘O’ is printed on the screen about
> 50% of the time, which I believe is an overflow warning from the Fastpath
> logger. However, the number of errors being detected by the RXMetadata()
> object is almost zero. How can this be?
>
> Some questions:
>
>    -
>
>    How seriously should I take the Fastpath ‘O’ warning? What does it
>    actually mean? Does it mean that this burst of samples will be
>    corrupted/incomplete?
>
> It absolutely means that samples were lost.
>
> The metadata should include time stamps that will allow you to compute how
> much was lost.
>
>
>    -
>
>    Why is the RXMetadata object not returning an error every single time
>    that the Fastpath logger does?
>
> This I’m not certain of.
>
> Thanks,
>
> Brendan.
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Reply via email to