VL53L0X GPIO Interrupt did frequent / irregulary not trigger and unexpected trigger when no target present

[BGrie.1]

I have invested a lot of time and find no solution: I use two VL53L0X sensors in a custom board design with an ESP32 and use of the ST-Library functions.

The usage of the GPIO Interrupts did not work as expected, because frequently / irregulary they did not trigger even if they should, because the detected object hit the trigger condition. I have written a check function where I can see, that the sensor measures and reports the correct distance, the correct DeviceMode (Continous), the correct trigger condition (TresholdLow or High), correct PalState (Running), no error.... , but did not raise the GPIO Interrupt (ClearInterruptMask was executed before...).

In general I know, that my design and functions are working, because in 60 -80% of the trigger situations everything works as expected:

• the system is configured with VL53L0X_DEVICEMODE_CONTINUOUS_RANGING, LOW and HIGH-triggers are set and everything is cleared
• usually the system waits for a VL53L0X_GPIOFUNCTIONALITY_THRESHOLD_CROSSED_LOW with 100mm Treshold.
• after trigger detection the trigger is NOT cleared and nothing changed
• after 100ms a manual re-check ("debouncing") of the trigger condition is carried out with VL53L0X_GetRangingMeasurementData
• if the trigger condition is still ok - the measurement is stopped, Interrupt mask cleared, VL53L0X_SetGpioConfig(...VL53L0X_GPIOFUNCTIONALITY_THRESHOLD_CROSSED_HIGH..) with the predefined Treshold_high 150 mm and the measurement is started again to detect the leaving of the object.
• after the next trigger the procedure goes the same way only with "reverse signs"

If the problem with the not firing trigger occurs it's mostly in the Threshold_Crossed_High condition, but also in the ..Low.

I'm wondering especially, when I read all relevant data from the sensor in such a situation, that it shows the correct measurements and configuration, but did not set the GPIO and InterruptMask?!?? My actual workaround is to restart the sensor with XShut - but this cannot be the way ...

My second concern is the GPIO/Interrupt-behaviour when there is no target present, because the trigger fires as he wants with no comprehensible method - so it is useless. To clarify - in my test setup I have added a wall behind my sensors - so that the maximum distance and readings are about 400mm , but this is also a limitation I don't want to have ...

I hope for some help because I have invested a lot of time and I'm at the end of my skills and patience ...

[John E KVAM]

I doubt the sensor's issue is that it doesn't interrupt.

It's far more likely that there is something about your target that is causing the sensor to get erratic data.

In these cases I ask people to remove the wait-for-interrupt and get all the range data. Does that data match your expectation?

One can use the Evaluation kit to do this. Put it where you expect your device to be. You can then test (with interrupts and without) that the system can work. This would eliminate any physical issue.

It will also tell you if all the measurements are accurate enough.

One problem is that the sensor averages all the photons that it gets back.

So if your target does not fill the field of view, the sensor will average the photon times from the target and the wall.

In this condition you will "over-range".

If your max distance is 40cm it really should be fine.

But have a look and make sure the data is as you expect.

It really should work.

One other thought ... are your distances particularly short? The VL53L0X has an issue with really short targets returning ranges that are too long. (The light reflects off the target, and echos several times. This leads to over-ranging. )

Could that be the problem?

And the last thoght I had was how fast is your target moving relitive to the timing budget you have? If it's moving quickly you are still going to get the average of all photons but I expect the data will be very erratic.

• john

[BGrie.1]

Hi John,

thank you for the fast answer and your thoughts.

I will test the behaviour without the GPIO-interrupt on bare range-data. (I wantet to avoid this because it makes some additional work in my setup ...).

The absolute accuracy of the measurements is not so important for me - I already know that my different sensors have different inaccuracies between 30 and 60 mm depending from the range. I only need "some repeatability", because I can align the trigger tresholds as required. This is also one reason for my "debouncing" resp. "hysteresis" between treshold low and high, because I need a reliable information about "object is in range" and "object is out of range".

In my test-setup I use a cardboard or my hand as target and move it right-angled in front of the sensor - within the lower trigger treshold. This the object cross from one side into in the field of view and disappear also to the side. The speed is really "not fast", but as mentioned in my post most of the errors are happening at trigger treshold high - what means the target is disappearing out of the sensor view. The slower my object is (very slow) - the better it is - but on the one hand not good enough and on the other hand - this is not my use case. When I move the target normal to the sensor in its measurement direction it becomes better - there are less errors but still a lot.

The relation of the objects size to the field of view is not so bad (I think) - an envelope or hand in 80 mm distance. This is my lower area for my use case and only now used for testing. In reality I want to adjust my lower treshold between 100 and 300 mm and treshold high between 150 and 500 mm. And as mentioned - it should work without background (resp. the background can be far away).

If you agree(?) I don't see a good reason for the malfunction until now, but I will change -as suggested by you- for testing the interrupts to range readings - and then I will be back (as Arnold Terminator says... 😉

Bernd

[BGrie.1]

Hi John,

as announced I have changed for testing my GPIO-Interrupt function to a polling function on base of range-data readings:

