How to Choose a Cellular Modem for a Battery-Powered Tracker
Reading time: 6 minutes
Last modified:
A battery tracker spends nearly its whole life asleep. It wakes, finds a position, sends a few bytes and goes back to sleep. The modem decides how much each of those wakeups costs, and it decides whether the SIM you ship will register at all.
Across two GPS tracker families, the GAT bird and animal tracker and the Micare vehicle tracker, we tested modem and GPS combinations from 2019 to 2024. This post lists what we compared, what the tickets say about each decision, and where the data is thin. We quote a number only where our tracker records one.
The problem: report rarely, run for years
Both trackers share one profile. They report a position at long intervals, they send an alarm when an accelerometer reports movement, and they must not need a charger. That profile changes which spec-sheet questions matter:
- Time spent searching for a tower matters more than peak current.
- Sleep and off-state draw matter more than throughput.
- Payloads are small, so a full data plan is overhead.
- GPS and cellular share one small board and one battery, so they interfere with each other.
What we tested
2G generation: SIM868, SIM808, A9G
We began in late 2019 with a SIM868, with one goal: get a GPS fix and send the coordinates over USSD to Emnify. The SIM808 followed. One ticket for custom SIM808 logic closed with the note that no solution was found.
The A9G stood out because it has its own C SDK, so firmware can run on the module itself. We spent time on the SDK, flashing over a TTL converter and bugs in GPS search. The repository README shows the cost: a Windows-centred toolchain, a newest SDK release from 2019 (older ones are unstable), and a compiler that fails to install on Ubuntu. The tickets give no verdict on the A9G. That toolchain would cost maintenance for years.
STM32 + SIM800 + L80-R
The next board used a separate microcontroller, a SIM800 modem and an L80-R GPS module with an external antenna, plus an ADXL345 accelerometer. The ticket history records our first surprise here (see below).
SIM7020C and SIM7080G
In 2023 we switched a Micare prototype from SIM800C to SIM7020C and set the goal to compare power consumption in MQTT mode. In parallel we researched LTE modules that fit the board by size and shortlisted SIM7080G, SIM7000G and A7670. SIM7080G and SIM7020C samples arrived from Germany. In January 2024 a ticket replaced SIM800C with SIM7080G.
The decision table
| Modem | What we checked | Verdict |
|---|---|---|
| SIM868 | GPS coordinates sent over USSD to Emnify | Ticket closed; goal was a working bench setup |
| SIM808 | GPS and custom logic; later a full prototype board | Custom logic ticket closed unsolved |
| A9G | On-module SDK, flashing, GPS search bugs | Not carried forward; toolchain was heavy |
| SIM800 + L80-R | Board with external GPS module, USSD and MQTT | Base of the 2G design |
| SIM7020C | Power draw in MQTT mode against SIM800C | Prototyped; the tickets record no number |
| SIM7080G | LTE-M and NB-IoT registration, MQTT, built-in GNSS | Chosen for the 4G board |
What surprised us
The voltage regulator blinded the GPS antenna. The STM32 needs 3.3 V, and the other parts ran straight from the battery. A regulator solved the supply and produced noise that drowned the GPS receiver. A ticket on GPS efficiency called for layout changes so components stop interfering with the antenna. A second ticket proposed an Atmega328p, which runs from the battery without a regulator.
A newer modem refused our SIM. SIM7080G registered in roaming on the 1NCE SIM our client sent. It did not register on an Emnify SIM, and a local SIM failed on three Russian carriers. The same Emnify SIM registered from a phone. The older SIM800 worked with a plain local SIM and with Emnify, and sent data over MQTT. A modem swap changes your connectivity contract along with your board.
The GPS module drew more while off. On the Micare board the L80 backup supply pin drew 7 µA. The LC86G that replaced it drew 13 µA on that pin and needed a separate regulator. The datasheet allowed that regulator no more than 1.5 µA when off. We measured about 7 µA, and a ticket opened to find out why.
Cell towers gave poor coordinates. For LBS we parsed the modem’s tower report (the AT command CENG=3,1) and sent it to Google’s location service. All towers came from one operator, one or two stood close and the rest far away. The service placed the device by the first tower only. The ticket suggests the CNETSCAN=1 command instead. We shipped LBS to production in May 2024 and show it on the web dashboard only.
Tactics that cut modem time
- GSM sleeps during the GPS wait. Connect, send alarms, put the modem to sleep, wait for the GPS fix, wake the modem and send everything. The ticket calls tower search and GSM initialisation the hungriest operation.
- USSD as a data channel. On GAT we sent positions through an Emnify USSD gateway and parsed them on the server. A ticket compared USSD send time with 3G and MQTT, and it records no result.
- Bounded GPS search. Micare firmware makes three fix attempts. If two fixes in a row fail on a status message, the device stops searching and sends the status alone.
- RTC against watchdog. We compared sleep with the watchdog against an RTC alarm, using the datasheet and measurements on the device.
A checklist before you pick a modem
- Take your actual SIM and carrier to the bench. Registration failed for us even though the SIM worked in a phone.
- Measure the off state and the sleep state of every module, GPS included, before you look at the active current.
- Keep the regulator and the GPS antenna apart, and test the fix time after each layout change.
- Decide how the device reports a position when GPS fails: a retry limit, LBS or a status-only message.
- Pick the smallest payload format your server can parse, and check whether a data plan is needed at all.
- Check whether the toolchain survives a change of team.
What we have not measured
The tickets do not give a field battery life for any combination. The 4G board was still in revision when the last ticket closed, so we do not claim a result for it. If you build a similar device, run the bench tests above on your own hardware.
We 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
Which cellular modem is best for a battery-powered GPS tracker?
No single modem leads on all axes. A 2G module such as SIM800C attaches on almost any SIM and has simple AT commands. An LTE-M and NB-IoT module such as SIM7080G is built for newer networks, but in our tests it refused SIMs that a 2G module accepted. Test your SIM and carrier on the bench before you order boards.
Why does a GPS tracker need a sleep cycle for the modem?
Tower search and network registration are the hungriest operations in the device. We wake the modem when there is something to send and keep it asleep while the GPS waits for a fix.
Can a tracker send data without a data connection?
Yes. We used USSD through an Emnify gateway as a cheap data channel on the GAT bird tracker. A server-side parser turns the USSD string into coordinates. The trade-off is a tiny payload.
What is LBS and when do you use it?
LBS, location by cell tower, gives a rough position from the towers the modem sees. We use it as a fallback when GPS finds no fix. It is coarse, and the quality depends on which towers the modem reports.
Does the GPS module affect battery drain?
Yes, even switched off. On the Micare board the backup supply pin of the LC86G drew more than the one on the L80 it replaced, and the module needed its own regulator, which leaked in the off state.