How to Deploy IoT Devices You Can't Easily Visit Again

Sensors installed in remote locations where return visits aren't practical

A truck roll to a sensor in a suburban warehouse costs maybe $300. A truck roll to a sensor on a ridgeline in the Yukon costs $15,000, requires a helicopter, and only happens during a 6-week weather window in late summer. If your firmware bug shows up in October, you’re waiting until July.

That math drives every design decision. This is an opinionated checklist, written from the perspective of having watched too many “it worked on the bench” devices go silent 60 days into a 5-year deployment. I work at Hubble, and we’ll get to where I think satellite BLE fits, but the checklist matters more than the vendor.

Design Principle: Assume You’re Never Coming Back

For genuinely remote sites, install-and-forget is the only honest design constraint. Three rules I’d staple to the wall:

  • Every component has a defined failure mode. Not “shouldn’t fail.” Defined. What does the device do when the GPS module browns out? When the flash wears? When the battery hits 2.8V at -30°C?
  • Every external dependency is a liability. Cloud APIs deprecate. Cell carriers retire 3G. Battery vendors get acquired and reformulate the chemistry. Assume each will betray you within the device’s lifetime.
  • If you can’t debug it from 1,000 km away, you can’t debug it. Build the diagnostics in before the first unit ships, not after the third one goes dark.

Connectivity: The Decision That Defines Everything

Get this wrong and nothing else matters.

Why LoRa is often the wrong answer for truly remote sites. LoRa is great for dense clusters within range of a gateway you control. The problem: in true wilderness, you don’t have a gateway. You’re deploying two devices, the sensor and the gateway, plus the gateway’s backhaul (usually satellite or cellular), plus the gateway’s power system. You’ve now doubled your failure surface. And you’ve done it to save power on a link that wasn’t your bottleneck. The 15 km range numbers in Semtech whitepapers assume line-of-sight that mountains, canyons, and forest canopy don’t provide. If you have 50 sensors in a 2 km radius near a power source, LoRa’s defensible. For a single sensor on a glacier, it’s a trap.

Cellular (LTE-M/NB-IoT). Fine where coverage genuinely exists. Verify it on-site with the actual modem and antenna you’ll deploy, not with a coverage map and not with your phone. Carrier coverage maps are aspirational marketing. Roaming agreements expire too, and NB-IoT roaming in particular is a mess outside the carrier’s home country.

Iridium / Swarm. Proven, global, and expensive. Iridium SBD costs add up fast if you’re sending more than a few packets a day, and the modems pull serious current during transmit (think hundreds of mA for several seconds). Right answer for bulk telemetry from a vessel with a real power system. Wrong answer for a coin-cell sensor.

Satellite BLE (Hubble). Disclosure: this is us. The pitch: your device speaks plain Bluetooth Low Energy, the same stack you’ve already debugged on the bench, and our satellites act as the gateway. No ground infrastructure to deploy. No LoRa gateway to maintain. Power draw is in line with normal BLE advertising, which is orders of magnitude below an Iridium burst. The trade-off: it’s built for low-data telemetry, not bulk transfer. If you’re sending kilobytes a day of sensor readings, it fits. If you’re streaming images, it doesn’t. Coverage and current capabilities are documented in the Hubble network and satellite docs.

| Option         | Range    | Power   | Infra Needed | Cost/MB | Best For        |
|----------------|----------|---------|--------------|---------|-----------------|
| LoRa           | 2-15 km  | Low     | Gateway      | Low     | Dense clusters  |
| LTE-M/NB-IoT   | Cellular | Med     | None*        | Med     | Near coverage   |
| Iridium        | Global   | High    | None         | High    | Bulk telemetry  |
| Hubble (SatBLE)| Global   | V. Low  | None         | Low-Med | Sparse remote   |

A rough decision tree:

Is there reliable cell coverage on-site (verified by survey)?
├── YES ──> LTE-M / NB-IoT
└── NO
    ├── Multiple devices within 5 km of each other?
    │   ├── YES ──> Consider LoRa + satellite backhaul gateway
    │   └── NO  ──> Skip LoRa
    └── Low data volume (<1 KB/day)?
        ├── YES ──> Hubble (satellite BLE)
        └── NO  ──> Iridium / Swarm

Power: Design for the Worst Week, Not the Average

