Introduction
Ocean freight remains the backbone of global trade: countless containers cross the seas every day carrying everything from raw materials to consumer electronics. Despite its importance, the mid-ocean leg of a shipment can still be a visibility black box. Real-time satellite trackers exist but are expensive and power-hungry, which limits their deployment to high-value cargo. For many operations, a more pragmatic approach is to log positions on the container itself and transmit the data opportunistically when a cellular network is available at the next port.
This article provides a deep technical dive into building a satellite-free container tracking system. It discusses system architecture, hardware design, firmware logic, data ingestion, security, power budgeting, and deployment considerations. The goal is to present enough detail that a developer or engineer could implement and adapt the ideas for their own projects. This is not a product pitch; it is a synthesis of best practices and lessons from the field.
Why Avoid Satellites?
Satellite communication solves the mid-ocean gap, but at a significant cost. A satellite modem typically uses tens to hundreds of milliamps when transmitting, requires a service plan, and adds complexity. In contrast, an IoT device that stores GNSS fixes and waits until it reaches a cellular network can operate on a few microamps during sleep and only tens of milliamps for a few seconds during sporadic uploads. For many cargoes that do not require minute-by-minute updates, the delay of a few days is acceptable. The cost savings allow a fleet operator to equip every container instead of a select few.
This model is widely used in other domains (e.g. wildlife GPS collars, asset trackers, data loggers) and adapts well to ocean containers. The core challenge is building a device that can survive harsh marine environments, accurately log locations and events, and then synchronise data reliably when back on land. Let's break down what that entails.
High-Level Architecture
A satellite-free tracking solution has three main pieces:
Device: A self-contained unit with a GNSS receiver, microcontroller, non-volatile memory, battery, cellular modem and optional sensors. The device is affixed to the outside of the container so that its antennas have a clear sky view.
Network: When offshore, the device remains offline. Once near a port, it connects to LTE-M, NB-IoT or GSM networks using a roaming SIM/eSIM. It uses a lightweight protocol (MQTT or HTTPS) to upload buffered data.
Backend: A cloud service ingests the uploaded logs, reconstructs the container's route, validates data integrity, and exposes the information via dashboards or APIs. Because uploads may be sporadic, the backend must handle out-of-order entries and retries gracefully.
A minimal architecture can be implemented with open-source components. For example, a Mosquitto MQTT broker receives packets from devices, a microservice decodes and stores them in a database, and a simple web interface visualises the tracks. A more elaborate deployment might integrate with transportation management systems, generate alerts, and support over-the-air updates.
Designing the Hardware
Processor and Memory
The heart of the device is a low-power microcontroller (MCU). Popular families include ARM Cortex-M (STM32, NRF9160), ESP32, or RP2040. The MCU should support deep sleep modes and have enough SRAM/flash for code and buffering. A typical tracker logs 1–5 position fixes per hour; with 32 bytes per fix, a 1 MB flash chip can hold many weeks of data. External SPI flash is often used to avoid wearing out internal MCU flash.
GNSS Module
Multi-constellation receivers (GPS, GLONASS, BeiDou, Galileo) improve fix reliability. Modules like u-blox M8/M9 or Quectel L70 have cold-start sensitivity down to –127 dBm and can acquire a fix in seconds when aided. The GNSS should be duty-cycled: power it only when needed and use hot-start capabilities to shorten on-time. Some modules provide a timing pulse or sync line that the MCU can use to schedule wake-ups precisely.
Cellular Modem
Choose a modem that supports LTE-M and NB-IoT with fallback to 2G. These standards are designed for low-power IoT devices. For example, the Nordic NRF9160 is a combined MCU and LTE-M modem. When the device comes within coverage, the modem attaches to the network, negotiates power saving mode (PSM) or extended discontinuous reception (eDRX), and opens a data socket. Keep the modem off while offshore; some designs even remove power from the modem entirely via a transistor.
Sensors
Beyond location, sensors provide context:
- An accelerometer can detect vibrations when the container is loaded/unloaded or in motion
- A temperature/humidity sensor monitors ambient conditions; some cargo requires temperature logging
- A light sensor can detect door openings (sudden exposure to light)
- A magnetometer or gyroscope can determine orientation and tilt
Use I2C or SPI to interface sensors, and sample them only when the MCU is awake to minimise power.
Power Source
Primary lithium batteries (e.g. Li-SOCl₂) offer high energy density and long shelf life. A 19 Ah battery can power a device for several years with proper duty cycling. Rechargeable lithium or supercapacitors are alternatives if you can occasionally recharge (e.g. solar). Design the circuitry for wide voltage ranges and include a low-dropout regulator to supply the MCU. Consider an inline current sense resistor to measure draw and adjust duty cycles dynamically.
Enclosure and Mounting
The enclosure must be rated at least IP67, salt-spray resistant, and able to withstand shock and vibration. Use gaskets and stainless steel fasteners. Magnetic mounting simplifies installation on steel doors; adhesives or bolts provide more permanent attachment. Position the tracker so that the GNSS antenna has a clear view (e.g. on the top corner of a door). Avoid obscuring the device with cargo or stacking to maintain connectivity. Antenna placement is critical: some trackers embed patch antennas; others route coax to an external antenna for better performance.
Firmware: State Machine and Data Logging
A reliable firmware architecture isolates hardware drivers from application logic and implements a clear state machine. The following pseudocode illustrates a typical loop:
enum State { SLEEPING, ACQUIRE_FIX, LOG_DATA, CHECK_NETWORK, TRANSMIT, OTA_UPDATE };
State state = SLEEPING;
while (true) {
switch (state) {
case SLEEPING:
sleep_until_next_wakeup();
state = ACQUIRE_FIX;
break;
case ACQUIRE_FIX:
GNSSFix fix = gnss_get_fix(timeout=120s);
log_record(fix);
state = LOG_DATA;
break;
case LOG_DATA:
read_sensors();
log_record(sensors);
state = CHECK_NETWORK;
break;
case CHECK_NETWORK:
if (cell_network_available()) {
state = TRANSMIT;
} else {
state = SLEEPING;
}
break;
case TRANSMIT:
for (Record rec : read_log()) {
bool ok = upload_record(rec);
if (!ok) break; // connection dropped
mark_as_sent(rec);
}
state = SLEEPING;
break;
case OTA_UPDATE:
if (new_firmware_available()) {
download_update();
apply_update();
}
state = SLEEPING;
break;
}
}
Key points:
Duty Cycling: The SLEEPING state uses a low-power timer or interrupt to wake at scheduled intervals (e.g. every 30 minutes). The MCU stays in sleep mode otherwise.
Logging: A record may include timestamp, latitude/longitude, battery voltage, sensor readings, and firmware version. Use a binary format or compact JSON to minimise storage.
Network Checks: When the GNSS fix indicates the container is near land (e.g. within a latitude/longitude bounding box) or the accelerometer detects unloading (vibration pattern followed by stillness), power on the modem and attempt registration. Avoid scanning too often offshore to save power.
Transmission: Send data in small chunks with acknowledgements. MQTT with QoS 1 or HTTPS POST requests both work. Include device ID and sequence numbers for de-duplication. After confirmation, mark logs as sent or erase them.
Updates and Commands: The OTA state listens for configuration updates (e.g. change logging interval) or firmware images. Ensure that update downloads can resume if interrupted and verify signatures to prevent tampering.
Firmware should also implement failsafes: watch dog timers to recover from hangs, CRC checks on log storage, and safe recovery paths if the device resets mid-transmission.
Backend: Ingesting and Processing Data
Once the device connects, the backend must authenticate, parse, store and analyse the data. A minimal pipeline might look like this:
Authentication: Each device has an ID and a secret key. The TLS client certificate or a token is used to authenticate with the broker/server.
Ingestion: Data arrives over MQTT under a topic such as devices/<id>/logs. For HTTP, the device POSTs JSON to an endpoint. Use a load balancer to handle bursts when a ship of hundreds of containers enters port.
Parsing: Decode each record; check timestamps and geofence membership; reject outliers.
Storage: Insert records into a time-series database (e.g. InfluxDB, TimescaleDB) keyed by device ID. Keep unsent copies to support reprocessing if needed.
Visualisation & Alerts: A web app displays the path on a map, aggregates statistics (total distance, average speed), and triggers alerts (door opened, high temperature). Integrate with logistics software to update ETAs or notify customers.
Here is a simple Python example using paho-mqtt to subscribe and process logs:
import json
import paho.mqtt.client as mqtt
BROKER = "your.broker.host"
TOPIC = "devices/+/logs"
def on_message(client, userdata, msg):
device_id = msg.topic.split("/")[1]
records = json.loads(msg.payload)
for rec in records:
# Validate and store rec
print(f"Device {device_id}: {rec['timestamp']} {rec['lat']},{rec['lon']} batt={rec['vbat']}V")
# insert into database...
client = mqtt.Client()
client.on_message = on_message
client.tls_set() # configure TLS
client.username_pw_set("username", "password")
client.connect(BROKER, 8883)
client.subscribe(TOPIC)
client.loop_forever()
A production implementation would add error handling, database writes, and perhaps an event-driven architecture (e.g. AWS IoT Core with Lambda functions) to scale automatically.
Security and Data Integrity
Tracking data can reveal trade patterns and sensitive shipment details, so security is paramount. Best practices include:
Transport Security: Use TLS with strong cipher suites. Rotate certificates periodically. Avoid sending data in plaintext.
Device Authentication: Store credentials in secure elements or encrypted flash. Prevent cloning by binding keys to hardware IDs.
Data Validation: Use hashes or message authentication codes (HMACs) to detect tampering. Each record can include a checksum. On the backend, reject records with invalid signatures.
Firmware Protection: Sign firmware updates and verify signatures before applying. Protect bootloaders with readout protection to prevent extraction of keys.
Privacy Compliance: Anonymise or aggregate data before sharing with third parties. Provide customers with controls over who can view their shipment information.
Power Budgeting and Life Expectancy
A common question is: how long will the battery last? The answer depends on the duty cycle, network availability, and ambient temperature. The average current I_avg can be estimated as:
I_avg = (I_sleep * t_sleep + I_gnss * t_gnss + I_modem * t_upload) / cycle_time
Where:
-
I_sleepis the microamp draw during sleep (e.g. 10 µA) -
t_sleepis the sleep duration (e.g. 2.7 hours if logging every 3 hours and GNSS+upload takes 300 s) -
I_gnssis the GNSS current (e.g. 25 mA) andt_gnssits active time (e.g. 60 s per fix) -
I_modemis the modem draw (e.g. 100 mA) andt_uploadthe upload time (e.g. 120 s per day if uploading once) -
cycle_timeis the total cycle (e.g. 24 hours)
Plugging in numbers yields an average current in the low hundreds of microamps. A 19 Ah battery would last roughly 19 Ah / 0.2 mA = 95,000 hours or about 10 years. In practice, self-discharge, cold temperatures, and network retries reduce life, but multi-year operation is realistic. Designing for a margin (e.g. 2×) and monitoring battery voltage in logs helps schedule replacements.
Deployment, Placement and Integration
When deploying trackers, consider the operational context:
Single Trip vs. Permanent: Freight forwarders may attach a tracker for a single voyage and retrieve it at destination. Make the device easy to mount and remove; include return instructions. If permanently affixing trackers to owned containers, route the antenna to a protected but exposed location and plan for periodic maintenance.
Physical Placement: Mount the device externally where it won't be crushed by other containers. Door handles or top rails are common. Ensure the GNSS antenna faces upwards and the cellular antenna has a clear path to shore. Avoid placing the tracker deep inside a stack where steel walls block signals.
Activation & Test: Activate and test the device at origin. Ensure it obtains a fix and uploads a record while still in cellular coverage. This confirms correct mounting and network registration.
Integration: Expose an API or webhook to downstream systems. For example, your TMS might poll GET /containers/{id}/latest to obtain the last reported position or subscribe to port-arrival events. Use standard formats (ISO timestamps, WGS84 coordinates) to make integration straightforward.
Enhancements and Future Directions
A store-and-forward tracker is a solid foundation, but you can enhance it with advanced features:
Hybrid Tracking: Augment offline logging with AIS vessel position data or shipping line schedule APIs to provide estimated mid-ocean positions. Fuse these estimates with actual logs upon upload.
Edge Intelligence: Use onboard algorithms to detect anomalies (e.g. rapid temperature change, door opening outside port) and prioritise their upload. Send urgent events as soon as any network is available.
Remote Configuration: Implement a downlink channel so the server can change logging intervals or request an immediate position. This requires the device to listen briefly after connecting.
Open Source Collaboration: Consider publishing your firmware and backend under open licences. The community can contribute drivers, bug fixes and new features. Many IoT platforms (ThingsBoard, ChirpStack, EMQX) support custom device templates and may accelerate development.
Conclusion
Satellite-free tracking combines low-power hardware, smart firmware, and scalable backend services to deliver actionable visibility at a fraction of the cost of real-time satellite trackers. By logging GNSS fixes and events offline and uploading them opportunistically, you can understand where your containers have been, detect when they arrived at or left ports, and monitor conditions such as temperature or door openings.
This article walked through the technical decisions involved: choosing components, implementing a robust state machine, securing data, estimating power budgets, and deploying devices in the field. While every logistics operation has unique requirements, the patterns described here should help engineers build and iterate on solutions that meet dev.to's educational and ethical standards.
If you have experience developing similar devices or want to discuss specific design challenges, feel free to leave a comment. Let's continue making supply chains smarter and more transparent.
Top comments (0)