VL53L5CX basic ranging doesn't return any results

[ALohr.1]

For the past week or so I've been trying to interface this sensor. I've reached a point where I get no errors during the firmware download and initialisation of this sensor. Using the example, I then start ranging (which gives a 255 error?), but when use check_data_ready() it responds saying there is data to be read from the sensor. So, the next step is a call to get_ranging_data() which passes as well.

Despite all this, the results struct still remains empty of any values. That is to say, no targets are detected, no valid range measurements were taken. This makes no sense however, since I have my hand about 30cm from the sensor, which has a white ceiling as the background around 2m away. Lastly, using my phone camera I can see that the sensor is outputting every 1second, in accordance with the default frequency value.

On the topic of default values. I added all the "get" functions to verify the default parameters. All this passes with no errors and yet, the values returned don't match the default configuration parameters outlined in the datasheets and application notes. Ie: When I use get_frequency_hz(), instead of '1', it returns '26'.

I know there's a lot to go over here, but I'm hoping something jumps out at someone to offer some assistance. I'm losing my mind quite a bit here. Some other information. I'm bit banging an I2C communication to avoid buffer limitations, secondly, this runs at around 220KHz. Again, using a debugger and stepping through the initialisation gives zero errors. Is it just that 220khz clock rate a problem at all for getting results data?

[John E KVAM]

and you are absolutely sure none of your fuction calls return bad status.

(I always use status += function(). Then every frew calls I check the status. Saves a lot of code.)

If the sensor is firing, then you are ranging.

the L5 can return rather a lot of data. 6000 bytes per range is quite possible. At 220KHz, you can only do a few ranges per second.

I'm concerned you are only reading partical buffers.

Go to platform.h and disable everything except distance, status, NB_targets detected.

That will reduce the traffic dramatically.

If your I2C results don't match what you expect, consider a word swap issue. The sensor can go a long way on bytes, only for find a word-swap issue.

if you see the laser flash on a webcam, see if you can determine the number of flashes per second.

(Do not use a cellphone camera - those have very good IR filters on them and you won't see a flash.)

• john

[ALohr.1]

Reduced the data read size. it is now 64. Note I'm just using the default configuration.

Phone IR filters are good, but they aren't perfect. I can 100% see the laser being emitted once ever second (1Hz). I'll also add that I'm still having a problem with the star_ranging() function, but that is in another post. That 'error' seems to have no effect. I also added the += on the status and monitor that for every call. It has been running for about 10 mins and there has been no error return by the get_ranging() function.

Here is a screenshot of the results

This is over multiple reads. No matter what I put in front of it, all the status is 255, and distance, nb targets, tempC, are all 0. Something is fundamentally wrong, I went back (again) and checked my wrbyte rdbyte functions. Seems all in order. Multi reads and writes seems okay too. To avoid buffer issues on the reads I do a single byte read for the number of bytes requested by the VL53L5CX ULD.

can you explain further what you mean by word swap issue?

[John E KVAM]

you should have a sequence number in the first byte or so. starts at 0, goes up to 255 then to 128 incrementing again to 255. Do you get that?

There has to be something wrong with your I2C. Looks like you are reading data - or the laser would not fire after the first couple of times, but you are not getting good values.

Do you get anthing in the rest of the structure?

Try putting a known constant in your structure and see if it changes.

I don't think those 255s are coming from the sensor.

Maybe a scope on the I2C.

Something is fundimentally wrong.

• john

[ALohr.1]

I can confirm the sequence number works as you say. Starts at 0 and goes up to 255, and starts back up at 128. More specifically, it goes back down to 127. Not sure if that's significant. I get nothing in the rest of the structure.

Before the sensor initialises, I have set the 'silicon_temp_degc' value to 100. As soon as I get a ranging measurement, the value resets back to 0. Further debugging with a logic analyser on the I2C bus, reveals that different data is being sent back each time. Definitely not all, 0s and not all 1s.

When I step through the get_ranging_data() function, I can see that for some reason the variable "msize" is 0 the a lot of the time. meaning that no data is being copied from the temp_buffer, into the results data. Secondly, it seems that the"block_headers" don't match the ones defined in the vl53l5cx_api.h file. Stepping through the for loop in get_ranging_data(), I stop where the block header gets assigned. the value retrieved doesn't match the block header macros in the vl53l5cx_api.h file. Example: TARGET_STATUS_BH = 0xE0840401 from, the header file. The block header received from the sensor is: 0xE0840001. we can see the 3rd hex value is different. Converting this to the block header union values, the "size" = 0, which shouldn't be the case. This comes directly from the sensor. Something is seriously awry here. I can't figure it out.