Measuring Multiple vl53l4cd on single i2c line

[TomBaker1993]

I am currently implementing a series of  vl53l4cd sensors into a project.

These work really well and I am able to address these individually on one shared i2c line.

These sensors are working perfectly fine on this shared line when measured independently but when an object is blocking both sensors, the readings speed up and the readings of both sensors becomes much less accurate and noisy.

Is there a specific approach to reading sensor data from both sensors simultaneously?

As a test I did move one of these sensors onto another i2c line, and the issue continued. I originally thought it was congestion on the i2c line but it clearly isn't and may be the way I am getting the distance data from both sensors.

I am using the Arduino library - https://github.com/stm32duino/VL53L4CD/

I have attached a video which should hopefully show what I am seeing. The yellow line is one sensor and blue is the other. 

Thanks  

[John E KVAM]

unless you have to be extremely quick about it, would you consider trying to keep your sensors out of sync?

You could create a timing budget of 30ms and an intermeasurement period of 60ms, giving a 50% duty cycle. Then start the sensors out of phase. This is a guaranteed solution. 

If you have a target farther away, do you still get the issue? 

We don't see much interference, unless the sensors are close - but with a near, reflective target side-by-side sensors are the same as close.

I'm sorry for the issue, I'm guessing you are just seeing too much light.

- john 

[TomBaker1993]

Hi John,

Sorry for the late reply on this - that has certainly seemed to help the problem. 

Although I am now seeing another issue, which I wonder if it is related or if you have seen this before? 

I have the two sensors sharing the same i2c line, and I use the following to create a detection distance of 600mm. 

uint8_t status = sensor_vl53l4cd_sat_left.VL53L4CD_SetDetectionThresholds(200, 600,3);

This works perfectly when only a single sensor is used but when using two sensors I get intermittent readings outside of that 600m range. As I say this is intermittent, with it only doing it sometimes.

Any ideas what could be the cause of this?

Video attached to show the issue.

[John E KVAM]

Are the sensors pointing toward each other? Or both looking at the same mirror? Generally they don't interfere but if you have a short integration time and they are close, you might get an odd number or two randomly.

- john

[TomBaker1993]

Hi John,

No - facing in opposite directions. For that exact reason of stopping interference I have placed a divider to ensure it’s not rogue readings. 

[John E KVAM]

You said the answers 'speed up'. The sensor has a timing budget and an inter-measurement period. It cannot 'speed up'. But if you are only plotting data with a good RangeStatus, you could get more interrupts. 

I see a lot of 'up and down' motion. I'm guessing that's your hand. Quick motion does cause an issue with our anti-aliasing filter. If the first half of the range does not match the second half, we would through a Warning error 4. 

If you know the result is from motion, you can use the data. But most people do not out of caution. 

I'm guessing you are losing data points due to that error 4, so it appears to be going slow.

try moving your hand slower. Does that cause the data to be more stable. 

Lets do this:

At each interrupt, put in some code that looks like this. By knowing the time and status on each result, you can figure out what is going on. (You might try getting the deltas between calls to GetTick, or you can do the math in your head when you look at the data.

VL53L4CD_GetResult(dev, &results);

printf("ms = %ld,Status = %3u, Distance = %5u mm, Signal = %6u kcps/spad\n",

HAL_GetTick(),

results.range_status,

results.distance_mm,

results.signal_per_spad_kcps);

[TomBaker1993]

Hi John,

The speeding up of data received has been resolved with your initial answer and a  50% duty cycle.

The issue I am facing now is that I set the threshold to 600mm so it doesn't read any values outside of that distance but get intermittent readings higher than that when using two sensors. This shouldn't happen. 

These sensors are facing in opposite directions with no way for the sensors to interfere with each other. Is this an interrupt related issue do you think?

Thanks

Tom

[John E KVAM · Accepted solution]

No - it is not related to the hardware interrupt. The sensor is really pretty basic. It gets a result; decides what kind of interrupt you have set and triggers the interrupt based on your setting. 

The only thing I can think of is you got the interrupt from sensor A and perhaps read the result from Sensor B. 

If B had a range result greater than 600, it would NOT have triggered the interrupt, but if you read the sensor data anyway, it would return the valid range data. 

- john