VL53L1X problem with the SW standby consumption after the initialisation sequence.

[DGibe.1]

Hi all,

I'v developed a board with my microcontroller and one VL53L1X-SATEL - Breakout board that came with my X-NUCLEO-53L1A1 kit. I use a 3v battery for the board without regulator and 1K pull-up for the I2C line(100khz).

I use the VL53L1X ULD API files for the initialisation and the one shoot ranging measurement. After the initialisation (SetDistanceMode=short, SetTimingBudgetInMs = SetInterMeasurementInMs = 20mS) of the VL53L1X my CPU go to sleep mode and the current consumption is 6uA, every 30s my CPU wake up start measurement (StartRanging, CheckForDataReady, GetDistance, ClearInterrupt, StopRanging) consumption=14mA, the Distance value is ok and go to Sleep again.

All works like I expected, BUT every time I change the battery or I do a reset to my CPU, if there is no target in front of the VL53L1X, after the initialisation phase (sleep mode) the current consumption is 3mA (expected 6uA) and every 30s the CPU wake-up send a good distance measurement and go to sleep with 3mA again. If I put a target between 0 to 50cm during the initialisation phase (sleep mode), I get 6uA. I'v tried an initialisation with short&long distance and 20mS&100mS&500mS the problem continues: if no target then consumption in SW stanby is 3mA. If I force the HW stanby with the XSHUT pin the consumption returns to 6uA but I lose my configuration.

Kindly help me with this issue

Initialisation:

         if(!VL53L1X_GetID() && (Event.Log[0]==0xEA)) { // Test if sensor = present

           while(sensorState==0){

               status = VL53L1X_BootState(VL53L1X_ADDR_I2C, &sensorState);

               Event.timer_1mS = 2; while(Event.timer_1mS);

            }

            // This function must to be called to initialize the sensor with the default setting

            status = VL53L1X_SensorInit(VL53L1X_ADDR_I2C);

            status = VL53L1X_SetDistanceMode(VL53L1X_ADDR_I2C, 1);      // 1=short, 2=long

            status = VL53L1X_SetTimingBudgetInMs(VL53L1X_ADDR_I2C, 20); // mS

            status = VL53L1X_SetInterMeasurementInMs(VL53L1X_ADDR_I2C, 20); // ms

}

One shoot Ranging (every 30s):

WAKE-UP...

            status = VL53L1X_StartRanging(VL53L1X_ADDR_I2C);

            dataReady = 0;

            while (dataReady == 0){

               status = VL53L1X_CheckForDataReady(VL53L1X_ADDR_I2C_1, &dataReady);

               Event.timer_1mS = 2; while(Event.timer_1mS);

            }

            status = VL53L1X_GetRangeStatus(VL53L1X_ADDR_I2C_1, &RangeStatus);

            status = VL53L1X_GetDistance(VL53L1X_ADDR_I2C_1, &Distance1);

            status = VL53L1X_ClearInterrupt(VL53L1X_ADDR_I2C_1);

            status = VL53L1X_StopRanging(VL53L1X_ADDR_I2C_1);

...SLEEP

[John E KVAM]

I might suggest setting the timing budget to 20ms, and setting the intermeasument period to 30 seconds. It will range, sleep and 30seconds later do it again.

You can put your MCU to sleep and use the interrupt pin to wake you up.

but you really should see the 6uA during the sleep time.

The sensor uses 20mA WHILE RANGING, and 6uA between ranges.

I don't know where the 3mA could be coming from.

But I'm going to guess that it's still ranging.

Can you use a laptop camera to check for the light? (Iphones and late model phones all generate 940nm light and this us very good filters to remove it from the camera. So you cannot use them to detect the 940nm light.)

Or if you change the timing budget and see the power consumption go up during the 'sleep' phase you will know it's still ranging.

I don't know how this bug got by me. Sorry for the slow reply.

• john

[FBass.1]

Hi @John E KVAM​ 

I am experiencing a related problem.

I was not aware that the inter-measurement period could be set, so we connected the XSHUT pin to a timing circuit utilising the ICM7555. It is designed to constantly pull XSHUT low for 60s and then HIGH for 2.5s. The idea was that during the 2.5s the ToF will take a measurement and then sleep again when XHSUT is pulled low.

The problem arises when the XHSUT is pulled high again. We are unable to to take any further readings with the exception of the first one. It is worth mentioning that the µC is also asleep during this time as we will rely on the INT to wake up the µC when the measurement is outside the allowed parameters. I assume this is due to the fact that the configuration was sent to the ToF initially when the µC started up, but as soon as the µC sleeps and the ToF us put to sleep by pulling the XSHUT low it loses it's configurtation? As the µC is still sleeping when the ToF is then woken up, it has no configuration so it won't take any readings. Does this sound correct?

Kind Regards,

Friedl

[John E KVAM]

