Getting Started with Hubble Network

Bluetooth, but to space

BLE was designed for tiny power budgets and short hops between two devices in the same room. Hubble’s satellites pull those advertising packets out of the air from 600 km up.

Same SoC. No new radio, no new antenna, no new licensing. The work is a firmware integration.

If that sounds implausible: it sounded implausible to a lot of people, including the engineers who built it. The trick is on the receive side, where Hubble’s satellites use a phased-array antenna with over 100 elements working in unison to pull signal out of noise. Your device just transmits a slightly more deliberate BLE advertisement than usual.

Why this matters before you write a line of code

Hardware you probably already own. A Nordic nRF52840 DK, a Silicon Labs xG24 Dev Kit, a Nordic nRF54L15, an ST Nucleo WB55RG. Volume BOM for the RF section comes in around $2-3, versus $20+ for a comparable cellular design. No SIM, no carrier contract, no PTCRB certification, no antenna redesign.

Battery life measured in years. A device advertising every 2 seconds draws roughly 10-30 µA average. CR2032 coin cell: 1-3 years. Larger lithium primary: 5-10. Cellular gives you weeks to months on the same battery.

No platform gatekeeper. Apple Find My requires MFi membership and a 6-12+ month certification cycle. Google Find Hub: similar story. Hubble’s docs are public, the SDK is on GitHub, and you can ship without anyone signing off. (Honest comparison of all four networks here.)

Three-tier coverage. 90M+ scanning gateways including dedicated hardware and smartphones running the Hubble SDK; satellites in low Earth orbit guaranteeing at least one global pass per day. Terrestrial latency is minutes in populated areas. Satellite is your floor when there’s no one around.

If your application tolerates minutes-to-hours of latency (most asset tracking, supply chain visibility, environmental telemetry can), you’re in the right place. If you need bidirectional control or sub-minute alerts, you want cellular. (What cellular actually costs over 5 years.)

Constraints to know on day one

These will shape your design. Better to internalize them now than after your PCB is fabbed.

You’re building a beacon, not a peripheral. This is BLE advertisements, connectionless. No GATT services, no central-peripheral pairing, no MTU negotiation. If your last BLE project was a heart-rate monitor connecting to a phone, this is a different design pattern.

Payload: 13 bytes per packet for telemetry beyond the device ID. Pack binary, version your schema, plan compression. If you’re used to JSON over MQTT, this is a different problem.

TX power: 13-20 dBm for satellite reach today. Typical BLE advertising at 0 dBm won’t make it to orbit. Higher TX power costs more current per advertisement, so battery math gets done at your real TX setting, not the chip’s lowest. (Hubble’s roadmap brings this down to 4 dBm with their next-gen satellites.)

End-to-end encryption. Each device gets a unique key, hardware-protected on supported SoCs. You’ll generate keys in the dashboard and flash them per device.

Sandbox is your first gateway, not a limitation. Self-signup at dash.hubble.com gets you Sandbox access. Hubble’s network is probabilistic by nature: your beacon advertises, and gateways within range pick it up when they’re near. In Sandbox, the production terrestrial network still detects your packets and shows aggregate stats in the dashboard, but payload data is delivered through one specific gateway: the Hubble Connect mobile app on your phone.

That’s a feature, not a workaround. Without Connect, validating a new firmware build means walking around hoping for a passing gateway. With Connect on your desk next to the dev kit, you have a deterministic test loop: flash, advertise, see the packet land. Production access through the full terrestrial network goes through Hubble sales when you’re ready to ship.

What you actually need

  • A Nordic nRF52840 DK. It has an onboard battery, runs Zephyr cleanly, and is the board the team points new developers to. (Other supported boards: Silicon Labs xG24-DK2601B, Nordic nRF54L15, ST Nucleo WB55RG. Use those if you already have one on your desk; otherwise start with the nRF52840 DK.)
  • A free dashboard account.
  • The Hubble Connect mobile app on a phone you can keep next to the dev kit. This is your first gateway.
  • The Zephyr toolchain, via Nordic’s nRF Connect SDK. NCS layers Nordic-specific tooling on top of Zephyr, so you’ll be working with west, devicetree, and Kconfig. If you’ve never touched Zephyr, there’s a learning curve. The community guides linked at the bottom are honest about it.
  • About an hour for the first end-to-end loop, longer if Zephyr is new.

Zero to packets in the cloud

The canonical instructions live in the official docs and they’re more current than anything I’d reproduce here. The shape of what you’ll do:

  1. Set up nRF Connect SDK. Install nRF Connect for Desktop, use the Toolchain Manager to pull the latest NCS, install VS Code with the nRF Connect Extension Pack. Run the blinky sample on your nRF52840 DK to confirm the toolchain works before you touch anything Hubble-specific. If blinky doesn’t blink, fix that first.

  2. Clone the Hubble Device SDK as a Zephyr module from github.com/HubbleNetwork/hubble-device-sdk, then build the BLE network sample:

west build -p -b nrf52840dk/nrf52840 
modules/lib/hubblenetwork-sdk/samples/zephyr/ble-network
west flash

  1. Generate device keys in the dashboard and flash them with the firmware. The Register Your Devices guide covers key generation and onboarding.

  2. Power up and verify. Open a serial console at 115200 baud (minicom -D /dev/ttyACM0 -b 115200 on Linux/macOS, PuTTY on Windows). You should see Hubble Network init logs. Open Hubble Connect on your phone, walk near your board, and watch packets land in the dashboard. The Connect app is your gateway during Sandbox; once that loop works, the rest of the network is the same path with more scanners.

  3. Pull data programmatically. Once packets are flowing, hit the Cloud API to pipe them wherever you actually want them.

That’s the loop. Battery on the DK means you can disconnect USB and watch your beacon keep transmitting from the other side of the room (or the parking lot), which is closer to how the device will actually live in the field.

Where to go from here

Building your first prototype: Start with the Zephyr Quick Start and follow it end to end on your nRF52840 DK.

Stuck on Zephyr itself: The community has honest guides on the 10 most common Zephyr build errors, picking the right board target, and config options first-timers get wrong. They will save you a Saturday.

Sizing the business case: The True Cost of Cellular IoT breaks down what cellular actually costs over a 5-year deployment. Useful when someone in your org is reflexively defaulting to LTE-M.

Comparing networks: Bluetooth Networks vs. Cellular IoT covers Apple Find My, Google Find Hub, Hubble, and cellular side by side.

Going to production: The Cloud Integration guides cover fleet onboarding, key rotation, and the operational stuff that matters once you’re past prototype. Production access on the full terrestrial network is a sales conversation; the docs explain what changes.

You came here to ship a device. Go ship one.