vl53l1x number of SPAD?

[will3]

I have been using GetResult method of grabbing the sensor reading.  It returns this structure:

typedef struct {

uint8_t Status; /*!< ResultStatus */

uint16_t Distance; /*!< ResultDistance */

uint16_t Ambient; /*!< ResultAmbient */

uint16_t SigPerSPAD;/*!< ResultSignalPerSPAD */

uint16_t NumSPADs; /*!< ResultNumSPADs */

} VL53L1X_Result_t;

Using this approach I noticed something I might not have noticed otherwise.  The closer the object the smaller NumSPADs becomes.  For instance,  an object right up on the sensor which will read 0 mm appears to be using only 1 SPAD.  As I move the object further away NumSPADs increases. 

I would like to know if this is expected behaviour? I use the ROI 4x4 at boot time and at Ranging time so until now I didn't expect the number of SPADs to be anything else other than 4x4(=16)?

[John E KVAM · Accepted solution]

In ideal conditions the target returns 20MCPS. The sensor can deal with as few as 0.5MCPS, but we'd really like 20M. We add or subtract SPADs to get 20MCPS 

There are 256 SPADs in the array, but some are deliberately occluded. This partial SPADs come into play with really bright, close targets. 

The max number of SPADs you will get is something like 200. But it won't be an integer. However, the software in the API rounds to the nearest integer. Theory being it's not really critical. 

When you specify you want a 4x4 in the middle, the max you will get will be 16 - minus any occluded SPADs in that area. The min is tricky because the chip is free to pick some SPADs in that 4x4 area, but getting a 1 is clearly possible. 

If you want the full range of the sensor, you really cannot limit the ROI to 4x4. With only those few SPADs you will be limited range.

But if you know the target can never be farther away then 50cm say, limiting the ROI will save power, limit any oscillation in the DSS algo, and narrow the area the sensor is 'seeing'.