Friedl -

The sensor has no memory. So when you pull XSHUT low and bring it back to life, you at a minimum, need to re-initialize the sensor and issue the start command.

You don't have a choice. You must use the IM period to accomplish what you want to do.

Good news is that you can save a bit of power and some circuitry with your re-design.

Bad news is you have to do the re-design.

Your explanation is exactly what is going on.

The sensor has no persistent memory. So cycling the XSHUT will in fact start all over.

• john

[FBass.1]

Hi @John E KVAM​ 

Thank you for your prompt response. As you mentioned, good news is there is a solution, more good news is now on-time can be exactly only what the sensors needs to range as apposed to being on for i.e. 2 seconds and then bad news yes, redesign. I was so proud of my two timing circuits (one for each ToF) :D Redesign should be easy as it will mostly mean leaving off the entire timing circuit.

EDIT: Thank you, found the references in the API docs!

Many Thanks!

Friedl.

[John E KVAM]

The IM is the amount of time from the beginning of one range to the beginning of the next. For you it doesn't matter that much due to the long time between ranges, but if you wanted a 20ms range and then 20ms of wait, you would need 40ms for the IM Period.

So set the IM to 60*1000 as the timer is in milliseconds.

The timing budget is NOT in milliseconds - which seems goofy to me. (Apparently there is hardware reason for it.)

2.5 seconds is way too long for a TimingBudget. For most applications 30ms would do it. 60 if you really wanted a little better accuracy. And 500ms is the max.

But a TB of 30*1000*1000 is how one would specify 30ms.

[FBass.1]

@John E KVAM​ 

Thanks John. I edited my previous post but you were to quick for me 😊

Thanks again for the help, I will be in touch if we need anything else.

Regards, Friedl.

[DGibe.1]

Dear John,

Thank you for your suggestion, but I can't use this solution because I'm going to use not only 30s but also 1s , 8s and some time 48h for the intermeasurement. I don't have the interrupt line between the CPU and all VL53L1X (because of cable limit). It's more easy to me to start & stop the measurement and put the time sleep that I want. The other problem is that I'm using 3 x VL53L1X with my bus sensor and as you intermeasurement consumption is 20uS (not 6uA), 3 x 20uA is too more for me, I prefer the start & stop solution.

I have used a camera to check the light in Initialisation sequence and I can see the light very quickly ON and OFF, but after that stay OFF and again 3mA. As I'm using 3 sensors now I see 9mA and every 30s my CPU wake up do the start& stop measurement (I can see the light very quickly ON and OFF again like in the Initialisation) of each one. The value of measurement are correct but stay with 9mA in SLEEP mode. If I remove all VL53L1X one by one, I can see -3mA, -3mA & -3mA.

My timing budget is 20ms and I put the IM = 40ms like suggested by Dominique, the problem continues.

I do an experience maybe this can help you to find the problem:

I programmed a timing budget of 33 ms and a IM = 20ms and what's happening:

During my Initialisation sequence if I put a target I get 6uA in SLEEP mode and if there is no target I get 3mA, the problem continues OK, but after that every 30s, when I wake-up to get a measurement and go to SLEEP, the 3mA of consumption appears permanent even if I get 6uA in my Initialisation sequence that differs from my initial configuration (timing budget is 20ms, IM = 40ms) where the consumption come back to 6uA if my Initialisation sequence was 6uA too.

if you need more test from me please tell me.

Kind Regards,

Didier.

[John E KVAM]

Didier-

you are right. You can save more power by simply turning off the sensors. And it's not that hard. It's just that you need to re-initialize them from scratch every time. And that's not impossible, just re-run the code you started them the first time.

I programmed a timing budget of 33 ms and a IM = 20ms and what's happening:

The IM is the time from the start of one measurement to the start of the next. So if you wanted a 33ms TB and and a 100ms gap between them, the IM would be 130ms. (And I know, this is confusing.)

when I wake-up to get a measurement and go to SLEEP, the 3mA of consumption appears permanent

I don't know how this could be happening. The chip has only two modes. Ranging, and waiting.

When ranging it's 20uA, when ranging its 20mA. I can only assume that if you are consuming 3mA, the sensor is ranging/sleeping in such a manner as to consume 3mA. (This can happen if your power meter is doing some averaging.)

But you stated your solution. Just turn them off. You can either cut power to the sensors, or lower the XSHUT line.

I was trying to save you the hassle of the re-initialization, but it's fast enough.

[DGibe.1 · Accepted solution]

Hello John,

With the help of Dominique, we found the solution. The problem was:

As I use your VL53L1X breakout board, in your schematic the interrupt line has a pull-up R4=1K, and sometime the configuration sequence let the interrupt line state '1' or '0' so 3volts/1K = 3mA. I removed the pull-up and now all is fine.

Thank you for your help too: Problem SOLVED.

Didier