cancel
Showing results for 
Search instead for 
Did you mean: 

VL53L4CD - Signal is below the defined threshold

DrD00m
Associate III

Hey,

I have a custom made board/device which is using 4x VL53L4CD Tof Sensors to measure the distance. I have trouble to calibrate the sensors correctly or get correct values from them from time to time. Sometimes it works well - sometimes it does not.
What I can see is, that for sensor where the distance is not accurate I am receiving the result status " Signal is below the defined threshold", as described in the datasheet.
What exactly does that mean and how can I fix that? What is causing this issue?

The signal threashold is set to 5000 and the sigma is set to be 10.

I noticed when I am running the offset and xtalk calibration - this issue can disappear but it takes multiple calibration iterrations and sometimes it does not fix the problem.

 

And as well: what exactly is a 17% reflective material!? (as mentioned in the datasheet to calibrate offset and xtalk)

27 REPLIES 27

@John E KVAM wrote:

Most MCUs are a lot faster than that tiny sensor. If you toggle the Xshut at MCU speeds you could well get the sensor into a half-reset state. When restarting, give it a few milliseconds between lower and raising the XShut pin. 


Is 10ms sufficient? I added a 10k pull-up resistor to the xshunt pin of each sensor.
I was reading about this topic in another thread, that they had to use an analog value for the pins. I might try that. Is there a minimum value which needs to be reached? I will measure each xshunt and see if they are 0 for or slightly above that

I know that I want a threshold - that is why I measure first to receive that. I need to know what the closest object is to detect anything in between. 
But if the sensor gives me sometimes a 0 and sometimes a high value I am not sure what the threshold needs to be, you understand what I mean? The device finds the threshold by itself - if that works! But with a mixture of 0 and (in my case) 1600mm it becomes impossible to determine.

 


It says, 'Don't generate an interrupt unless the status is good, the signal is strong, the sigma is low, and the distance is below this level.


For the sensor with strange values from the example before I am setting the following values:

Average: 86
Threshold percentage: 10
Threshold: 77
Signal Threashold: 5000
Sigma mm: 10

Average is the average value which was measured. And 77 is set as distance threshold. This sensor generates permanent interrupts if I set it up like that.

 

John E KVAM
ST Employee

The sensor will never give you zero, unless your object is very close indeed. 

An error would return a distance of 8192 minus the error number. So no-signal would return 8190 (no signal being error 2).

I'm not sure what threshold percentage is in this context. 

I would have expected you to use:

 

VL53L4CD_Error VL53L4CD_SetDetectionThresholds(Dev_t dev,
    uint16_t distance_low_mm,
    uint16_t distance_high_mm,
    uint8_t window);
Using this you would only get an interrupt based on distance.

 

 

 

 

 


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.

I have never seen something like 8192 so far.

threshold percentage is a value I subtract from the threshold I am about to set to avoid false-positives - so I simply subtract 10% of the average value I measured. 

I am setting low and high_mm to be this threshold. But I am setting the threshold after the measurment you see in the log. 

I try again to explain:

  1. you setup the device in a position x above ground 
  2. you start the device which will measure the current distance 30 times.
  3. This 30 distance values will be averaged minus 10% (example: if the average is 100, I will set 90 as threshold)
  4. the edvice will be enabled as low power mode with interrupts on that threshold

When I run this pointing to my ceiling I get this result

 

Sensor 1 Average: 1819
Sensor 2 Average: 70
Sensor 3 Average: 1826
Sensor 4 Average: 1815

 

where the values of sensor 2 are as follows

 

distance: 37 [- : Warning! Signal is below the defined threshold]
distance: 53 [- : Warning! Signal is below the defined threshold]
distance: 55 [- : Warning! Signal is below the defined threshold]
distance: 77 [- : Warning! Signal is below the defined threshold]
distance: 238 [- : Warning! Signal is below the defined threshold]
distance: 74 [- : Warning! Signal is below the defined threshold]
distance: 61 [- : Warning! Signal is below the defined threshold]
distance: 70 [- : Warning! Signal is below the defined threshold]
distance: 37 [- : Warning! Signal is below the defined threshold]
distance: 36 [- : Warning! Signal is below the defined threshold]
distance: 86 [- : Warning! Signal is below the defined threshold]
distance: 0 [- : Warning! Signal is below the defined threshold]
distance: 84 [- : Warning! Signal is below the defined threshold]
distance: 41 [- : Warning! Signal is below the defined threshold]
distance: 87 [- : Warning! Signal is below the defined threshold]
distance: 53 [- : Warning! Signal is below the defined threshold]
distance: 58 [- : Warning! Signal is below the defined threshold]
distance: 113 [- : Warning! Signal is below the defined threshold]
distance: 25 [- : Warning! Signal is below the defined threshold]
distance: 54 [- : Warning! Signal is below the defined threshold]
distance: 95 [- : Warning! Signal is below the defined threshold]
distance: 33 [- : Warning! Signal is below the defined threshold]
distance: 65 [- : Warning! Signal is below the defined threshold]
distance: 261 [- : Warning! Signal is below the defined threshold]
distance: 76 [- : Warning! Signal is below the defined threshold]
distance: 70 [- : Warning! Signal is below the defined threshold]
distance: 46 [- : Warning! Signal is below the defined threshold]
distance: 66 [- : Warning! Signal is below the defined threshold]
distance: 16 [- : Warning! Signal is below the defined threshold]
distance: 40 [- : Warning! Signal is below the defined threshold]

 

even tho they are all pointing to the ceiling.

Now I left the device over night and all 4 sensors on my board showing the same ceiling values except: one of them triggers the interrupt permanently.

 

I placed an object 100mm in front of the sensors and one of them gave me this values:

distance: 42 [- : Warning! Signal is below the defined threshold]
distance: 102 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 92 [- : Warning! Signal is below the defined threshold]
distance: 104 [✓ Valid measurement]
distance: 75 [- : Warning! Signal is below the defined threshold]
distance: 102 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 100 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 74 [- : Warning! Signal is below the defined threshold]
distance: 103 [✓ Valid measurement]
distance: 75 [- : Warning! Signal is below the defined threshold]
distance: 76 [- : Warning! Signal is below the defined threshold]
distance: 102 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 79 [- : Warning! Signal is below the defined threshold]
distance: 102 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 103 [✓ Valid measurement]
distance: 94 [- : Warning! Signal is below the defined threshold]
distance: 101 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 56 [- : Warning! Signal is below the defined threshold]
distance: 101 [✓ Valid measurement]
distance: 100 [✓ Valid measurement]
distance: 43 [- : Warning! Signal is below the defined threshold]
distance: 101 [✓ Valid measurement]
distance: 104 [✓ Valid measurement]
distance: 66 [- : Warning! Signal is below the defined threshold]

all others gave me

distance: 103 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 103 [✓ Valid measurement]
distance: 105 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 104 [✓ Valid measurement]
distance: 103 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 100 [✓ Valid measurement]
distance: 100 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 103 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 101 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 104 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 102 [✓ Valid measurement]
distance: 100 [✓ Valid measurement]

This happens on 3 different boards every time. 

Now - I wrote the driver code in toit - and it works for 3 of 4 sensors. And this is something I do not understand at all. I also have written the same code in Micropython, where it works for all 4 sensors perfectly fine.
I can not run the Arduino code of yours because it always crashes with a core-panic "divisionByZero".

I am going crazy right now - this is day 5 I try to understand this behavior and I have no clue whats going on. I can't even break it down to anything.
I have seen the same behavior on 3 different Boards
Always Sensor 1 and 2 had issues, never Sensor 3 and 4 
There is no difference in how they are attached or placed. 
It can not be I2C as far as I see it because I can see all data on the bus
The same sensor works with my micropython code but it does not with my toit code. (I can not see a difference there in the implementation)
After it was working with micropython, switching back to toit, it works until I power reset the board.
I have never seen something like that.

If it works with micropython - it can not be a hardware problem, right?

With toit it works with 3 out of 4 Sensors - so it must be a software problem? But how can I have one board which just works with toit on all 4 sensors?? This is driving me crazy.

Is there any way you can help me with that?

Okay - I created very basic code (again). 
Sensor 1 and 2 returned always 0 when I tried to read the distance. But both sensors are working with micropython.

I added 1ms sleep after each I2C write and before every read and then I always received a value from the device. But - sensor 1 and 2 start hanging in a interrupt loop which means they never clear the interrupt.
The interrupt triggers imideatly after setting up the sensor. Any idea why this is?

Somehow I2C speed seems to be a problem here. Sensor 1 and 2 are closest to the ESP32 - 3 and 4, where I never see this issues, are furthest away. 
Any idea what this could be?

I have the feeling that the config is changing something about the I2C. Can you tell me what this registers are for?

  • 0x5e = Range Config A
  • 0x5f  = ???
  • 0x61 = Range config B
  • 0x62 = ???
  • 0x65 = ???
  • 0x67 = ???
  • 0x68 = ???

There must be something wrong with I2C Timings and coomunication when I am changing this registers. The Config from the original code is only changing those compared from default cfg to the low power cfg.

DrD00m
Associate III

Your Arduino example code is also crashing btw.

Starting...
Guru Meditation Error: Core  1 panic'ed (IntegerDivideByZero). Exception was unhandled.

Core  1 register dump:
PC      : 0x42002125  PS      : 0x00060830  A0      : 0x8200199c  A1      : 0x3fcebbe0  
A2      : 0x3fc958b8  A3      : 0x000000ff  A4      : 0x00000000  A5      : 0x00000000  
A6      : 0x00000000  A7      : 0x0000e100  A8      : 0x00000000  A9      : 0x3fcebbb0  
A10     : 0xffffffff  A11     : 0x00000052  A12     : 0x00000006  A13     : 0x00000000  
A14     : 0x3fcec6bc  A15     : 0x00000000  SAR     : 0x0000001b  EXCCAUSE: 0x00000006  
EXCVADDR: 0x00000000  LBEG    : 0x40056f5c  LEND    : 0x40056f72  LCOUNT  : 0x00000000  


Backtrace: 0x42002122:0x3fcebbe0 0x42001999:0x3fcebc10 0x42003d12:0x3fcebc50




ELF file SHA256: 972f97422299d5a6

 

John E KVAM
ST Employee

Are all your pointing at exactly the same place? If so, light from one sensor can be recevied by the other sensors. 

Consider starting them at different times and set your timing Budget and inter-measurement period such that they are not all running at the same time. 

My guess is one always works, but there is interaction between the sensors. 

One can get the ambient light measurement from the sensor. When you get these issues, is the ambient light going way up?

I suspect you are confusing what the sensor is giving you with what you are getting from the software. 

I'm not familiar with the particular software you are using. 

Generally, we like at least 0.5M counts. 5000 seems like a high setting. Your 'low signal' is just a warning that your signal is under the count you set. Try 500. (Again, I'm assuming that is K counts. Could be different based on your software. 

The Range A and Range B setting are for how long the sensor integrates. Call setting Set_timingBuget and watch those change. The units for this clock register are really odd. But bigger is longer. The ULP uses settings that are really low to save power. It gives up a lot of accuracy, however. 

 

Perhaps you could submit another entry on "Arduino example code is crashing." Tell me where you got that code, and how you ran it. I will have someone look at it. 

Could you tell me where you got your software. I'd like to look into it. So many people have taken our software and adapted it for various things. It would be interesting for me to have a look at it. 


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.

I still haven't figured out what the problem is - I posted another thread about the interrupt issue.
You can find my code here:
https://github.com/open-thngs/trap-a-rep-trigger/blob/main/src/toit/src/vl53l4cd-driver.toit

https://github.com/open-thngs/trap-a-rep-trigger/blob/main/src/toit/src/vl53l4cd.toit

https://github.com/open-thngs/trap-a-rep-trigger/blob/main/src/toit/src/config.toit

Those are the main files or driver implementation which I ported from the C and C++ code (from adafruit). I tried running this code with a single sensor while disabling all others. Still the same problem. (which means there is no interference with the sensors). I made sure the sensors are disabled by looking at them with my phone-camera.
Also the sensor returns a value 0mm (with the warning about being below the limit) which is odd. I assume if it reads a 0 that something got dropped in I2C maybe? still being ACK?!

I tried so many things and currently it is always the second sensor - but from hardware point of view I can not identify any difference. If I run the micropython code in this repo (you can find it in src/micropython/app2.py) everything is working perfectly fine with all 4 sensors.
I also have now one board where the toit code also works just fine - which does not really help, it makes it even more confusing. You can find the board schematics in this repo as well.

So my hard guess is, that it has something to do with I2C. But also here I can not figure out what it is. I am assuming that the sensor somehow is reacting wirdly to the I2C or it misses some bytes. But thats just a feeling - because if I track the i2c communication on the bus I can see all data being transmitted on the bus correctly.

Is there any timing issues I need to know for any of the commands?