LTE Beacon: Programming principles & good practices

Estimote LTE Beacon is fully programmable using JavaScript. This makes it flexible and powerful. However, with great power comes great responsibility.

There are certain principles you need to adhere to, in order to make the most out of the beacon’s potential.

In this article, we talk about the mechanisms we’ve incorporated into the design of the LTE Beacon to maximize its efficiency. We also offer a handful of tips that will help you optimize your code and avoid pitfalls that could lead to issues like excessive battery usage, and generally ensure efficient use of the LTE Beacon’s limited resources. 

Familiarizing yourself with these limitations and following the principles outlined in the guide is an important first step to creating a successful solution using Estimote LTE Beacons.

Below are some programming principles to bear in mind when creating your micro-app for Estimote LTE Beacon.

What’s ahead (aka Table of Contents)

Action-reaction

In order to limit current consumption, low power devices usually turn off most of their components, leaving only essential modules powered up. When an event occurs (a button is pressed or a timer fires), they quickly turn on the required peripherals, carry out an action, and then switch the component off again (a.k.a. ‘sleep mode’). Following this pattern, a micro-app should not be running all the time. Instead, it should register itself to different kinds of events happening within the device like:

-timers
-button presses
-acceleration change
-radio communication
-BLE scanning

Ideally, your micro-app should handle events as quickly as possible, allowing the device to go to sleep as soon as possible. Your micro-app can be more power-efficient if you take an approach that includes registering for events or using timers. This is why the API has no delay function — without it, only these power-conscious approaches are possible.

Single Micro-app execution

Your micro-app’s main code block should be executed only once, when the app is installed, or when the device starts up. The code should configure the device (set the advertised BLE packets, for example) and register all the necessary event handlers.

Limited execution time

Every millisecond of running your app’s code is a millisecond of relatively high energy consumption. To minimize it, the device places a 10s hard limit on the execution time of your code.

In practice, when a piece of code runs for too long, an exception will be thrown and your app will stop. This applies only to code written by the user. The execution of API functions will not be affected, because of their predictability.

These limitations are intended to prevent excessive energy consumption, as well as to decrease the risk of accidentally creating an infinite loop.

Periodic communication

Long distance communication is power-consuming. It involves both transmitting and receiving data packets, data encoding, link establishment, fault recovery, etc. In most cases, transmitting user data can be done quickly (in about 1-2 seconds), but the preparation time can be quite long (up to over 15 seconds). In order to limit overall energy consumption, the LTE Beacon follows a set of rules:

  • Communication is initiated by the LTE Beacon — it can analyze incoming signals (timers, button-presses, accelerometers, etc.) and choose to begin transmission when necessary.
    all communication is carried out in a single synchronization window during which the device turns on its modem and sends all the data packets at once.

  • The data is kept in persistent storage for synchronization — the app can queue a number of small data packages and then send them all at once. You can trigger the synchronization window manually, but calling it too frequently will drain the battery quickly. Make sure not to overuse the sync.now() method and ideally only use it for emergency alerts.

The synchronization window is also a time when the device checks for any incoming messages, such as user data, a new app waiting to be uploaded, or firmware updates. This means that data pushed to the device will wait in the Cloud until the device wakes up and downloads it.