Two VL53L1X sensors influencing their measurements

[MPehi.1]

Hello!

I am using two VL53L1X Time of Flight sensors and the setup is working fine - I am getting measurements from both sensors after successfully changing their I2C addresses.

So far so good.

What is interesting, however, is when the two sensors face each other! I put them at a distance of 50mm from each other and then plotted the measured distances over the timestamps. The measurements show very interesting disturbances! As if the sensors are "ping-pong"-ing each other. Their measured values jump sometimes to 6000+ mm! (See attached pdf)

An array of sensors will be mounted on two individual RC-cars to achieve collision avoidance over the entire radius of the car. It might happen so that two sensors influence each other when they come in sight of each other.

Can you please suggest a way to mitigate this effect?

Thank you!

Mihail

[John E KVAM]

Our contention that they don't interfere is based on a longer timing budget. My guess from your application is that you want to run with as short a timing budget as you can.

so first thing to try is dig more information out of the sensor.

Read the Ranging status. My guess is those 6000's will give you an error status.

Read the ambient light level. If nothing else, that light level will jump through the roof when the cars get closer.

You might be able to use that characteristic.

To get true ambient and true signal level, you need to take into account the number of SPADs used to collect the data.

True ambient = (ambient/SPADs) *200 (This will give you a normalized number to use in you comparisons.

True Signal = (signal/SPADS) *200

Between the status, the ambient, and the signal level you should be able to get a good idea of what is going on.

Good luck,

• john

[MPehi.1]

Thank you for the quick response! I will get back to you with new results!

[MPehi.1]

Dear John,

​

I have had the opportunity to use the information presented in your answer.

​

Firstly, what you suggested -- reading the Ranging status -- was 100% correct. When the two sensors face each other, tthe ranging status code is usually either 7 or 4!

​

I have a couple of questions regarding to the true ambient and signal rates, however.

1. Why is the (ambient rate/SPADs) multiplied by 200? What I mean is - what is hiding behind this magic number 200? If it were the total number of available SPADs, wouldn't it be 256 (16*16 SPAD array)?
2. Looking at the VL53L1X_api.c (using the ULD - ultra lite driver), there exists the function VL53L1X_GetAmbientPerSpad() (and VL53L1X_GetSignalPerSpad() respectively), which returns (ambient/SPADs) *2000; (not 200!). It is very similar to the equation you suggested.

Can you please elaborate on the true ambient and true signal values, please? Any information where I could find an explanation of these values is also highly appreciated.

Kind regards,

Mihail

[MPehi.1]

Dear John,

I am reposting my follow-up question as a reply to my original question, as I have not received a response from your side to my reply!

​

I have had the opportunity to use the information presented in your answer.

​

Firstly, what you suggested -- reading the Ranging status -- was 100% correct. When the two sensors face each other, tthe ranging status code is usually either 7 or 4!

​

I have a couple of questions regarding to the true ambient and signal rates, however.

1. Why is the (ambient rate/SPADs) multiplied by 200? What I mean is - what is hiding behind this magic number 200? If it were the total number of available SPADs, wouldn't it be 256 (16*16 SPAD array)?
2. Looking at the VL53L1X_api.c (using the ULD - ultra lite driver), there exists the function VL53L1X_GetAmbientPerSpad() (and VL53L1X_GetSignalPerSpad() respectively), which returns (ambient/SPADs) *2000; (not 200!). It is very similar to the equation you suggested.

Can you please elaborate on the true ambient and true signal values, please? Any information where I could find an explanation of these values is also highly appreciated.

Kind regards,

Mihail

[John E KVAM]

sorry for the slow reply - I miss emails sometimes. Sorry about that.

there are 256 SPADs, but some are occluded to solve a high signal rate return problem. So 200 is a reasonable number to use for Max number of SPADs.

(You might see 211 as the max number of SPADS, but that differs chip to chip.)

This sensor returns the total signal rate, but to get a real idea of the signal return we need to know how many SPADS were enabled.

You could create and use Signal per SPAD, but that number is pretty low. Multiplying by 200 just gets in into a handy range.

Ouch. I wrote the GetAmbientPerSpad() function and it should have been 200. I'll have to look at that.

There really is no 'right' answer here. As long as your values are self consistent the signal you record for different distances and materials will give you the information you need.

• john

[MPehi.1]

Thank you very much for your response!

The takeaway for me is that the values for the signal and ambient rates for different measurement conditions (surface, lighting, etc.) should be experimentally determined, correct?

Are there any general guidelines for what values to expect for a measurement, besides the maximum values of their data types (uint16_t)?

Please disregard my question if it is considered off-topic: would you consider uploading the ULD to GitHub/GitLab so that developers can contribute to the driver code? Potential software faults, which could lead to computation errors would be caught earlier and fixed with a pull request!

Thank you once more, your insight is very helpful!

Mihail

[John E KVAM]

In general the signal strength will go down with distance. However mirrors and reflective tape return so many photons, that rule of thumb is not universal.

Specular (mirror-like) surfaces behave quite differently than lambertian (textured) surfaces. Human skin reflects between 40 and 61% and does not correlate to the 'color' of the skin for instance.

Wool reflects amazingly well, cotton fleece not very well at all.

And I think publishing the ULD on GitHub is a great idea.

I'll see what I can do.

(Big companies are like that.)

• john

[MPehi.1]

Dear John,

I am writing after quite some time to inquire about the status of the VL53L1X ULD.

In particular, is there a decision about whether the driver will be put up on GitHub/GitLab?

Otherwise, I would be interested in knowing if the ULD download has been updated to reflect the changes we discussed (ambient/SPADs) *2000; (not 200).

Kind regards,

Mihail

[MPehi.1]

Hello John,

I'd be happy to know whether there have been any news regarding to porting the VL53L1X ULD driver to GitHub?

Kind regards,

Mihail

[John E KVAM]

Mihail -

In the mad dash for the next product (VL53L3 - just released) and improvements to existing ones (VL53L1CB - due out very soon) and then the totally new technology (VL53L5 - due out in Q1 next year) I find there just doesn't seem to be any time left over to think about github and the UltraLite Driver.

I've not done it and I'm afraid I'm the only one who was considering it.

Sorry about that.

• john