VL53L0X laser ranging modules multiple sensor configuration not working

[darrylb123]

I'm trying to get 2 VL53L0/1XV2 modules working as described in https://tasmota.github.io/docs/VL53Lxx/
I have 1 sensor connected to an ESP32 running Tasmota 12.4.0. It is the default ESP32 build

I'm trying to get the i2C address reconfiguration working.

When using the default with one sensor and the i2C GPIO pins configured (without the XSHUT gpio), the module displays distance correctly.
Adding the VL53XX XSHUT gpio pin causes the module to be ignored.
Performing an i2cscan {"I2CScan":"No devices found"}.
I'm uncertain if I should be able to see the module at the new address 0x78.

I do not see the log message as shown in the screenshot

• SENSOR VL530X 1 Detected Setting the address to ...

I've tried disabling the other I2C drivers as described in the document (backlog i2cdriver16 0;i2cdriver40 0;i2cdriver31 1;i2cdriver54 0)

I've tried several VL53xx modules and different ESP32 boards, same result

[barbudor]

Are you using the same model ?
As of today you can't mix L0X and L1X as they are based on different drivers

I2CScan => Not device found : may be a clue of bad cabling but not necesseraly as if the XSHUT pins are in Shutdown mode, the VL will not respond

I will try to setup a test during the week-end

[darrylb123]

Yes, same model. Just one doesn't work either once the xshut is configured. Does the xshut need an external pull-up resistor? I measured 3v on the xshut. I tried configuring the module without choosing an xshut gpio so single module but configured the xshut gpio as a relay. Operating the relay button enabled and disabled the module as expected. Darryl

…

On Sat, 11 Mar 2023, 8:41 pm Barbudor, ***@***.***> wrote: Are you using the same model ? As of today you can't mix L0X and L1X as they are based on different drivers I2CScan => Not device found : may be a clue of bad cabling but not necesseraly as if the XSHUT pins are in Shutdown mode, the VL will not respond I will try to setup a test during the week-end — Reply to this email directly, view it on GitHub <#18160 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVJ5XJHFR4BBGBDI5RTW3RJGVANCNFSM6AAAAAAVXIQGR4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[darrylb123]

Just tried a pullup resistor on xshut.
Get this error message from i2cscan
14:13:41.234 CMD: i2cscan
14:13:41.252 RSL: RESULT = {"I2CScan":"Error 5 at 0x01"}
14:13:46.329 CMD: i2cscan
14:13:46.347 RSL: RESULT = {"I2CScan":"Error 5 at 0x02"}

Timeout, it seems.

i tried the same sensors on an esp8266 and they worked exactly as the document describes. Worked with 1 sensor and xshut connected and with 2 sensors.

So, something in ESP32 version?

[barbudor]

I just tried on an ESP32 without any problems (You need Weblog 3 to see hte below messages):

00:00:00.370 I2C: Sensor VL53L0X 1 detected - Setting address to 0x78
00:00:00.457 I2C: Sensor VL53L0X 2 detected - Setting address to 0x79

16:08:58.613 CMD: i2cscan
16:08:58.644 MQT: stat/esp32dev2/RESULT = {"I2CScan":"Device(s) found on bus1 at 0x78 0x79"}

I can't tell what's going wrong on your side, may be bad contacts, but it's working as expected
I didn't used any external pull-up resistors

[darrylb123]

I soldered all connections into the connectors, including the crimp connectors. I still had to use pullup resistors, but got it reasonably reliable with both sensors.
I left it overnight and found both sensors had reset to 0x29. A restart got them working again.
I assume my problem is the sensitivity of the xshut input on my modules I bought off AliExpress.
Any drop in voltage from 3.3v resets the module.

I looked at the initialisation code. The detect function Vl53l0Detect() only seems to be called once, at bootup.
I could add some test code to restart the module whenever the sensors return null, pretty ugly though

Could Vl53l0Detect() be called whenever there is a failure at 0x78 etc to reasign the sensor addresses?

[frollard]

Could Vl53l0Detect() be called whenever there is a failure at 0x78 etc to reasign the sensor addresses?

This would be fantastic - the ability for a command/berry script to detect 0x29 showing up triggering only the re-initialization instead of a full reboot.
I'm running 8 sensors (pop machine inventory counter), and losing them typically one at a time. Also, I find they drop furthest electrically on the string first, then work their way back to the esp32. Stronger pullups may be a solution to slow the problem, but not to handle it in software. (Also using the cheaper purple board aliexpress versions, but with high quality connectors crimped onto ribbon cable.).

[barbudor]

I would say, first try to fix your hardware
The pull-up is mandatory per the datasheet and also because the XSHUT GPIO is moved to tri-state (turned to input)
The pull-up should be close to the VL chip, not to the ESP. So if there is problems in the connection between the ESP and VL, the VL XSHUT pin doesn't becomes floating with a risk of resetting the VL.

I don't see any problem in changing the code so the XSHUT pin stay as an OUTPUT set at HIGH and I can do that if you feel it would be better but still that will not solve the possible connection issues and the pull-up remains mandatory.

Calling the full Vl53l0Detect() would be a bad idea as it would reset every VL chip, even those still working.
It should be possible to do something smart and re-configure only those who have been reset.
So I think, solving the hardware should be the priority.

[frollard]

