Unable to get distance measurements from VL53L3CX

[NSack.1]

I'm using an ESP32 to communicate with the VL53L3CX. I successfully reworked the vl53l3cx_platform.c file to get communication working with the sensor using I2C, which is a good start. But when I go to read from the sensor (using polling, not hardware interrupt mode) I can't seem to get any valid measurements.

The status of the readings mostly alternates between 4 and 5, with an occasional 14. I see plenty of negative distance measurements. But unfortunately, not status readings of 0 indicating that the reading is valid (not that I'd expect negative distance readings to be valid). Screenshots of logs are at the bottom of the post.

I do not perform any calibration for now as I'm just trying to get some initial readings. Could this be the problem? I wasn't sure if the sensor must be calibrated before measurements can be successfully collected.

My code works as follows:

1. Initialize I2C code
2. VL53LX_WaitDeviceBooted
3. VL53LX_DataInit
4. VL53LX_StartMeasurement
5. VL53LX_GetMeasurementDataReady
6. Once ready, VL53LX_GetMultiRangingData
7. VL53LX_ClearInterruptAndStartMeasurement

I loop through steps 5-7.

As you can see in the screenshots, the Stream Count (displayed as Count) does not increment as expected either. To explain more terms in the logs, Status refers to the RangeStatus, D is RangeMilliMeter, Signal is SignalRateRtnMegaCps, and Ambient is AmbientRateRtnMegaCps.

Let me know if I can clarify anything, and thanks in advance for any help!

[John E KVAM]

First thing is to verify that your porting of the I2C is correct.

My rule is that if you see a negitive distance, you have a byte-swap isssue.

Take the code in the attachment below and call in just after you initialize the chip.

validate the print-outs.

Once this works you can remove the code.

The first line reads the ModelID, ModuleType, RevID, and ModuleID starting at 0xC0.

These 4 bytes are then combined in big-endian format to build the expected_value.

The rd_write_verification() function reads the same 4 bytes using all possible I2C access mechanisms and compares the result to the expected result.

The rest of the code executes the other write mechnisms and compares the read results to the expected. 

[Julien NGUYEN]

Hi NSack.1

It is a good start that you have been able to modify the platform files to adapt to the ESP32. The problem, you have, looks like read/write register issue. After the step 1, please check if you get a correct Chip ID (0XEAAA) before to continue.

 VL53LX_RdByte(Dev, 0x010F, &byteData);

 printf("VL53LX Model_ID: %02X\n\r", byteData);

 VL53LX_RdByte(Dev, 0x0110, &byteData);

 printf("VL53LX Module_Type: %02X\n\r", byteData);

 VL53LX_RdWord(Dev, 0x010F, &wordData);

 printf("VL53LX: %02X\n\r", wordData);

Julien

[NSack.1]

Thank you both for the quick response! I did some more digging yesterday with the logic analyzer and it turns out the original issue was in fact with I2C (I misinterpreted the datasheet with 0x52 as the 7 bit device address, not the address already bit shifted).

But now that I am successfully communicating with the sensor I'm still having issue with range measurements.

@John E KVAM​ The I2C Test successfully runs and passes. The only discrepancy is for the first read, but I believe that's because the ModelID is different for the VL53LX (0xEEEA) compared to the sample code with VL53L1X (0xEACC). Please see the first attached image, but it all looks good to me, so I don't think it's a byte swap issue, but I could still be mistaken.

@Julien NGUYEN​ That is a great idea- I've added Chip ID verification to the initialization code and successfully receive 0xEAAA now.

The issue I see now is that, although the distance measurements are not negative, they remain unchanging and have status values of 4 and 12. The Signal and Ambient values too remain constant. Oddly enough the count continues incrementing to 255 and when it rolls over does not go to 0, but rather rolls over to 128. That does strike me a potentially a byte swap issue, but since the I2C test code works as it should I'm not sure where/how it could be happening.

I don't think this should change anything, but in terms of functionality the initial test code only delayed 1 ms before checking if data was available; for readability I delay 1s after every measurement occurs before calling VL53LX_ClearInterruptAndStartMeasurement.

I feel like I'm getting close, but am missing something.

EDIT: Repositioning the sensor and reinitializing communication and I'm starting to get more varied results. Still a lot of readings with status 4 and 12, and occasionally 7, but also some valid readings with statuses of 0 thrown in for good measure. I'm still seeing the weird wraparound for stream count. It starts at 0 and increments as it should, but after it hits 255 it goes to 128 before increasing. When I do get successful readings with a status of 0 it seems pretty arbitrary, mostly statuses of 4 and 12. So something is still very inconsistent.

[bully]

Hello,

any update on this? We're also getting same distance, no matter what.

ID registers are read correctly... 

Is there any working example/docs how to work with this sensor?

Thanks,

regards.