How to make the VL53L8CH to get data with 64 zones with 18 bins at 15 Hz?

[Licx]

Currently I connected the X-NUCLEO-53L8A1 to F401RE, and I notice that on the web page of VL53L8CH, the sensor can get the data with 64 zones with 18 bins at 15 Hz. But when I use the VL53L8CH with the Example_12_cnh_data which use VL53LMZ_ULD_API, I found that when I set the cnh config to get the data with 64 resolution, 16 bins, and 15Hz, the fps I get from the serial port is only 3.6Hz, not 15Hz. Is there any way to improve the FPS of the code?

[Upasana]

Hey, I know this is not related to your problem but I was wondering if you could share the pinout config you used? since I am also using the same components.

[Licx]

I used X-NUCLEO-53L8A1, and connected it to F401RE. After that I used CubeIDE_F401RE_Example directly, which can be found in STSW-IMG043_ULD(https://www.st.com/en/embedded-software/stsw-img043.html). This Example can be used to view pin settings in cubeide.

[Anne BIGOT]

Hello

Your question regarding the FPS have been reached internally.
Please accept some delay in the response as Christmas time i coming.
Regards

[John E KVAM]

One might suggest it's not the sensor that's the limiting factor, but your MCU. Are you using a 1MHz I2C? Are you doing anything with the data that takes time? The sensor is not the limit here, but the IO bandwidth and doing something with the data. I'd look there. 

- john

[Licx]

Thanks for your reply, currently I am using F401RE and use the code based on Example_12_cnh_data derectly.

[Anne BIGOT]

The example code is only meant to be an example of how to configure and decode data.  Nothing in the code is optimised for speed.

 

Data size of the CNH data for 8 x 8 x 18bins is about 6KB   => best case about 60ms at 1000KHz I2C.

 

Sending data to host, via USART-USB link takes considerable time (921.6KHz baud rate)

 

In Example_12_cnh_data you can try commenting out all the printf() statements except the one that prints out the streamcount.   Then you will see what rate you can get data from the sensor ignoring the extra time it takes to send the data to the host.

 

To achieve higher frame rates you can use DMA to allow you to read data from VL53L8CH via I2C while concurrently sending data to the host via the USART-USB.

 

The STM32 firmware that is used with the MZAI EVK GUI project uses this approach with the data to be sent to the host being buffered before being sent to the host as a single block via DMA transfer.  With this method 10fps is achieved, with the limiting factor being the time it takes to send data to the PC host.

 

[Licx]

Thanks for your reply, I will try the solution that you mentioned.

[RogerM]

The data format implemented in the encoded_frame module is not something ST is documenting as it is treated as a "private" method to communicate between the EVK and the GUI. We don't have any libraries to share to read this datastream from the EVK.

However, having said that the format is very simple, and you are welcome to adopt it in your own code if you wish.
It sends data as binary blocks formatted as follows:
- a few text characters as a block header.
- a byte that contains a <block_type> value.
- a binary block of data.
- a crc value.
- a few text characters to mark the end of the block.

On the frame rate that you see (7.5fps) have you confirmed that the STM32 is able to capture at a higher rate if only minimal data is uploaded to the host, for instance just the print the frame number to the serial port...so the limiting factor is the upload to the host?

[Licx]

Thanks for your reply, I also think the limiting factor is the upload to the host.

[Licx]

Besides, as shown in the figure is a ball, the depth difference of one pixel is less than 3.7mm. But as shown in the histogram, the depth difference is more than 15mm. I would like to know if this is caused by noise or some other reasons?

 

[RogerM]

Sorry, I am not entirely sure what is expected in the screen shots.
But I can make a few general comments.
The basic histogram bin width in terms of difference-of-target-range-per-bin is about 37mm per bin.  So it is very hard to determine accurate ranges just by inspection of the histogram bins. 
On the other hand the "target range" zone output from the sensor uses quite sophisticated algorithms to extract target ranges from the histogram data -- so I would expect these to always give more accurate ranges.
On the the topic of "noise" in the histogram. The noise we see is just in amplitude, primarily caused by ambient light. We don't see any noise in the time / range dimension, i.e. no significant jitter in timing from frame to frame.
Hope this clarifies these points.