Average insolation will get your device through 11 months a year and kill it in February. Size the solar panel and battery for the worst week at your latitude with realistic dust, snow, and shading. NREL’s insolation datasets are a good starting point; pad them by 30%.

A few specifics I’d insist on:

  • Battery chemistry matches temperature range. LiFePO4 won’t charge below 0°C without damage. Li-SOCl2 primaries handle -40°C and have absurd shelf life. The catch: they can’t be recharged, and they passivate if you draw too little current for too long. Pick deliberately.
  • Quiescent current dominates. A device asleep 99.5% of the time is defined by its sleep current, not its active current. Measure it on the actual board with a precision DMM or a Joulescope. Datasheet numbers are best-case lab conditions and they lie.
  • Brown-out behavior is defined and tested. Inject a slow voltage decay on the bench. Watch what the firmware does. Then watch what it does when it comes back up. That’s your February behavior.

Firmware Architecture for Remote IoT Maintenance

Remote IoT maintenance is a firmware architecture problem. If you treat it as ops, you’ve already lost.

OTA with A/B partitions and automatic rollback. Two firmware slots, a boot counter, and a watchdog that swaps back to the known-good slot if the new image fails to check in within N boots. Non-negotiable. The first time a bad OTA bricks 200 devices in the field, you’ll wish you’d built it.

Watchdogs at multiple layers. Hardware WDT for hangs. Application heartbeat for logic deadlocks (a stuck state machine can keep kicking the hardware WDT forever). Connectivity heartbeat: if no successful uplink in X hours, force a full reboot. Belt and suspenders.

Safe mode. After 3 failed update attempts or N consecutive crashes, drop to a minimal known-good firmware that does nothing but advertise battery voltage, reboot count, and last error code on a reduced duty cycle. You can recover a device in safe mode. You can’t recover one stuck in a boot loop.

Telemetry includes diagnostics, not just sensor data. Every packet should carry battery voltage, RSSI or link quality, reboot count since commissioning, uptime, and last non-zero error code. When something goes wrong, this is the only forensic data you’ll ever have. The Hubble advertising packet format gives you the byte budget; spend some of it on diagnostics.

Field Commissioning: The Step Everyone Underestimates

Most “failed deployments” didn’t fail in the field. They failed at install and nobody noticed until the data didn’t show up two weeks later.

  • Commissioning works fully offline. Don’t assume the technician’s phone has signal. It doesn’t. Pair locally over BLE, verify on the device.
  • Use a deterministic checklist app that reads live sensor values, runs an end-to-end uplink test, confirms battery and solar input, and only then issues a green light. No “looks fine.” Either every check passes or the install isn’t done.
  • Photograph the install. Log GPS automatically. When something goes wrong in 18 months you’ll want to know which way the panel was facing and whether a tree grew into the line of sight.
  • Green-light criteria are unambiguous. Defined thresholds, not vibes.

If you’re building this flow from scratch, the BLE provisioning guide and the device SDK reference apps are a reasonable starting point.

Physical and Environmental Hardening

  • IP67 minimum. IP68 if there’s any chance of submersion, burial under snow, or sustained driven rain. Cable glands matter as much as the enclosure; most water gets in through the wires.
  • UV degrades plastics and cable jackets faster than you think. A 3-year deployment in high-altitude sun will turn a generic ABS enclosure into a chalky shell. Specify UV-stabilized polycarbonate or use metal.
  • Wildlife is real. Rodents chew cables. Birds nest in enclosures. Bears investigate things that smell new. Armor exposed cables, seal vents with mesh, mount above ground where you can.
  • Mounting survives the worst storm in the local 10-year record. Look up the actual wind and snow load data for your site, then double it. The mast is cheap; the helicopter isn’t.

Pre-Deployment Checklist 

[ ] OTA tested end-to-end with rollback
[ ] Power budget validated for worst-case month
[ ] Quiescent current measured (not estimated)
[ ] Connectivity verified on-site, not on map
[ ] Commissioning works with zero internet
[ ] Diagnostics in every telemetry packet
[ ] Enclosure rated for 3+ years UV exposure
[ ] Mounting survives 10-year storm
[ ] Known-good firmware fallback in place
[ ] GPS + photo logged at install

If you can’t confidently check every box, delay the deployment. The cheapest fix is the one you make before the helicopter takes off.

Hubble Network provides satellite connectivity to Bluetooth devices anywhere on Earth, removing the need to verify cellular or LoRa coverage before deploying to remote sites. See how it works →