Has anyone observed this (attached) behavior on VL53L0x?

[Martysm]

I'm collecting 100 samples on a 200ms timing budget and reporting the average once a minute, so if it's just one sample, it's high by what you see * 100. The behavior appears sensitive to the value for sensor.setSignalRateLimit(). I have it down from 0.25 (25kcps) to 0.025 (2.5kcps) for the bulk of the graph. For the right ~10% of the graph it is set to 0.005 (5kcps) to see if that reduces the frequency of occurrence.

With higher SignalRateLimit() settings, or the default value, I get more frequent and several levels of spike indicating that one or more readings are just some overflow value x.01, .02. .03 or .04, depending on whether the condition occurs 1, 2, 3,4 etc. times in 100 samples. I can deal with it at this point and have a useful system, but it's bugging me.

The L0X is installed in a ~half full steel 275V oil tank with zero ambient light and it has a cover with cross talk barrier.

I know that the 4CD would probably be better, and I am experimenting with at present, but the availability of breakout configurations is much more limited so that will be a mechanical problem.

If anyone knows what's going on here and how to mitigate it, I'm all ears. Thanks.

[John E KVAM]

I'm going to guess here a little bit. For some reason you are getting a bad range status - which you might not be checking. When you get a bad range we put 8192-range_status into the distance result. It's not a distance - it's an error.

I'm thinking that you are not filtering the status, but accumulating the resullt.

If you can't print the status to figure out what is going wrong, at least remove any data that is longer than 2M (which is the max of the sensor.)

The range_status is not the function return. You call a function to get this data from the sensor.

I can perhaps give you more data if you can tell me what the status is.

BTW - the VL53L4CD has an identical footprint, a more compact laser and software that is MUCH easier to use. It's plug replaceable and cheaper.

The VL53L0X is a 2 Meter part in favorable conditons. It will do 1.3 meters in your tank. The VL53L4CD is a 1.3 meter part. But it can do that 1.3 meters in your tank.

• john

[Martysm]

Thanks John. That's what I was thinking. No I am not checking range status. I did not realize that function was available in the L0X Arduino libraries. I see it in the 4CD library example you have published. I'll go back and look for it in the L0X lib. If I find it I will try to write something that will ignore any range status other than 0 inside the 100 sample loop If I can't figure that out I can just ignore any returned distance value that is > the height of the tank. I am trying though to do the best I can with the sensor before I resort to fudging the data.

How low can/should I go on SignalRateLimit() in a sealed up cold black environment? I know I CAN go to 0.000, but should I? I've also noticed that lowering it has the effect of damping a sinusoidal drift I was getting with a period on the order of hours and an amplitude of a few mm. 

I would really like to use the 4CD because of the FOV angle because the tank has a curved bottom. The narrower angle will get me closer to the bottom before picking up returns from the sides. I can't figure out a good and simple way to mount your hole-less breakout board with the 4CD. Right now I am using the Chinese L0X boards that have the 2mm holes on either end and room for the Hornix cover screw-mounted to a 3mm thick black acrylic sheet, laser cut for the 2mm holes and the cover oval. That mount plate is then glued into a PVC adapter with pipe thread for the tank fitting. Unfortunately the guys in China haven't picked up on the 4CD part yet, as far as I can tell.

[John E KVAM]

My friends at sparkfun might have a product in the form facture you desire. Same VL54L4CD, just on a different board.

https://www.sparkfun.com/products/18993

You can also check AdaFruit.

https://www.adafruit.com/product/5396

And Pololu - who does not appear to have an L4CD version (yet?)

(Although to use those you might need to desolder the I2C connectors. though)

How low can/should I go on SignalRateLimit() in a sealed up cold black environment?

The signal rate limit only returns a different status when your signal goes below a certain amount.

It's our way of warning you that the data might be suspect.

If you aren't checking the status, then it doesn't matter.

