programming FOV

[rexxdad]

we are using the early version 1x in a vertical detection mode.  it has a 23 degree fov. 

in some of our testing we determined we need more.. FOV

currently we tilt the board holding the TOF sensor to eliminate wasted FOV where the sensor would be projecting on a wall.  tof mounted 8ft high on the wall, projecting down, so we have tilted the FOV out, so that the back edge of the FOV is parallel to the wall its mounted on. 

the newer 5x/8x have bigger FOV.. 63 and 90 degrees..

 we don't need that much, BUT  I would like to detect on the outer edge, vs a smaller square 

4x4 with edge against the exclusion zone. or 6x4 with the 4 edge against the exclusion zone. 

pic attached, box mounted on wal, tof pointing down,  zoom in on box, 

pad layout and detection zone

is this possible? 

we need 6-10ft of detection in a narrow band. maybe 20-24 inches wide. 

[John E KVAM]

The VL53L8CX is our best sensor. It's the result of doing this for 10 years. It will range the farthest and give you a distance to a 12-inch target at 6 feet. (It has 8x8 zones at 5 degrees per zone.) I'm quite certain it will solve your problem. But it does cost more than the VL53L1X. And it uses more power, and the software is more complex (although we have written most of it for you.)

If you use the L1 with the most restrictive FoV you would cover that 2ft target, but you have reduced the number of photon detectors so much that I fear you might not get the range you desire. 

So here is what to do...

First figure out if you project can afford that VL53L8. If so, invest the $56 dollars in the eval kit and try it. 

I suspect it will do everything you need. 

(Sorry I could not load the screenshot, or I might have given you a better answer.)

- john

[rexxdad]

thanks,  I wonder why you couldnt open the jpg? work security policy?

[rexxdad]

speaking of the software,  we intend to power off the sensor  when there is no detection possible, and  power it back on when it is possible.  to save overall power.

the esp32 driver for the 1x, does not like this, and crashes pretty consistently.   I havent looked for the source to see what we might change. (dont really want another pile of code we would be responsible for...lol). do you think there is any reason this might be a problem. 

1000 power cycles a month..  

[John E KVAM]

"I wonder why you couldn't open the jpg? work security policy?" 

That's pretty funny. I work for ST. And that's the sort of policy we could enact.

It did open the Fifth time I tried it. 

I like your tilt idea. No reason to range on the wall if you know it's there. 

just offset your Region of Interest (ROI)as you have shown, and you will be doing it the best you can. 

Increase your TimingBudget as much as you can. Narrowing the ROI limits the distance you can see, so you might need more time to get enough photons back. 

1000 cycles per month should be no issue. 

But you could just drop the XShut line, and most the chip will turn off. maybe not the absolute lowest power, but it's pretty low.

- john

[rexxdad]

thanks I have the timing  budget at 50 so far, have not set a custom ROI yet.(on the 1x)

initial responsiveness is important

[rexxdad]

I looked at the doc for the 8x.. and it doesn't  appear to support ROI movement, 

it DOES support an external sync pin to turn on/off detections.  sort of like xshut on the 1x

the doc had this sentence

External synchronization pin
An external trigger source can be used to synchronize the ToF ranging acquisitions for applications where there
may be interference concerns. Such interferences include multiple VL53L8CX devices or IR image sensors within
close proximity

the second part, I wonder if there is any info on 'close' proximity 

our 'close' is approx 3ft between sensors, again with FOV in vertical slices.. not horizontally 

the doc doesn't  say if the range is a cone of FOV size. or a slice?  I'm hoping a slice , but maybe that is my software or using the sharpener to filter out 'not of intertest' pads. 

[rexxdad]

one more question, on the 5x and 8x, the loop in the driver that processes the sensor data  uses x(height) and y(width)

my assumption is that data is from and assumed orientation  where the sender sbdvrecei er are horizontal, parallel to the ground.

in our case they will be vertical, so the processing should be reversed. .  x is width and y is height, right? the hardware and driver dont know the physical orientation.  

[John E KVAM]

Exactly correct. In a cell phone the Transmit and the receiver are along a horizontal axis, but there is now requirement. People rotate their cellphones all the time. 

Rather than learn which axis is which I just test it by moving my hand into the FoV slowly. Some people like mirrored, some don't. And the rotation is up to you.

- john

[rexxdad]

thanks. our hardware is mounted on a wall, and we want to control the size of the fov

I got it now.  the sparkfun processing app really gives you a visual, attached.

sensor 8ft off the floor, full 64 cell view

red is the wall behind

blue is a counter top, at 5ft down from sensor

green is the floor

we will narrow to the center  2 wide 4 high cells.