Suggested lux calculation improvement

[iquizzle]

The current algorithms produce a negative lux under certain conditions (especially low light).

Current:
lux1 = ( (float)ch0 - (TSL2591_LUX_COEFB * (float)ch1) ) / cpl;

The fixed value of TSL2591_LUX_COEFB can cause negative values when IR intensity is high. This should be replaced by a dynamically scaling coefficient. A better implementation would be this:

Improved:
lux = ( ((float)ch0 - (float)ch1 )) * (1.0F - ((float)ch1/(float)ch0) ) / cpl;

The raw difference is taken initially and a correction factor of 1-ch1/ch0 is applied to scale down the lux with increasing IR intensity. This ratio represents the amount of IR present within the full spectrum. This should give a better approximation to lux given the 2-channel constraint of the sensor.

[microbuilder]

Fixed with 2b3b098 ... thanks for taking the time to suggest an improvement here!

[CaptainMack]

I am unsure if this actually fixes it, as I'm using the current calculation and still get the 65535 (negative number in an unsigned int). However, I am unsure if this can be related to another error (where it jumps from 0 to 65535) and the sensor has to be sampled more than 2 times.

[NuclearPhoenixx]

Also still having negative lux results in low light environments with calculateLux and normal gain and timing.

[systembolaget]

At MID and LOW gain, and matching integration times, briefly shadowing the sensor still returns negative numbers. A slow EMA filter will often prevent this from happening, but when one changes gain/integration time on the fly with a button, the sensor restarts often with large negative values returned. Ironically, the old TSL2561 fares better here.

[microbuilder]

Please see my somewhat gigantic response to the lux issue here: adafruit/Adafruit_CircuitPython_TSL2591#7 (comment)

I've tried to dig into this, and put some theory down and separate photometric units (illuminance measure in lux, based an an estimation of human vision) from radiometric units (irradiance), and show how the two are mapped based on the CIE 1931 luminous functions, but the final conversion coefficients are still a WIP. :(

If possible, maybe the conversation should be continued there just to have everything in one place?

[microbuilder]

Reopening this issue until the related issue is also resolved since this is still an open question.

[SimonMerrett]

Not sure on the attitude to cross-posting here but this may help someone. adafruit/Adafruit_CircuitPython_TSL2591#7 (comment)

[microbuilder]

@SimonMerrett All good, and you're right to cross post here, thanks again.

[TCIII]

I recently purchased two of the Adafruit tsl2591 modules to be able to determine sunlight lux levels for a two axes solar tracker. Since the tsl2591 will saturate beyond 88,000 lux and direct, bright sunlight can reach lux levels well beyond 132,000 lux, I determined that a 1/32 thick piece of Teflon would provide sufficient attenuation so that the tsl2591 would not go into saturation.
Using my attenuator and a wide range light meter calibrated to a secondary source traceable to NIST, I determined that I needed a multiplication factor of ~4 when using the attenuator. However as was documented above, I would get an occasional negative lux reading and the sensor would output readings over 200,000 lux during sun to cloud to sun transitions when using the "advancedRead subroutine to read the lux level from the sensor.
Finally I decided to try the "unifiedSensorAPIRead" subroutine to read the lux level from the sensor. During the first sensor lux level reading in bright sunlight, the sensor lux level reading was within 1,000 lux of my calibrated light meter and in cloudy/diffuse sunlight, the reading was within 500 lux of the calibrated light meter. On a fully sunny day with no clouds, I plan to plot sensor/light meter data points every hour from sunrise to near sunset and perform a retrogression calculation to determine a best fit curve for the tsl2591 sensor and make any necessary adjustments to my attenuator multiplication factor.
Bottom line here is that the "Unified Sensor API" routine should be looked at so as to determine why its accuracy and consistency seems to be much better than the "Advanced Read" routine.