fivesixzero
commented
3 years ago I took a look at thils while doing some APDS9960 testing with a Clue today, without using the adafruit_clue aggregated library.
The TL;DR is that _the state you're observing is being flipped by adafruit_clue library_ rather than this driver, which the clue library is using. A change to that code would be required to change the behavior while using that library, so an issue posting or PR over there would be the way to go. Otherwise if you'd like to simply avoid that behavior you could use the device driver directly instead of using the aggreagated library.
To double-check this I took a look with a logic analyzer and looked at the source of each bus transaction. It was easier to make sense of by shifting it into a table, which I've added below.
This data was generated by a Clue running CircuitPython 7.1.0-beta0 with the freshest version of this driver (5e69b206ba0097cf93ac82834b014203eb14e758)
| Reg | Read | Write | Register Name | Library Code | Note |
|---|---|---|---|---|---|
| 0x92 | 0xAB | ID |
if self._read8(APDS9960_ID) != 0xAB: |
Is this the droid we're looking for? | |
| 0xAB | 0x00 | GCONF4 |
self.enable_gesture = False |
Disable gesture (read) | |
| 0xAB | 0x00 | GCONF4 |
_gesture_mode = RWBit(APDS9960_GCONF4, 0) |
Write "false" to GMODE to disable gesture engine |
|
| 0x80 | 0x03 | ENABLE |
self.enable_proximity = False |
Disable proximity (read) | |
| 0x80 | 0x03 | ENABLE |
enable_proximity = RWBit(APDS9960_ENABLE, 2) |
Write 0 to ENABLE[2] (<PEN>) |
|
| 0x80 | 0x03 | ENABLE |
self.enable_color = False |
Disable color (read) | |
| 0x80 | 0x01 | ENABLE |
enable_color = RWBit(APDS9960_ENABLE, 1) |
Write 0 to ENABLE[1] (<AEN>) |
|
| 0x80 | 0x01 | ENABLE |
self.enable_proximity_interrupt = False |
Disable proximity interrupt (read) | |
| 0x80 | 0x01 | ENABLE |
enable_proximity_interrupt = RWBit(APDS9960_ENABLE, 5) |
Write 0 to ENABLE[5] (PIEN) |
|
| 0xE7 | AICLEAR |
self.clear_interrupt() |
Clear all non-gesture interrupts | ||
| 0x80 | 0x01 | ENABLE |
self.enable = False |
Puts sensor in lower-power sleep mode (read) | |
| ~375ms delay | |||||
| 0x80 | 0x00 | ENABLE |
enable = RWBit(APDS9960_ENABLE, 0) |
Write 0 to ENABLE[0] (PON) |
|
| 10ms delay | |||||
| 0x80 | 0x00 | ENABLE |
self.enable = True |
Puts sensor in normal operating mode (read) | |
| 0x80 | 0x01 | ENABLE |
enable = RWBit(APDS9960_ENABLE, 0) |
Write 1 to ENABLE[0] (PON) |
|
| 10ms delay | |||||
| 0x8F | 0x01 | CONTROL |
self.color_gain = gain |
Set ALS/color gain (read) | |
| 0x8F | 0x01 | CONTROL |
color_gain = RWBits(2, APDS9960_CONTROL, 0) |
Write 1 to CONTROL[1:0] (AGAIN) |
|
| 0x81 | 0x01 | ATIME |
self.integration_time = integration_time |
Set integration time | |
| 0xAA | 0x00 | GCONF3 |
self.gesture_dimensions = 0x00 # all |
Set gesture dimensions | |
| 0xA2 | 0x40 | GECONF1 |
self.gesture_fifo_threshold |
Set gesture FIFO threshold (read) | |
| 0xA2 | 0x40 | GECONF1 |
gesture_fifo_threshold = RWBits(2, APDS9960_GCONF1, 6) |
Write 01 to GCONF1[7:6] (GFIFOTH) |
|
| 0xA3 | 0x40 | GECONF2 |
self.gesture_gain = 0x02 # gain 4 |
Set gesture gain (read) | |
| 0xA3 | 0x40 | GECONF2 |
gesture_gain = RWBits(2, APDS9960_GCONF2, 5) |
Write 2 to GCONF2[6:5] (GGAIN) |
|
| 0xA0 | 0x32 | GPENTH |
self.gesture_proximity_threshold = 50 |
Write 50 (0x32) to GPENTH |
|
| 0xA6 | 0x83 | GPULSE |
self._write8(APDS9960_GPULSE, (0x2 << 6) \| 0x3) |
Write 2 to GPULSE[7:6] (GPLEN) and 3 to GPULSE[5:0] (GPULSE) |
The final state of the device after this driver's init has color, proximity, and gesture disabled at startup and those settings appear to stick after the init. The enabled bit in the ENABLE register is ENABLE[0] (PON), which puts the device in a "normal" (non-sleep) operating state.
There are some interseting choices made during the init that might bear closer examination and experimentation, like some of the gesture config that's going on, and the use of GCONF4[0] (GMODE) rather than ENABLE[6] (GEN) for controlling gesture feature enable. The datasheet seems to indicate that GEN and GMODE are used a bit differently but it isn't easy to make sense of at first glance.
FoamyGuy
The CLUE module sets the sensor object's enable_color and enable_proximity to true before asking for the related data. It never sets them to false. More interestingly I don't see where in the sensor code those values get propagated to the sensor enable register, although they do get initialized from the register value.