Agreed on all points. I am of the opinion that the circuit is sound - nothing floating. I watched it with an oscilloscope and didn't see anything out of the ordinary. No spurious pulses high or low; no runt pulses. The i2c bus was slightly rounded on the rise but well within spec for clock timing.
The boards themselves have the pullup on board. Maybe adding more pullup current to drive the line more decisively will reduce problems. (my max length is about 3 feet. not great, not bad). Testing the circuit on my bench stays working for days. Testing it in-situ in the vending machine regularly loses some sensors until reboot...so I can't rule out noise on the electrical lines. It is trapped in a Faraday cage with a compressor motor after all.

There was an interesting post on a parallax forum regarding these same chips. Every once in a random while the library they were using would randomly send out several dozen clock pulses with the data line held, so it just transmitted effectively a bunch of 0xFF, clobbering all the registers of the VL chips until reboot. (Was believed to be an esp32 problem, not a library/code problem)
Sadly, I've never managed to catch the exact moment a sensor goes null/resets to 0x29 ic2 address...but they definitely seem to drop from their assigned 0x78++ addresses to default after some time. Shutdown pin shouldn't change that address...as nothing done to a different address should change it.
This leads me back to either the:

• chips browning out, possible but they shouldn't...I've added big tank caps and noise suppression caps to no avail. Nothing visible when scoping the power lines
• Defective chips that just suck
• soft/hardware glitch with esp32 that clobbers the config registers on the chips.

Calling the full Vl53l0Detect() would be a bad idea as it would reset every VL chip
Even if it resets those that are working...the re-initialization would take a few dozen milliseconds, shouldn't harm any other processes.

Bikeshedding: The only other change that might be useful is outputting out-of-bounds values as -1 instead of null. Currently invalid/no object detected caused by too close or too far is also null - so it can be difficult to determine if a sensor is actually dead.

[darrylb123]

I found I could get them to work reliably only with the use of pullup resistors on xshut.
Without the pullup resistors they would keep reverting to default 0x29 and only 1 or neither would work.
Now I can reliably get {"I2CScan":"Device(s) found on bus1 at 0x78 0x79"}
I measured 2.9V on xshut when running without the resistors and 3.1V with.

[darrylb123]

I just bought proper connectors for my devices and esp32 board and made soldered connections into the plugs.
I left off the pullup resistors and both devices were recognised. The log said they were changed to 0x78 and ox79.
An i2cscan showed device(s) at 0x29, none at 0x78 or 0x79. Same result as before.
I installed 2.7k pullup resistors on the actual devices.
First time I checked they were at 0x78 and 0x79 but when i went back to the front screen one showed distance, the other null.

I did an i2cscan and one was now at 0x29, that is the module had reset??

I rebooted and simply re-ran i2cscan for a few times. One module reset after the 3rd i2cscan.

[darrylb123]

I also had the situation where the multiple vl530lox chips would reset to default address over a period of time. After exhausting all the possibilities of power supplies, pull-ups etc, I gave up and put one per processor. An oscilloscope never managed to capture the moment that caused the failure. I second the idea of calling Vl53l0Detect() when the devices go away, a full processor reset is the only alternative. Possibly a means of calling it from berry may be suitable. My observation is that mostly, they all fail together, so there are no working ones to keep running.

…

On Sun, 19 May 2024, 6:42 am frollard, ***@***.***> wrote: Agreed on all points. I am of the opinion that the circuit is sound - nothing floating. I watched it with an oscilloscope and didn't see anything out of the ordinary. No spurious pulses high or low; no runt pulses. The i2c bus was slightly rounded on the rise but well within spec for clock timing. The boards themselves have the pullup on board. Maybe adding more pullup current to drive the line more decisively will reduce problems. (my max length is about 3 feet. not great, not bad). Testing the circuit on my bench stays working for days. Testing it in-situ in the vending machine regularly loses some sensors until reboot...so I can't rule out noise on the electrical lines. It is trapped in a Faraday cage with a compressor motor after all. There was an interesting post on a parallax forum regarding these same chips. Every once in a random while the library they were using would randomly send out several dozen clock pulses with the data line held, so it just transmitted effectively a bunch of 0xFF, clobbering all the registers of the VL chips until reboot. (Was believed to be an esp32 problem, not a library/code problem) Sadly, I've never managed to catch the exact moment a sensor goes null/resets to 0x29 ic2 address...but they definitely seem to drop from their assigned 0x78++ addresses to default after some time. Shutdown pin shouldn't change that address...as nothing done to a different address should change it. This leads me back to either the: - chips browning out, possible but they shouldn't...I've added big tank caps and noise suppression caps to no avail. Nothing visible when scoping the power lines - Defective chips that just suck - soft/hardware glitch with esp32 that clobbers the config registers on the chips. Calling the full Vl53l0Detect() would be a bad idea as it would reset every VL chip Even if it resets those that are working...the re-initialization would take a few dozen milliseconds, shouldn't harm any other processes. Bikeshedding: The only other change that might be useful is outputting out-of-bounds values as -1 instead of null. Currently invalid/no object detected caused by too close or too far is also null - so it can be difficult to determine if a sensor is actually dead. — Reply to this email directly, view it on GitHub <#18160 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVN4KRJUBQFPF3LQXB3ZC64LZAVCNFSM6AAAAAAVXIQGR6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TIOBSGQ2DC> . You are receiving this because you authored the thread.Message ID: ***@***.***>