• as already in my previous solution: the basic setup at startup makes some testing with range readings and range status evaluations when there is no object but only the background present -> all readings are ok with a spread of <15 mm for 10 measurements (with getSingleRangingMeasurement) at ca. 400mm, range-status is 0 or 2, VL53L0X_Error is 0
• the sensors are configured with VL53L0X_SENSE_DEFAULT,  VL53L0X_SetGpioConfig(... VL53L0X_DEVICEMODE_CONTINUOUS_RANGING, VL53L0X_GPIOFUNCTIONALITY_NEW_MEASURE_READY, ...) and measurements startet with VL53L0X_DEVICEMODE_CONTINUOUS_RANGING
• for trigger start each sensor gets one RTOS-Task where I loop over VL53L0X_GetMeasurementDataReady() (with 10ms delay between the loops) ->   VL53L0X_GetRangingMeasurementData() -> VL53L0X_ClearInterruptMask() -> (a lot of) Error checking and printing -> Check of the trigger conditions -> next loop

The observations are:

• It runs as wanted and shows the expected range measurements with range status 0 or 2 and VL53L0X_Error 0
• When I move in the object I receive the expected trigger and also when I remove it
• frequent I have in the situation at moving the object in or out one (or two) loops with errors which can be
  • from VL53L0X_GetMeasurementDataReady -> Error -6 (Range error) (most frequent) or too many loops (more than 200) (not so often)
  • from VL53L0X_GetRangingMeasurementData -> RangeMillimeter >8190 or RangeStatus 4 (Phase Fail)
• after such errors the function is usually as before without resetting something, but sometimes I have some hundred RangeMillimeter >8190 before the correct measurements are coming back ..?!?

On this basis the physical situation seems to be ok for me - but the basic probems with the GPIO-trigger are still there.

Hope you can help based on this analysis, because the polling - solution is not ok for the final project. If you need more analysis or information - please let me know.

Bernd

[John E KVAM]

Interesting.

The sensor will only generate the interrupt if the range is STATUS=0. That might explain why you miss some.

if the RangeMillimeter >8190, then you got a STATUS != 0.

Status =6 ?? Really? The user manaual does not have a 6. I'm not sure how you got that. can you give me the version number of your software??

A statud=2 is 'signal fail'. if you get this the number of photons returned was not big enough to 'see' the target.

and if you can't get a range on an object once, it will happen repeatedly until something changes.

As an experiment, use a white piece of paper to replace your target. White printer paper is 88% reflective and you will get a good range on it unless there is a lot of motion. Use this to prove you get an iterrupt at the right time. ('m bettting you will.)

While you still have the prints available, keep track of the status you are getting in various conditions.

Remember -

0 - Range Valid - Ranging measurement is valid

1 - Sigma Fail - Sigma fail will trigger particularly in ambient light, when the amount of ambient light is adding too much noise onto the ranging measurement.

2 - Signal Fail - Signal fail will trigger when the return signal is too low to give enough confidence on the range measured. The limit will be given by either the signal limit or the RIT (Range Ignore Threshold).

3 - Min Range Fail - Not enabled as default.

4 - Phase Fail - Phase fail will trigger when wraparound conditions are detected or when noise on signal is too high.

5 - Hardware Fail - Hardware Fail will trigger if a VCSEL failure, or VHV fail are detected.

If you want more ideas you are going to have to describe your envionment. threshold distances, target description, ambient light conditions.

There has to be something causing the status !=0 that we have to figure out.

• john

[BGrie.1]

Hi John,

the status -6 did come from VL53L0X_GetMeasurementDataReady() (NOT from VL53L0X_GetRangingMeasurementData()) and the function VL53L0X_GetPalErrorString() returns for -6 "Range Status" - (do I make a mistake with that?). In the meantime I have replaced the function VL53L0X_GetMeasurementDataReady() with a check of the Interrupt-Pin and it seems to run "smoother" than before, because with the function I see in the Osci relative different time slices for the measurements and with use of the GPIO-interrupts from VL53L0X_GPIOFUNCTIONALITY_NEW_MEASURE_READY they are more even.

RangeStatus 2 is the most seen Status, 0 is only shown when I hold my object (it is a white cardboard) very short in front of the sensor. For my understanding from reading your manuals - RangeStatus 2 only shows a lower quality or confidence level of the signal, but the result can still be used. Also I read nowhere that the trigger can only be used with RangeStatus 0 - and this would be a problem.

What I have read in the user manual UM2039 on page 21: "Note: There is no interrupt generated if no target is detected in threshold high mode (with any threshold value)." -> this behaves totally different in my setup - without background and no target the interrupt fires like he wants ...?!??

I still need your help - is it an good idea to show a photo or video (is this possible here?)??

Bernd

[BGrie.1]

Hi,

here are two screencasts to show my setup and the situation. (I hope it's understandable, - I never made a screencast before ...).

The first video shows the setup and the behaviour with polling of the sensor data.

The second video in the next message shows the behaviour with GPIO-interrupts. (it's only possible here to add one file...)

Hope you find a solution with these informations.

Bernd

[BGrie.1]

second video with GPIO interrupt mode

[BGrie.1]

No idea? - no help?? - Is anybody out there???

[John E KVAM]

I'm really sorry. I answered your query, but it appears my answer was not posted. I have no idea how that could be.

If you are getting a lot of '2' errors you can adjust the the Range Ignore threshold (RIT)to so that is less likely. But be a little careful. If you lower it too much, the coverglass crosstalk will generate a 'ghost' image.

But as your issue is a very bright target at very close distance you might solve your issue by increasing teh RIT.

At short distances the VL53L0X has a problem. The light goes out, hits the target and reflects. But a lot of the light reflects off the target and 'echos'.

The sensor then gets a distance that is too long.

So at 2cm you will get 2 cm, but at 1 cm, you might actually range 3 cm.

This effect will happen with really reflective targets - like white paper.

If this is occuring, the solution is to back the sensor up so that your target cannot get too close,