Suppose a prototype should react when an object reaches a particular place. You might detect a dark mark passing a sensor, or measure how far away a surface is. Both can trigger an action, but they answer different questions and create different mechanical requirements.
The distinction matters for interactive objects and small mechanisms. A presence-sensing discussion for an art project on the Arduino forum shows why the intended target must be specified: recognizing a person is not the same as noticing any nearby object. On our bench we tried two narrower tools, a single-channel reflectance module and a VL53L0X time-of-flight ranging module, on a Raspberry Pi Pico with MicroPython programs built in BIPES.
A reflectance threshold observes a local surface condition
The reflectance module sends light toward a nearby surface and compares the returned light with a threshold set by an onboard potentiometer (R5 on this module). Turning it moves the switching point. It is not a distance calibration.
Our program read GPIO6 with pull-up enabled, tested for a low reading and printed a trigger message every 20 ms while the condition held. We moved the sensor by hand near a contrasting target. Our written notes described a different pin and a black/white branch that was not in the program we actually ran. The supported result is a switching response in that hand-held arrangement, not a working line follower.
Surface finish, spacing and ambient light all affect this kind of sensor. Before attaching meaning to high or low, record both states with the target materials and the mounting distance you intend to use. Which state means "dark" depends on the module's circuit; it is not a universal rule.
A ranging device returns a number that still needs interpretation
The VL53L0X module used I2C0 with SDA on GPIO4 and SCL on GPIO5, after installing its driver. The program requested repeated range readings; the block version used a 200 ms delay and the console version one second.
The output included values such as 38 and 156, and also 8190. That value should not be presented as a measured 8.19 m. Our record does not establish what it means. It is a reason to read the driver, find how it reports invalid or out-of-range results, and filter them before any reading triggers an action.
In practice that means logging readings with no target in view, with a target beyond the useful range, and with a target too close, and seeing what the driver returns in each case. Only then decide which values the product treats as "nothing there" and which as a valid distance.
The enclosure window is part of the sensor
ST's VL53L0X product information covers crosstalk compensation and integration behind cover glass. That makes the enclosure's optical window part of the design, not a cosmetic layer added after a bench test. Our test used the open module with no window, so it says nothing about performance behind a cover. The same is true of the reflectance module: a window in front of it changes what light comes back.
Choose by the question
| What the product needs to know | Sensor to try | What to test next |
|---|---|---|
| Has a mark or edge passed a fixed point? | Reflectance switch | Threshold with real materials and spacing |
| How far away is a surface, and is it changing? | Time-of-flight ranging | Invalid-reading handling, cover window |
| Is a person present? | Neither alone | Define the target, then choose a method |
Neither sensor on its own establishes who or what is in front of it, or reliable detection of someone standing still. If the product depends on that, define the target and test conditions first.
For the next prototype, fix the sensor, target and enclosure geometry together. Mount the sensor where it will live, put the real window in front of it, and log readings across the full range of positions, including no target at all.