cancel
Showing results for 
Search instead for 
Did you mean: 

vl53l5x GO2 error on 8x8 resolution

Thomas6
Associate II

Hi,

I managed to get the sensor working with firmware VL53L5CX_1.3.11. It works even if I reduce the data load and disable everything except distance.

My problem is, that I do not receive any data if I switch the resolution to 8x8 - the sensor is only delivering data in 4x4 resolution. This happens for all data and for only distance data.

I tried several different chips. The error code is 167 = 0xa7 in check_data_ready (GO2 error status). I got no error before neither when switching the resolution nor when starting ranging.

Thanks

1 ACCEPTED SOLUTION

Accepted Solutions
Thomas6
Associate II

Hi,

I finally managed to find the error: my implementation of dci_read_data had a bug. So writing dci worked and therefore having no need for configuration reads worked fine (4x4), but changing the configuration (8x8) needs dci reads, which delivered the wrong result and then configuration of the sensor got corrupted.

Thanks for your input, which helped a lot, and sorry for any inconvenience.

- Thomas

View solution in original post

4 REPLIES 4
John E KVAM
ST Employee

You are getting 4x4 data because you actually failed to switch it to 8x8. 

So the question to ask is, "How did you attempt to switch it to 8x8?"

Did you stop the sensor, change it and restart the sensor?

Attach that bit of code, and I will try to duplicate your issue.

- 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.
Thomas6
Associate II

Hi, thanks for the reply. My post was a bit misleading. The sensor normally initializes to 4x4 - and this works for me. But when I call set_resolution directly after init and before start_ranging, I get this error in check_data_ready. So I do not receive 4x4 data instead of 8x8 data - I receive no data at all when changing the resoltion. The example file also changes ranging_frequency and target_order. I tried it as well, but with no success. I also upgraded to the latest firmware 2.0.0, but with no success.

Is there a way to check that the firmware was uploaded? Can one download it for byte-by-byte comparision?

If you got 4x4 to work, then I'm guaranteeing that the firmware is uploaded.

You called set_resolution with a 64 and it didn't work?

And when you do that start, you notice that the call does A LOT more than just set a bit. The system ranges once and queries the result expecting the right number of bytes. And apparently you did not get them. So, your start failed. 

Debug your start command. 

Did you get the correct resolution? Should be 64. 

Then it goes through all the output_bh_enables to determine the output size. (The sensor and the host MUST agree.)

Tell me where in this process the start command went wonky, and we can figure out what went wrong. 

What number of bytes was it looking for?

- 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.
Thomas6
Associate II

Hi,

I finally managed to find the error: my implementation of dci_read_data had a bug. So writing dci worked and therefore having no need for configuration reads worked fine (4x4), but changing the configuration (8x8) needs dci reads, which delivered the wrong result and then configuration of the sensor got corrupted.

Thanks for your input, which helped a lot, and sorry for any inconvenience.

- Thomas