we use the following in a commercial product.
VL53L0X Time-of-Flight Distance Sensor Carrier
We buy from polulu or sometimes Digi key, we dont have a fake part.
Over the 3 months we have started to see a lot of failures (20 of around 200). We have used the part for something like 10 years without any major problems (a few failures a year and its probably just ESD). Specifically, these new failures are that the sensor is reading “0mm” output
If we replace the sensor, it starts to work again
Questions
Has anything changed internally on the “VL53L0X Time-of-Flight Distance Sensor Carrier”
what can we do to protect the “VL53L0X Time-of-Flight Distance Sensor Carrier”, ie TVS?
We are feeding SCL/SDA directly from a microcontroller (ITEM NO: 3101 A-Star 32U4 Micro) as well as 5V and common too. We do have a few other devices on the 5V but just mosfet gates.
To avoid confusion, please note that our company name is Pololu, not “polulu.”
We test every unit and have not heard any other reports of problems with this product, nor have there been any recent changes to our manufacturing process for these. What potential hazards exist depends on your system, so it is difficult to offer much specific advice about protecting the boards without more specific details about the application.
Do the sensors that you are having trouble with continue reporting bad results after being taken out of your system and tested more? Have you tried retesting any of them in a minimal setup (e.g. just the sensor and a microcontroller)?
Hi Patrick
Yes, the sensors are broken and continue to produce 0 for the reading after they are removed from the unit. Yes, if there are sometimes an issue in the past, we have to reset power over the entire system for them to work again, but this is not the case with the recent problems (it helps them recommunicate). Infact, these recent failrues are still communicating, it is just the measurement that is broken. The sensors never work again after the failure. We had had occasional failures over the last 10 years or so that we have used them, but never producing 0mm as the result and never having so many failures. It seems the last 5 systems in a row have had at least one bad sensor, some 2 or 3, this never use to happen. Our design is static, has never changed, and it only interfaces directly with the Leonardo from Pololo anyway so there is no magic in understanding it, its very simple.
Perhaps you can verify that nothing has changed wiht the design or even the laser module part that is used.
I just noticed that this thread is not in the best category, so I moved it to our support category.
Can you clarify what board you are using to interface with your sensors? We have not offered Arduino Leonardo boards in a long time; are you referring to one of our A-Star 32U4 controllers?
I can confirm that our design for these has not changed. If you’d like, it might make sense at this point for you to send us some of your boards so we can take a look at them and see if we can learn something about what is happening that way. Can you email us with your order information and a reference to this thread?
yes, we are using the
POLOLU2128 POLOLU.COM ITEM NO: 3101 A-Star 32U4 Micro
Its called the Leonardo as the arduino complier/IDE uses the “leonardo” setting
I would just like someone to tell me if anything changed on the design like an obsolete part.
I did save a bunch of the bad ones if you want us to send them to you.
I have looked at them myself under the microscope and there is no visible damage and the voltage regulator is still working. It appears to the laser that is not working.
As I mentioned previously, nothing has changed with our product, and we test every unit. Are the units you are seeing problems with failing sometime after operating normally, or are they never working for you? Can you post some pictures of the boards and your overall setup?
By the way, if you want the A-Star to be identified as an A-Star in the Arduino IDE (instead of being identified as a Leonardo), you can accomplish that by following the instructions in the “Programming using the Arduino IDE” section of the A-Star 32U4 user’s guide (though it should not be consequential to keep identifying it as a Leonardo).
Thank you for the pictures. Given your information that similar setups have worked for you over the past several years, I think these are unlikely to explain the current problems, but here are a couple things that caught our attention:
It is not clear from your schematic what the relay is for, but I do not see any immediate problems with the connections shown there. Has that part of the circuit been the same since you started using these sensors?
The wire colors shown in your picture are counterintuitive for the connections you are making (green, white, red, black for VIN, GND, SDA, SCL respectively, rather than red and black for VIN and GND), so it might be worth checking that these are all being wired correctly.
You mentioned earlier that you are still able to communicate with the sensors; can you explain how you confirmed that? For example, if you are using our library, have you verified that the init() function returns true?
Establishing when exactly the sensors are failing and what your system is doing at that time will probably be a critical prerequisite to understand what is going on. Is it possible for you to somehow more actively monitor some of your systems after installing new sensors to identify when failures are happening? We can also still arrange for you to send us some of your units for us to look at, although it might still be difficult for us to provide much insight without a more complete understanding of what’s going on at the time of failure.
was hoping we could punt but we had 3 bad ones today just to build 1 system.
people in our production team get upset as it takes a lot of time to replace the part.
was thinking maybe we can mail a few in for you to look at?
Im goign to go through our inventory to test them all.
We can arrange a return if you email us with your order information and a reference to this thread. Can you also answer the questions in my previous post? It would be most immediately helpful to establish whether the boards are working for a while and then breaking, or if they appear damaged as soon as you install and try to use them in your setup. Looking at the sensor carrier’s VIN pin with a scope like you suggested would also be a good idea.
I am somewhat embarrassed but I think that only a few of the chips are broken.
I dont know why, but I am finding the system has to be rebooted to make them work
Even when we come up from a clean boot, the polulu ICs are not always recognized with the same code we have always used.
where it is confusing is that the device is producing 0mm rather than a unrecognized answer
I posted out code.
we also have a LED running from the micro (addressable LED)
Again, this code has been running for 7 years
I am not sure what would cause a program that has been working for years to start having trouble now, but if you are able to sometimes resolve the issues by rebooting the system, that does sound consistent with a software/code issue.
On initial inspection nothing immediately stands out as problematic with your code, but we should try to reduce it to the simplest program that still experiences the problems you are facing. I recommend testing some of the sensors you are having trouble with in a simplified setup (ideally, just your A-Star and the sensor carrier) using one the example programs from our library. It might be a good idea to try the latest version of our VL53L0X library, 1.3.1, for that (it looks like you are using 1.0.2). Can you let me know how that goes? If that works, start adding other parts of your code and system back on to see if you can identify when the issues start to appear.
