Understanding VL53L3CX histogram data

[dscdsc]

Hi, I'm a little confused about the data that is returned by VL53L3CX sensor. Here's a video illustrating the data.

I would expect the histogram to be a time-series of the return pulses, with position on the x-axis representing their arrival times (directly mapping to distance), but instead its a single pulse with a fixed position and only the intensity of it changes. Am I thinking about this data wrong?

[John E KVAM]

That histogram data looks strange. When you call the get_additional_data function you should only see one 'hump' changing. Those smaller 'echos' aren't really there.

The other thing about your experiment is the light goes out in a cone, and your table top is in the field of view after a bit of distance. No problem if you table is flat as glass, but it reflects. (at distance N the diameter of the cone is 1/2 N).

One note about the histogram. The histogram contains ambient light measurements in the first 4 bins of every-other range. Make sure you account for that.

Each 'bin' of the histogram accounts for about 20cm. So with your short movements, I would not expect much to change except the amplitude.

(the range is the bin number of the first bin above the ambient + ratio between the initial bin and the next bin.)

• john

[ABesp.1]

I've checked my histogram data generated by VL53L3CX Sensor and I also have those additinal spikes in my plot (see below), although there are no additonal objects within field of view. The Sensor is fixed in 70cm height and directed towards a white wall in 60cm distance. I assume the calibration data has not been included yet, since actual range report seem to be okay. Where do these two spikes come from?

 

[John E KVAM]

I think there is something wrong with your data capture. You are right. One object - like a wall will give you 3 'posts', like you have, but you will not those repeats.

Would you be willing to share some pseudo code?

Each bin is 20cm (more or less) So at 60cm you would expect to see data in the 3rd bin. And adjustments within the 20cm depends on the ratio between the first and second post. So I would have expected to see two bins at almost the same height as you have.

At 70 cm the initial post would be about half that of the second one.

That data almost looks like the combination of multiple collects. Very similar, but slightly different values - what I would expect from multiple collects.

• john

[ABesp.1]

Alright, I have defined the following array inside my result structure

int32_t histogram[VL53LX_HISTOGRAM_BUFFER_SIZE];

which holds bin data for each VL53LX_MultiRangingData_t

memcpy(result->histogram,
	VL53LXDevDataGet(pdev, LLData).hist_data.bin_data,
	sizeof(result->histogram));

Then I just format it into a string

HAL_StatusTypeDef TransmitHistogramDataRS232(
		UART_HandleTypeDef *huart,
		measurement_result *rdata)
{
	char bin[5];
	char buffer[150];
 
	sprintf(buffer, "%u;%u;", HISTOGRAM_DATA, rdata->sensor_id);
 
	int i = 0;
	while (i < VL53LX_HISTOGRAM_BUFFER_SIZE - 1)
	{
		sprintf(bin, "%i-", (int) rdata->histogram[i]);
		strcat(buffer, bin);
		i++;
	}
	sprintf(bin, "%i", (int) rdata->histogram[i]); // print last element without splitter
	strcat(buffer, bin);
	strcat(buffer, ";\r\n");
 
	return HAL_UART_Transmit(huart,
			(uint8_t*) buffer,
			strlen(buffer),
			strlen(buffer) * 10);
}

On my computer a simple python script is running, which encodes this string to an array again and plots the data.

Edit: By the way, I also realised that two subsequent histograms always differ by a shift along the x-axis. Is that a correct behaviour?

[John E KVAM · Accepted solution]

I think you found a different way to get the data than we suggest.

We use:

VL53LX_Error VL53LX_GetAdditionalData(VL53LX_DEV Dev,

VL53LX_AdditionalData_t *pAdditionalData)

This function will return the histogram data.

But there is a trick. The data is formatted for the hardware and not for you.

Under the covers there are 2 ranges (an 'a' and a 'b' range)

The first 2 'bins' of the arrays are NOT histogram data.

And the next 4 bins of the 'a' array are ambient data - not histogram data.

So if you use VL53LX_GetAdditionalData and plot starting at bin 6 of the odd ranges and bin 2 of the even ranges you will do better.

The A ranges have 20 valid bins, the B ranges have 24 valid ones.

The other minor point in your experiment is the sensor sends out a cone of light such that the diameter of the circle of illumination is 1/2 the distance.

This is a long way of saying that your table is in play if you mount your sensor that low.

[FLiu.3]

@ABesp.1​ Hello, have you sovled the 'repeated posts' problem?

@John E KVAM​ We also met the similar problem, when we faced towards a white wall in ~60cm distance, the data we collected are shown below.

Objects=1, Status=0, Distance=613mm
918   868 48957 65546 35408  1175  1143   964   916   940 48461 66164 36065  1159  1113   947   919   944   941   928   846   880

where the first row is achieved by `VL53LX_GetMultiRangingData` and the second row is by `VL53LX_GetAdditionalData`. Code is attahced as following.

status = VL53LX_GetMultiRangingData(Dev, pMultiRangingData);
status = VL53LX_GetAdditionalData(Dev, pAdditionalData);
pHistData = &(pAdditionalData->VL53LX_p_006);
 
if (pHistData->number_of_ambient_bins > 0) {
    if (status==0) {
        status = VL53LX_ClearInterruptAndStartMeasurement(Dev);
    }
    continue;
}
// You mentioned that
// 'The first 2 'bins' of the arrays are NOT histogram data.'
// 'And the next 4 bins of the 'a' array are ambient data - not histogram data.'
for(int i = pHistData->number_of_ambient_bins+2; // start from truly histogram data
    i < VL53LX_HISTOGRAM_BUFFER_SIZE; i++) {
    printf("%5d ", pHistData->bin_data[i]);
}
 
no_of_object_found=pMultiRangingData->NumberOfObjectsFound;
printf("\n#Objects=%u, ", no_of_object_found);
for(j=0; j<no_of_object_found; j++){
    if(j!=0)printf("\n");
    printf("Status=%u, Distance=%hdmm",
            pMultiRangingData->RangeData[j].RangeStatus,
            pMultiRangingData->RangeData[j].RangeMilliMeter
    );
}

We have noticed two problems from these collected data.

1. One additional cluster of spikes appeared although there are no additonal objects within field of view (i.e. the repeated posts problem). You mentioned that it looks like combination of multiple collects, how can we solve it?
2. There are obvious offset for all histogram data, are they come from ambient light? how can i remove them? (one possible solution maybe directly subtract all the values by the estimated ambient value in `VL53LX_histogram_bin_data_t`, i.e. `VL53LX_p_028`)

@Eleon BORLINI​