Please explain the optical center values returned by ST's VL53L1X API function VL53L1_GetCalibrationData()

[JamesLo]

I am using Pololu's adaptation of the ST library for Arduino. When I call VL53L1_GetCalibrationData() and print the optical center x and y values, I get 0x70 for both. How should I interpret this value? I've tested on an Arduino Uno as well as a MKRZERO. I was expecting these values to be in the range 0x00 .. 0x0F since the SPAD array is 16 X 16. Is nibble order simply reversed? If so, should one reverse the nibble order when identifying a SPAD for other API functions, e.g. VL53L1_SetUserROI()?

[JamesLo]

Oh, OK, I think I know now. The VL53L1_optical_center_t struct is commented "4.4 format" which I assume means it's a fixed point fraction, consistent with the value being returned. I wonder if it ever returns the fractional part?

[Nick Wilke]

I've been doing a whole bunch of testing the last few weeks, and I haven't seen the fractional range value be anything other than 0

[John E KVAM]

​Not quite. There are 256 individually numbered SPADs. But they are numbered in quadrants.

Take a look at UM2555 - It explains the numbering system to you. It's on ST.com - just search for it.

Also download the latest VL53L1X UltraLite driver. Even if you don't use it you can see how the ROI stuff works.

Good luck.

[JamesLo]

I think the UltraLight driver is different from the ST library adapted by Pololu (https://github.com/pololu/vl53l1x-st-api-arduino) which I gather is based on an older ST library. It hides the hardware SPAD numbering details from the application and doesn't have a function to set the ROI center. For setting ROI, the relevant doc in my case is UM2356 section 2.5.6. I also traced the calls in VL53L1_SetUserROI to VL53L1_encode_row_col, which computes a single SPAD identifier, one conforming to the spec in UM2555 section 4.1, from a 0-based xy pair. So while I agree that the hardware identifies the SPADs as 256 individually numbered elements, I don't see any evidence that the API I'm using refers to them that way (from the application's perspective).

[John E KVAM]

​When I wrote the UM2555, I added a couple of functions to the UltraLite driver - you need to go get the latest version of STSW-IMG009. https://www.st.com/content/st_com/en/products/embedded-software/proximity-sensors-software/stsw-img009.html

Sorry about that.

Actually Pololu did a fantastic job of reverse engineering our software. They are one of the reasons we wrote the UltraLite driver. Feel free to take whatever you can and add anything from the UltraLite driver you need. I tried to make everything in the ULD as simple as I could so you can take whatever you need.