LV53L3CX and similar sensors low level software programiing data

[AGrod.1]

Hello all.

I'm looking for any serious software documentation for LV5x sensors and... I cant't find any?!?

For serious software documentation I understand precision description of all registers and macro procedures i.e. calibration, data collection etc.

I'm using a lot of different peripherals from different producers, processors etc. To this time I never meet situation, that telatively complicated component have really no any documentation except for simplified (unusable) description and ready complicated API 100% wrote in C.

I want to try to use LV53L3CX in industrial robust and micropower sensor and I must have full control in this project. I do'nt want to use ST microprocessor, because I'm using others. And I don't wat to use (I can't use) any processor with RAM and ROM big enough for needs of original API. No any LV5x sensor don't need so peripheral hungry control. But for making project like this, good documentation is necessary.

Is it possible to get LOW LEVEL software documentation for LV53L3CX. Or better, for all tye family of ST' ToF sensors? Reverse engineering of API is to expensive (time, money) and risk of the make mistake is to big.

[John E KVAM]

In the VL53 sensors, there are 512 registers that can be changed. And changing most of them will just break the system. I'm sure you could write a driver based on just banging registers, but when you were done you would end up absolutely hating ST.

Creation of the API was our compromise. We tried to expose all the features we could with that API and keep it easy for customers.

One issue with the L3CX is that the final answer is computed on your MCU from the raw histogram data provided from the sensor.

So even with the registers, you would still need to process the raw data. Again you probably could do it, but it took ST years and there were a lot of people.

If you really want control, may I suggest using the VL53L1X sensor with the Ultra Lite Driver.

This is our smallest API being only a few hundred lines of VERY SIMPLE code. It should not require any reverse engineering.

This part uses a different algorithm - that is not histograms. It can be fully computed on the sensor.

Perhaps this will be more to your liking.

[AGrod.1]

Thank you very much for your answer.

Unfortunelly 53L3 seems to be only device suitable for my application (short range included, possibility of strong crosstalk rejection). I have read documentation.

I must to use extra lens with about 5mm airgap. I need to reduce cone angle and reduce dust immunity. It's an industrial application. I tried Sharp previously and I expect that most ST devices will produce the same (poor) effect in my project. My only hope is (was) 53L3's flexibility. And maybe I'm wrong?

[John E KVAM]

Using a lens to concentrate the laser power is not recommended. The issue is the laser is invisible and the photons at 940nm will enter your eye. We carefully designed the sensor to be eye-safe and using a lens will violate that eye-safety. That being said, if this application's safety is guaranteed some other way and you have an an optical engineer, you can test and certify the laser yourself. Just be careful. These devices can be potentially harmful if you concentrate the light.

An air-gap of 5mm will not work without some effort. The problem is that even a good lens will reflect a few percent of the photons, and they will bounce back. This crosstalk will confuse the sensor. You must find a way to prevent the photons that don't go out into the world from getting into the receive side and short-circuiting the operation. We suggest using a pair of light-pipes separated by an opaque barrier.

• john

[AGrod.1]

Thank you John. I know all this. Limiting cone to 30% with saving the same light intensity is not any problem to me. I need distance up to 0,7m only and I can limit the beam power. Every final product must be certified with a producer responsibility, like yiu know.

I also need to have as big as possible beam diameter at outer wall of the lens because of dust. So initial airgap must to be used.

These miniature sensors are very problematic in usage. Only simple and popular solutions will accept very thin coverglass located (almost) directly on the sensor body. Only one small piece of dust at the glass and sensor is blind! It's not acceptable. Maybe in toys and a part of consumer electronics. I know, this is main market...

So, only problems are a crosstalk (I have prepared some tricks for reducing it) and proper device working FROM 2-3cm + low level software for it. I expected that multi target sensor will better in reducing crosstalk than "simple" sensor.

I have good working solution for my application. But I'm trying to replace it by single module (TX/RX). More simple for installation and service. I have no other options than TOF devices for now.