VL53L0X timer issue

Hello, I am trying to get readings at 100hz from my vl53l0x sensor. To do that I need to use some sort of interrupt to tell me when I can start next reading, either timer based or interrupt pin (I am using the pololu library). I have looked at similar posts on the forum but cant find an answer to why im not getting faster speeds. The code I have posted here is me trying to use interrupt pin, but it only reads 20hz . Any help would be much appreciated,

#include <Wire.h>
#include <VL53L0X.h>
#include <TimerOne.h>
#include “RTClib.h”
RTC_DS1307 rtc;
VL53L0X sensor1, sensor2;// define objects for sensors
float distance;
const int GPIO1 = 2;
const int GPIO2 = 3;

void setup(){
Serial.begin(2000000);
rtc.begin();
Wire.begin();
pinMode (GPIO1, INPUT_PULLUP);
pinMode (GPIO2, INPUT_PULLUP);
pinMode(6, OUTPUT);
pinMode(7, OUTPUT);
digitalWrite(6, LOW);
digitalWrite(7, LOW);
//SENSOR
digitalWrite(6, HIGH);
sensor1.init(true);
sensor1.setAddress(0x30);
Serial.println(“set address 0x30 for first sensor”);
delay(100);
digitalWrite(7, HIGH);
sensor2.init(true);
sensor2.setAddress(0x31);
Serial.println(“set address 0x31 for second sensor”);
delay(100);
sensor1.setTimeout(500);
sensor2.setTimeout(500);
sensor1.startContinuous();
sensor2.startContinuous();
}

void loop(){
if(digitalRead(GPIO2)==LOW)
{
distance = sensor1.readReg16Bit(sensor1.RESULT_RANGE_STATUS +10);
sensor1.writeReg(sensor1.SYSTEM_INTERRUPT_CLEAR, 0x01);
Serial.println(distance);
}
}

This section of the data sheet seems to imply that the fastest readings you could expect would be 50hz, but I defer to the Pololu product specialist since I don’t know their library.

Hi, jonathanF.

As jlo said, the fastest speed supported by the VL53L0X is about 50 Hz (using a timing budget of 20 ms). To read at that speed, you need to call sensor.setMeasurementTimingBudget(20000); with our library to set the timing budget to that value. Could you see if adding that to your code makes it work for you?

Kevin

Yes, I now get readings at 50hz. I did however read a forum post (arduino.cc forum) where someone said that using the hardware interrupt pin would enable faster readings (100hz) because if the object was close to the sensor (<20cm) the GPIO would be triggered faster than the standard " High speed" mode. The same guy said he could run it even faster but then the sd card where he stored his data would become full too quickly. @kevin do you know anthing about this? If 50hz is max supported does that mean that it is possible to go 100hz unsupported=)

Yes, you’re right; if you use single shot mode (readRangeSingleMillimeters() in our library) or continuous back-to-back mode (startContinuous() with no arguments or an argument of 0), it should be possible for you to get the result early if the sensor doesn’t take the entire timing budget (which is really just an upper limit for the amount of time a reading can take). This behavior is supported by the sensor and our library even without the hardware interrupt pin; our library polls a status register on the VL53L0X to get the measurement as soon as it’s ready.

Kevin

Thank you @kevin. Do you mean that using only > Blockquote startContinuous(0) would be enough to poll as fast as possible and get above 50hz? Should I still use > Blockquote sensor.setMeasurementTimingBudget(20000); and is there anything else in the first post’s code block that I need to add to achive what you just described.

I think either startContinuous(0) or startContinuous() with no arguments should give you the readings as fast as the sensor can get them, and setMeasurementTimingBudget(20000) should work to set the time allowed for each reading to the minimum. The sensor will still try to take the full 20 ms if it needs to, so to maximize the possibility of getting faster readings, you should try to use large, highly reflective targets at short distances to maximize the strength of the return signals.

If you have trouble getting it to work, let us know and I can try to test it out here. (You might consider starting with just one sensor to avoid the added complexity of handling two.)

Kevin