-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Negative lx values #24
Comments
Yeah, I observed this annoying behaviour too. Need to reasearch a bit more about how the lightsensor works and how the registers work together in cases like overflows. Help is greatly appreciated! 👍 |
I put an EMA filter on the value, so a brief near total shadowing won't contaminate the output with negative values, but that is no proper solution. |
There's an additional problem missing in this library for sensor saturation/overflow. See Also, there's another issue about which equation is used across projects. |
That's good to know, thanks! Have to have a look at that 👍 |
I have been playing with the dynamic configuration of the integration and gain registers. Initial observations (I'm using the arduino cpp not circuit python) are that consecutively increasing the values of gain and integration time works but decrementing back through them produces way fewer valid (in-range) readings. One more quick observation is that negative lux values only happen if ir > full, so you can add that check in before it returns a lux value, a bit like the register overflow check. |
It's been awhile since I was testing our hardware, but the 37888 number sounds familiar as output from the sensor. The 36XXX number is more conservative to capture an overflow (and in-line with the newer DS). Given the Lux conversion is still getting hashed out in another issue, I'm not sure what the ~1000 counts difference will make. |
Was this issue ever fixed? Currently having the same issue using Arduino. I'm trying to measure an LED light and when I reach ~2800 Lux it reads as -1Lux. |
Take a look at these posts as the negative values should get corrected here: Also, there's another issue about which equation is used across projects. |
the method where the lux value is calculated returns -1 if one of the number arguments is equal to 0xFFFF which is 65535. This means, that there is an overflow and that you have to reduce either the sensitivity or the integration time. |
Closing. This may have been fixed by some of the lux updates. Could not easily recreate it running current library code at lowest gain and integration time and holding finger over sensor. But also, the computation of lux for the TSL2591 is a point of discussion. This library implements something, but it may not be the best something. Lots of discussion here: |
It seems that the problem is not yet solved.
In low-lighting conditions (early evening office space, home dining room, etc.), simply waving one's hand at one foot distance (and shorter) produces negative lx values.
The text was updated successfully, but these errors were encountered: