cancel
Showing results for 
Search instead for 
Did you mean: 

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

JamesLo
Associate II

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()?

5 REPLIES 5
JamesLo
Associate II

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?

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
ST Employee

​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.


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.

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
ST Employee

​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.


If this or any post solves your issue, please mark them as 'Accept as Solution' It really helps. And if you notice anything wrong do not hesitate to 'Report Inappropriate Content'. Someone will review it.