Transform library support for binnings 6, 8, 12 and 24 - VL53L9CX

[GZOJRO]

Section 2.5 of UM3656 says "For a complete description of the library capabilities, refer to the vl53l9-transform-c documentation." The X-CUBE-53L9A1 v1.0.0 package ships Documentation/ media-object/transform-c.chm and media-c.chm, but those document the generic transform framework they do not contain any mention of VL53L9, binning or resolution.

In vl53l9-transform-c, _retrieve_output_size() accepts only raw frame sizes 14842 (54x42) and 3844 (24x20); the stream capability tables likewise list only those two resolutions. Calling the pipeline at other binnings is rejected, so 18x14, 12x10, 8x6 and 4x4 produce raw data with no calibrated depth.

The underlying algorithms appear resolution-generic — vl53l9_algo_extract() takes frame width/height, crop offsets and binning as parameters, the calibration offset map is bicubic-resized to arbitrary width/height, and the radial-to-perpendicular map is computed per width/height/binning.

Questions:

• Is support for the other binnings planned, or deliberately excluded?
• If we were to extend it ourselves, could you supply the pre-crop raw frame geometry and crop offsets for each binning? We can infer the uncropped cases from Table 12 (18x14 -> 3 x 504 B + 126 B = 1638 B, matching exactly; 12x10 -> 780 B, matching), but the cropped cases do not close: 8x6 computes to 312 B against the 416 B. Guessing these offsets risks silently misaligned zones, which we are not willing to ship.

[MathieuA]

Hello,

Yes, other binning modes will be supported later.

The current focus is on higher resolutions because these resolutions are used most often. Other resolutions will be supported later by the post-processing library.

If there is a specific use case for lower resolutions, please share it.

 

Yes, the Datasheet table 12 values show the raw map size.

The binning modes 2, 6, 8, and 24 are straightforward. The raw data dimension equals the number of pixels multiplied by 2 because the data is encoded on 16 bits. Therefore, 54 x 42 x 2 = 4536 bytes per map.

Binning modes 4 and 12 are more complex because the captured area is square, at 24 x 24 or 8 x 8. However, because the module lens is rectangular, the first and last rows must be cropped. This is not a full hardware crop. Instead, receiver cells are disabled during exposure. The raw maps are sent in 24 x 24 or 8 x 8 format, and the crop information is used during data processing.

I hope it answers your question.

Best Regards,
Mathieu

[GZOJRO]

Hello,

Thank you for your reply. This clarifies our doubt regarding the frame geometry.
 

Our main focus is optimizing the system for latency and speed, so we were wondering whether lower binning configurations could be used. We would also appreciate some clarification regarding the sensor-side processing time.

In our measurements, the sensor consistently appears to introduce an overhead of approximately 4 ms between the end of exposure and the data-ready interrupt, before any data is transmitted to the STM32. Since we only have one evaluation board available and its MIPI CSI interface is not routed, hence we are exploring alternatives.

Our test setup is:

• MCU: STM32N657 @ 800 MHz

• Interface: I3C @ 12.5 MHz

• Sensor mode: LONG

• Timing is measured using the Cortex-M55 DWT cycle counter

• We measure the interval between issuing the frame trigger and receiving the data-ready (INTR) signal.

• This interval occurs entirely before the I3C read begins, so we believe it represents sensor-side processing time.

Our measurements are:

Binning	Exposure	Response	Response − Exposure
4	2 ms	7534 µs	5534 µs
4	4 ms	8193 µs	4193 µs
4	6 ms	9941 µs	3941 µs
4	8 ms	12343 µs	4343 µs
2	2 ms	7347 µs	5347 µs
2	4 ms	8202 µs	4202 µs
2	6 ms	10106 µs	4106 µs
2	8 ms	12507 µs	4507 µs

This suggests that there is roughly 4 ms of sensor-side overhead after exposure and before the data becomes available, and that this overhead is largely independent of the resolution/binning configuration.

We also noticed that reducing the exposure to 2 ms does not reduce the total response time proportionally, suggesting that there may be a minimum processing/response-time floor.

We initially suspected that this overhead might be related to DSS. However, repeating the sweep with DSS disabled changes the response time by only approximately 377 µs at 24×20 and 682 µs at 54×42, consistently across the different exposure times. 

Could you please confirm whether our interpretation is correct? In particular, we would appreciate confirmation on:

1. Whether approximately 4 ms sensor-side overhead is expected.

2. Whether this overhead is largely independent of binning/resolution.

Thank you.

