Understanding Customised Asset Tracker v2 Application
1. Introduction
Asset Tracker v2 is a real-time configurable ultra-low power capable application firmware for the nRF91 Series System in Package (SiP). Emcraft develops a customized version of the Asset Tracker v2 application, which supports nRF9151 System-On-Module (SOM) Hardware Architecture and implements several additional features.
This document provides an overview of the overall application architecture and the differences between the original and customized versions of the application. For details about the original Asset Tracker v2 application refer to the Nordic documentation page.
2. Asset Tracker v2 Architecture
The following table provides a brief overview of the Asset Tracker v2 application architecture:
Module/API | Location in Source Tree | Description |
|---|---|---|
Application module |
| The application module an initial point of entry for the application and sends periodic sample requests to other modules in the system. |
Data module |
| The data module gathers data that has been sampled by other modules in the system and stores it into ring buffers. It keeps track of data requested by the Application module and decides when data is sent to the cloud. |
Cloud module |
| The cloud module establishes and maintains the connection to a supported cloud service. It uses the Cloud wrapper API to integrate and handle the client libraries present in the nRF Connect SDK. |
Cloud wrapper API |
| The cloud wrapper API is a generic API used for controlling the connection to a supported nRF Connect SDK client library through Integration layers. It exposes generic functions such as |
Debug module |
| The debug module intends to improve the overall debugging experience in the application. By default, it subscribes to all the events in the system and implements support for Memfault through the Memfault module integrated in nRF Connect SDK. |
Location module |
| The location module controls the GNSS, cellular, and Wi-Fi® positioning functionality. It can be used to retrieve the location of the device in the form of events containing a position, velocity and time (PVT) structure. |
Modem module |
| The modem module communicates with the modem to control the LTE connection and retrieve information from the modem about the device and LTE network. |
Sensor module |
| The sensor module interacts with external sensors present on SOM-NRF95151. It collects environmental data and detects motion over a set threshold value. |
External sensors API |
| The External sensors API is used to configure external sensors and collect sensor readings. |
User Interface and LED modules |
| The User Interface and LED modules handle events from the UI (buttons, LEDs) elements on SOM-NRF95151. |
Utility module |
| The utility module provides the functionality to administer and monitor mechanisms in the application architecture. |
Modules common API |
| The Modules common API provides the functionality to administer mechanisms in the application architecture, and consist of functions that are shared between modules. |
Unit tests |
| Unit tests, applicable to a set of Asset Tracker v2 modules. |
Watchdog |
| Watchdog module. |
Events |
| Source files that declare events, which are used by other application modules. |
Add-ons |
| Various add-ons that implement support for nPM1300 PMIC, LPS22HH and LIS2DW12 sensors, RTC, etc. Refer to Understanding Customised Asset Tracker v2 Application | 4. New Features of the Customised Asset Tracker v2 Application for details |
Application Configuration |
| Various configuration files and overlays for Asset Tracker v2 application. |
MCUboot Configuration |
| Subdirectory containing configuration files and devicetree overlays for MCUboot bootloader. |
Memfault Configuration |
| Configuration files used to integrate Memfault SDK into the Asset Tracker v2 application. |
3. Changes in the Customised Asset Tracker v2 Application
3.1. Real-time Configurations
The default configuration has been modified to lower the device power consumption and reduce frequency of cloud data transfers.
The real-time configurations supported by the application are listed in the following table:
Real-time Configurations | Description | Default values | |
|---|---|---|---|
Device mode | Either in active or passive mode. | Passive | |
Active |
| Cloud updates occur at regular intervals. |
|
Active wait time | Number of seconds between each cloud update in active mode. | 300 seconds | |
Passive |
| Cloud updates occur upon movement. |
|
Movement resolution | Number of seconds between each cloud update in passive mode, given that the device is moving. | 1800 seconds | |
Movement timeout | Number of seconds between each cloud update in passive mode, regardless of movement. | 7200 seconds | |
Location timeout | Timeout for location retrieval during data sampling. This value should be large enough so that the location can be retrieved in different conditions. This can be considered more of a safeguard rather than the deadline when the operation must be completed. Hence, this value can be larger than the sampling interval. | 300 seconds | |
Accelerometer activity threshold | Accelerometer activity threshold in g. Minimal absolute value for accelerometer readings to be considered valid movement. | 4 g | |
Accelerometer inactivity threshold | Accelerometer inactivity threshold in g. Maximal absolute value for accelerometer readings to be considered stillness. | 4 g | |
Accelerometer inactivity timeout | Accelerometer inactivity timeout in seconds. Minimum time for lack of movement to be considered stillness. | 60 seconds | |
No Data List (NOD) | A list of strings that references data types, which will not be sampled by the application. Used to disable sampling from sensor sources. For instance, when GNSS should be disabled in favor of location based on neighbor cell measurements, the string identifier | No entries (Request all) | |