cancel
Showing results for 
Search instead for 
Did you mean: 

How to read only distance and signal strength from VL53L4CX and how to get better performance in a sunlit room.

kps98
Associate III

Hi,

I am using VL53L4CX sensors with a custom-made board which uses the STMH755ZI. I am using the library provided by STM to get the sensor measurements.

Initially, my tests were done using a Teensy 4.0. At that point, I noticed that a single VL53L4CX sensor takes around 3ms to get data through I2C when using the VL53L4CX library. However, when I switched to the VL54L4CD library, it was much faster, taking around 0.5ms per sensor. This includes all the data that the sensor provides.

After that, I moved to the STMH755ZI. Since this is an STM chip, I thought it might be more compatible and faster compared to the Teensy, as the TOF sensor is also made by STM. Contrary to my expectations, the time it takes to read one sensor significantly increased. Using the VL53L4CX library, it takes around 10-11ms to read data for a single sensor. Then I tried the VL53L4CD library and was able to reduce the time to 1ms per sensor.

I am working on a project with strict time constraints, so I commented out reading the unwanted data in the VL53L4CD library such that I am only reading the signal rate and distance. Now, I was able to reduce the time taken to 0.5ms. For all the above tests, I was using a 1MHz I2C speed. Why is it varying this much between microcontrollers when the I2C speed is the same?

I checked whether it is waiting for the data to be ready or not, but it is not. It is the I2C transmission that is taking all this time.

In almost all scenarios, the data I need is just distance and signal rate. The range I need is around 50cm, and the VL53L4CD library works the way I need it to. However, when I use it in sunlight (not directly under the sun but in a sunlit room), as expected, the sensor gives terrible results. I noticed that the datasheet says the VL53L4CD will give 90% readings for a gray target under 400mm outdoors, whereas the VL53L4CX will give the same performance up to 1100mm. Is this purely based on hardware? I am actually getting really poor readings after 330mm and I am using the VL53L4CD library with the VL53L4CX sensor. Will changing the library help in this scenario? If I change the library, will I be able to reduce the time taken for reading the data to 0.5ms by reading just the distance and signal strength? If so, how can I do it, as it looks much more complex than the VL53L4CD library?

Thanks,

Kiran

1 ACCEPTED SOLUTION

Accepted Solutions

The 24 4-byte integer VL53L4CX raw data is a lot more than the 2-byte signal strength and the 2-byte distance. So, I'd expect 10X time spent in the I2C transfer and then your MCU still has to analyze the data. 

The CX code is technically more accurate, so if you are not seeing it, perhaps there is a configuration issue. I'm guessing integration time (TimingBudget).

It all our development we are doing nothing other than servicing our sensor. But I expect your MCU has something else to do. So, the CD code does have its advantages. 

When it comes to sunlight, you are going to have problems. The sun puts out a tremendous amount of 940nm light and that is very difficult to overcome. 

Best I can tell you is to try it in your application. 50cm is not out of the question depending on the size and reflectivity of your target. Your worst case is going to be on a very bright sunny day (up to 120K Lux) and with the sun behind the sensor reflecting off your target. 

- john


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.

View solution in original post

5 REPLIES 5
John E KVAM
ST Employee

The VL53L4CD and the VL53L4CX are basically the same chip differing only in how the software works. But they are NOT interchangeable. The L4CX silicon has been selected to run the more demanding software.

If you already have the L4CX hardware and are running it with the L4CD that's just fine. And in fact, you can do it the other way round for short testing. (Buying the L4CD and running the CX code will work most of the time, but please don't do it in production. It leads to quality issues eventually.)

The CD code runs on the sensor - and you just read the result. It's easy, and quick. 

the CX code returns the raw data to your MCU. And it is your host that digs out the answer. 

This actually works better - although it takes more work. We do provide the code, so you should be able to just swap it out. 

In the L4CD we use an algo called Sigma Delta (although it's not quite the same as you get when you google it.) As its name suggests it's a statistical algo. On the V4CX we use histograms. This is the number of photons returned during each clock cycle after the laser turns on. The sensor uploads the histogram data, and the code running on your host pulls out the answer. 

Histograms do work better - which is why in a sunlit room it will perform better. But how much better really depends on the amount of sun, and the target you are looking at. But it also depends on the direction of the sunlight.

In my outdoor experiments the sun behind the sensor is worse than sunlight perpendicular to the axis between the sensor and the target. I'm guessing sunlight in a room will bounce all over and might give more uniform.

A lot of words to tell you that if the L4CD under-performs your expectations, then swap the driver and give the L4CX a shot. The L4CX does work better. 

 


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.

One point I missed...

When the VL53L4CX returns the raw data, it sends more bytes than VL54L4CD. The CX software sends 24 4-byte integers, each containing the number of photon strikes per clock cycle after the VCSEL (laser) turns on. 

that raw data is why the CX code works better, but it's also why the CX takes more I2C time to transmit the data.

The sensor will start the next range while you are reading the current one, so your reads should not slow you down. 

You could still maintain 10ms ranging. 

- john


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.

Hi John,

Thanks for your reply. I didn't get better results using CX library. CX library is not only taking too much time, it is actually giving me poor results compared to CD library.  Like i mentioned the range i need is around 50cm. CX library is giving me really bad results consistently, without the interference of sunlight, whereas CD library is giving me better results and better loop time. I haven't tried CX library in sunlight yet because i can't give up that much time for reading sensors. The best i can do is 1ms, so i might probably stick to CD library. One other question i have is why does the time taken to read sensor change from teensy to STM if I2C speed is same?

 

Thanks,

Kiran

The 24 4-byte integer VL53L4CX raw data is a lot more than the 2-byte signal strength and the 2-byte distance. So, I'd expect 10X time spent in the I2C transfer and then your MCU still has to analyze the data. 

The CX code is technically more accurate, so if you are not seeing it, perhaps there is a configuration issue. I'm guessing integration time (TimingBudget).

It all our development we are doing nothing other than servicing our sensor. But I expect your MCU has something else to do. So, the CD code does have its advantages. 

When it comes to sunlight, you are going to have problems. The sun puts out a tremendous amount of 940nm light and that is very difficult to overcome. 

Best I can tell you is to try it in your application. 50cm is not out of the question depending on the size and reflectivity of your target. Your worst case is going to be on a very bright sunny day (up to 120K Lux) and with the sun behind the sensor reflecting off your target. 

- john


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.
kps98
Associate III

That makes sense. Thanks