Hey, Having some issues with the VL53L4CX. Can anyone help me out?
I am trying to use many of these sensors in a line simultaneously, they work separately fine however when they are working together the sensors don’t give results.
Hi Jeremy,
I’d be happy to help, if you could provide a picture of your setup and the code you are running that would be much appreciated.
1 Like
Hey Jack thanks for your response!
I’m working on a project that involves using an array of 16 VL53L4CX sensors to measure both the X and Y coordinates of objects in front of the array. I aim for a loop time of less than 50ms and have set a 1MHz I2C clock. Currently, I am able to read from all sensors in approximately 33ms on average.
Initially, I faced an issue where, without waiting for measurements, I would get around 12 proper readings followed by 12 no-object detections consistently. To address this, I implemented the blocking function VL53L4CX_WaitMeasurementDataReady(). This resolved the issue of inconsistent readings, but a new problem emerged.
Now, when reading from more than one sensor, approximately 90% of the time, I get either no object detection or some random readings in alternate loops. I conducted a test where I placed an object only in the line of sight of one sensor, and it worked perfectly. However, when I placed an object in the 5cm to 60cm range (I haven’t tested above 60cm as my area of interest is within this range), I often receive no object detection (Range status = 255).
Previously, I was using VL53L0X, which worked better in terms of reliability. I switched to VL53L4CX to achieve a higher I2C speed and more accurate readings. However, this issue is hindering my progress. The reason for switching sensors was to overcome occasional failures in obtaining readings with VL53L0X, but now, with the blocking function, there’s a risk of increasing loop time.
Here are some details about my setup:
- I’m using a Teensy 4.0.
- I have a 2.2k pull-up resistor, and I’ve experimented with different pull-up values as suggested in the datasheet, but it had no effect.
- I change the address of all sensors on startup, and this process works fine.
- I’ve increased the I2C buffer length to 255 in the Wire library to ensure the blocking function works properly.
I would appreciate any insights or suggestions on what might be causing this behavior and how I can address it. Thank you for your assistance.
1 Like
Initialisation
for (unsigned int i = 0; i < 16; i++)
{
mcp.digitalWrite(i, HIGH);
sensors[i].VL53L4CX_WaitDeviceBooted();
sensors[i].begin();
sensors[i].InitSensor(address);
sensors[i].VL53L4CX_StartMeasurement();
address = address + 2;
delay(10);
}
Wire.setClock(1000000);
Read
void readDistance()
{
VL53L4CX_MultiRangingData_t MultiRangingData;
VL53L4CX_MultiRangingData_t *pMultiRangingData = &MultiRangingData;
for (int i = 0; i < 16; i++)
{
status = sensors[i].VL53L4CX_WaitMeasurementDataReady();
status = sensors[i].VL53L4CX_GetMultiRangingData(pMultiRangingData);
distI[i] = pMultiRangingData->RangeData[0].RangeMinMilliMeter / 10.0; // mm to cm
status = sensors[i].VL53L4CX_ClearInterruptAndStartMeasurement();
}
}
1 Like
Hi Jeremy,
Thanks for the code and context. Some images of the wiring would be immensely helpful. Gives more context to the context you have provided
Hey Jack,
Here is the schematic. Hopefully this helps,
We are using teensy 4.0.,2.2k pullup. The Xshut is connected to a multiplexer which is used to change the address of each sensor during initialisation.
Thank you.
1 Like
Hi Jeremy
A couple of questions re mechanical layout.
What distance are we talking about with I2C signals.
Are the sensors in one line, ie; looped one to the next. Or are they connected in a star fashion with the I2C leads radiating out from a central point. Your schematic is not clear on this.
At 2k2 I don’t think you have any head room for multiple pull ups. You only have shown one set so I assume this is all.
Cheers Bob
1 Like
Hi @Jeremy251395 - this sounds like a rad project.
It’s awesome you’ve taken the time to do this properly with the shutdown pin and have each device enumerated with its own address - thats some boss stuff.
If I had to guess this feels like a bus issue - given that you’ve had stable operation with devices operating at a lower speed. The high data rate 1MHz might be the culprit here since you’ve switched to the VL53L4CX to obtain the higher speeds. Depending on the bus length the signal edges might be pretty mushy up around 1MHz. Remember, I2C was never intended to go beyond a small circuit board… We makers just flog it as far as we can and have wound up casually pushing it beyond its rated limits.
Some things that might reveal whether the bus speed / length is the culprit:
- does the bus become reliable at 100kHz, 400kHz?
- Can you observe the 1MHz edges with an oscilloscope? (at multiple points along the bus?
- Are you able to share a picture of the setup?
If bus integrity is the culprit it might be useful to extend the bus with an active terminator halfway along
2 Likes
Hey Bob,
The connections for SDA and SCL are daisy chained. The total distance I2c signal travel will be around 60cm and the Sensors are in one line.
Thanks for the response.
2 Likes
Hey Michael, thanks for you kind words!
We are getting reliable values at 100KHz. I should mention That at 1MHz We are getting the roofs distance quite well and also distances less that 7cm it works well.
I will also give the oscilloscope a try, thanks for the suggestion!
1 Like
And as always when troubleshooting: split test
Get one sensor working reliably, then a second and so on.
Introduce complexity until a point of failure and note where that line in the sand is.
My initial assessment may not be the actual cause, I’m just split testing off the information you’ve given where the only salient differences between Go and No Go are
- the device
- the bus speed.
3 Likes
I can share a picture, However they may not be much help as we are working with our own pcbs.
1 Like
