Concept renderThree reporting policies move energy cost to different places. Server-side geofencing costs a modem report per checked position. On-device geofencing costs GNSS fix checks. Motion-triggered reporting costs an always-on low-power accelerometer. This guide compares them using published sources, lists what to measure on your board, and what to ask first.
A tracker has two expensive actions: getting a GNSS fix and sending a report over the cellular modem. A reporting policy decides how often each one happens. This guide compares three policies using published vendor documentation, lists what to measure on your own board, and lists questions to answer before you choose. It contains no price and no measured result.
What do the published sources say?
These are the facts from vendor documentation that bear on the design. Each was read on October 31, 2026.
| Item | What the source says | How to read it | Source |
|---|---|---|---|
| Android: active geofences | Limit of 100 per app, per device user. | Phone-side reference for a count limit. A standalone tracker has its own limit that you set in firmware or on the server. | Android geofencing guide, as of October 31, 2026 |
| Android: minimum radius | Set the minimum radius between 100 and 150 meters for best results. | Reference for how small a fence can be before position error dominates. Your GNSS error on your board is not published here. | Android geofencing guide, as of October 31, 2026 |
| Android: notification responsiveness | A higher value improves power use by increasing alert latency. The guide gives an example: with a value of five minutes, the app checks for an enter or exit alert once every five minutes. | Shows the basic trade: fewer checks, more delay. | Android geofencing guide, as of October 31, 2026 |
| Android: dwell transition | Use the DWELL transition instead of ENTER to cut alerts when driving past a geofence. The alert fires only after a stop of a given length inside the fence. | A pattern you can copy as a timer in your own state machine. | Android geofencing guide, as of October 31, 2026 |
| Bosch BMA400: low power mode | 800 nA is sufficient when the low power mode is used for activity detection as self wake-up. The datasheet range for the mode is 800 nA to 1200 nA by performance setting, at a fixed 25 Hz data rate. | Sensor-only current. It excludes the MCU, modem, GNSS receiver and regulators. | Bosch BMA400 datasheet, as of October 31, 2026 |
| Bosch BMA400: wake-up interrupt | The wake-up can wake the sensor to normal mode and can wake the external MCU when the interrupt is mapped to the interrupt pin. | The hardware path that lets the MCU stay asleep until movement. | Bosch BMA400 datasheet, as of October 31, 2026 |
The Android guide is for phone apps. We cite it only as a reference for count, radius and latency trade-offs.
How do the three policies compare?
| Policy | How it works | Where energy goes | Alert latency | Cloud and ops |
|---|---|---|---|---|
| Server-side geofencing | Device reports position on a timer or on motion. The server compares each position with the fences. | One modem report per position you want checked. The fence list lives in the cloud. | Includes the report interval, the network path and server processing. | Cloud cost follows message count. Fences change without touching the device. |
| On-device geofencing | Firmware stores the fences and checks fixes locally. It reports only on a fence transition. | GNSS fix checks on a schedule, plus a modem report when a transition happens. | Includes the check interval and the time to get a fix. | Fewer messages to the cloud. Fence changes need a downlink or an update path. |
| Motion-triggered reporting | An accelerometer watches for movement while the MCU, GNSS and modem sleep. Movement starts the fix and report sequence. | Sensor current all the time, plus fix and report energy after movement. | Includes the motion setting, the wake path, the fix time and the attach time. | Few messages while parked. A sensitive motion setting can wake the modem more than planned. |
The policies can be combined.
What should you measure on your own board?
The sources above do not give modem energy, GNSS energy, false-trigger rate or alert latency for your hardware, so measure them on your board.
| What to measure | How to instrument or collect it | Raw data to record |
|---|---|---|
| Full-board waiting current | Put a current meter or power analyzer on the battery rail. Record the board in SLEEP and in MOTION_ARMED, with every peripheral in its intended state. | Raw current traces with timestamps, firmware build, accelerometer register settings and the state the firmware reports at each moment. |
| GNSS fix energy and time | Log energy and time from receiver power-on to the first valid fix. Repeat for each start type, in open sky and in the places your device will sit, such as a vehicle or a building. | Per-start energy, time to first fix, receiver start type, sky condition, antenna placement and ephemeris age. |
| Modem attach and send energy | Capture the battery rail from modem wake to modem idle for one report. Include a first attach after a long sleep and a repeat report soon after. | Energy per report, attach time, message size, carrier, signal condition and retry count. |
| Motion threshold behavior | Configure the accelerometer wake-up threshold and duration. Carry or mount the device in the real conditions, such as a vehicle, a bag or a shelf next to a machine, and log every wake-up interrupt. | Interrupt timestamps, threshold and duration registers, how the device was mounted, and a ground truth note of when real movement occurred. |
| End-to-end alert latency per policy | Move the device across a fence edge on a known schedule. Log the time of the physical crossing, the fix, the send, the server receipt and the alert delivery. | Timestamps at each hop, clock source for each timestamp, policy settings and network condition. |
| Wake count per day under real use | Run the firmware through a typical day of your use case and count FIX_ACQUIRE and REPORT entries per state path. | State transition log with timestamps, wake reasons, and the battery rail trace for the same period. |
What should you ask before you choose?
- What is the longest alert delay your customer will accept, and who wrote that number down?
- How many fences does one device need, and who changes them after the device ships?
- Can your downlink path carry a fence update to a device that is mostly asleep? How long does the update wait for the next wake?
- Does the asset spend most of its time parked or moving? What is the carry condition: vehicle, container, tool case or a person-worn item for an adult or older adult?
- Which alert do you need: entering, leaving, or staying for a set time?
- What does a false alert cost your customer, and what does a missed alert cost?
- Is the cloud cost per message already in your plan, and how many messages per day does each policy create?
- What do you do when GNSS finds no fix at the timeout? Do you report the last known position with a flag, or report nothing?
- Does your product need a manual "locate now" request from the app, and how does the sleeping device receive it?
- Which of your energy numbers are measured on your board and which are still guesses?
Questions about tracker reporting policy
Can I use the Android Geofencing API on a standalone tracker?
No. It is an API for phones. This article uses its published guidance (as of October 31, 2026) for the 100 geofence limit, the radius advice and the latency trade-off, as reference points only.
Does the BMA400 figure tell me how long my tracker lasts?
No. The datasheet figure of 800 nA for activity detection is the sensor alone (as of October 31, 2026). It excludes the MCU, modem, GNSS receiver and regulators.
What is a dwell timer for?
It holds back an alert until the asset has stayed inside a fence for a set time. Android describes the same idea as its DWELL transition, used to reduce alerts when passing by a fence.
If you want to talk through a tracker design, tell us about your tracker. You can also read about our LTE and GNSS tracker development.
Sources
All pages accessed October 31, 2026. Re-read them before you decide.
- Android Developers, Create and monitor geofences: https://developer.android.com/develop/sensors-and-location/location/geofencing (accessed 2026-10-31)
- Bosch Sensortec, BMA400 datasheet: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bma400-ds000.pdf (accessed 2026-10-31)
Planning a tracker? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →