Skip to main content
Visitor II
May 18, 2026
Question

VL53L0X Configuration

  • May 18, 2026
  • 1 reply
  • 67 views

Hello!

We use the VL53L0X as a time-of-flight sensor on a custom PCB. We used Arduino to configure and read the VL53L0X during development of our embedded system. Now later in development, we find differences between Arduino readings and readings taken from our Linux-based Embedded System (LES). I am investigating what differences exist between our Arduino application used during development and the application running on the LES. While not every sensor is showing shifts in range measurement, the worst case shifts are 6-7mm difference and repeatable.

I have collected all I2C communication with the VL53L0X from boot to when we enter the measurement loop for both Arduino and LES hosts. I see some differences and have investigated what I can, but I have a hard time understanding what exactly those differences mean without a register map and descriptions. I understand ST will not provide this information, so I am hoping you can instead provide any insight on my below questions. 

The main differences I see are when we read the SPAD map (registers 0xB0-0xB5) from the sensor during boot. My understanding is that ST does some calibration to account for part-to-part variation.Those calibration factors are stored in VL53L0X internal registers (0xB0-0xB5) and the host is responsible to read those values and store them. At what point are they used again, and why does the host need to store them? In our application we write them back to the same locations we read them from, although sometimes the data appears modified. The SPAD map configuration is currently my biggest source of confusion.

Another difference I've noticed is when we read the 0x83 register. No definition is given for what this address is, but we do some bitwise operations and write the data back to register 0x83. Could you briefly explain what this register is for?

Lastly, the final difference captured showed different data being written to the SYSTEM_INTERMEASUREMENT_PERIOD register and subsequent registers (0x04-0x08). This appears to be the delay between when one measurement ends and the next begins. I think this could be due to how sensor variation is handled as I don't see any source code to calculate a variable intermeasurement time. Can you confirm if the sensors provide values describing timing variation to account for part variability?

Beyond what I've described above, the Arduino and LES are operating the sensor in the same way, under the same conditions, in the same application. Any support would be much appreciated!

Kind Regards,

Brycen

1 reply

Technical Moderator
May 19, 2026

Hi:

According to my own understanding, about the SPAD,

for example, below 4x4 SPADS:

the cross one means bad SPAD that never be used; the others are all good.

the red circle means the SPAD where the signal energy is attenuated by 5 times;

the green circle means the SPAD where the signal energy is attenuated by 5 times.

Bin_1-1779187483627.png

Note: This is just an example, the real SPAD map is not like this.

 

1. registers 0xB0-0xB5

In example code, you can find below information. First read out all initial device information which includes the reference SPADS information. we can get the good or bad and type of each SPAD. 

According to the type of SPAD and its corresponding count, then decide whether to execute management or set directly.

Status = VL53L0X_get_info_from_device(Dev, 1);
 
/* set the ref spad from NVM */
count = (uint32_t)VL53L0X_GETDEVICESPECIFICPARAMETER(Dev,
ReferenceSpadCount);
ApertureSpads = VL53L0X_GETDEVICESPECIFICPARAMETER(Dev,
ReferenceSpadType);
 
/* NVM value invalid */
if ((ApertureSpads > 1) ||
((ApertureSpads == 1) && (count > 32)) ||
((ApertureSpads == 0) && (count > 12)))
Status = VL53L0X_perform_ref_spad_management(Dev, &refSpadCount,
&isApertureSpads);
else
Status = VL53L0X_set_reference_spads(Dev, count, ApertureSpads);
 
- read SPAD-related information from device internal data
- derive an applied SPAD configuration
- then write back a runtime SPAD enable map that is not necessarily a raw unchanged copy of the originally observed bytes
So, the data written to `0xB0–0xB5` can legitimately differ from the initially observed values if the API performs reference SPAD management.
The purpose of this step is to dynamically select the most suitable SPADS based on the current state of the scene as a reference.
 
2. Register `0x83`
This is a stroke/handshake/read gate register in the internal NVM/info read process.  Not a regular ranging service register.
 
3. VL53L0X_REG_SYSTEM_INTERMEASUREMENT_PERIOD
The default setting value of inter-measurement period is in DefaultTuningSettings.
you can use API VL53L0X_GetInterMeasurementPeriodMilliSeconds to readout and check.
At the same time, you can use API VL53L0X_SetInterMeasurementPeriodMilliSeconds and VL53L0X_SetMeasurementTimingBudgetMicroSeconds, to verify the relationship between Time Budget and Inter-Measurement period in the following drawing.
Bin_4-1779191257445.png
In general,
increasing the inter measurement period will allow decrease power consumption while keep maximum ranging capability.
Increasing timing budget will allow increase the maximum ranging capability and power consumption.
If the inter-measurement period is shorter than the timing budget, once the device completes the ranging, the next ranging starts immediately.

Best Regards,

Bin FAN


 

 
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.