Satellite fleet tracking that separates dead zones from real trouble

When a tracker leaves cellular coverage, the dot on the map stops moving, and nobody can tell whether the vehicle is in a dead zone, has a dead unit or is being stolen. Dual-mode devices that fall back to Iridium keep a message channel open, but a channel is not an answer. In this article, we look at how TSPs can turn those messages into alerts, honest reports and a service customers renew, using Navixy and the newly integrated Inmosat CarFinder Sat as the working example.

What happens when a vehicle leaves the coverage area?

Let's say Truck 14 is halfway through a night run on a mining road. At 3 a.m. it crosses a 40 km valley with no cellular signal, the dot on the dispatcher's map stops moving, and the screen offers nothing more. The valley may be the whole explanation. The unit may also be dead, or someone may be running a jammer to get a load off the road unnoticed.

Dead zones are not rare edge cases. There are logistics cases that point out large uncovered areas from African deserts to South American jungles, besides, unattended 2G towers widen the gaps. Jamming is the deliberate version. Jammers were reportedly involved in about 85% of roughly 3,400 cargo truck thefts in Mexico in one 2020 tally, and in 64% of theft events in the first half of 2024, according to a cargo-security provider.

What makes this hard for a TSP is that the platform can only say so much about silence. The Device lost connection rule counts silence against a timeout, and IoT Logic flows run when a message arrives, so a unit that says nothing gives a flow nothing to work with. Our recent home-presence article makes the same point in another domain. Your dispatcher is left with a red dot and a guess.

A second channel changes the picture. A dual-mode device keeps cellular as its primary link and falls back to Iridium when GSM is lost, so the dead zone becomes a series of sparse check-ins instead of a blank. It's a big step, not a cure. The limits come later in this piece.

If you want to see how devices connect to Navixy before reading on, the activation guide is the place to start. It shows what a satellite unit needs from the platform side.

What a satellite tracking setup needs to cover

Before choosing hardware, it helps to agree on what the setup has to do. For a fleet that regularly leaves coverage, the list is short.

1. Position beyond coverage. The vehicle keeps reporting without cellular and returns to it when it is back, since Navixy's Iridium guidance has GSM keeping priority.
2. A predictable cost. Satellite airtime is priced above cellular data, so it has to be spent on the assets that need it.
3. A way to call for help. An SOS that does not depend on a cell tower.
4. Context for silence. A way to tell a dead zone from a real problem, with alarms that do not cry wolf.
5. Reports that stay honest. Trips, parking and mileage that still mean something on sparse points.

The payload limits explain why the second and fifth items matter. The common Iridium SBD transceivers send up to 340 bytes and receive up to 270, and a message can take 5 to 20 seconds to cross the network. A Geotab support article describes its Iridium option as pinging every 30 minutes and typically sending only location. Small and sparse is simply how satellite data looks.

Turning the checklist into something a vehicle can carry

Navixy's 2026.07 release added the Inmosat CarFinder Sat, a satellite GPS device, to the supported list. Inmosat lists two digital outputs, memory for more than 100 messages, over-the-air configuration and internal GPS and satellite antennas, and the unit reports over both cellular and Iridium. That covers the first item on the list.

The device can't do the rest alone. Judging whether silence is normal, setting alarm timers that fit the reporting pattern and explaining sparse reports all happen after the message arrives.

A check-in arrives from the dead zone. What happens next?

Truck 14 sends a check-in from the valley just after 3 a.m. Here is what the platform can do with it.

Give the check-in a place

Dark zones are places, and Navixy already knows how to describe places. Draw geofences around the coverage holes you know about, such as the mining road, a mountain pass or a stretch of desert highway. The check-in stops being a pair of coordinates and becomes Truck 14, inside the valley zone, just after 3 a.m. The audit later in this article will find the holes you don't know about.

Build the rule in IoT Logic

The geofence functions inGeofence(), enterGeofence() and leaveGeofence() let a flow branch on where a message came from. For Truck 14 the rule is simple.

Satellite check-in → inside a known dark zone? → yes, log as routine / no, escalate

A check-in from inside a dark zone is routine. A check-in from anywhere else goes to a Webhook node, which sends an HTTP POST to the customer's security desk or ticketing system without waiting for a reply. What a check-in carries depends on the device and its mapping in Navixy, so send a test message and inspect it in the Data Stream Analyzer before you deploy.

Set timers that fit the pattern

A red dot that is always red is just wallpaper. Dispatchers who see the same offline alert every time a truck crosses the same valley stop reading it, and the usual cause is one timeout applied to every device. A unit checking in hourly over satellite and one updating every 30 seconds over cellular cannot share the same idea of silence.

