Continuous mode freezes with default, smallest delay

[tekktrik]

I caught wind from a colleague that when using continuous mode with default smallest delay, the sensor will randomly freeze up and begin returning only the same value(s) depending on if reading single values or from history. Time to trigger seems to fluctuate. It should be reproducible by running the continuous mode at the smallest interval speed. It seemed like setting the delay for continuous mode readings to 20ms fixed it.

[aryakeyvan-star]

any updates on this error? changing the delay for continuous mode didn't solve the problem for me.

[tekktrik]

I haven't checked but am happy to dig further in the coming weeks

[aryakeyvan-star]

yes thank you.

I have been stuck on this for the past weeks. Can't find other people who have had similar problems which is weird.

Any immediate clues which might causing this?

[tekktrik]

Just got another sensor, I'll do some more digging with that and that datasheet,

[bigredfrog]

Ping on this one. Did anyone get insight?

I am running a sensor at 20ms convergence, continuous mode. After a few hours in a stable measurement scenario, i see a lock up where the 16x buffer returns exactly the same data as previous, so you can see the expected noise in those 16, but it is exactly the same 16 values.
Unfortunately it does not appear to report a error code in status!

I have previous tests running effectively with single measurement polls and it runs stable for days, but that eats runtime, really want the 16x measure in the background and service periodically.

I also see hard coded sleeps in the driver for start up scenario relating to continuous mode reset.

If i implement a hard reset on each cycle I will have to break that out to allow the main code to run and callback later rather than sleep. I am attempting to make a group of measurements every second while also servicing other things, so the runtime is critical.

I will put some observations on timing implications here, also try a longer convergence time.

[bigredfrog]

Likely my instance of vl8160x was on its way out. One more teat cycle later and it will not even respond to i2c at all. Swap0ed for another physical instance all on stemma-q plug and cable and appears to work fine. Will soak test for 24 hrs plus

[bigredfrog]

No joy, second device has locked up. Assuming it is still going to be on the i2c bus, but there is a real instability going on. Next step is to see if I can detect it. I know that there is no error code, and meas buffer seams to contain old values, show expected noise but no longer changing

[Biftake]

I caught wind from a colleague that when using continuous mode with default smallest delay, the sensor will randomly freeze up and begin returning only the same value(s) depending on if reading single values or from history. Time to trigger seems to fluctuate. It should be reproducible by running the continuous mode at the smallest interval speed. It seemed like setting the delay for continuous mode readings to 20ms fixed it.

Same issue for me with