Battery GPS Tracker Power Design: Sleep and Gating

A GPS tracker that reports once a day looks like it should run for years. Our consumption sheet shows the limit: at one report a day, half the daily energy goes to the report and half to sleeping. Cut the report cost and sleep current sets the floor. Cut sleep current and the report sets it.

This post covers the power decisions in two tracker lines, GAT (a bird and animal tracker) and Micare (a vehicle tracker), and what the tickets and code record about each. Where a ticket gives a number we use it. Where we calculated, we say so. Our modem comparison covers the choice of module. This post covers how you run it.

Where the energy goes

A tracker has four consumers: the microcontroller, the GPS receiver, the cellular modem and the accelerometer. The accelerometer stays powered to wake the device, and the tickets give no figure for its draw. The long, costly phases in our tickets are the two searches: the GPS for a fix and the modem for a tower.

In June 2022 we measured a GAT prototype in several firmware states. Average draw ranged from 5.5 mA to 44 mA:

Firmware state	Average draw
No MCU sleep, GPS never switched off, modem awake during the GPS search	44 mA
Same, but the modem sleeps during the GPS search	37 mA
No MCU sleep, GPS switched off between reports	25 mA
Wake every 30 s, sleep the modem, drop the GPRS session each time	21.6 mA
Wake every 30 s, sleep the modem, keep the GPRS session	5.5 mA

The ticket adds a warning: the readings include the modem’s status LED and the error of a USB tester. Use them to compare states, and do not use them to size a battery. The 44 mA state also worked only about every other attempt, with voltage sags.

The last two rows show the largest single effect. Dropping the GPRS session and re-attaching on every wake cost about four times the current of staying attached. The ticket that introduced GSM sleep says the same in words: tower search and modem initialisation are the hungriest operation.

In July a second sheet turned the same bench work into per-event energy. It labels the column “mA”, but the sums only work as milliamp-hours, so we read it that way:

Event	Duration	Energy
GPS search plus send	40 s	0.756 mAh
Alarm, 2 min sleep, status check	149 s	0.244 mAh
Stop alarm plus GPS search plus send	40 s	0.488 mAh
One day of sleep	86 360 s	0.7197 mAh

From these we calculate two things. The 40-second GPS search averages about 68 mA. The sleep line works out to about 30 µA, a figure we derived by division and did not read off a meter.

One report a day costs 0.756 + 0.7197 = 1.4757 mAh. The sheet turns that into 745 days, or 24.5 months, which implies a cell of about 1100 mAh. One report a minute costs 44.5 mAh a day, about 30 times more, and the sheet gives 0.8 months. At that rate sleep current is noise. At one report a day, it matters as much as the report.

Power gating with MOSFETs

The ATmega328 firmware in our GAT repository defines two MOSFET pins, one for the GPS and one for the modem. Both start LOW in setup, so nothing is powered until the firmware asks. Before every sleep, the sleep routine switches both off. A separate STM32 test sketch does the same with a gate pin on the modem, behind a build flag, and waits five seconds before it cuts power.

The GAT firmware uses both tools. The modem sleeps over its DTR line while the GPS searches, and the MOSFET removes power for the long sleep. A SIM7080G test on Micare favours power removal over the modem’s own sleep mode. Switching the modem off with a command gave 3.12 µA, the same as PSM, and cutting its supply made no difference. Registration took the same time in all three variants. The engineer who ran the test rejected PSM for four reasons:

• the modem may not enter the mode, and not every operator supports it;
• the entry takes extra time and energy;
• the standard’s minimum timer is 20 seconds, and the observed entry took about 30;
• if the code does not wait for the entry, it ends up in an uncontrolled state, because the modem may or may not sleep.

At the 10-minute report interval in the ARMED and DISARMED modes, powering the modem off won. The ticket leaves the short SOS interval unverified.

Gating has its own failure modes, and we hit three:

• Inrush current. Capacitors behind the switching transistor drew a large charging current at turn-on. Removing them was the best fix we found.
• Resets. On the LC86G board the microcontroller reset whenever power came through a transistor to the GPS. Replacing the transistors with an LDO that has an enable pin fixed it.
• Leakage in the off state. The GPS module’s backup supply pin drew 7 µA on the old L80 and 13 µA on the LC86G. The LDO should draw no more than 1.5 µA when off, and we measured about 7 µA. A software fix for the backup pin lowered consumption. The ticket records no final off-state number for the LDO.

