Transmission Guidance
The Satellite Network
Hubble's Satellite Network lets a standard Bluetooth® Low Energy (BLE) device transmit up to 13 bytes of data from almost anywhere outdoors—no gateway, cellular, or Wi-Fi required. The device uses the same 2.4 GHz BLE radio it already has; no dedicated satellite hardware is needed.
Hubble's LEO satellites orbit at approximately 550 km and actively maintain their orbit via onboard propulsion (station keeping). Because their position is predictable, the device may be provisioned with orbital parameters once and it remains valid for its lifetime in the field.
See a simple diagram for how Satellite Network works.
When to Use It
The satellite network suits stationary or region-locked outdoor devices that send small, infrequent updates from locations with no other connectivity: asset and equipment tracking in remote areas, container and fleet monitoring, fixed-position tank or meter readings, environmental sensors, and periodic heartbeat messages.
Each message is up to 13 bytes. The network delivers one or more transmit opportunities per day. It is not built for real-time reporting, high-frequency data, large payloads, or indoor use.
What to Expect
Satellite Passes
A pass is the window lasting 3-5 minutes when a satellite is above the horizon and can receive device transmissions. With Hubble’s current constellation, pass opportunities occur one or more times per day.
- The Hubble Device SDK predicts pass times entirely on-device using satellite ephemeris (orbital parameters) plus current time and known device position, with no live connection required at transmit time.
- During a pass, the device transmits the same packet several times across the window to improve delivery odds.
- After the satellite receives a packet, it downlinks to a ground station when in range. Target end-to-end delivery: within 6 hours.
- A missed pass is not a device failure; the next pass opportunity is expected within 24 hours, and often much sooner. Note that satellites perform station-keeping maneuvers approximately once per month. During those windows the gap may be longer than usual.
Device Location
The satellite network does not provide the location of the transmitting device. If your application requires position data and has a GPS module or other on-device source, we recommend that you encode it in the 13-byte custom payload.
For efficient beaconing using orbital parameters, the device must know current time and provisioned installation location to calculate when a satellite is expected to be overhead.
Device Requirements
| Requirement | Detail |
|---|---|
| Transmit Power (Tx) | ≥ +20 dBm radiated. Most designs require a front-end module (FEM) or power amplifier (PA). |
| Battery | Peak current at +20 dBm transmission exceeds coin cell capacity. |
| Antenna | Dipole recommended (chip/PCB trace antennas reduce coverage). |
| Software/RTOS (real-time operating system) | Supported systems on a chip (SoCs) only (see supported SoCs). Additionally, devices need free Flash and RAM headroom for the SDK module. |
Use of Radio
The Satellite Network protocol runs on the device's standard 2.4 GHz BLE radio but operates at a slower bit rate than standard BLE advertising, enabling a link to a satellite orbiting 550 km overhead. The SDK handles all radio modulation details; you never work at this level directly.
Note the data link is one-way: the device only transmits and never receives anything back on the satellite link.
Dual-Stack Behavior
A device can operate on both the Terrestrial and Satellite Networks using the same radio, but only one at a time:
- When a pass is imminent, the device tears down the BLE stack and enters SatNet transmission mode for the duration of the pass.
- After the pass, BLE is re-initialized and terrestrial operation resumes.
The Hubble Device SDK manages this transition automatically in Hubble Controlled Transmission Timing mode. Design your application to tolerate a 3-5 minute BLE blackout during each pass.
Maximizing Reliability
1. Meet the transmit power requirement
Reaching our current generation satellite in low-earth orbit requires ≥ +20 dBm radiated output. Most BLE chipsets output 0–8 dBm, therefore a front-end module (FEM) or power amplifier (PA) is required for most designs.
2. Use a dipole antenna
A dipole's wider radiation pattern provides more usable retries per pass as the satellite moves across the sky. Chip and PCB trace antennas are supported but reduce coverage.
3. Meet device placement requirements
- Optimize placement for ≥ 45° elevation cone unobstructed in all directions
- Maintain ≥ 2 cm clearance from metal or liquid surfaces
- Light to moderate tree canopy (≤ 50% overhead foliage) is tolerated but may interfere
- Cloud cover, rain, and light snow should not affect the link
- Indoor deployments are not currently supported
4. Choose the right reliability mode
Hubble’s SatNet transmission module supports multiple reliability modes, where the SDK wakes and transmits at the right time automatically. Higher reliability costs more energy per pass. For applications where power is unconstrained or clock synchronization is unavailable, Customer Controlled Transmission Timing lets you manage retransmissions directly, including continuous transmission for the full pass duration.
5. Choose the right payload size
The SDK supported these payload sizes: 0, 4, 9, or 13 bytes. Smaller payloads leave more time for retries within the pass window.
Comparison to Terrestrial
Satellite Network shares the same SDK, device key, encryption modes, payload model, and API/dashboard as the Terrestrial network. A device can move between the two networks freely with no permanent changes (see Dual-Stack Behavior above).
| Factor | Terrestrial | Satellite |
|---|---|---|
| What receives device transmission | Nearby BLE gateway or phone | LEO satellite passing overhead |
| When you can transmit | Continuously; data transmitted any time a gateway is in range | Pass-based: beacon during predicted pass opportunities (1 or more per day) |
| Transmit power (Tx) | Standard BLE output (low to high range supported). | +20 dBm (FEM/PA may be required) |
| Custom Payload | 0-13 bytes | 0, 4, 9, or 13 bytes |
| Provisioning | Device only needs current time when using time-based encryption mode. | Device needs current time and installation location for efficient beaconing using orbital parameters from SDK. |
| Coverage | Global (low to high-density areas) | North America |
| Placement | Indoor or outdoor; mobile | Outdoor, with clear sky view; recommend fixed position installation |
| Data delivery | Near real-time | Within 6 hours |
| Location Data | From scanning gateway location lock. | Not currently provided. |