[MathieuA]

Hello Gzojro,

The following application note can be consulted: https://www.st.com/resource/en/application_note/an6522-guidelines-for-tuning-ranging-profiles-with-vl53l9cx-stmicroelectronics.pdf

It explains the relationship between exposure, binning, the streaming interface, dynamic spad selection (DSS), and power modes.

The benefit of binning is small during the total frame integration.

From this point of view, the main benefit of binning is to reduce the exposure while keeping the same signal-to-noise ratio (SNR). However, it is worthwhile for an outdoor application with low IR ambient light, because performance is good with 4 ms exposure at full resolution.

Another advantage of binning is that it reduces the volume of data. If a MIPI interface is used, the frame size does not matter, but with an I3C or I²C interface, it does. Binning 4 reduces the frame size by a factor of four compared with binning 2. The readout duration can drop to 3 ms with an I3C interface.

To answer the 2 questions:

• yes 4ms is expected
• Yes this overhead is due to internal FW activity

BR,
Mathieu

[GZOJRO]

Hello,

Thank you for clarifying.

After a few more tests with the same setup we observed that the exposure time we set has some overhead as well.

For example, in LONG/Ambient we request 4 ms and the part takes 7295 µs from trigger to frame-ready, against 6631 µs at 1 ms — a difference of only 664 µs for 3 ms of extra exposure. Investigating this, we found three separate effects, and we would like to confirm our understanding of each.
 

For example, at 24×20 (binning 4) and an 800 MHz host:

• 1 ms requested exposure → 6631 µs trigger-to-frame-ready
• 4 ms requested exposure → 7295 µs trigger-to-frame-ready

We investigated this and found what appears to be a minimum time per ranging step.

Using shots_base directly, we measured:

shots_base	Delivered exposure	Trigger → frame ready
4	1744 µs	6634 µs
5	2181 µs	6631 µs
6	2617 µs	6631 µs
7	3053 µs	6806 µs
8	3489 µs	7046 µs
9	3925 µs	7295 µs
11	4797 µs	8080 µs

Below about 3.4 ms delivered exposure, increasing the exposure does not change the frame time. Above this point, the response increases approximately linearly.

We also repeated the test in SHORT/Precision and found a similar floor:

• LONG: ~6631 µs / 6 ranging steps ≈ 1105 µs/step
• SHORT: ~7599 µs / 7 ranging steps ≈ 1086 µs/step

This makes us suspect there is a minimum duration of roughly 1.09 ms per ranging step.

We also verified that Dynamic SPAD Selection is not causing this floor; disabling DSS adds a nearly constant ~430 µs.

Could you please clarify the following?

1. Is there a documented minimum time per ranging step of approximately 1.09 ms?
2. Can this time be reduced through any supported configuration, such as power mode, VCSEL settings, or a shorter ranging sequence?
3. Can the number of ranging steps be configured directly? We see STREAM_STEP_NUMBER, but do not see a public API for it.
4. We observe approximately a 9% overhead relative to the delivered exposure. Is this explained by any datasheet?
5. Is there a supported way to request sub-millisecond or non-integer exposure times, or is directly modifying NB_SHOT_STEP the only way to do this?

We are mainly trying to understand the minimum achievable frame latency and whether the exposure/step timing can be optimized further. Please let us know if there is any inconsistency in our setup or understanding.
 

Thank you.

[MathieuA]

Hi,

There are FW activity between before, after and in parallel ot the exposure and also between each step (and Channel illumination).
Then for a 7 steps ranging mode the Firmware will take the control 14 times and program both the Hardware and Laser Driver, duration is stable with the profile/exposure but a bit faster in 6 steps ranging mode.

In parallel of this the Firmware is also computing the pixel sensitivity (DSS), duration is resolution dependent.

Before the exposure the firmware is waking up different IP/component and after it put them in standby.

All these programming steps cost few us.

About the exposure configuration, yes, you can modify the API to accept sub millisecond argument.

Best Regards,

Mathieu

[GZOJRO]

Hi Mathieu,

Thank you for the clarification.

Since the current driver does not permit frame periods below 10 ms, we tested the sensor in slave mode by applying a 100 µs low pulse on SYNC_IN to trigger each frame.

With this approach, the sensor operates at up to 145 Hz with 1–2 ms exposure and 129 Hz with 4 ms exposure, without dropped frames or noticeable changes in measurement data.

During 5-minute indoor tests, the reported sensor temperature stabilized at approximately 52 °C at 100 Hz and 59 °C at 125 Hz (4 ms exposure).

