Maximum Inter measurement period of VL53L1X

[MFran.4]

The title says it all. I can't find the info on any of the three documents i read (Datasheet/Api/ULD Api).

Thank you

Mirco

[MFran.4]

Anyone?

[John E KVAM]

In the ultra-light driver, the code is below. It shows, as input, a unsigned 16 bit value in ms. So 65536/1000 is 65 seconds.

But if you are willing to play a little bit you see the sensor's register is an 32 bit value in milliseconds * the ClockPLL. Assume the clockPLL is 0x3ff (its max)

Also there is a 1.075 offset to handle the case were the fast clock and the slow clock are skewed.

So if you want to modify the code, you can enter (4 billiion/0x3ff)ms. , to bet a staggeringly large number. But you'd have to verify the accuracy of the timing however.

I've not tried it.

The current code handles 64 seconds, and we figured that was enough.

VL53L1X_ERROR VL53L1X_SetInterMeasurementInMs(VL53L1_Dev_t dev, uint16_t InterMeasMs)
{
	uint16_t ClockPLL;
	VL53L1X_ERROR status = 0;
 
	status = VL53L1_RdWord(&dev, VL53L1_RESULT__OSC_CALIBRATE_VAL, &ClockPLL);
	ClockPLL = ClockPLL&0x3FF;
	VL53L1_WrDWord(&dev, VL53L1_SYSTEM__INTERMEASUREMENT_PERIOD,
			(uint32_t)(ClockPLL * InterMeasMs * 1.075));
	return status;

The quick change to the code would be to put a *1000 in line 9. That would change the input from ms to seconds. Then you could do your own testing.

Don't forget to change the 'get' function as well.

[MFran.4]

Thank you!

I'll try.

[John E KVAM]

Well, that is hard to tell. I would have set the timing budget and the intermeasurement period and then issued the start.

What I think is getting you is that this sensor runs asynchronously. It generally does not stop the nanosecond you issue the stop, but after the current range ends. So I'm guessing your commands might not have been processed. But it's hard to tell.

From a rebooted sensor do he setup and issue the start. You should see something close to 10seconds.

At the very least put some waits between your commands.

Or you can issue the intermeasurement command without stopping, but it will not take effect until after the next range finishes.

• john
•  

[MFran.4]

Hi, turns out it was a problem about types.

My uint32_t value was always truncated in a uint16_t value, hence the low intermeasurement time with high values.

Changing the uint32_t typedef in vlxxxx_types.h should solve my problem.

Thank you for your time! I wouldn't have checked if you didn't assure me that the sensor could sleep a lot:grinning_face_with_sweat: