Incorrect distance measurement in Short distance mode

[phantom-8]

Under Short distance mode with timing budget and inter-measurement time of 33ms, the VL53L1X library sometimes return incorrect distance measurement even with Range Status code of 0.

The below log is from measurement of 5 sensors. The 1st column is logging time & sequence number, 2nd to 6th columns are distance measurement with range status in square brackets for 5 sensors. Some of the measurement from the 3rd sensor has 0 or small distance values even the range status code is 0. All the sensors are stationary (not moving) and pointing at fixed targets with distance of at least 1m. BTW, I've also tested with a single sensor configuration, so the problem has nothing to do with multiple sensors.

Note: The 3rd sensor is pointing at the side of a black shiny piano facing 45 degree.

[00:04:54.034, 08749]      1243 [0]            1212 [0]            1838 [4]            1802 [4]            1041 [2]            
[00:04:54.067, 08750]      1241 [0]            1208 [0]            27 [0]              1796 [4]            1046 [2]            
[00:04:54.100, 08751]      1241 [0]            1209 [0]            1806 [4]            1792 [4]            1063 [2]            
[00:04:54.134, 08752]      1244 [0]            1208 [0]            22 [0]              1831 [4]            1078 [2]            
[00:04:54.168, 08753]      1244 [0]            1209 [0]            51 [0]              1810 [4]            1077 [2]            
[00:04:54.201, 08754]      1242 [0]            1200 [0]            0 [0]               1811 [4]            1080 [2]            
[00:04:54.235, 08755]      1245 [0]            1194 [0]            23 [0]              1790 [4]            1074 [2]            
[00:04:54.268, 08756]      1238 [0]            1199 [0]            1423 [4]            1762 [4]            1050 [2]            
[00:04:54.302, 08757]      1243 [0]            1198 [0]            310 [2]             1783 [4]            1094 [2]            
[00:04:54.335, 08758]      1242 [0]            1204 [0]            1195 [2]            1834 [4]            1052 [2]          

[cparata]

Hi @phantom-8 ,
giving a look to the values of your sensors we can say:
Sensors 1 and 2 are working fine.
Sensor 3 gives very strange values. I guess that the reason could be due to the inclination of the front plane. You can try to rotate the sensor in order to point to a plane at 90 degrees. Besides, take into account that maximum value for Short Distance Mode is more or less 1.3 meters. So, maybe you should use this sensor in Long Distance Mode too.
Sensor 4 seems Out-Of-Range, so you should switch also in this case to Long Distance Mode.
Sensor 5 seems experiencing poor signal (Error number 2), so you can try to increase the Timing Budget to 100 ms in order to increase the quality of the measurements but it could not be enough due to physical limitations; so also in this case (like for Sensor 3) you could be obliged to change the position of the sensor.
I hope that these tips can help you.
Best Regards,
Carlo

[phantom-8]

Hi Carlo, thanks for reply. The sensors are installed onto a robot. The reason for choosing short distance mode is because it's immune to strong ambient light. I don't need to detect stuff for more than 1 meter. However, I expect the sensors not to return incorrect values when it says the measurement is valid (setting RangeStatus to 0). For sensor 3, it should just report Out-Of-Range (RangeStatus of 4), not 0 or small distance with RangeStatus of 0.

During my testing, I've encountered another serious problem. There seems to be some conflicts on the I2C bus with Serial Port receive. I've reported a similar issue a while back and have made an amendment on it.

[fpistm]

Some fix/enhancement have been done around Serial and I2C.
Those have been merged in the core (IRQ priorities, UART fixes around IT reenabling and Error handling).

[cparata]

Hi @phantom-8 ,
in fact regarding the sensor 3, I guess that you receive some interference in the measurements due to the 45 degrees inclination of the front piano. Did you try to put the sensor in front of the piano with 90 degrees inclination? In this case are the measurements more reliable?
Best Regards,
Carlo

[phantom-8]

Hi @fpistm, thanks for informing me on the fix. I'll try and see if it helps.

Hi @cparata, the piano scenario is just 1 of the examples. In short distance mode, there are many other instances where the sensors report incorrect measurement even it says it's valid. The problem is that the robot will move around based on the sensor data and the data can't be trusted. I'm now switched to Long distance mode and doing some more testing and see if this mode is more reliable.

[cparata]

Hi @phantom-8 ,
what I mean it is that when you have a range of measurements very various like in the case of sensor 3, normally it is due to some obstacles that "are seen" by the laser cone of the sensor. For example, I had a very similar behavior on my desk because there was a shelf that "was seen" by the laser cone of the sensor and so the shelf sometimes interfered with the measurements of the distance of the ceiling. It was sufficient to move the sensor far from the shelf and in this way the shelf did not interfere in the measurements anymore. A behavior, like that, can explain what happens also on your side.
Best Regards,
Carlo

