VL53L0X returns 0x1FFFF (8191)

[Hardwariano]

Hello, I'm using a VL53L0X and it returns 0x1FFFF depending on whether a function within "VL53L0X_StaticInit" is commented or not during initialization.

If "VL53L0X_set_reference_spads" is commented, the sensor sends values (with a large offset). But, if "VL53L0X_set_reference_spads" is not commented, the sensor sends 0x1FFFF all the time.

Is this problem related to this other ST forum thread?

Regards

[Julien NGUYEN]

​Hi ,

We recommend you do not modify the basic functions of the driver.

To correct the offset error, you have to call the offset calibration function once the VL53L0X_StaticInit() function is called.

Thanks,

Julien

[Hardwariano]

Hi Julien, thanks for your answer.

Sorry, I think I explained it wrong.

My main problem is not the offset (I will use the function "VL53L0X_PerformOffsetCalibration" as you suggest to correct it).

My problem is within the "StaticInit" function. I don't want to modify the API that ST gives me, but the thing is that without modifiying the library, the sensor doesn't work (sends 0x1FFFF all the time). The VL53L0X only does something when I comment "VL53L0X_set_reference_spads" (I figured it out by trial and error).

That's why I asked if this problem was related to this other "initialization problem" thread. I'd like to know if it's an internal sensor problem or has to do with my program.

Regards

[Julien NGUYEN]

​Hi DDSG-1

The VL53L0X_set_reference_spads() function returns 0 from my side.

Could you please go inside the function and tell me where you get a returned status different of 0 for the first time.

Thanks,

[Hardwariano]

Hi Julien,

The function "VL53L0X_set_reference_spads" returns 0 all the time. This function sends the following frames:

• 56 FF 01
• 56 4F 00
• 56 4E 2C
• 56 FF 00
• 56 B6 B4
• 56 B0 00 F0 FF 01 00 00
• 56 F0 /// 57 00 F0 FF 01 00 00

When I request distance measured, I get the following all the time:

• 56 14 /// 57 21 06 BF 04 00 00 00 00 00 00 1F FF

The strange thing comes when I change the "local Status" variable to a "volatile local/global Status" variable (I only make this change in my code). In this case, sent frames are the same as before (56 FF 01, 56 4F 00, etc) except for the distance:

• 56 14 /// 57 5B 06 1B 04 2C 1C 0B 30 00 12 00 5D
• 56 14 /// 57 5B 06 18 04 3C 80 0B EE 00 0E 00 5E
• 56 14 /// 57 5B 06 BF 04 01 C2 04 47 00 AC 01 09

As you can see, now the sensors detects my hand movements.

Any idea?

[EDIT] It seems that the weird "volatile trick" only works sometimes, so there must be something else I don't understand.

Anyway, the problem related to commenting or not commenting the function "VL53L0X_set_reference_spads" is the same: the sensor returns 0x1FFF if not commented, and real distances if commented.

Regards

[John E KVAM]

The only thing I can think of is you somehow got bad reference SPADs when you first calibrated and called the "VL53L0X_get_reference_spads", so when you set them after the next boot, you make a mess.

Is it possible?

[Hardwariano]

I'll take a look at the calibration process.

Thanks

[Hardwariano]

Hello John.

I checked the program and the calibration process and now it works well. I'm not sure what happened but I didn't get the wrong measurement again. I think that SPAD calibration is now correct.

Now I have some doubts about SPAD calibration. Function "VL53L0X_perform_ref_spad_management()" returns two values: refSpadCount and isApertureSpads:

1) Are these parameters manufacturing dependant? I ask because my board has 3 VL53L0X and each one returns different values before and after VL53L0X_perform_ref_spad_management():

• Sensor 0: After staticInit() --> refSpadCount = 5 /// isApertureSpads = 0

After VL53L0X_perform_ref_spad_management() --> refSpadCount = 12 /// isApertureSpads = 0

• Sensor 1: After staticInit() --> refSpadCount = 6 /// isApertureSpads = 0

After VL53L0X_perform_ref_spad_management() --> refSpadCount = 10 /// isApertureSpads = 0

• Sensor 2: After staticInit() --> refSpadCount = 17 /// isApertureSpads = 1

After VL53L0X_perform_ref_spad_management() --> refSpadCount = 11 /// isApertureSpads = 0

2) ¿Could you please explain briefly what exactly those parameters are? I get an idea of what refSpadCount means, but I can't understand the meaning of isApertureSpads and why some sensors return 0 and others return 1 after staticInit().

I also can't understand why after VL53L0X_perform_ref_spad_management() they all have similar values (12,10,11 and 0,0,0)

Regards.

[MMeng.3]

Hi,

I have the exact same behaviour. Did you ever figure out what the problem was?

[Hardwariano]

Hi MMeng

Unfortunately I could not solve the problem.

What I did was to change the TOF sensor. I chose the VL53L1CX and VL53L1CB sensors.

Personally I think VL53L1CX/CB works better and are much easier to control and understand than VL53L0X. Also, the documentation and API are much better explained.

Regards

[John E KVAM]

To combat getting too much light in the sensor, some SPADS are covered with an Aperture to limit the amount of light that can get in. This is why we return the SPAD count as a floating point number.

The RefSpad is a region of the photon detect array that we use to determine when the laser is turned on. There is a fairly long time from the time we put power to the laser and when the laser starts emitting.

The calibration establishes which detector elements get triggered when the laser comes on and how many. As the geometry of the chip changes during the reflow process, we need to calibrate for this geometry. And if the light shines on some of the occluded 'aperture' SPADS, we need to use more.

Before you calibrate you get our factory calibration. After you calibrate you get the changes induced by the reflow process.

• john

[John E KVAM]

The RefSpads are those SPADs that trigger when the laser turns on. It's how we know the exact time the laser starts emittng. But the VCSEL is a different bit of silicon that the SPAD array, and really tiny differences in placement mean we need to know which are most effected by the laser - and those become the RefSpad.

At the factory we did a calibation. But during the reflow process, the gemotry of the chip changes every so slightly. And that means we have to recalibrate.

And thus some calibrations will return different numbers. That's not an issue.

Early on, we noticed that some chips were failing the RefSpad calibration - because the Factory number was so different from the current geometry that the calibration fails.

The trick, when this happens, is to set the RefSpad to 3 and try again. By bringing the RefSpad back to 'nominal', the calibration will pass. (This should have been fixed in a more recent release.)

-john

[MMeng.3]

Thanks for the reply. But this still doesn't work.

I've inserted a call to

 VL53L0X_SetReferenceSpads(&myDev, 3, 0);

either before the staticInit() or the PerformRefSpadManagement() but neither works. VL53L0X_PerformRefSpadManagement() constantly returns (0,0) for refSpadCnt and isApertureSpads for any device.

[John E KVAM]

the 8191 is what the sensor returns when something is wrong. (Check the RangeStatus. It's not 0.)

If you are having trouble getting PerformRefSpadManagement() to pass, try setting the refSpads to 3 and run the calibration again.

(On some chips, the reflow process warped the sensor so much that the internally set value is not close enough to allow the sensor to calibrate. Setting it to 3 prior to running the calibration seems to fix it.)

There are legitimate reasons to get 8191, but assuming you have a target within range, you should see it and get a good value.

But you need to set some reference SPADs, So that bit of code checks the NVM for them and if valid uses them, but it would be better if you calibrated the RefSpads and stored them in your memory and used those at boot up instead.

• john