VL53L0X Divide by Zero error in API

[RMill.3]

Hi all,

Got a divide-by-zero exception whilst porting the API to the ESP32. The error occurs at line ~1960 in vl53l0x_api_core.c in this bit of maths:

    		sigmaEstRef =
                VL53L0X_isqrt((cDfltFinalRangeIntegrationTimeMilliSecs +
                    finalRangeIntegrationTimeMilliSecs/2)/
                    finalRangeIntegrationTimeMilliSecs);

Here is where finalRangeIntegrationTimeMilliSecs comes from (a few lines before)

		finalRangeIntegrationTimeMilliSecs =
			(finalRangeTimeoutMicroSecs + preRangeTimeoutMicroSecs + 500)/1000;

All values there are UINT32. It might be a problem with my porting, or how the ESP32 treats rounding, but finalRangeIntegrationTimeMillis = ( 0 + 53 + 500) / 1000 which the platform interprets as 0. Has anyone had this error before?

I've fixed this for the time being by checking for a zero value (and setting to 1) before doing the isqrt. The device seems to work pretty well, though I am getting sigma error response when reading measurements. I've only got a single module so not sure if this behaviour is related to the above.

Curious how this error has occured - both finalRange and PreRange seem to be taken from the device configuration - called after DataInit()

		/* Calculate final range macro periods */
		finalRangeTimeoutMicroSecs = VL53L0X_GETDEVICESPECIFICPARAMETER(
			Dev, FinalRangeTimeoutMicroSecs);
		/* Calculate pre-range macro periods */
		preRangeTimeoutMicroSecs = VL53L0X_GETDEVICESPECIFICPARAMETER(
			Dev, PreRangeTimeoutMicroSecs);

Can anyone give suggestion what I'm doing wrong? Or Is this a genuine bug in the API?

[mkuma.2]

Hi Team,

I am also facing this issue ,Could you please help us out?

[John E KVAM]

A sigma error means the averaged data is so uncorrelated that the sensor is warning you that the answer is suspect. It has nothing to do with your timing bug.

It has more to do with what the system is seeing.

But I think the major problem is that you are failing to get the correct number of milliseconds.

Getting the time is always a porting problem. You need to understand how your clock counting functions work on your machine.

In the VL53L0_i2c_platfform.c file there are 2 functions:

int32_t VL53L0_get_timer_frequency(int32_t *ptimer_freq_hz)

{

    *ptimer_freq_hz = 0;

    return STATUS_FAIL;

}

int32_t VL53L0_get_timer_value(int32_t *ptimer_count)

{

    *ptimer_count = 0;

    return STATUS_FAIL;

Note they are not populated in the delivery. One needs to fill those out or the time counter will not work.

and once you can count milliseconds, your problem will go away.

I hope.

• john

[mkuma.2]

Hi Jhon,

Probably you are right for VL53L1 sensor,where VL53L1_GetTickCount is used some part of the Core API.

In VL53L0x driver, cannot find VL53L0x_get_timer_value and VL53L0x_get_timer_frequency/ is never seem to be used in core api.

Also

pRangingMeasurementData->TimeStamp = 0; /* Not Implemented */

Could you please help us understand the scenario?