VL53L0X laser ranging modules multiple sensor configuration not working #18160
Replies: 6 comments 5 replies
-
Are you using the same model ? 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 |
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Just tried a pullup resistor on xshut. 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? |
Beta Was this translation helpful? Give feedback.
-
I found I could get them to work reliably only with the use of pullup resistors on xshut. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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
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
Beta Was this translation helpful? Give feedback.
All reactions