VL53L5CX works for the default VL53L5CX_RESOLUTION_4X4, but not for VL53L5CX_RESOLUTION_8X8

JahKMC · ‎2024-04-25

I'm using the example project provided for the VL53L5CX and it works fine with the default 4x4. The `vl53l5cx_init` method within the vl53l5cx_api.c is where I believed it should be configured in this section where I passed in VL53L5CX_RESOLUTION_8X8 to both send_offset_data and send_xtalk_data :

I also noted this post which said the buffer should be increased, which did not work. I wanted to know if anyone could supply an example of using the 8x8 resolution. The image below is the current output.

John E KVAM · ‎2024-04-25

In that code there is a function that sets the resolution. I think you are doing only half the work.

uint8_t vl53l5cx_set_resolution(
		VL53L5CX_Configuration 		 *p_dev,
		uint8_t				resolution)

This tells the sensor what the resolution is and any time it's needed the function calls get_resolution.

the call you made is to set the resolution in the crosstalk but does not set the resolution itself.

Dont worry about crosstalk until you have your coverglass.

- john

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

JahKMC · ‎2024-04-25

Thank you for the information! @John E KVAM I've set it here and it seems to somewhat work ? I am currently unable to output anymore than 37 values(please see the second screenshot) :

John E KVAM · ‎2024-04-25

When testing like this - point the sensor at something closer so that you absolutely know that there is a target in the field of view. First thing to do is verify you have at least on target. Next check the Range_Status. 5, 6, 9 and maybe 12 are valid, the rest are warnings that there is an issue. Then you can check the distance.

My guess is you have no target in those zones.

But without a picture I cannot tell .

- john

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

JahKMC · ‎2024-04-26

@John E KVAM I have tested it holding a book over the sensor. and the target_detected is returning 1 for the the array.

I rolled back to see what target_status(looked in the header and this looks to be the method) would return with 4x4 resolution and it returned 5 for each zone. When moving back to 8x8 it returned to me 0 and I continued to see the same issue in the screenshot from the previous post. Is there a reason why I'm retrieving 0(Ranging data not updated) in this case ?

JahKMC · ‎2024-04-30

@John E KVAM I had forgot to mention that I used the sensor connected to a H7, where I saw this issue, but using a F7 I saw no issues with the distance output.

That was an oversight on my part. If you have any information why, please let me know.

JahKMC · ‎2024-05-01

Is there any reason for the difference in output from the F-series(F7) in comparison to the H-series (H7 and screenshot above)?

John E KVAM · ‎2024-05-01

The sensor has no idea which MCU or CPU it's talking to. If you get different results, then there is something different about your setup. Be careful though. I was running some tests and could not duplicate them. It drove me nuts until I realized that the afternoon sun was affecting my experiments.

Run your tests with a sheet of white paper. Paper is 88% reflective and we can use it as a standard.

I don't know what your book looks like so I cannot render an opinion. But I know what the sensor does when looking at white paper.

Tape a few to a bit of cardboard if you want to cover the full field of view.

Include a picture of your setup from the sensors point of view. maybe I can spot something.

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

JahKMC · ‎2024-05-09

Hey, John. Here is an image of my current setup. Within the bin is the sensor:

Here is the output for distance when 8x8 resolution:

Here is the screenshot of the of 4x4 resolution:

Both distance outputs were done with this cover on top. I recall you mentioning the open space I am currently in could be affecting the values I am receiving, so I've chosen to cover the sensor whole. Both instances had a target status of 5. I've also tested it to measure towards the floor you see in the image and I still see the same pattern of lowered measurements ( I did this incase the space in the bin was too tight).Is there any reason for the difference given the set up I have ?

Please note I am currently running in VL53L5CX_RANGING_MODE_CONTINUOUS

JahKMC · ‎2024-05-14

@John E KVAM any update on this ? Let me know if you need any additional information(i.e. signal_per_spad, ambient_per_spad,etc).