You have an advantage in that you know you will always have a target. And that target will be within certain limits. Any data outside those limits is impossible - so it's fair to throw away the data.

I'd really like to know the status however.

The status value really does contain information about why the result might be suspect.

• john

[John E KVAM]

And I do like your design. I've seen other designs that used a flat board connected the sensor and then they filled the structure with potting material. Makes it water-proof. Althougth once done, there is no changing it.

[Martysm]

Thank you. I have a long way to go b4 I'm ready to pot it all up!!!! - If ever.

I looked at the SparkFun board after your webinar on this last week and cussed them for putting the connectors on the "wrong" side. The thought of removing them never occurred to me. I'm usually capable of thinking outside the box..... dunno what happened there. Keeps me humble I guess. I'll have to look at that again. Perhaps they can come off and be reinstalled on the other side.

Regarding "It's our way of warning you that the data might be suspect.

If you aren't checking the status, then it doesn't matter."

Really? Coulda fooled me. Let me see if I can get to my data at another location where I have two tanks/two VL53L0s running on identical code with only different SignalRateLimit settings.The yellow sensor has been running with a SignalRateLimit of 100kcps and the green 25kcps.

The discontinuity is a result of having the oil company come deliver some oil last week. They were supposed to deliver 200gal (100@tank). I believe (from my remote location) that this indicated the driver was probably stoned and misread the order to deliver 100 into each tank delivering, instead, 100gal total. I was expecting around a 400mm delta. Being remote, I don't know for sure if the offset (uncalibrated as yet) was really bad and a function of distance, or what.

The only way to know for sure is to either drive down there and find the delivery slip or wait for the charge to come through on the cc, and at $3.50/gal I don't want to rush them on the cc. My bet though is they delivered 100 instead of 200.

If I understand what you are doing in the code on the device (i.e. "When you get a bad range we put 8192-range_status into the distance result"), if this condition occurs whenever the SignalRate < SignalRateLimit, then it is going to happen at higher frequency when signalRateLimit is set higher than it will when it's set lower. Also, it will happen more frequently measuring longer distances, than it will measuring shorter distances (by inverse square).

I believe I see this effect in the data as well. I think I am going to have to take a drive.....

Anything more you can tell me to illuminate what's behind the curtain will no doubt improve my shadow boxing score.

[Martysm]

This: "I'm thinking that you are not filtering the status, but accumulating the resullt. ..."

is a bingo.

I now filter the data and exclude any points out of valid physical range and the problem is gone. I also keep track of the number of bad points on each read cycle as a measure of if and by how much the signal returns are deteriorating. The magenta (below) is the oil volume in the tank and the two little blips on the blue line are one bad data point each, diring those two read cycles(out of about 300). Now they are not summed in nor is their index value added to the divisor. No impact now on the published result, but this IS what WAS generating the offset-to-a-higher-value data lines.

You were 100% on the money. Thank you.

[Martysm · Accepted solution]

Just a 6 month follow up.  Bottom graph is oil burner run time hours in 100ths.  Total 157 hours over the period.   The top graph is the VL53LCD distance measurement converted to gal remaining(green) and the "signal" measurement(yellow).  There was a 177 gal fill on 11/29.  Total consumed over the period 138 gal.  Works out to 0.88 GPH.  It's a 0.85 GPH (marked) nozzle.

At fill time I ordered 185gal based on the data and the tank took 177.  There's some subjectivity in guessing when he's going to show up on my end and on the driver's end when the whistle stops and he shuts off the pump.  It's all close enough for me.  The signal level minima was 7-8 when the level was as low (measured distance was at its maximum) as I ever want it to be.  So all good.  I did have one mid-october system hang.  I don't remember what it was but it was not sensor related and easy to fix with a reboot of something.  I've got these VL53L4CDs on three tanks now with AliExpress covers (literally $1.50@) running on ESP8266s and they all work great.

[Anne BIGOT]

Thank you for your feedback.