VL53L0X TOF sensor (#2490) timing

I have successfully connected two of the sensors to an A-Star micro and can read reasonably accurate distance information from both, certainly adequate for my project. I do have some timing questions regarding the Pololu Arduino library (GitHub pololu/vl53l0x-arduino/VL53L0X.cpp).

In my project, I have to be reasonably sensitive to the amount of time spent waiting for a sensor reading to become available so I can take the appropriate actions based on the absence or presence of “obstacles” detected by the two sensors. If I interpret the data sheet and the implementation of your library correctly, I’m likely to be able to get readings faster using continuous mode. [Q1] DO YOU THINK THIS IS TRUE?

Further, if I understand the implementation of method VL53L0X::readRangeContinuousMillimeters correctly, once called, it will loop until a reading is available from a sensor. Thus, the method is “blocking” from the perspective of my program using the library. So, since I need to read both sensors, I’ll make two “blocking” calls. Thus with default timing budgets, it take be up to 66 ms to get readings from both sensors. [Q2] IS THIS ASSERTION CORRECT?

I believe I could avoid blocking by implementing a new method in the VL53L0X class nominally called “checkForReadingAvailable()” that would read the status register once and return the status. I believe by calling the “ready” method for both instances my program could in effect determine how and when to “block”, either waiting for both sensors to be ready and then calling readRangeContinuousMillimeters, which will not block, for both sensors, or in fact going off and doing other things for several ms before checking again. Depending on things somewhat out of my control, this approach could still take up to 66 ms, but would more likely get closer to the minimum of 33 ms. Of course, I’d have to copy and modify the library to do that, but I anticipate no problems doing so. [Q3] DOES THIS SEEM REASONABLE?



The continuous mode should result in a higher measurement frequency and the individual measurements should be quicker. You are also correct about our VL53L0X::readRangeContinuousMillimeters method being a blocking function. Checking the status register seems like a reasonable approach, but if you have hardware interrupt pins available on your microcontroller, you might also consider looking into the interrupt functionality of the GPIO1 pin on the VL53L0X. Also, if you want to try sacrificing some accuracy for faster readings, you can look at how we enable high-speed mode in our “Single” example (which basically just calls the setMeasurementTimingBudget function).