GSM sleep until the GPS fix

The cheapest saving on GAT came from changing the order of work. The ticket describes four steps: connect the modem, send any alarms, put the modem to sleep while the GPS searches, then wake it and send everything together. The goal was fewer tower searches and fewer modem initialisations.

The bench result is the 44 to 37 mA step in the table above, about 16 percent by our arithmetic. We closed the ticket after tests, and it records no energy figure for the change on its own.

A related test compared running the GPS and the modem in parallel against in sequence. Parallel finished the same work 50 seconds sooner and drew 4 mA more. The ticket does not record which one lasted longer, and neither do we.

Sleep, and what wakes the device

The ATmega328 firmware in our repository carries the 1.4.x versions that the Micare tickets cite, and the Micare microcontroller runs at 8 MHz. Its sleep routine does five things:

1. It disables the ADC and the serial ports.
2. It turns off brown-out detection in software.
3. It enters power-down mode.
4. It wakes on a watchdog interrupt every four seconds and counts cycles until the configured sleep time ends. The code comment caps one sleep at 45 days.
5. It wakes at once on a rising edge from the accelerometer or on the button.

The accelerometer (an ADXL345) works as a motion switch. The tracker sleeps until movement, sends an alarm, then searches for a GPS fix. Testing gave us two decisions. Before every sleep the firmware reads the accelerometer’s interrupt pin, because a trigger that arrived during setup would otherwise leave the device asleep until the next one. And on Micare we split the accelerometer interrupt from the GPS interrupt and the GSM serial line from the GPS one. The firmware had named one pin for both interrupts.

On Micare we added an external DS3231 RTC. The firmware sets an alarm before sleeping, for an interval the server supplies per mode. The wake sources are the accelerometer, the button and the RTC alarm. The RTC syncs from the GPS time on a successful fix. We ruled out cell-tower and NTP sync because the clock is accurate enough without them.

RTC against watchdog

In May 2024 we compared the two sleep methods against the datasheets and on the device.

Source	Current
DS3231, datasheet	0.84 µA
DS3231, measured	0.6 to 0.8 µA
Watchdog on, datasheet at 1.8 V	3.5 µA
Watchdog, a note from another ticket (device switched off by its button)	about 5 µA

We could not get a stable watchdog reading. Current falls slowly after the microcontroller goes to sleep, so any reading depends on when you take it. At 3.3 V the datasheet figure is higher than at 1.8 V. The gap is about 4.3 µA (5 minus 0.7). Over a year that is about 38 mAh, a calculation, or about 3 percent of the 1200 mAh cell we sized a GAT case for. The saving is small. The tickets record no verdict, and the firmware went on to wake from the RTC alarm. An RTC also keeps wall-clock time, while the watchdog only counts intervals.

The RTC also caused trouble. A GPS module returned a bad date after a failed fix, and the firmware’s only check was that the year exceeded 2022. One device stored a timestamp in 2057 and could not return to the current time without an EEPROM reset.

FRAM instead of EEPROM

A tracker that cannot reach the network has to store reports and send them later. On the ATmega328 we first used the internal EEPROM. The tickets record the work around it: a check of what happens at overflow (nothing writes, since EEPROM and flash are separate), a limit of 70 records, a ring buffer split out into its own library, and the discovery that memory cell zero was unstable, which broke our “is the EEPROM clean” check.

On the 4G board we moved to an external FRAM chip over I2C. The ticket states the task and not the reason, so we cannot give you a measured benefit. One test showed the chip holds 544 records, each a position and a timestamp. Then we hit a collision: the FM24CL16B answers on eight I2C addresses from 0x50 to 0x57, and the ADXL345 sits at 0x53, so the memory and the accelerometer fought over the bus.

Bounded retries

Two drain bugs were loops with no exit. One firmware version kept trying to reach a tower with no limit, never reached the sleep routine and drained the cell. We now give three attempts at the tower. For the GPS, if two fixes in a row fail on the 24th status message, the device stops searching and sends the status alone. Both rules cost nothing in hardware.

