What Hardware Engineers Should Know Before Building on Skylo

Hardware design considerations and tradeoffs when integrating Skylo satellite IoT modules into connected devices

You’ve seen the pitch: take your existing NB-IoT stack, point it at the sky, and get global satellite coverage through a 3GPP standard. No proprietary protocols, no exotic hardware. Skylo makes it sound like the last connectivity gap in IoT just closed.

Parts of it are true. But if you’ve shipped a cellular IoT product before, you already know the distance between a standards document and a production deployment. With NB-NTN, that distance is bigger than Skylo’s marketing materials suggest. The power math is different. The cost math is different. The coverage reality is different.

Here’s what you need to model before you commit your design.

Skylo Coverage Gaps: Not the Blanket You Think It Is

Skylo’s coverage map looks impressive at first glance. But there’s a meaningful difference between “satellite footprint” and “your device can reliably send a message right now.”

The actual availability of an NB-NTN link depends on satellite pass schedules, elevation angles, and your device’s physical environment. A satellite at low elevation means longer path loss, more atmospheric attenuation, and a higher chance that terrain, buildings, or tree canopy block the signal entirely. The minimum usable elevation angle for most NB-NTN links is around 25-30 degrees. That carves out a big chunk of the sky.

For LEO-based NTN services, the satellite isn’t always overhead. Your device might have a 10-minute window every 90 minutes, or less, depending on the constellation’s orbital plane and your latitude. Messages queue. Latency isn’t seconds; it’s minutes to hours. If you’re used to NB-IoT where the base station is always there, this is a fundamentally different availability model.

Then there’s the roadmap problem. “Global coverage” today means something different than “global coverage in 2026.” Skylo’s constellation partnerships are still scaling. Some regions have good revisit times. Others have gaps you won’t find on the marketing page.

What’s your application’s maximum tolerable message latency, and have you validated it against Skylo’s actual pass schedule in your specific deployment geography?

NB-NTN Power Consumption: The Link Budget Tax

This is where many designs break.

Reaching a satellite (LEO at ~550 km, GEO at ~36,000 km) requires fundamentally more energy than reaching a cell tower 5 km away. The path loss difference is enormous, and it shows up in every part of the power budget.

NB-NTN modules typically transmit at 23 dBm, compared to 14-20 dBm for terrestrial NB-IoT. Peak transmit current jumps from roughly 120 mA to 350-500 mA. The protocol also has to handle Doppler pre-compensation, timing advance for propagation delay, and longer preamble sequences, so each transmission window stretches from the 1-5 second range up to 10-60 seconds.

        POWER BUDGET COMPARISON (TYPICAL)
+-------------------+-------------+--------------+
|                   | Terrestrial | NB-NTN       |
|                   | NB-IoT      | (Satellite)  |
+-------------------+-------------+--------------+
| Tx Power          | 14-20 dBm   | 23 dBm       |
| Peak Tx Current   | ~120 mA     | ~350-500 mA  |
| Typical Msg Time  | 1-5 sec     | 10-60 sec    |
| Sleep Current     | ~2 µA       | ~2 µA        |
| Energy per Msg    | ~0.15 mWh   | ~2-5 mWh     |
+-------------------+-------------+--------------+
  Values are approximate; vary by module, antenna,
  and network conditions.

Each NB-NTN message costs roughly 13 to 33 times the energy of a terrestrial one. That’s a wide range, but even the low end reshapes your power budget. Sleep current is similar, but if you’re sending even a few messages a day, active-mode energy dominates.

The cascade hits fast. A device you designed for 5-year battery life on terrestrial NB-IoT might last 18 months on NB-NTN with the same cell. To get back to 5 years, you need a bigger battery, which means a bigger enclosure, which means higher unit cost, different tooling, different logistics.

Have you re-run your power budget with NB-NTN Tx parameters, and does your target battery life still hold?

Skylo Module Cost and Data Economics

The BOM story is similarly rough for teams accustomed to cellular IoT pricing.

Mature NB-IoT modules from Quectel, Nordic, or others run $5-8 at volume. NB-NTN capable modules, based on Qualcomm 212S or MediaTek NTN chipsets, start at $20 and up. That’s a 3-4x premium on the connectivity module alone.

But the module isn’t the whole story. Satellite links need better antennas. A terrestrial NB-IoT chip antenna or small PCB antenna (maybe $0.50-2) won’t cut it. You’ll likely need a patch antenna or helical with higher gain, running $2-5. And as we covered, you probably need a bigger battery.

Data pricing compounds the problem. NB-NTN data plans look affordable per-message or per-byte on a rate card. But multiply by fleet size and years of operation, and the numbers grow. Typical plans run $3-10/year per device for low-throughput use cases, versus $1-3/year for NB-IoT.

       PER-DEVICE COST COMPARISON (APPROX.)
+--------------------+-----------+-----------+
|                    | NB-IoT    | NB-NTN    |
+--------------------+-----------+-----------+
| Module             | $5-8      | $20+      |
| Antenna            | $0.50-2   | $2-5      |
| Battery (5yr tgt)  | $2-4      | $5-12     |
| Annual Data Plan   | $1-3/yr   | $3-10/yr  |
+--------------------+-----------+-----------+
| 5-Year TCO (est.)  | $15-30    | $45-85    |
+--------------------+-----------+-----------+
  Ranges reflect volume pricing and typical
  low-throughput IoT use cases.

