#Vl6180x
1 messages · Page 1 of 1 (latest)
Well thats disappointing. Looking at the elastic data, admittedly from my phone, it looks like it has locked up within an hour, seeing the same values coming through, an average of the 16 reads which should have random noise, but not seeing that, just a fixed value, and no error status either. I tested error reporting was sane. I might have to do a deep reset every reading cycle....
I will post some code and observations here tomorrow incase anything sticks out.
Looks like a similar scenario at https://github.com/adafruit/Adafruit_CircuitPython_VL6180X/issues/26
I have added a comment there
So I think I have a few experiments to do.
1 measure the instance creation time which includes all the settings upload. This will help me decide if I can afford to pay that regularly.
-
Try a longer convergence time and see if it become more stable
-
Stretch time between my shutting continuous mode off and on due to warning in
https://github.com/adafruit/Adafruit_CircuitPython_VL6180X/blob/main/adafruit_vl6180x.py#L190
1 is some quick and dirty testing, 2 and 3 are soak tests.
Another thread of interest https://community.st.com/s/question/0D50X0000BwlkKrSQI/vl6180x-bus-lockup
Also need to try shorter i2c wires, or change order of boards, i currently have 100mm to a ATH20 then 100mm to the vl6180x. Why i would get random lock up of measurement but otherwise working from this I dont know, but its another variable.
Mostly notes to self, but I need to check device operating mode while in continuous range, make sure it is mode 3, range continuous
Also look at usage of history buffer / clear buffer command, may allow detection of frozen ranging.
Presently no way to tell if repeated "out of range" 255s in buffer are real or stuck, but if clear buffer does something like set buffer to all zeros then that will allow detection of "no measurements" and a deeper recovery.
Swapped temperature sensor and distance sensor around on i2c. That can run in background while i rig another setup and look at other options
So not only did it still fail again after 30 minutes, but now it is not visble on i2c at all. Swapped for another and running clean for 2 hours.
I suspect I need to bench test all the sensors now, if one has failed, then maybe others. New test is running clean. I want 24 hours out of it though before I declare victory...
No joy, it locked up again, so there is more going on here...
Even doing a full reinit every measurement cycle does not protect. Locked up after 1 hour. Now i am wondering if this is a glitch in the power supply. I can cycle power on the i2c i believe and cause a full power cycle there, but not sure what that will do on stabilization time or keeping the sensor at a stable temperature 😦
I need to go back to my measurement implementation that has otherwise been stable and see if this instance is also stable on it. This will expose the chance of it being the power brick for example.
My "stable" instance has been running a teat for a week solid, so at least I can go back to exactly what that code is and compare...
Noting I will come back to this problem when I have everything else in my project implemented, but I cannot get continuous mode to stable. It locks up between seconds and hours of runtime, with the buffer returning the same collection of values that have in themselves expected noise. So last good values before lockup
At that point there is no error reported, and even with full re init, it seems the device cannot be recovered.
Requires power cycle to work again
Where as single measurements seem bullet proof. Implemented single measurement with a loop that measures repeatedly until 100ms left in measurement cycle, and then average out the responses, and it runs overnight happily
This allows me to soak up runtime for other things, with that single measurement being ~25ms, but means i dont get to offload any of the runtime.
So i can get a good averaging on a one second basis, with compromised measurements if i get delays for ntp for example, but it should be a working system.
I can scan buttons and update diaplay with reasonable impacts to samples per second.
Next will be webserver!
As it should only delay if there is something to be serviced, I can look at that timing and decide if I care
However in the future I really want to get stable continous and I am at a loss to the cause.
Seems such a simple lifecycle.
Init
Enable continous @ 20ms per
Read 16 samples once enough time has passed
Repeat for ever.
I have tried everything with adjusting sample time. Turning on and off continous post reads with 300 ms stabilisation timing.
Full reinits every cycle.
Disabling ALL my other functionality
All fails with similar lock ups. Some sensor board seem to fail predictably sooner than others
I cant believe the component itself is the problem.