Navixy lets you set the offline timeout per device in the connection state settings, from 1 minute to about 3,000 days. The field shows 10 minutes until you save a value, but that is only a placeholder, and unsaved devices fall back to a built-in timeout that varies by device and connection type. The Device lost connection rule adds its own custom time to a separate 10-minute default, so build one rule per reporting profile. The docs do not spell out how the two timers interact, so test the combination on one unit first.

Reports that stay honest with sparse points

Now the customer disputes Truck 14's trip. The mileage looks lower than the fuel receipts suggest, and part of the run is missing from the track. Sparse points are the likely cause, and every report has a promise it can keep and one it cannot.

Parking detection needs the unit to stay below the idle speed for the full minimum inactivity time, so that setting has to be longer than the reporting interval. If the interval exceeds the idle time, Navixy will not display tracks and the device can sit in a Parked state. Geofence visits are built from the points received, so a short visit between two check-ins never shows up. Mileage suffers because infrequent points cut corners and the virtual odometer lags.

Freshness matters too. Data more than five minutes old is shown as not current, so buffered uploads after a dead zone carry the status GPS not updated even when the unit is healthy. Write down what each asset class's reports will and will not show, and agree that one-page profile before go-live.

The panic button that works without cellular

A dead zone is also where Truck 14's driver is alone. A panic button that only works with cellular coverage fails exactly when it is needed, and Teltonika's Zambia case shows the pattern. An Iridium Edge modem sends the alert with coordinates over Short Burst Data, and it only transmits when the tracker cannot use the cellular network.

On Navixy, an SOS rule can turn a panic event from a supported device into SMS, email, push or in-app notifications for whoever is on shift. For supported integrations, output commands can also travel back to the device over the satellite path when its last connection arrived over SBD.

Keep satellite events out of a silo

Most customers already have a system that owns the response, whether that is a security desk, a ticketing tool or a transport management system. Navixy's lone worker safety article makes the point for personal trackers, and it holds here too. The alert belongs in the customer's process, not on one more screen.

The Data Source node brings route or shipment data into a flow, so a stop scheduled inside a dead zone can count as expected. Live data forwarding sends messages to a third-party server over 29 supported protocols, and the reports API lets a customer portal pull reports without opening Navixy. IoT Logic is a separately licensed feature, and satellite devices are activated manually through the operator's gateway, so plan for both before you promise a go-live date.

Find who needs satellite before you sell it

The smartest satellite sale is the smallest one that solves the problem, and your customers' existing data can show how small that is. Navixy's Iridium guidance puts the sweet spot at a tracker that often leaves coverage, sends under 1 Mb a month and has to stay online, so start by screening the fleet you already track on cellular.

Raw IoT Data exposes both the time a device generated a message and the time the server received it, and you can export it as CSV or Parquet, with plan-based time windows that commonly start at 30 days. Load it into IoT Query for SQL access, or build the view in Dashboard Studio and export it as a report. Long gaps between messages, and buffered uploads right after them, mark the assets and routes that are your satellite candidates. The rest stay on cellular.

Then treat the satellite message as a budget. At least one reseller bills in 50-byte steps, so decide what the message carries, such as position, ignition, a panic flag and an output state, and leave the rest to cellular. IoT Logic works on data after it arrives, so it cannot cut airtime. The device decides what it sends, and tracking mode is the lever you have.

For a TSP, this can be more than a hardware upsell

A field-service fleet, a mining contractor and a cargo carrier all lose signal, but they will not buy the same service. The hardware and the Navixy environment can stay the same while the dark zones, timers, escalation paths and reports change for each customer.

That lets a TSP sell the answer to whether a truck is all right, and package tiers instead of a device. A basic tier could be satellite tracking with honest reporting profiles. A monitored tier adds check-in judgment and escalation. An integrated tier feeds the customer's own systems.

What none of this fixes

Satellite does not defeat GNSS jamming. Position still comes from the GNSS receiver, so a jammed unit can lose its position fix even if its message channel is still open. Navixy's GPS and GSM jamming rules depend on what the device itself can detect and report.

Installation is the other limit. A satellite link needs a reasonable view of the sky, and vehicle roofs and other structures can obstruct it when the antenna sits inside the cab, so where the antenna goes matters as much as which device you buy.

The valley stays dark. The report doesn't.

A satellite channel has an awkward commercial problem. When it works, nothing dramatic happens, so a customer paying for it sees a cost and no visible benefit. Measurement fixes that. Report the hours each asset spent outside cellular coverage, the check-ins that kept it visible and the alerts judged routine instead of escalated, and the invisible value becomes a line in the monthly report.

Truck 14's valley will still be dark next month. The difference is that the report will say so, which should make the renewal conversation a much easier one.

If you are building satellite fleet tracking services for your customers, we would like to hear what you are working on. Get in touch with the Navixy team to discuss what your platform should do once the message arrives.