VL53L4CD: Measurement and Consumption Issues

[cvlt]

We are having issues with the VL53L4CD Time of Flight Sensor.

The sensor works properly after initialization, but after some measurements it starts having problems. 

It either stops ranging or returns a ranging result similar or equal to the previous one, while returning data ready TRUE and ranging OK (Results status 0).

Here's a description of what happens when the sensor still ranges but gives wrong results (second case):

- We take an initial ranging (distance from an object)
- We move the sensor away from the object
- We ask for a ranging: the result is similar or equal to the initial measure.
- Now we move the sensor away again
- We ask for a new ranging: the result is the one we expect after the first movement.

Some detailed info:

- The sensor initialization is copied from the "ranging basics" example attached with the drivers.
- We changed the interrupt to active high by changing the value of register 0x30 in VL53L4CD_DEFAULT_CONFIGURATION (VL53L4CD_api.c)
- We set timing budget to 50ms and intermeasurement time to 0

This is pseudocode for our sampling function, very similar to the "ranging basic" example:

1. Wait 5ms
2. VL53L4CD_StartRanging

3. Wait 90ms

4. VL53L4CD_CheckForDataReady
5. If DataReady
    5.1. VL53L4CD_ClearInterrupt
    5.2. VL53L4CD_GetResult

6. VL53L4CD_ClearInterrupt
7. VL53L4CD_StopRanging

Between two samplings (call to the sampling function) the sensor is NOT reinitialized with VL53L4CD_SensorInit.

I also attach power profiling screenshots of the two situations (sensor stops ranging and sensor gives incorrect measurements).

Best Regards,
Claudio

[John E KVAM]

I never liked that 'ranging_basic' example. It leaves out the call that configures your timing budget and your inter-measurement period. And you need to know those. 

Set the Timing budget to 30ms and the inter-measurement period to 100ms. You should see a nice clean plot of high power for 30ms and 70ms of low power when you start ranging. 

But you really need one more thing. You need either a poll of 'are you done yet?" or a wait for interrupt. 

With your code you don't know if 10 ranges have finished or none. 

And that's leading to your latency issue. 

And you should not need to re-initialize the code. 

After a start_ranging, you can call stop_ranging and then call start_ranging whenever you need to. 

- john

[cvlt]

Hi John,

first of all I want to thank you for taking care of our issue, and for replying so soon.

I found a new version of the driver that solves an issue with StopRanging and the interrupt pin; I downloaded the one we were using in April... and this issue is the reason we were not using the GPIO1 PIN and changing its configuration.

I then tested your suggestions, and the sensor works as expected. I will test it for the next days to see if our issues are definitely solved.

Now, your message left me with some doubts:

But you really need one more thing. You need either a poll of 'are you done yet?" or a wait for interrupt. 

Isn't this what the CheckForDataReady function is for? We are using that.
Anyway, now that the GPIO1 Pin works, I'll probably use that.

It leaves out the call that configures your timing budget and your inter-measurement period.

I am configuring them. I think my message wasn't clear because the values that I'm setting are the default ones also set by SensorInit.
Still, with the sensor working properly, it make sense to set intermeasurement time different from 0 even if I want to do one-shot samplings:
- Because if we use the interrupt Pin we are sure that a measure is ready;
- and in the meanwhile, before we clear the interrupt or stop ranging we are saving power as ranging is suspended.
Do you agree?

[cvlt · Accepted solution]

Hi, in the end I found that updating the driver solved the issue.