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.