We would appreciate your clarification on a few points:

1. Laser safety: Does SYNC_IN-triggered operation above 100 Hz remain compliant with Class 1 laser safety requirements and the datasheet specifications?

2. Frame-rate limitation: Is the 10 ms minimum frame period a laser safety restriction, or is it simply the minimum characterized operating period?

3. Temperature limits: What are the maximum permissible operating temperatures for the sensor die and laser driver?

4. VCSEL lifetime: Could a cumulative laser on-time of approximately 0.5 seconds per second affect VCSEL lifetime or long-term reliability?

5. Higher frame-rate support: Would ST consider operation at approximately 125–140 Hz safe and reliable for continuous use, and is this operating range officially supported?

We would appreciate your guidance on whether this configuration is suitable for sustained operation, particularly regarding laser safety and long-term reliability.

Thank you for your continued support.

[MathieuA]

Hi,

Yes, using the external synchronization pin is a good approach to maximize the frame rate.

There is no laser safety risk for several reasons.

In this context, what matters is the average emitted power. The average power depends on the emission duty cycle, which is the ratio of the VCSEL emission period to the acquisition period during frame acquisition. It also depends on the frame duty cycle, which is the ratio of the exposure time to the frame period.

The module limits the maximum emission duty cycle to 5% per step, and the default ratio in the profiles is 4.4% maximum, but in average during a frame we are more at 3%. These limits ensure compatibility with Laser Class 1.

The module was tested in the worst-case emission condition, which occurs at 30 FPS with an exposure duration greater than 28 ms. Above 100 FPS, the frame duty cycle is lower because the exposure time is shorter. As a result, the VCSEL is used less.

The frame rate limitation is linked to the frame period. The device does not start another frame acquisition until the previous acquisition is fully complete. Make sure that another frame is not triggered too early.

During sensor evaluation, 2 ms was identified as the physical limit for stable and accurate measurement. An exposure time above 2 ms is recommended. If the platform can stream and process more frames, that is acceptable. A maximum of 120 FPS was reached with a CX3 CPU.

The sensor was characterized and qualified for an ambient temperature range of -40°C to 70°C, but it stops operating if the junction temperature exceeds 105°C. This behavior is a safety feature.

The sensor is expected to self-heat less at higher frame rates because the frame duty cycle is lower than that of a 60 FPS profile with a 12 ms exposure time, for example.

Cheers,

Mathieu

[GZOJRO]

Hello Mathieu,

Thank you again for answering our questions about SYNC_IN and exposure. We have a follow-up about connecting several VL53L9CX sensors to a single CSI-2 port.

Our setup uses a VL53L9-based board with an STM32N657 (NUCLEO-N657X0-Q). The sensor streams RAW8 over one data lane at 1 Gbps on VC0. We are using ST’s driver, and 54 × 42 at 100 fps works well.

We would like to connect three or four sensors to the N657’s CSI-2 receiver and trigger them through SYNC_IN at staggered times, so their frames do not overlap on the link. Each frame occupies the link for about 0.24 ms of the 10 ms period.

We checked the receiver’s lane-state flags between frames. The clock lane remains in high-speed mode throughout streaming, while the data lane returns to the stop state (LP-11). This suggests that the sensors keep driving both lanes, which would prevent them from sharing the same lanes without a MIPI switch or bridge.

Could you please clarify the following?

1. Clock-lane mode: Can the VL53L9CX use non-continuous clock mode and return its clock lane to LP-11 between frames? If so, which register or firmware patch enables this?
2. Pin states: Can the MIPI clock and data pins be placed in high impedance between frames while the sensor continues ranging? What are their states in hardware standby (XSHUT low) and software standby?
3. Virtual channels: The driver defines the virtual-channel register as one bit. Are VC0 and VC1 supported? Can VC2 or VC3 be used?
4. I3C with multiple sensors: Do two VL53L9CX sensors have different 48-bit provisioned IDs for dynamic address assignment, or should we release XSHUT one sensor at a time and assign addresses sequentially?
5. Reference design: Is there a reference design or recommendation for connecting multiple VL53L9CX sensors to one CSI-2 host, such as a 2:1 MIPI switch or an aggregator?

Thank you for your continued support.

[MathieuA]

Hi ​@GZOJRO,

Sure, is it possible for you to open a new topic on Multiple Devices on MiPi ?
I’m working on a dedicated documentation and webinar (Nov 10th).

Best Regards,

Mathieu

[GZOJRO]

Sure, will do.

Thanks!