Solved: Re: vl53l1cb: how to get the maximum distance - STMicroelectronics Community

hello, I'm using a vl53l1cb satel board, but I'm not been able to get a reading greater than 4m (aprox).

I'm using the vl53l1 zephyr RTOS driver, and I'm aware that the roi selection is different than the one of the UM2133, so I'm not selecting a specific roi, but still the maximun distance reported by the sensor is 4. Do you guys have any suggestion on how to be able to get the maximun distance reading using the zephyr driver?

1 ACCEPTED SOLUTION

Accepted Solutions

Alas you cannot. You have to use the ST driver. Here is why...

Natively the sensor is limited to 4m. That is its aliasing or wrap-around point.

Aliasing occurs when the photons from flash A return AFTER the flash B is sent out.

A target at 4.2 meters will return 0.2 meters - because the flashes of light got mixed up.

To detect this condition we use two sub-ranges with different pulse repetition intervals (PRI) and thus two different aliasing points.

If the two sub-ranges agree, you have a valid target less than 4.0 meters.

Let us assume the aliasing points are at 4.0 and 4.2M. (I might be off a bit.)

A real target at 4.4M would thus return 0.4 and 0.2 respectively.

The ST driver could simply report an error 4 (phase mis-match) and be done with it.

That's what your driver does.

But some bright programmer, decided to take this information and use it. If the phase difference is very close to 0.2 meters, one can infer that there was a wrap - and that one should add 4M to range A and 4.2M to range B.

But it's all done in the latest release of the ST driver software.

I'm guessing whoever wrote your driver took the ST driver, and translated it. But they did it BEFORE the distance modification was done.

There are lots of reasons to use translated drivers. ST has a certain 'style' of writing code, that some people find issues with. (Heck, it even drives me nuts.) But in this one case you really have to use the native ST code.

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

View solution in original post

4 REPLIES 4

Alas you cannot. You have to use the ST driver. Here is why...

Natively the sensor is limited to 4m. That is its aliasing or wrap-around point.

Aliasing occurs when the photons from flash A return AFTER the flash B is sent out.

A target at 4.2 meters will return 0.2 meters - because the flashes of light got mixed up.

To detect this condition we use two sub-ranges with different pulse repetition intervals (PRI) and thus two different aliasing points.

If the two sub-ranges agree, you have a valid target less than 4.0 meters.

Let us assume the aliasing points are at 4.0 and 4.2M. (I might be off a bit.)

A real target at 4.4M would thus return 0.4 and 0.2 respectively.

The ST driver could simply report an error 4 (phase mis-match) and be done with it.

That's what your driver does.

But some bright programmer, decided to take this information and use it. If the phase difference is very close to 0.2 meters, one can infer that there was a wrap - and that one should add 4M to range A and 4.2M to range B.

But it's all done in the latest release of the ST driver software.

I'm guessing whoever wrote your driver took the ST driver, and translated it. But they did it BEFORE the distance modification was done.

There are lots of reasons to use translated drivers. ST has a certain 'style' of writing code, that some people find issues with. (Heck, it even drives me nuts.) But in this one case you really have to use the native ST code.

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

Hello John, when you say the "ST driver" are you referring to the STSW-IMG019?

To test the sensor I used the vl53l1 zephyr driver without any modification (I'm guessing that a driver for the vl53l1x chip, but in other post I read that you can run the vl53l1x code on the vl53l1cb). I thought I was going to be able to get reading in the 4 to 8 m range. How could it be that the sensors is natively limited to 4m? I wanted it to get reading greater than 4m.

As you said, I also tried to modify the vl53l1x zephyr driver to run the img019 but only got measurements of 0, do you have any idea of whats could be going on on that?

Yes - that is the one.

Could I have you read:

Solved: VL53L4CX which distance mode should I choose? - STMicroelectronics Community

He had the same issue. He was using the L4, but the issue is identical.

I know nothing about a zephyr driver. But I'm pretty sure they are not going to do the unwinding of the phase differences to get that max distance.

If you had any driver working, then you I2C works. Have a look at the platform.c and re-write those functions for you I2C. Perhaps you could even call the I2C write functions that your zephyr driver uses.

That should be all you need to do to get it running. Then just look at some of the example code.

- john

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

Hello, thank for the help. I manage to get the sensor running. As you suggested i used the example to get the vl53l1_platform_ipp.c and others headers thas were not in the vl53l1's zephyr driver. But i'm still unable to get a long distance. I'm using ranging mode and i get good reading from 0 to ~180 cm, but can not get a reading beyond 180cm ( or 2m aprox). I usually got a negative value from that distance. Do you have any recommendation for that? I tested on a reflective white surface at night and the results were the same. I also run the i2c test to see if I got a bit swap somewhere but it was ok.

27 KB