cancel
Showing results for 
Search instead for 
Did you mean: 

Vl53L1X Nonrecoverable Measurement Accuracy Issue

otCT
Visitor

I'm having an issue with a breakout board housing a VL53L1X sensor where, between the breakout board and MCU, the only connections are power, gnd, sda and scl through a PCA9617ADPJ I2C buffer. I've set it up for continuous ranging at about 200ms timing budget and is usually accurate for my purpose of just detecting if something is within about 1-2 meters. I have my codes set up so if the sensor status returns 255 VL53L1_RANGESTATUS_NONE, the code will attempt to reinitialize the sensor for re-connection.  However, sometimes it will randomly enter this state when plugged in normally. While I'm still yet to figure out WHY it enters this state, my big issue is that once it reports VL53L1_RANGESTATUS_NONE and reinitializes, the ranging accuracy is hopelessly screwed up, where hovering a target about 4cm in front of the sensor reports a maxed out distance value of 8043mm, and linearly scales from there as an object gets closer. The absolute worst part about this is that a physical reset of the MCU does absolutely nothing to fix the issue. It will initialize like normal and start polling, but report VL53L1_RANGESTATUS_SIGNAL_FAIL if I'm outside that tiny 4cm distance, and VL53L1_RANGESTATUS_RANGE_VALID when within it. The only fix is physically cutting off supply voltage to the sensor by cutting power to my board, or disconnecting and reconnecting my breakout board. Once one of those two things are done, the issue is gone. I'm sure there's possibly some EMI or interference issue I need to figure out on my end for what's introducing these issues in the first place, but is there some deeper thing I can check for in this sensor to figure out why it gets stuck in this inaccurate state even after reinitializing? While the "simple" fix would be to implement a way on my board to cut power to the sensor, I'm not finding an obvious way in the API to even detect when the sensor is in this erroneous state, let alone recover from it.

0 REPLIES 0