[phantom-8]

Just wanted to report back. I've tested the newest stm32duino core (ver a4fb01). It didn't fix the UART issue that I have.

I've also use the compiler flag to increase transmit & receive buffer size to 1024 and the UART receive problem still happened. However, with the larger buffer size, the problem occurrence is less frequent comparing to before.

[fpistm]

Well hard to tell more and I could not reproduce this.
Could you tell us exactly your setup (hardware, wiring,..) and sketch used.

[phantom-8]

@fpistm, the setup is quite complicated. I've 6 sensors on the I2C bus and the UART receive problem started to occur. It was working fine under 5 sensors environment. It seems to me its timing related, as the I2C bus gets more traffic, the problem on the UART becomes more apparent.

I'm currently trying to bypass the UART problem. Since the stm32 doesn't need to receive much data from the other side, I'm implementing some rudimentary handshaking using digital pins. I will open up a ticket on the stm32duino core section later after I've finished my current project.

[fpistm]

You do not answer the questions which board you used and which I2C pins and USART pins?
I would like to check your setup. Without enough info, we could not help.
Telling you have an issue with UART Rx when you have 6 I2C sensors do not help, this can be a wrong pins configuration, wiring, parameters, issue on your sketches,...
Opening a new issue on core side will not change anything as you met issue with this lib.

[phantom-8]

I'm using STM32F103C8T6 Blue Pill. It's connected to another Arduino Mega 2560 via UART1 (Pin A9 & A10); and to a ESP32 via UART2 (Only Pin PA2). The connection between STM32 & ESP32 is 1 way. That is, STM32 will send information to ESP32 and only the TX2 (PA2) is connected. All 6 VL53L1X sensors are connected to the STM32 using SCL1 (PB6) and SDA1 (PB7). Each VL53L1X has the XSHUT pin connected to STM32 on Pin PB12, PB13, PB14, PB15, PA8 & PA12. The GPIO1 pin on the VL53L1X is not used.

BTW, I'm currently testing another VL53L1X library from Pololu on the STM32. This library also exhibits the same UART problem and that's why I think the problem is on the Arduino core, not the library itself.

@cparata, my initial testing on the Pololu VL53L1X library don't have the incorrect measurement when the RangeStatus is 0. In other words, the distance measurement is always correct when it says the data is valid. This is done on both Short & Long distance mode.

[fpistm]

Ok so it seems there are 2 issues.
One with the library and probably one with the core.
Please, Could you open one in the core with all info including the 3 sketches.

[phantom-8]

My report on the UART receive slowdown and missing data is a false alarm. It turns out to be the I2C bus problem. The I2C bus timed out and was slowing down my program in receiving UART data. Sometimes, the call to I2C even hang. The issue seems to be related to the 6th sensor wiring. This 6th sensor is installed on a different location than the other 5 sensors. I'm still trying to troubleshoot the exact cause. Sorry for the false alarm.

BTW, I tried to slowdown the I2C clock speed to 1K by calling "Wire2.setClock(1000)". Is this correct? Or is it even possible to make the I2C bus that slow?

[cparata]

Hi @phantom-8 ,
Actually the default I2C Speed should be 100khz. I would try to increase the I2C speed up to 400khz. The API should be setClock(400000).
Best Regards,
Carlo

[phantom-8]

The reason to slow down the I2C bus is because I'm having problem in the 6th sensor which is now being moved to the 2nd I2C bus for diagnostics. I suspect the culprit is the wiring or interference around the I2C wires. Thus, by decreasing the bus speed, the I2C bus should be more tolerable.

[fpistm]

Hi @phantom-8
Do you check the STM32F103 errata sheets?
https://www.st.com/content/ccc/resource/technical/document/errata_sheet/7d/02/75/64/17/fc/4d/fd/CD00190234.pdf/files/CD00190234.pdf/jcr:content/translations/en.CD00190234.pdf

Maybe you met one issue referenced here.

[cparata]

Hi @phantom-8 ,
could you try the STM32duino VL53L1X library setting the distance mode as long distance and reducing the size of spad array before starting to read the sensor values? Basically, you need to update the STM32duino VL53L1X library at the last available version (v1.0.3) and add to your code the following settings:

YourSensorInstance->VL53L1X_SetDistanceMode(2); // Long distance mode
YourSensorInstance->VL53L1X_SetROI(8, 8); // Change the spad array size from 16x16 to 8x8

Let me know if in this way the issue with Sensor 3 is mitigated.
Best Regards,
Carlo

[fpistm]

Any update on this ?

[fpistm]

@phantom-8 any update ?

[fpistm]

They were several update at core level around the I2C (Timing issue fixed, error management, ...).
This issue is opened since a while with no feedback so I close it.