Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronise getDistance and getRangeStatus #43

Open
hb020 opened this issue Dec 26, 2020 · 2 comments
Open

Synchronise getDistance and getRangeStatus #43

hb020 opened this issue Dec 26, 2020 · 2 comments

Comments

@hb020
Copy link

hb020 commented Dec 26, 2020

getDistance and getRangeStatus go together. No use reading getDistance if one does not know the range status, as the status will tell if the distance read is valid or not.
However, in the SDK they are 2 separate calls.
When in continuous mode, therefore, it is not always clear if the values that are read pertain to the same sampling.
This can be tested easily:

s1 = ds->getRangeStatus();
d = ds->getDistance();
s2 = ds->getRangeStatus();
if (s1 != s2) { .. signal error or ignore... }

When continuous mode is enabled, over time, you will get this error, especially if the reading conditions are bad.
It is not uncommon to have the following sequential readings
distance X, status 2
distance Y, status 0
distance Z, status 2

where X,Y and Z are each totally different from each other
In that case, with the present lib configuration, it is possible to read distance X or Z, status 0, what would be wrong.

It is best to read the related registers all at the same time from the device, as can be found in some of the other VL53L1X libs, as in the reference implementation STSW-IMG007.

@jimtng
Copy link
Contributor

jimtng commented Feb 1, 2022

@hb020 could you point me to the other libs which implemented reading the related registers at the same time?

@hb020
Copy link
Author

hb020 commented Feb 1, 2022

In the end I went with the "VL53L1X" pololu lib. It has less functionality as far as I remember, but does read correctly (see VL53L1X::readResults). I guess some others also can do the job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants