TinyLiDAR for IoT

If you look around, you'll notice a lot of smart little devices are being used in everyday life.
They are typically battery powered and usually connected to the Internet (aka the 'cloud') somehow. These are all what we call 'IoT' devices and they are fast becoming common place in the world today.

For IoT System Engineers, a lot of design effort is spent on optimizing power consumption. The reason for this is of course due to the limited capacity available in batteries. Changing out batteries in large quantities in remote areas can be a very expensive proposition.

So this instructable is all about optimizing power in tinyLiDAR.

TL;DR summary

We have a new "Real Time" measurement mode (as of firmware 1.4.0) to help maximize battery runtime in IoT devices.

Squeezing More Juice from Batteries

Intuitively, we can increase the runtime by simply reducing the IoT devices' power consumption. Okay so that's obvious! But how can you do this effectively and properly calculate the expected runtime?
Let's find out...

Step 1: Pure Energy

There are many ways to do this but we prefer to break it down to the basics and convert everything to energy. Electrical energy is measured in Joules (symbol J) and by definition:

A Joule is the energy dissipated as heat when an electric current of one amp passes through a resistance of one ohm for a period of one second.

Since energy (E) is also voltage (V) x charge (Q), we have:

E = V x Q

Q is Current (I) x time (T):

Q = I x T

So energy in Joules can be expressed as:

E = V x I x T

where V is the voltage, I is the current in Amps and T is the time in seconds.

Let's assume we have a battery pack made up of four AA alkaline (LR6) batteries connected in series. This will give us a total starting voltage of 4*1.5v = 6v. End of life for an alkaline AA battery is approx 1.0v so the average voltage would be about 1.25v. According to the mfr datasheet "Delivered capacity is dependent on the applied load, operating temperature and cut-off voltage." So we can assume about 2000mAhr or better for a low drain application such as an IoT device.

Therefore we can calculate that we have 4 cells x 1.25V per cell x 2000mAhr * 3600sec = 36000 J of energy available from this battery pack before it has to be replaced.

For the sake of simpler calculations, we can also assume the conversion efficiency is 100% for our system regulator and ignore the host controller's power consumption.

A Word About Cycling

No, not the type you ride on! There are a couple of technical concepts known as "Power Cycling" and "Sleep Cycling".
Both can be used to lower power consumption but there is a difference between the two.
The first one involves shutting your device off until its needed and then turning it on only for a short time to perform a measurement etc. Although this method is tempting to use due to its zero off current, there is a drawback where it will take some non-trivial amount of time to boot back up and burn energy while doing so.

The second concept involves just keeping the device in sleep mode with the hopes it will wake up faster but you will burn some finite amount of current while it's sleeping.
So which is the best to use?

It depends on how often you need to wake up.

Step 2: Run the Numbers!

We want to find the total energy (E) normalized to 1 second for each scenerio listed below.

Case A: Tc = 1sec; take a distance measurement every second
Case B: Tc = 60sec; take a distance measurement every minute.
Case C: Tc = 3600sec; take a distance measurement every hour.

To do this, we can say Tc is the cycle time for our measurements, ton the active time and toff the inactive time and rearrange our energy formulae as shown here:

For tinyLiDAR, the start up time is about 300ms or less and during this time it will take an average of 12.25mA while operating from a regulated 2.8v supply. Hence it will consume approximately 10.3mJ of energy for each startup.

The sleep/quiescent current for tinyLiDAR is an ultra-low 3uA. This is far lower than the 0.3% monthly self-discharge rate of an alkaline battery pack so we will investigate using only the "sleep cycling" method here.

Why not dispense with the micro and go directly to the VL53 sensor?

The answer to this is not quite so obvious. In the early days of smartphone development we learned that keeping the power hungry high speed processor alive to play mp3's was a surefire method to reduce battery life. Even back then we made every effort possible to use lower power "application processors" for periphery duties like playing music. It's not much different today and in fact, you could say its even more important as we miniaturize all these IoT devices with every decreasing battery capacities. So using an ultra-low power application processor for the sole task of controlling the VL53 sensor and providing data ready for further processing is a definite asset for any battery powered application.

tinyLiDAR Measurement Modes

It may not be clear in the user manual at this time [ but will be at some point as we are always updating our user manual :) ] -- there are actually 3 different measurement modes in tinyLiDAR.

MC Mode

From the inception of tinyLiDAR, we were obsessed with trying to get faster measurements from the VL53 ToF sensor. So we optimized our firmware to get the fastest and most consistent streaming data from it. This involved introducing buffering. A little buffering is a good thing since it allows the host controller (i.e. Arduino) to get its measurement data in a flash and move on to more important things. Therefore buffering is absolutely necessary and due to this we are able to achieve streaming rates in excess of 900Hz even on the relatively slow Arduino UNO. Hence, the fastest response time will be in using tinyLiDAR's MC or "continuous" mode.

