On 04/13/2021 11:23 PM, Brendan Horsfield wrote:
Fair enough. To ensure that this problem is logged with the Ettus
engineering team, is there an official mailing list or email address
that I should report this bug to?
You can put an issue in the GitHub repository:
https://github.com/EttusResearch/uhd/issues
This is UHD4.0? So this may be a pybind11 issue with it correctly
packaging the metadata from the C++ layer.
On Wed, Apr 14, 2021 at 12:02 PM Marcus D Leech
<patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>> wrote:
That just sounds like a bug. The Python API is still considered
experimental.
Sent from my iPhone
On Apr 13, 2021, at 9:22 PM, Brendan Horsfield
<brendan.horsfi...@vectalabs.com
<mailto:brendan.horsfi...@vectalabs.com>> wrote:
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 <mailto:patchvonbr...@gmail.com>> wrote:
Sent from my iPhone
On Apr 13, 2021, at 3:05 AM, brendan.horsfi...@vectalabs.com
<mailto: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.
https://github.com/EttusResearch/uhd/issues
*
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
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email to
usrp-users-le...@lists.ettus.com
<mailto: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
