2020-10-14 07:05 AM
Hi,
I am fighting with the offset calibration of multiple VL53L1X. I use the API ULD with Arduino.
I build a device to have 4 sensor[4] at 140mm far from a same plan. 2 of them give a good measure, 2 of them do not.
I have tried the following process to calibrate for each sensor[4] ({xx,xx,xx,xx} are the value during the debug):
sensor[i].GetDistanceInMm(&distance[i]); // distances are {115, 142, 143, 118}
uint16_t OffSetToF;
sensor[i].GetOffsetInMm(&OffSetToF); // returned values are {0, 0, 0, 0}
sensor[i].CalibrateOffset(140, &OffSetToF); //returned values are {26, 65533, 65532, 23}
sensor[i].SetOffsetInMm(OffSetToF); //with previous values {26, 65533, 65532, 23}
sensor[i].GetDistanceInMm(&distance[i]); // distances still are{115, 142, 143, 118}
Whatever the API (ST Ultra Light Driver or native ST_API), is the VL53L1X_GetDistance function (or GetDistanceInMm) supposed to give the measure corrected of the offset value calculated with the VL53L1X_CalibrateOffset function and setted with VL53L1X_SetOffset function (or SetOffsetInMm) ? or are we supposed to make the correction in our program ??
Regards,
Olivier
Solved! Go to Solution.
2020-10-21 09:57 AM
>>>VL53L1X_GetDistance function (or GetDistanceInMm) supposed to give the measure corrected of the offset value.
Exactly correct!
>>>or are we supposed to make the correction in our program ??
Well you certainly can make the correction in your program, but that's not the way we envisioned it to work.
65533 is a negitive number. And offsets can clearly be negitive.
So 115 + 26 = 141 which sounds right. and if 65533 is negitive 2, which would be right, and 655332 is -3 and 118+23 = 141 as well.
Accounting for rounding it's perfect.
But it doesn't appear that the offsets have taken effect, as you got the same answers you had.
Did you reset the chips?
Normally, one does the offset cal, the does a GetOffset() and stores that value in the MCU's EEPROM of flash.
then at reboot, one has to do a SetOffset with those values.
if you have done the calibration, the offset registers should have been set.
There is one trick...
The factory offset calibration is in the chip, but was rendered inaccurate during the reflow process.
So the offset cal function zero's this register before preforming the cal.
2020-10-21 09:57 AM
>>>VL53L1X_GetDistance function (or GetDistanceInMm) supposed to give the measure corrected of the offset value.
Exactly correct!
>>>or are we supposed to make the correction in our program ??
Well you certainly can make the correction in your program, but that's not the way we envisioned it to work.
65533 is a negitive number. And offsets can clearly be negitive.
So 115 + 26 = 141 which sounds right. and if 65533 is negitive 2, which would be right, and 655332 is -3 and 118+23 = 141 as well.
Accounting for rounding it's perfect.
But it doesn't appear that the offsets have taken effect, as you got the same answers you had.
Did you reset the chips?
Normally, one does the offset cal, the does a GetOffset() and stores that value in the MCU's EEPROM of flash.
then at reboot, one has to do a SetOffset with those values.
if you have done the calibration, the offset registers should have been set.
There is one trick...
The factory offset calibration is in the chip, but was rendered inaccurate during the reflow process.
So the offset cal function zero's this register before preforming the cal.
2020-11-15 11:02 AM
Thank you.
2024-07-27 03:04 AM
Having a similar issue but I understand your response. My question is more about what/where to call SetOffset at boot time.
Assuming:
At Calibration Time:
CalibrateOffset(140, &OffSetToF);
....Store OffSetToF in EEPROM....
At Boot Time:
SetOffsetInMm(....OffSetToF from EEPROM....);
Two questions:
Is there any negative impact to calling SetOffSetInMM with 0? The very first boot, before running Calibration, would do this?
Where exactly do you make the call to SetOffSetInMM in the boot up sequence? For instance, should it be called after boot but before any StartRanging?
Thank you!