Battery percentage from voltage

The battery figure in the app drives the customer’s decision to charge or replace. In March 2024 we measured a full discharge cycle of the Micare cell and prepared a formula. The server code holds two mappings. The first is a fourth-degree polynomial above 3.5 V, plus a linear ramp from 3.4 to 3.5 V for the last few percent. The second is linear, from 3.6 V (0 percent) to 4.0 V (100 percent). The server picks by firmware version: the polynomial from 1.4.46 on, the linear map below it.

In April a customer complained about the display. A device whose cell had emptied months earlier showed 40 percent in the app, and below 20 percent the units could hardly send. The customer wrote that 40 percent shown meant zero. Our reading is that a nearly empty cell sags under the modem’s burst, so a percentage taken from resting voltage overstates what the modem can still draw. The 3.4 V floor in the polynomial is the SIM800C minimum that our sizing table used.

Sizing a cell for one report a day

An earlier GAT table sized the battery for six and twelve months at one ping a day. It took an average of 73.84 µA and a 3.4 V cutoff, and it asked for 1600 mAh for six months and 2900 mAh for twelve. For five pings a day it used 129 µA and 2900 mAh and 5700 mAh.

Check the arithmetic and you find a gap. 73.84 µA over six months is 323 mAh, and over twelve it is 647 mAh. The table asks for about five times that. The ticket records no margin and no reason, so we cannot say what the factor covers. It may be derating for cold, self-discharge and the voltage cutoff. We include the table because the gap teaches something: write the margin down next to the formula. The later sheet, with 1.48 mAh a day, implies a much smaller cell. The two disagree, and neither was tested in the field.

What we did not measure

• No ticket records a field battery life for any tracker, and we claim none.
• No ticket gives microamps in sleep for the final Micare board as one figure, or milliamp-hours per report on the 4G board.
• No ticket gives wake time for the RTC path.
• We found a TPL5110 timer integration with an STM32 board in the GAT project, with the goal of ultra-low consumption. The ticket records no current figure. The later designs in our repositories use MCU sleep with MOSFETs, and nothing in the records says why.

A checklist

1. Measure every state, including sleep and off, with the modem LED removed or accounted for.
2. Write the per-event energy and the daily total in one sheet before you pick a cell.
3. Gate the GPS and the modem, then measure the off state including the regulator’s own leakage.
4. Keep capacitors small behind the switch, or limit the inrush.
5. Sleep the modem during the GPS search, or power it off, and compare against PSM on your carrier.
6. Check the accelerometer pin before you sleep.
7. Cap every retry loop.
8. Sync the clock from the GPS fix and reject dates you cannot trust.
9. Map voltage to percent with a measured discharge curve, then test it under load.
10. Write the margin beside the battery formula.

We design and build firmware, boards and clouds for devices like these. See our IoT product development service, the GAT bird tracker and the Micare GPS tracker. To discuss your tracker, get in touch.

Frequently Asked Questions

Should a battery GPS tracker cut modem power with a MOSFET or use the modem's own sleep mode?

On Micare's SIM7080G board, powering the modem off beat PSM. PowerOFF and PSM both measured 3.12 µA, but PSM engaged only after about 30 seconds and not every carrier supports it. Re-attaching to the network took the same time in every variant. At a 10-minute report interval the tickets chose power-off.

How much does sleeping the GSM modem during the GPS search save?

In a GAT bench test, average draw fell from 44 mA to 37 mA when the modem slept while the GPS searched for a fix. That is about 16 percent, a calculation from two measurements taken with a USB tester, so treat it as a rough figure.

Is an external RTC better than the microcontroller watchdog for sleep?

On Micare we found the RTC cheaper on paper and on the bench. The DS3231 datasheet gives 0.84 µA and we measured 0.6 to 0.8 µA. The watchdog figure is 3.5 µA at 1.8 V in the datasheet, and a separate test showed about 5 µA. We could not measure the watchdog cleanly because current falls slowly after the microcontroller sleeps.

How long does a tracker battery last if it reports once a day?

Our GAT sheet computes 1.48 mAh per day for one report with a 40-second GPS search, which is about 24 months on a roughly 1100 mAh cell. That is a calculation from bench numbers. We have no field result, and we do not claim one.