search

pimoroni / Pimoroni_CircuitPython_LTR559

MIT License
1 stars 1 forks source link

Lux value stuck at one value after second reading #2

Closed dglaude closed 4 years ago

dglaude commented 4 years ago

The first reading of Lux always give zero.

The second reading give something that seems proportional to the light (very low in the dark, very high with a flash on it, intermediate depending on the distance/orientation of the flash).

But after that reading, all further reading give exactly the same value again and again with no change (while the proximity sensor update in real time).

Test condition:

Gadgetoid commented 4 years ago

This is interesting- Lux is a little more complex than Proximity since it involves a calculation to get the result and fetches a couple of parameters in realtime to ensure it's compensated properly. It will also store the last "good" result and if the interrupt for the light sensor never fires, or the "new data" flag is never set then it will just keep outputting the same value like you observe.

I don't have any immediate idea why this might be happening (though I should check to be sure it's not doing the same on 5.x because this seems like the sort of thing I might have overlooked during testing). I'll have to upgrade my CLUE board and see if I can replicate.

dglaude commented 4 years ago

I will have to try again with the previous driver to see if it is an hardware issue or software. Your video on Twitter showing it was alive, was also stuck on one lux value, and only the proximity was moving. Best is to point a light source at it while testing. That way moving your hand affect both proximity and light.

Gadgetoid commented 4 years ago

Looks like a software issue- if I short-circuit the light sensor interrupt by swapping:

als_int = self.light.new_data or self.light.interrupt_active

for

als_int = True

Then it will get new light readings as expected.

I have two theories:

  1. The light sensor interrupt isn't being enabled for some reason
  2. The way that i2cdevice handles reads, causes the interrupt values to be reset before they are even read
Gadgetoid commented 4 years ago

Okay it was a variation on number 2 - reading the individual light sensor data channels failed to trigger a reset of the new data flag.

It's only taken me... looks up... 2 hours 😬 to figure that out.

Gadgetoid commented 4 years ago

I published v0.0.1 out of curiosity and it looks like the .mpy build is working. Nice- https://github.com/pimoroni/Pimoroni_CircuitPython_LTR559/releases/tag/v0.0.1

I've also raised a PR to add it to the Community Bundle - https://github.com/adafruit/CircuitPython_Community_Bundle/pull/39

dglaude commented 4 years ago

I tested the 0.0.1 release and it works with Enviro+ Feather Wing on:

My test was just with the minimal set of *.mpy file, yours and the one from Adafruit, and the simpletest code.

The only thing is that first lux reading is always 0, but that could be documented. Also, maybe the mpy file does not need circuitpython in it's name and could be shorter.

dglaude commented 4 years ago

Also tested with a Feather M0 Express.

All my test are with the latest firmware (6.0.0-alpha2) and the latest bundle with adafruit_bus_device and adafruit_register from 2020/08/10.

dglaude commented 4 years ago

Wait, I can close this I assume...