BTW, if you ever get a chance, you should connect a serial cable to the TTY output pin on tinyLiDAR and you will see what this MC mode does. It literally takes a measurement as fast as it possibly can and in doing so, it fills up it's I2C buffer with the absolute latest data. Unfortunately, since it's running at full speed, it is also burning the max amount of power. See below for the current vs time graph of this MC mode.

SS Mode

The next mode is what we call "SS" for "single step" mode. This is basically the same high performance mode above but in a single stepping loop instead. So you can get fast responses from tinyLiDAR but data will be from the previous sample so you will have to take two measurements to get the very latest data. See below for the current vs time graph of this SS mode.

Both of the above modes have fit the bill nicely for most users since they were quick and easy to use - just issue a "D" command and read the results. However ...

Moving forward to the IoT world where every milli-Joule counts, we have a new paradigm.

And it's the exact opposite to what we have coded in tinyLiDAR! For the IoT world we need single measurements at infrequent intervals in order to conserve power and extend the runtime.

RT Mode

Happily, we can now say that we have a solution for this scenario as of firmware 1.4.0. It's called the "RT" mode for "real time" measurements. And it basically implements a trigger, wait and read method. To use it, you can still just issue the "D" command to start the measurement, but for this RT mode you must wait an appropriate amount of time for the measurement to finish and then read the results. tinyLiDAR automatically goes to its lowest quiescent state of sub 3uA in-between samples. It's actually still simple to use and even more energy efficient now since you only have to take one measurement instead of two to get the very latest data, i.e. zero buffering.

See below for the current vs time graph of this new RT mode.

Step 3: Actual Measurements

Using the MC continuous mode for infrequent IoT measurements makes little sense since we only need single measurements. Hence we can focus our attention to the SS and RT modes instead. Operating tinyLiDAR from a regulated supply of +2.8v provides us with the lowest power dissipation. So in using the High Accuracy (200ms) presets, we measured the following energy consumption on tinyLiDAR:

SS/single-step mode: 31.2 mJ averaged over 2 measurements
RT/real-time mode: 15.5mJ averaged over 1 measurement 

Plugging these above values into our energy formula and normalizing to one second we can find the runtime expectations assuming the energy from our battery pack is 36000 J.

Case A: reading every second (take 2 readings to get latest data)
Tc = 1sec
Ton = 210ms per reading x 2 readings
Toff = Tc - Ton = 580ms
Ion(avg) = 26.5mA per reading
Ioff(avg) = 3uA quiescent current
Vcc = 2.8V supply voltage

Active energy consumed by load in Joules is
Eon = Vcc x Ion x Ton
= 2.8V x 26.5mA * 420ms
= 31.164mJ

Inactive energy consumed by load in Joules is
Eoff = Vcc x Ioff x Toff
= 2.8V x 3uA x 580ms
= 4.872uJ

Normalizing to Tc
E = (Eon + Eoff )/Tc
= (31.164mJ + 4.872uJ)/1
= 31.169mJ or 31.2mJ per second

Runtime in seconds is therefore the total energy of source/energy consumed
which is 36000J / 31.2mJ
= 1155000 seconds
= 320 hours
= 13.3days

Repeating these calculations, we can find the runtimes for the other scenarios:

SS mode

Case A: 2 Readings per second. Normalized energy is 31.2mJ. Therefore runtime is 13.3 days.

Case B: 2 Readings per minute. Normalized energy is 528uJ. Therefore runtime is 2.1 years.

Case C: 2 Readings per hour. Normalized energy is 17uJ. Runtime is calculated at >>10 years, hence loading due to tinyLiDAR is negligible. Battery pack will therefore be limited only by it's shelf life (i.e. approx 5 years)<br>
 

RT mode

Case A: 1 Reading per second. Normalized energy is 15.5mJ. Therefore runtime is 26.8 days.

Case B: 1 Reading per minute. Normalized energy is 267uJ. Therefore runtime is 4.3 years.

Case C: 1 Reading per hour. Normalized energy is 12.7uJ. Runtime is calculated at >>10 years, hence loading due to tinyLiDAR is negligible. Battery pack will therefore be limited only by it's shelf life (i.e. approx 5 years)

Hence, the new Real Time mode using sleep cycling is a benefit here to extend the runtime past 4 years if one measurement is taken every minute as shown in Case B.

Note that the host controller's energy consumption was not taken into account for this analysis and the battery pack specs were on the conservative side. You can find much more powerful batteries as desired to suit your needs.

Thanks for reading and stay tuned as we will provide a working IoT example using tinyLiDAR for our next instructable.
Cheers!