VL53L3CX GUI I2C transaction recording, how?

[Tvan .13]

I have an STM32 Nucleo F401RE plus X-Nucleo-53L3A2 board.

IDE and the rest of the toolchain installed, including the STSW-IMG016 P-NUCLEO-53L3A2 pack graphical user interface.

The data brief of the GUI states "I2C transaction recording" which is of my major interest.

How do I start this transaction recording? In the GUI software I did not find any option. The datalogging feature only logs sensor output, not I2C transactions. 

The reason is that I need to extract the I2C command sequence and parameters in order to initialize a VL53L3 sensor using a very tiny low cost microcontroller. Loading the full API is not possible for that processor.

Any help getting the I2C transactions recorded and downloaded would be greatly appreciated.

[John E KVAM]

That is going to be hard with this chip. The reason is that on the VL53L3 lots of the processing is done on your MCU. The raw data - called a histogram is uploaded to the MCU and it is the MCU that does a lot of the work. And it's largely the power of your MCU that gives you longer ranging and multiple targets. 

I want you to consider a different sensor. Either the VL53L4CD or the VL53L1X are much better choices. With these two, all the processing is done on the chip, and the transactions are much more straight forward. 

The L4CD ranges to 1.3Meters and has an 18 degree Field of view. 

The L1X ranges to 4Meters and has a 27 degree Field of View.

Both have a very small driver that might fit into your MCU as is. 

Both are footprint compatible with the VL53L3 that you were looking at. 

- john 

 

[Tvan .13]

Thanks for your reply. Considering another sensor is always an option.

The reason I asked is that on the P-NUCLEO-53L3A2 pack graphical user interface page

(  https://www.st.com/en/embedded-software/stsw-img016.html  )

is mentioned under All Features:

* I2C transaction recording

 

I was just wondering, how do I let it perform that function.

For the kind of application I am working on, just running the proper initialisation of the sensor is enough. No API means for this productL more application code.

[John E KVAM]

it was meant to be controlled via a selection on the data Logging tab of the GUI. I've never used it. I remember seeing it one of the sensors - but I'm having trouble finding it. 

But I'd do it differently. 

Buy the P-Nucleo-53L4A1 - if using the VL53L4CD or

P-nucleo-53L1A1 if you decide to use the VL53L1X (ranges farther, but costs more)

Both drivers come with example software. 

Using that set up the sensors and get them running the way you want. 

Then edit the Platform.c file. This one file contains all the I2C software. 

Modify it to simply printf all the bytes in and out. 

But do have a look at the code. It's absolutely as small as I could make it.

Might just work for you too.

- john

[Tvan .13]

Thanks for your info.

Currently I can not change the type of sensor unfortunately.

Where can I find the embedded source code or at least application layer?

I suppose the monitor software (which has great functionality) is intended as an engineering tool, not as a marketing tool. Curently it shows how good the sensor can function in a test setup. Only it shows nothing whatsoever on how an engineer can replicate these results, using the same dataset or initialisation sequence.

With my current product I have a sensor problem. In the Nucleo setup the problem has disappeared. And as I can not see what is sent to the sensor, I still have no clue on how to initialize the sensor in such a way that it will work in my application.

Thanks in advance for your help. 

[John E KVAM]

Looks like you found a bug in our documentation. There is no I2C data logging. It got removed somewhere in the last bunch of years we have been developing these sensors.

So, let's tackle this problem the old-fashioned way. 

If your sensor is running, but you didn't 'see' something you think you should be able to see, try increasing the timing budget. This is really the only adjustment you can make. This fixes a lot of issues. 30ms is the default in the GUI, but you can increase it by a lot. You get more photons and thus, a better result. 

Next step is to see if you can get the RangeStatus. This is not the result of the function call, but a register returned by the sensor. It tells you what the sensor thought was wrong. There are a good half dozen statuses.

Next, have a look at the signal, sigma, and ambient. Those three numbers tell you a lot. Low signal is the major cause of errors. Sigma is a lack of correlated distances - and comes from a complex scene. 

Next, consider the physical issues. Using the GUI - perhaps without coverglass - And it works. But does it work when you use your coverglass? Could be crosstalk calibration. It would mean you would be ranging short. Is that your issue?

Sometimes the customer's structure gets in the way. Sensor cannot tolerate that. Check to see that nothing is within a 45 degree cone starting at the center of the sensor.