VL53L1X sensor fail to measure

[Mcabe.1]

Hello,

I want to measure distance with VL53L1X connected to ESP32. I can read correctly vl53l1x reference registers and I initialize without problem but i can't read measures.

I want to get readings by polling.

This is my code:

---------------------------------------------------------------------------------------------------------------------------

VL53L1_RdByte(Dev, 0x010F, &byteData);

VL53L1_RdByte(Dev, 0x0110, &byteData);

VL53L1_RdWord(Dev, 0x010F, &wordData);

status = VL53L1_WaitDeviceBooted(Dev);

status = VL53L1_DataInit(Dev);

status = VL53L1_StaticInit(Dev);

status = VL53L1_SetPresetMode(Dev, VL53L1_PRESETMODE_AUTONOMOUS);

status = VL53L1_SetDistanceMode(Dev, VL53L1_DISTANCEMODE_LONG);

status = VL53L1_SetMeasurementTimingBudgetMicroSeconds(Dev, 140000);

status = VL53L1_StartMeasurement(Dev);

 do{

 status = VL53L1_GetMeasurementDataReady(Dev,&byteData);

 if(byteData == 1){

        status = VL53L1_GetRangingMeasurementData(Dev,&RangingData);

        printf("Ranging data status: %u\n",RangingData.RangeStatus);

        printf("Ranging data: %u\n",RangingData.RangeMilliMeter);}

 status = VL53L1_ClearInterruptAndStartMeasurement(Dev);

 vTaskDelay(140 / portTICK_PERIOD_MS);

 }while(1);

---------------------------------------------------------------------------------------------------------------------------

The status of every function is 0 until VL53L1_GetRangingMeasurementData(Dev,&RangingData) function, where the return status is -13, VL53L1_ERROR_CONTROL_INTERFACE.

This is how I show the return stuts of every functions:

---------------------------------------------------------------------------------------------------------------------------VL53L1X Model_ID: EA

VL53L1X Module_Type: CC

VL53L1X: EACC

status boot: 0

status DatInit: 0

status StaticInit: 0

status SetPresetMode: 0

status SetDistanceMode: 0

status SetMeasurementTimingBudgetMicroSeconds: 0

status StartMeasurement: 0

data ready GetMeasurement: 1

status GetMeasurement: -13

Ranging data status: 255

Ranging data: 4294967295

data ready GetMeasurement: 0

status GetMeasurement: 0

---------------------------------------------------------------------------------------------------------------------------

As you can see, in the first polling, the status of GetMeasurement function is -13, the flag os dataready is 1, but the measurement is wrong. After that, in all pollings, GetMeasurement status is 0 but data is never ready.

[John E KVAM]

I wish I had one answer, but I don't.

Things to check - in no particular order:

1) If you I2C cable is long, the bus can 'glitch' making the I2C communication fail. If this happens the CLK like will be stuck low.

2) Check to see if the sensor is ranging. You cannot see the flash, but your laptop camera can. Or use your cell phone. But IPhones will not work. They have an IR filter on them.

if you don't see the continuous flash of light the sensor never got started.

3) check the I2C communication looking for a byte-swap or word-swap issue. The early commands only do byte communication. But the important commands use words and even longwords. It's easy to get those wrong. I attached a bit of code you can insert to verify your communications. You might need to tweak it a bit to get the Dev right, but it's pretty simple code.

4) A status of 255 is a catch all for an undetermined error. So one can only guess that some of the initial parameters were wrong.

[John E KVAM]

If what you want to do is simple ranging as in your code above, you might consider using the UltraLite Driver for the VL53L1X.

the code does less, but it's a lot smaller and will enable you to do the simple ranging as in your example above.

I've also enclosed an AppNote on the I2C_verification.

[Mcabe.1]

I verify I2C and every function is OK. I tried UltraLite Driver and I have the same problem

[Mcabe.1]

I have check that when the I2C buffer is large, as 135 bytes for example, VL53L1_ReadMulti() can't read. It fails exactly when it writes register address in I2C, before reading values.

[John E KVAM]

​We do write a large 135 byte buffer and some processors don't like it. It's a small matter to break up the write into manageable chunks in the write_mult() and read-multi() function itself.

Sorry about that. Being from ST, I only checked the write_multi() on the ST processors I had and the RaspberryPi. Both those worked, so I called it good.

Sorry about that.