At 10,000 devices over 5 years, that TCO delta is $150K-$550K.

At your target fleet size, does the TCO delta justify the satellite coverage gain, or is a hybrid cellular-plus-satellite architecture the better play?

3GPP NTN in the Real World: Mature on Paper, Young in Practice

3GPP Release 17 defined NTN extensions for NB-IoT. Release 18 refines them. The standard exists, and that’s what makes Skylo’s approach more appealing than proprietary alternatives long-term.

But a standard on paper and a working ecosystem are different things. The chipset vendors (Qualcomm, MediaTek) shipped their first NTN-capable silicon recently. Module vendors are still qualifying designs. Skylo’s network is still growing. The interoperability chain (specific chipset to specific module to specific satellite to specific ground segment) hasn’t been tested across years of field deployment. There are edges.

Firmware complexity goes up. Your embedded team needs to handle Doppler pre-compensation, GNSS-assisted timing synchronization, and satellite-specific paging behaviors. These aren’t just new API calls; they’re new failure modes. What happens when GNSS fix fails? When the timing advance calculation drifts? When the satellite handover doesn’t complete before the pass ends?

Field debugging is harder too. With terrestrial cellular, you can walk to the base station. With satellite, you need clear sky, the right pass window, and often specialized RF test equipment. Your test strategy needs to account for this.

Is your firmware team resourced for NTN-specific complexity, and do you have a test plan that doesn’t depend on perfect sky conditions?

When Skylo Isn’t the Right Answer

Skylo makes sense for some use cases. But engineers often reach for it before honestly evaluating whether their application actually needs what NB-NTN provides.

One-Way Telemetry: Consider BLE-to-Satellite

Many IoT deployments are fundamentally one-directional. Sensor readings every hour. GPS pings every 15 minutes. Threshold alerts. Asset check-ins. If your device sends data up and never needs to receive commands down, NB-NTN’s two-way capability (and its associated cost and power overhead) might be overkill.

Hubble takes a different approach: your device transmits using standard BLE, and Hubble’s satellite constellation receives the signal directly. No cellular module at all. The Hubble device SDK works with common BLE chipsets you probably already have on your bench. Power draw is dramatically lower, module cost drops to a few dollars, and firmware is simpler because you’re working with a familiar BLE stack rather than wrestling with NTN-specific protocol behavior.

The tradeoff is real: no downlink. No firmware OTA over satellite. No message acknowledgment. Your application has to tolerate fire-and-forget semantics. For agricultural sensors, wildlife tracking, cold-chain monitoring, or stolen vehicle recovery pings, that’s often fine. You can read more about how the BLE-to-satellite architecture works and see if it fits your use case.

Two-Way with Proven Global Coverage: Iridium

If you genuinely need bidirectional satellite communication with reliable global coverage today, not on a roadmap, Iridium is the proven answer. Their 66-satellite LEO constellation provides pole-to-pole coverage that’s been operational for over 20 years. The 9603N SBD module runs $15-30, message latency is typically around 30 seconds, and the developer ecosystem is battle-tested.

The tradeoffs: Iridium’s protocol is entirely proprietary (no 3GPP anything), data costs are higher for larger payloads, and you need an Iridium-specific antenna. But coverage is real, today, everywhere. For maritime applications, remote industrial control, emergency safety devices, or any use case where “message must get through” is non-negotiable, Iridium’s track record is hard to argue with.

Choosing Your Satellite IoT Path

Here’s a simple decision tree:

Does your device need satellite connectivity?
  |
  NO --> Stick with cellular IoT (NB-IoT / LTE-M)
  |
  YES
   |
   Is downlink (commands/OTA) required?
   |
   NO --> Is cost and power critical?
   |        |
   |        YES --> Evaluate Hubble (BLE-to-satellite)
   |        NO  --> Skylo or Iridium both work
   |
   YES --> Do you need global coverage TODAY?
            |
            YES --> Evaluate Iridium SBD
            NO  --> Skylo NB-NTN (with coverage
                    validation in your regions)

Hybrid architectures (cellular primary with satellite fallback) are often the pragmatic choice. You get low cost and low power when terrestrial coverage exists, and satellite as the safety net when it doesn’t. But hybrid adds firmware complexity and BOM cost for two radios, so it’s a tradeoff in itself.

The right answer depends on your specific use case, deployment geography, power budget, cost target, and timeline.

Build with Eyes Open

Skylo and NB-NTN represent a real step forward for IoT connectivity. The convergence of satellite IoT with 3GPP standards matters, and it’ll matter more as the ecosystem matures over the next 2-3 years.

But “3GPP standard” doesn’t mean “drop-in replacement for cellular.” Do the power math. Do the cost math. Run the coverage validation in your actual deployment regions, not on a slide deck. If you want to evaluate the BLE-to-satellite path, you can register test devices through Hubble’s platform and run the comparison yourself.

Hubble Network enables direct-to-satellite connectivity from a standard Bluetooth chip — no second radio, no hybrid firmware complexity. See how it works →