{/* Node 1 — Tracked Device */}

Your
Device

Beacons with encrypted custom payload during satellite pass

{/* Connector 1 — RF Uplink */}

Hubble Protocol

{/* Node 2 — Satellite */}

{/* Earth globe */}

Hubble Constellation

Hubble Satellite

Packet detected from orbit during pass (one or more opportunities per day)

{/* Connector 2 — Downlink */}

Downlink

{/* Node 3 — Hubble Backend */}

Hubble
Backend

Receives encrypted packet with custom payload and timestamp

{/* Connector 3 — API / Webhook */}

API / Webhook

{/* Node 4 — Customer Application */}

Customer
Application

Receives decrypted packet with custom payload and timestamp

**Devices transmit based on satellite pass opportunities.** Using satellite ephemeris data (orbital parameters for each satellite in the constellation), the Hubble Device SDK computes the next pass opportunity entirely on-device and schedules transmission for the start of that window. The constellation offers at least one transmit opportunity per day, with each pass window lasting 3–5 minutes. During a pass, the device transmits the same packet multiple times across the window to maximize the chance of a successful capture. Once a satellite receives the packet, it downlinks to a ground station when in range, with end-to-end delivery typically within 6 hours. --- # Test with a Pluto SDR # Test with a Pluto SDR --- ## Overview Use this guide to confirm your device is transmitting valid Hubble **Satellite Network** packets before you wait on a real satellite pass to tell you. - **What:** A [Pluto SDR](https://www.analog.com/en/resources/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html) — a software-defined radio (SDR) that plugs into your computer over USB — sits on your bench and receives your device's transmissions directly, so you can check the radio works within minutes instead of waiting for a pass. (For background on how packets travel from your device through a satellite pass to the cloud, see [How Hubble Satellite Network works](https://hubble.com/docs/network/satellite/how-it-works).) - **How:** The `pyhubblenetwork` CLI drives the SDR through a Hubble-provided Docker image that handles RF reception and decoding, then prints decoded packets to your terminal. - **Result:** If packets appear with your device ID and incrementing sequence numbers, the device is transmitting valid, decodable Hubble Satellite Network packets. **Scanning is the happy path.** Only if scanning finds nothing do you need to [capture raw samples](#if-scanning-finds-nothing) and send them to Hubble. :::info A local scan receives RF off the air — it does **not** send anything to the cloud. Packets seen here will **not** appear in your Hubble dashboard. Confirming the full end-to-end path still requires a real satellite pass. See the [Satellite Quick Start](/docs/network/satellite/quick-start). ::: ### What you need | Requirement | Detail | |---|---| | ADALM-PLUTO | [Analog Devices ADALM-PLUTO](https://www.analog.com/en/resources/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html) SDR, connected over USB. | | Docker | [Docker Desktop](https://www.docker.com/products/docker-desktop/) (macOS/Windows) or [Docker Engine](https://docs.docker.com/engine/install/) (Linux), with local access granted on your machine, running before you scan. | | Python | Python 3.9 or later, for [`pyhubblenetwork` CLI](/docs/guides/cli). | | A transmitting device | Powered on and running a satellite transmit build. See [Satellite Quick Start](/docs/network/satellite/quick-start) Step 4. | | Device key | Optional, only needed to decrypt payloads locally. The base64 or hex key from [device registration](https://hubble.com/docs/guides/cloud-integration/register-devices#register-new-devices). | --- ## Set up ### 1. Prepare the Pluto Do this once, before your first scan. What's needed depends on your OS. The Pluto's USB networking defaults to RNDIS mode, which Windows and Linux support natively but macOS does not. | OS | What to do | |---|---| | **Linux** | Nothing. Plug it in. | | **Windows** | Install the [ADI USB drivers](https://wiki.analog.com/university/tools/pluto/drivers/windows) before plugging the Pluto in. Do **not** change `usb_ethernet_mode` — Windows does not support NCM. | | **macOS** | Switch the Pluto to NCM mode (below). | Either way the Pluto ends up reachable at `192.168.2.1`, which is what the scanner uses by default. #### macOS: switch to NCM mode 1. Plug the Pluto into USB. It mounts as a drive named **PlutoSDR**. 2. Open `config.txt` on the PlutoSDR drive. Under `[SYSTEM]`, set: ```text usb_ethernet_mode = ncm ``` **Note:** Spelling matters — an unrecognized value silently falls back to RNDIS with no error. :::warning If `config.txt` has no `usb_ethernet_mode` line at all, the Pluto is running firmware older than v0.33, which predates NCM support. Update it using the [ADI firmware update guide](https://wiki.analog.com/university/tools/pluto/users/firmware), then repeat. ::: 3. Save and eject the drive. The drive reappears after a few seconds; that is not a reboot. 4. Power-cycle the Pluto. The setting is only applied at boot. (Alternatively, also set `reset = 1` under `[ACTIONS]` in step 2 and the Pluto reboots itself on eject.) 5. A new network interface appears and the Pluto answers at `192.168.2.1`. You can send a test ping in terminal to confirm: ```text ping 192.168.2.1 ``` ### 2. Install pyhubblenetwork Open your terminal and install the Hubble CLI ([source and full command reference on GitHub](https://github.com/HubbleNetwork/pyhubblenetwork)): ```bash pip install pyhubblenetwork ``` For CLI-only use, `pipx install pyhubblenetwork` keeps it isolated from your other Python environments. If you already have it, upgrade: ```bash pip install --upgrade pyhubblenetwork ``` ### 3. Start Docker Start Docker Desktop (or confirm the Docker daemon is running on Linux) and leave it running. The first scan pulls the SDR image, which takes a few minutes; later scans reuse the cached image. **Docker must have local network access to use the Pluto SDR.** For example, on macOS you may confirm the application has access under Privacy & Security > Local Network. --- ## Scan for satellite packets With the Pluto connected and your device transmitting nearby: ```bash hubblenetwork sat scan ``` The command verifies Docker, starts the SDR container, waits for the receiver to come up, and then streams decoded packets until you press `Ctrl+C`. Useful variations: ```bash # Stop after 60 seconds hubblenetwork sat scan --timeout 60 # Stop after 5 packets hubblenetwork sat scan -n 5 # Decrypt payloads locally with your device key (hex or base64, 16 or 32 bytes) hubblenetwork sat scan --key "" # JSON output, one object per line hubblenetwork sat scan -o json ``` ### What success looks like Packets print as a table as they arrive: ```text +--------------+--------+--------+----------------------------+----------+----------+--------------+----------------------+ | DEVICE_ID | SEQ | TYPE | TIME | RSSI_DB | CHANNEL | FREQ_OFFSET | PAYLOAD | +--------------+--------+--------+----------------------------+----------+----------+--------------+----------------------+ | 1a2b3c4d | 41 | DATA | Tue Aug 11 10:14:02 2026 | -62.4 | 17 | -1240 | | | 1a2b3c4d | 42 | DATA | Tue Aug 11 10:14:34 2026 | -61.8 | 22 | -1198 | | +--------------+--------+--------+----------------------------+----------+----------+--------------+----------------------+ ``` You're looking for: - The **device ID** matching the device you registered. - **Sequence numbers incrementing** across packets, which shows a live transmit loop rather than one lucky decode. That confirms the device is transmitting decodable Hubble Satellite Network packets at the RF layer. ### Decrypting payloads Passing `--key` decrypts each payload locally with the same AES-CTR scheme used on the terrestrial network. The counter source (`UNIX_TIME` or `DEVICE_UPTIME`) is auto-detected from the packets and announced; force it with `--counter-mode` if needed: ```bash hubblenetwork sat scan --key "" --counter-mode DEVICE_UPTIME ``` Packets the key cannot decrypt are hidden by default. To see them anyway, with a pass/fail column: ```bash hubblenetwork sat scan --key "" --show-failed-decryption ``` Packets appearing here but failing to decrypt usually means a key or counter-mode mismatch between your firmware and your device registration, not an RF problem. --- ## If scanning finds nothing Work through these first: | Check | Detail | |---|---| | Docker is running | The scan fails immediately if the daemon isn't up. | | Pluto plugged in first | Connect the Pluto **before** starting the scan, and make sure nothing else is using it. | | Device is transmitting | Confirm via firmware logs that the transmit loop is actually running. | | Device is close by | Keep the device within a few feet of the Pluto, clear of large metal objects. | | Antenna attached | Both the Pluto and the device need their antennas connected. | | Latest CLI | `pip install --upgrade pyhubblenetwork`. | If you've been through those and still see nothing, capture raw samples so Hubble can analyze the RF offline. ### Capture samples for Hubble Leave the device transmitting and the Pluto connected, then run both commands: ```bash # 10 seconds of raw IQ samples, written to a NumPy .npy file hubblenetwork sat record 10 --output capture.npy # 10 seconds recorded and re-analyzed into a plain-text RF diagnostic hubblenetwork sat signal-report 10 --output report.txt ``` - **`record`** captures the raw radio signal with no decoding. This is the file Hubble can reprocess. - **`signal-report`** records IQ and analyzes it offline into a readable link-health summary: per-symbol timing and drift, channel-hopping validation, amplitude and SNR, and chipset metrics. It reports signal quality only and contains no decoded payloads. Both accept `--output PATH` (a timestamped filename is generated if you omit it). Capturing longer than 10 seconds produces a larger file and covers more transmit attempts; 10 to 30 seconds is usually enough. :::info `signal-report` contains no payload data. The raw `.npy` capture contains whatever your device transmitted over the air, in encrypted form. ::: ### Send them to Hubble Open a support ticket from your [Hubble Dashboard](https://dash.hubble.com) — account icon in the top right, then [Support](/docs/support) — and attach both files along with: - Your device ID and the hardware/chipset you're testing. - The SDK sample or firmware build you flashed. - The counter mode the device was registered with. - What you already tried from the checklist above. --- # Satellite Quick Start # Satellite Quick Start --- ## Overview This guide takes you from an unconfigured device such as a developer kit to confirmed satellite packet reception, then to efficient transmission via pass prediction. Read alongside the [Hubble Satellite Network Transmission Guidance](/docs/network/satellite/transmission-guidance). View supported Bluetooth® [developer kits](/docs/compatibility) for satellite transmission. Onboarding can run multiple days: satellite passes are periodic and brief, so end-to-end confirmation waits on real passes. However, you can validate locally (Step 5) so the device is proven well before the first pass. ### Resources - Hubble Dashboard - `hubble-device-sdk` ([Github repository](https://github.com/HubbleNetwork/hubble-device-sdk)) - `pyhubblenetwork` CLI ([Github repository](https://github.com/HubbleNetwork/pyhubblenetwork)) ### Pick your path 1. Pre-flashed eval device from Hubble: no software development kit (SDK), Pluto, or firmware work. Go straight to Steps 6 to 7. 2. [Supported dev board / reference platform](/docs/compatibility): flash a reference sample, validate, customize payload. Steps 1 to 5 go fast (known-good hardware). 3. Custom hardware: same path plus SDK bring-up. Run a reference sample on a supported board first (Steps 3 to 5) to see what "working" looks like, then port in Step 8. ### Prerequisites | Requirement | Detail | |---|---| | **Supported device** | A [supported SoC](/docs/compatibility#satellite-network-supported-socs) **and** ≥ +20 dBm transmit power (requires a PA/FEM, or an SoC with an integrated one).
The fastest start is a [developer kit validated for satellite](/docs/compatibility) that reaches +20 dBm out of the box. | | **Hubble organization** | A Hubble account with Hubble Live access (Terrestrial and Satellite). Sandbox does not have Satellite access.
If your organization does not have Satellite access, reach out to **support@hubble.com**. | | **Clear sky view** | An outdoor placement with unobstructed sky. Indoor testing will not reach a satellite (see [Step 6](#6-place-the-device)). | ### Optional Resources | Resource | Detail | |---|---| | **Pluto SDR** *(recommended)* | An ADALM-PLUTO over USB, plus Docker, to validate transmission locally in [Step 5](#5-validate-locally-with-a-pluto-sdr). | | **`pyhubblenetwork` CLI** | Python 3 and `pip install pyhubblenetwork`, for Pluto scans and device registration. | | **API token** *(pass prediction only)* | A token with the `read-satellites` scope, exported as `HUBBLE_API_TOKEN`, to fetch orbital parameters in [Step 9](#9-pass-prediction-transmit-efficiently). | --- ## 1. Qualify the device Confirm the device can physically reach the network before any integration. **Most of this cannot be fixed in firmware later.** **SoC and transmit power** are both covered on the [Chip Compatibility](/docs/compatibility#satellite-network-supported-socs) page: your chip must be on the supported list *and* reach ≥ +20 dBm. That page also lists the [developer kits validated for satellite](/docs/compatibility) if you want known-good hardware. Two further requirements are specific to satellite transmission: | Requirement | Detail | |---|---| | Antenna | ≥ 40% efficiency at 2.4825 GHz (standard patch recommended). | | Crystal | 40 PPM crystal. | ## 2. How it works Hubble Terrestrial Network uses a standard Bluetooth® Low Energy (BLE) advertisement that nearby gateways relay to the cloud. The Satellite Network uses a **custom Hubble protocol** received directly by an overflying satellite, reusing your existing BLE radio (no separate satellite radio). One or more satellites pass overhead each day, each in view briefly. A dual-mode device pauses BLE, initiates Satellite and transmits repeatedly while the satellite is in view, then hands the radio back. An efficient device predicts passes and transmits only when a satellite is overhead (Step 9 below) instead of transmitting blind. :::success See a [**basic diagram**](/docs/network/satellite/how-it-works) for how Satellite Network works. ::: ## 3. Register and provision Register a new device at [dash.hubble.com](https://dash.hubble.com) to provision a secret device `key` (same for Satellite and Terrestrial; see [Onboard devices](/docs/guides/cloud-integration/register-devices) guide). ### Device Registration Via the Hubble dashboard (look for “Add a Device” in the top right, then "I just need a device key") or via `pyhubblenetwork` (see documentation on the repository README). ### Device Configuration Register with counter mode set to `DEVICE_UPTIME` for development. The counter starts at zero and advances with uptime, so no time provisioning is needed, and it matches the continuous sample in Step 4. (Production devices using pass prediction (to know when a satellite is overhead to transmit to) should register with `UNIX_TIME`, but this quick start guide, `DEVICE_UPTIME` is simpler due to the lack of timing requirements.) :::warning The firmware's counter source **must match** the registration or the backend cannot attribute/decrypt. Save device ID + key together. You need the device key twice: embedded in firmware, and for local Pluto SDR decryption (Step 5). ::: ## 4. Build a transmitting device Start with the continuous-transmit sample: a simple TX loop that confirms hardware and backend config in isolation. 1. Pull the SDK from `main`. 2. Fetch the radio blob first (Nordic + SiLabs). `west update` does not pull it, and the build fails to link the satellite radio without it: ```shell west blobs fetch ``` 3. Flash the continuous sample: Zephyr sat-continuous or TI sat-continuous. Provide your base64 device key at build time (Zephyr): ```shell west build -b nrf54l15dk/nrf54l15/cpuapp . -- -DCONFIG_SAMPLE_HUBBLE_KEY=\"\" west flash ``` > **Note:** TI is make-based (not west) and you supply the crypto implementation; the sample ships a ready one. See the TI README. > **Note:** A clean build only proves it compiles, not that the radio transmits (confirm in Step 5). Ship the default config first: continuous TX at a fixed interval, empty 0-byte payload. ## 5. Validate locally with a Pluto SDR Validating a device using the Pluto SDR helps ensure that the radio is transmitting correctly and that the encrypted link is valid. This cannot validate the full end-to-end path, but it catches problems within minutes instead of waiting on a real pass. Requires an ADALM-PLUTO over USB and Docker running. ```shell pip install pyhubblenetwork hubblenetwork sat scan # stream until Ctrl+C hubblenetwork sat scan --key "" # decrypt payload locally ``` Success means packets attributed to your device ID with incrementing sequence numbers. The scan sends nothing to the cloud, so it will not appear in the dashboard. Cloud reception needs a real satellite pass (Step 7). :::success See [**Test with a Pluto SDR**](/docs/network/satellite/pluto-sdr-testing) for Pluto setup, the full scan reference, and how to capture IQ samples for Hubble support if the scan finds nothing. ::: ## 6. Place the device Placement matters as much as firmware: the device needs a clear shot at the satellite. - Outdoors, clear skyview in as many directions as possible. Rooftop is ideal. - Test a couple of orientations (rotating one device can lose signal noticeably). - Clear of obstructions, large metal, and liquids. - Space multiple devices at least 6” (15cm) apart. ## 7. Confirm reception Cloud reception is the real confirmation and needs a transmission to a satellite during an actual pass. ### Timing One or more passes per day for your location on a periodic schedule. Check the Pass Explorer page on [dash.hubble.com](https://dash.hubble.com) for the next pass before assuming anything is wrong, and give it several passes. Packets should be available from a pass within 6 hours of the pass occurring - note that this is not instantaneous. ### How to check for packet reception Open [dash.hubble.com](https://dash.hubble.com), select the device, look for received packets with the expected payload and a satellite icon (indicates the packet came via the satellite network). Seeing your packet in the dashboard closes the full chain (firmware to RF to satellite to backend). ## 8. Integrate into your own firmware Fold satellite functionality into your application/RTOS. Mirror the continuous sample first (simple loop), then re-validate against Pluto and a live satellite exactly as before to isolate changes. See documentation in the Hubble Device SDK on how to perform the integration of firmware onto your device. ## 9. Pass prediction (transmit efficiently) In order to conserve power, a device can use the Hubble pass prediction algorithm to transmit only during windows when a satellite is overhead. ### Prerequisites Real Unix time on the device at init (baked in or provisioned over BLE) and the device location (coordinates). You also need a Hubble API Token, which you can generate from your Hubble Dashboard. ### Provision with Pass Prediction 1. Fetch current orbital parameters: SDK tools/orbital_params_fetch.py calls the Hubble API and writes them out; needs `HUBBLE_API_TOKEN` exported. 2. Provision the parameters onto the device (firmware or runtime over BLE). 3. Set time on the device (note if you are using the DEVICE_UPTIME based counter mode for encryption from previous steps you will need to use the hubble_set_time API in firmware to set the device time). 4. Use the SDK pass-prediction calls: get the next pass, wake shortly before it, transmit across the window, sleep. > **Reliability modes:** higher reliability repeats the transmission more times per pass (better delivery, more power/airtime). We recommend starting with the HIGH reliability mode and moving to NORMAL if performance is acceptable. ## 10. Tune performance Once receiving end to end, run the continuous sample, check packets delivered per pass, and tune transmission count and reliability mode against your delivery and power budget. Your Hubble contact can share per-pass performance data. ## 11. Troubleshooting | Issue | Resolution | |---|---| | No RF on local Pluto | Confirm device is transmitting, Pluto is connected before the scan starts, and Docker is running. | | Decoded locally but never in the cloud | Local scan doesn't push to the cloud (needs real pass). Confirm device is in the right org, and that firmware key, key size (16 vs 32 byte), and counter mode match the registration. | | Payload rejected | Length must be exactly 0, 4, 9, or 13 bytes. | | Key formation error | If converting base64 to raw bytes, verify it. A wrong/wrong-size key is rejected at startup with a logged error. | | Radio blob missing (Zephyr) | Verify blob was fetched in Step 4. | | Other issues | Reach out to Hubble support (support@hubble.com). | --- # Satellite Network Regulatory Compliance # Satellite Network Regulatory Compliance Review this guide for regulatory certification for your device's use of the Hubble Satellite Network protocol **in North America (United States, Canada and Mexico).** --- ## Overview This guide covers certification for Hubble Satellite Network enabled device operation in the **United States** under the Federal Communications Commission (FCC), in **Canada** and in **Mexico** under their respective jurisdictions. :::warning **Certification only applies to Satellite Network:** The Hubble Terrestrial Network protocol operates entirely within standard Bluetooth® Low Energy (BLE) specifications, so it doesn't require re-certification in any of these jurisdictions. ::: ### Responsible Party Certification is required for any compliant, commercially deployed product using the Satellite Network protocol, and needs to be in place **before commercial launch** of your product. Obtaining this certification is the responsibility of the device manufacturer or operator ("responsible party"), not Hubble. Typically, this is the company that holds the equipment authorization for the device — whoever brings the device to market under their name, even if manufacturing is outsourced to a contract manufacturer or ODM (original design manufacturer). --- ## FCC Part 15 (United States) The FCC regulates unlicensed radio frequency (RF) devices operating in the US, including Bluetooth to satellite. **FCC Part 15 certification** is specific to the exact frequencies, timing, and power levels a device was tested with — it doesn't automatically extend to operation outside those parameters (per **FCC Part 15.21**). ### Differences for Satellite Network **Satellite Network** operates the radio differently than standard Bluetooth in order to reach satellites in low Earth orbit (LEO). Consequentially, your device's original Bluetooth certification doesn't extend to Satellite Network operation. :::tip If your device runs both Satellite and Terrestrial protocols, it needs to be certified for Satellite Network even though Terrestrial-only operation wouldn't require it. ::: | Parameter | Standard Bluetooth | Hubble Satellite Network | | --- | --- | --- | | Operating frequencies | 2.402–2.480 GHz (40 channels) | 2.481+ GHz, band-edge (19 channels) | | Frequency hopping | Standard BLE hopping | Inter-packet hopping for dwell-time compliance | | Silence period | Standard BLE timing | 0.8 ms between packets | | Preamble format | Standard BLE preamble | Always-on preamble | | Target receiver | Terrestrial | Satellite (LEO) | #### Already have a certified device? If your device already holds an FCC ID for standard Bluetooth, that certification **does not cover Satellite Network operation** — even though it's the same piece of hardware. The existing certification was tested and granted for the standard BLE parameters above; adding Hubble's Satellite Network firmware changes the frequencies, hopping pattern, and timing enough that it falls outside that grant's scope. You'll need a new Part 15 certification for the Satellite Network-enabled configuration before commercial deployment, though your existing Bluetooth certification (and any chipset-level certification from your vendor) can typically be reused as supporting documentation rather than starting from zero. #### Doesn't Hubble's own FCC authorization cover this? No. Hubble holds its own FCC authorizations for the satellite constellation and ground stations, but those fall under a different part of the FCC rules (**Part 25**, space stations) than the ones governing your device (**Part 15**, unlicensed transmitters). Hubble's network-level authorization doesn't extend to your endpoint; each device design needs its own Part 15 certification, obtained separately by the responsible party. ### How to Initiate Certification 1. **Finalize your hardware and firmware.** Certification testing is done against your production (or near-final) hardware running Hubble firmware with Satellite Network enabled — not a bare dev kit. 2. **Gather your existing certification data.** Your chipset vendor's Core Design Number(s) and any existing Bluetooth FCC ID for the device speed up the process, since the test house can scope testing to what actually changed. 3. **Choose an FCC-accredited test house** (an FCC-recognized Telecommunication Certification Body, or TCB) and submit your device for testing. Not sure where to start? Reach out to Hubble Support — we can point you to labs we have experience working with. 4. **The test house runs the required tests** (see below) and reports the results. 5. **If the device passes**, the test house or your TCB files for an FCC ID / equipment authorization on your behalf, covering that hardware design. 6. **If any test doesn't pass**, the lab will tell you which parameter failed — you make the needed adjustment and retest. ### Typical Timing and Cost - **Typical timeline:** 4–8 weeks (device prep, lab testing, FCC filing) - **Typical cost:** roughly $15,000-$25,000, depending on test house and device complexity Since this takes 4–8 weeks and must be complete before commercial launch, start the process as soon as your hardware and firmware are finalized so it doesn't become a blocker on your launch date. :::note This certification covers **every unit of that hardware design**, not just the individual device tested — the same way a phone manufacturer certifies one model and ships millions of units. Firmware updates that don't change RF parameters remain covered by the existing certification. ::: ### Alternative Approaches #### Pilot or Demo If you're only running a limited pilot or demo, an **FCC Part 5 experimental license** lets you operate without full Part 15 certification — but only within specific locations, timeframes, and small device quantities, and never for paying commercial service. Full Part 15 certification is required before any customer-facing, revenue-generating deployment. #### Pre-certified RF module Starting from an FCC-certified BLE module helps, but doesn't remove the requirement. It gets you: - Certification of the RF transmitter itself (the "intentional radiator") - A reduced testing scope You'll still need: - Testing of unintentional radiation from your complete device (digital circuitry, power supply, etc.) — **Part 15.109** - Your own Declaration of Conformity or FCC ID filing - Confirmation that Satellite Network doesn't push the module outside the parameters it was originally certified for ### Test Requirements | FCC Certification Test | Requirement | | --- | --- | | **Conducted power** (15.247(b)) | Max conducted output power ≤ 1 W (30 dBm), measured at the antenna port | | **Frequency hopping** (15.247(a)(1)) | Minimum 15 hopping channels; channel spacing ≥ 25 kHz or ⅔ of 20 dB bandwidth; average channel occupancy ≤ 0.4 s per 20 s | | **Out-of-band emissions** (15.209) | Radiated emissions beyond the band edge must meet the spectral mask — especially important given Satellite Network's band-edge operation | | **Unintentional radiation** (15.109) | Emissions from digital circuitry; required regardless of module certification | **Pass all tests:** If your device passes all four tests, the test house (or your TCB) files for your FCC ID / equipment authorization directly — no design changes needed. In practice, devices built on a supported chipset running Hubble's Satellite Network reference firmware configuration typically pass without hardware changes, since the RF behavior has already been validated in Hubble's own testing. **Remediation:** If a test doesn't pass, the lab's report identifies exactly which parameter failed (for example, transmit power slightly over limit, or dwell time on a channel exceeding spec). Remediation is usually a firmware-level adjustment — tuning power output or hopping timing — rather than a hardware redesign, and you retest just the failed item rather than restarting the full process. Antenna or shielding changes are occasionally needed for unintentional radiation (Part 15.109) findings, since those depend on your device's full physical design, not just Hubble's firmware. ### Submission Checklist - ✅ Device is running finalized firmware with Satellite Network enabled - ✅ Conducted power tested for Part 15.247(b) compliance - ✅ Frequency hopping tested for Part 15.247 compliance - ✅ Out-of-band emissions tested for Part 15.209 compliance - ✅ Unintentional radiation tested (Part 15.109) — required even with a pre-certified module - ✅ FCC ID / equipment authorization obtained for the hardware design --- ## ISED RSS-247 (Canada) :::note Satellite-side authorization in Canada (a Foreign Satellite Approval, or FSA) is a separate regulatory track that covers satellite reception — it doesn't cover your device, and doesn't substitute for RSS-247 certification. Your device needs its own certification regardless of any satellite-side approval. ::: Certification in Canada is handled by **Innovation, Science and Economic Development Canada (ISED)**, the federal department responsible for radio equipment certification. Because SatNet is a frequency-hopping system operating in the 2400–2483.5 MHz band, it falls under **RSS-247** ("Digital Transmission Systems, Frequency Hopping Systems and Licence-Exempt Local Area Network Devices") — Canada's direct equivalent to FCC Part 15.247. The technical thresholds are closely aligned: a minimum of 15 hopping channels, with average occupancy per channel not exceeding 0.4 seconds within a period of 0.4 seconds times the number of channels. RSS-247 classifies SatNet-enabled devices as Category I equipment, which requires either a Technical Acceptance Certificate from ISED's Certification and Engineering Bureau, or certification through a recognized Certification Body. --- ## CRT Homologación (Mexico) :::note As in Canada, satellite-side authorization in Mexico (Confirmación de Criterio) is separate from device certification and doesn't substitute for it. Your device needs its own homologación regardless of any satellite-side approval. ::: Certification in Mexico is handled by the **Comisión Reguladora de Telecomunicaciones (CRT)**, the technical regulatory body operating under the Agencia de Transformación Digital y Telecomunicaciones (ATDT). CRT took over telecom equipment certification (*homologación*) after Mexico's previous regulator, the Instituto Federal de Telecomunicaciones (IFT), was dissolved in October 2025. Devices operating in the 2400–2483.5 MHz band using spread spectrum or frequency hopping require homologación under **NOM-208-SCFI-2016**, evaluated against Technical Provision IFT-008-2015. The process involves lab testing at an accredited facility, a Certificate of Conformity issued by a certification body, and a Certificate of Homologation issued by CRT. :::warning Mexico's regulatory structure changed recently — CRT has been the certifying body for less than a year as of this writing. Confirm current procedures with your test house or Hubble Support before starting, since some specifics may still be settling. ::: --- ## FAQs #### 1. Do we need to certify every device? No, certification is per hardware design. One certified representative device covers every unit of that design, including firmware updates that keep the same RF parameters. A certification can't be carried over to a different hardware design, even if it runs the same firmware. #### 2. Does duty cycle matter — what if the device only transmits a few times a day? No. Certification requirements are based on whether the device transmits RF energy, not how often. #### 3. Can I keep changing the Satellite Network protocol without re-certifying? Depends on what changes. Frequency plan, timing/dwell-time, or power level changes require re-certification. Payload content, encoding, or application-layer changes that don't touch RF parameters do not. #### 4. Can we test or demo without certification? Yes, under an FCC Part 5 experimental license — limited to R&D, specific locations/timeframes, and small quantities. Not permitted for commercial service. --- ## Resources - [FCC Part 15 Rules (47 CFR §15)](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15) - [FCC Equipment Authorization Procedures](https://www.fcc.gov/equipment-authorization-procedures) - [FCC-Accredited Test Lab Directory](https://apps.fcc.gov/oetcf/eas/reports/TestFirmSearch.cfm) - [ISED RSS-247, Issue 4](https://ised-isde.canada.ca/site/spectrum-management-telecommunications/en/devices-and-equipment/radio-equipment-standards/radio-standards-specifications-rss/rss-247-digital-transmission-systems-dtss-frequency-hopping-systems-fhss-and-licence-exempt-local) (Canada) - [NOM-208-SCFI-2016](https://www.dof.gob.mx/normasOficiales/6413/seeco11_C/seeco11_C.html) (Mexico — radio communication systems using spread spectrum/frequency hopping) > **Questions about your specific device or timeline?** Reach out to Hubble Support. --- # Satellite Transmission Guidance # 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. :::note See a simple diagram for [how Satellite Network works](/docs/network/satellite/how-it-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**](/docs/compatibility#satellite-network-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. :::warning 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: 1. When a pass is imminent, the device **tears down the BLE stack** and enters SatNet transmission mode for the duration of the pass. 2. 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](/docs/network/terrestrial/transmission-guidance#1-set-transmission-power-and-advertising-interval) 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](/docs/network/terrestrial/coverage) 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. | --- # Coverage import FlexBox from "@site/src/theme/hubble/components/FlexBox"; import MorphicGlassBox from "@site/src/theme/hubble/components/MorphicGlassBox"; import Button from "@mui/material/Button"; import Typography from "@mui/material/Typography"; import {NavLink} from "react-router-dom"; export const FeatureList = [ { title: 'Network Explorer', description: <>Evaluate Terrestrial Network coverage for your custom devices in specific geographic areas or along user defined routes. Network Explorer calculates the estimated number of detections in a 24 hour period and shows the typical delta between detections (use "expert" mode)., actions: [ { label: 'Go to Network Explorer', link: 'https://network.hubble.com/', icon: 'fa-regular fa-arrow-up-right-from-square' } ] } ]; export function Feature({title, description, actions, backgroundImage}) { return ( {title} {description} {actions.map((action, idx) => ( ))} ); } # Coverage Our growing global Terrestrial Network – powered by Bluetooth® Low Energy (BLE) scanning gateways – captures device broadcasts across many environments, from major cities to highways and ports to rural regions. --- {FeatureList.map((props, idx) => ( ))} --- # How It Works # How It Works The basics on how a global **Bluetooth® Low Energy (BLE)** connectivity network transmits data from your devices to your custom application. --- ## How the Terrestrial Network Works A device beaconing on Hubble's **Terrestrial Network** broadcasts short advertisements using the [BLE specification](/docs/device-sdk/terrestrial/advertising-packet). The network of scanning gateways is composed of Hubble partners and Hubble customers alike. When a gateway (such as a smartphone or dedicated hardware gateway) detects that advertisement within range, it appends its own location, signal strength, and location accuracy metadata, then forwards the record to Hubble's backend. The result is a timestamped detection event: where your device was seen, when it was seen, and any [custom payload](/docs/guides/device-integration/custom-payload) transmitted in the advertisement.

Tracked
Device

Beacons on Hubble Network with encrypted payload

BLE Advertisement

Global Coverage

Scanning
Gateway

Network of 100M+ scanners detects advertisements in proximity

Forwarded Packet

Hubble
Backend

Receives encrypted packet with gateway location and timestamp

API / Webhook

Customer
Application

Receives decrypted packet with custom payload, location and timestamp

**Detection is probabilistic.** The number of captures a device receives depends on scanner density, signal strength, beaconing behavior for [your custom device](/docs/guides/device-integration/custom-device), and platform-specific scanning schedules. Understanding these factors is key to getting the most out of a network built for any Bluetooth capable device. :::tip Go Further Check out Terrestrial Network coverage with [**Network Explorer**](/docs/network/terrestrial/coverage), and review guidance for device discoverability on the network with [**Transmission Guidance**](/docs/network/terrestrial/transmission-guidance). ::: --- # Transmission Guidance # Transmission Guidance --- ## The Terrestrial Network Hubble's Terrestrial Network is composed of more than **100 million scanning gateways** — including smartphones, consumer gateways, and industrial gateways — providing coverage across low- to high-density areas worldwide. **Scanning behavior:** - Scan intervals vary by scanner, with a minimum of approximately 5 minutes and a maximum of 30 minutes. - Each scan window lasts 25–30 seconds, and reliably detects devices within 10–20 meters. - There is no hard cap on devices detected per scan, though performance may degrade above 50–100 simultaneous advertisements due to radio saturation on the gateway. - Offline, powered-off, or low-power smartphones may not execute Bluetooth scans or submit updates. ### What to Expect **Detection on a BLE Network is probabilistic.** The network provides statistical reliability over time, not guaranteed per-packet delivery. A single detection gap is not evidence of device failure. #### Detection Frequency Detection frequency depends on local gateway density, device configuration, and environment. - In typical **urban** deployments, a well-configured device advertising every few seconds may receive anywhere from a handful to dozens of detections per hour. - In **low-density or indoor environments**, gaps between detections are normal. #### Data latency Once a scanning gateway captures a BLE advertisement, data is typically delivered to the Hubble backend within seconds to a few minutes, depending on the scanner's connectivity. --- ## Location & Data Quality ### How Location is Determined Position on the Terrestrial Network comes from the **scanning gateway**, not the tracked device. When a scanner detects a BLE advertisement, it attaches its own GPS coordinates at the time of capture and submits those as the device's reported location. This means: - **Accuracy depends on the scanner.** In open outdoor environments, positions may be accurate to a few meters. In dense urban or indoor environments, error can exceed 50 meters. Each packet includes `location.horizontal_accuracy` and `location.vertical_accuracy` fields (in meters), reported directly from the scanning gateway's GPS chipset, which can help you assess the confidence of a given detection's location fix. - **Position confidence is not a discrete field** in the raw dataset. Customers who need to assess reliability should apply the data cleaning practices below to filter and weight detections based on their use case. ### Factors That Affect Data Quality - **Scanner mobility:** A moving smartphone may record a location that doesn't accurately reflect where the BLE signal was received. - **Redundant captures:** Multiple nearby scanners can detect the same transmission, producing duplicate records with slightly different location and timestamp data. - **Connection backtracking:** Scanners that disconnect and reconnect to networks can briefly report stale or conflicting location data. - **Signal interference:** Environmental factors or competing wireless signals can affect capture reliability. ### Data Cleaning Best Practices Terrestrial Network data is collected directly from Bluetooth scanners without immediate filtering or aggregation. - **Filter duplicates:** Multiple scanners may capture the same transmission. You may choose to [filter packets](/docs/guides/implementation/backend#filtering-data-packets) with near-identical timestamps and locations, based on your use case's sensitivity. - **Detect outliers:** Flag large, sudden jumps in location data (GPS jumps or teleportation). These often indicate a scanner reconnection event or faulty device reporting. - **Validate timestamps:** Missing or inconsistent timestamps can distort transmission pattern analysis. - **Aggregate over time:** Smoothing data over suitable intervals helps filter transient inaccuracies and gives a more reliable picture of device activity. ### Edge Cases #### Colocated devices Colocated devices, such as multiple devices shipped in the same box, may show different detection rates. BLE operates in shared 2.4 GHz spectrum, and smartphone gateways scan intermittently rather than continuously. Factors like scan window alignment, local RF conditions, and radio collision dynamics mean that two devices placed inches apart can produce different packet counts, even with identical hardware and firmware. > **Go Further:** For a complete evaluation, we recommend testing network performance over multi-day windows rather than short intervals, looking at average detection rates across the full sample period. --- ## Maximizing Discoverability :::tip Try [**Network Explorer**](/docs/network/terrestrial/coverage) to test coverage under different beaconing strategies for your devices. For advanced configuration, use the **Device Simulator** tool in [**Expert Mode**](https://network.hubble.com/) to evaluate probability of detection and time between detection based on transmit power and rate. ::: #### 1. Set Transmission Power and Advertising Interval Transmit power and advertising interval work together to determine how reliably your device is detected. Transmit power (Tx power) sets your effective range, and higher power improves detection reliability. The advertising interval (Tx rate) sets how often a passing scanner can catch a transmission, and shorter intervals increase the probability of overlapping with a scan window. Because higher-power devices reach more scanners per transmission, they can advertise less frequently. The recommended interval therefore scales with device output power class: | Device Output Power | Tx Power | Recommended Advertising Interval | |---|---|---| | Low power | 0–4 dBm | ~1 second | | Mid power | 4–13 dBm | ~2 seconds | | High power | 13 dBm and above | ~2–4 seconds | :::note At lower output powers, advertising frequency can make a large difference in detection performance. If your device is constrained to a low power class, prioritize a shorter advertising interval to compensate. ::: ##### High-Output / Power-Amplifier Devices Devices with an external power amplifier (PA) fall into the high-power class and can transmit up to **+20 dBm**, substantially increasing detection range in open or RF-noisy environments. This is most beneficial in large outdoor deployments, maritime or logistics environments, and areas with significant physical obstructions. #### 2. Account for mounting and enclosure Metal enclosures, equipment chassis, and dense packaging materials significantly attenuate BLE signals. If your device is deployed inside or adjacent to metallic structures, factor in signal loss when setting Tx power and advertising interval. #### 3. Beacon Consistently Regular transmissions ensure continuous network presence regardless of intermittent scanner coverage. Shorter beacon intervals during periods of movement and longer intervals when stationary can help balance battery life and detectability. #### 4. Rotate Payloads Frequently Each payload rotation updates the content of the BLE advertisement. Independently of device ephemeral ID (EID), which rotates based on `counter_source`, the incremented sequence number for the advertisement packet (used for nonce in encryption) is intended to signal that a fresh payload is available — which anecdotal evidence suggests correlates with more captures from nearby scanners. Hubble supports **up to 1,024** unique sequence numbers per EID rotation period. For applications where discoverability is a priority, rotating at or near this rate is recommended. > **Note:** For IN100 chips, payload rotation is independent of EID rotation (controlled via `period_exponent`). You may rotate payload using a dynamic data source in your configuration file. #### 5. Rotate MAC Addresses Regularly changing the MAC address protects user privacy and helps avoid long-term tracking of a single device identifier by the network. We recommend using a Non-Resolvable Private Address (NRPA) in your advertisement. #### 6. Keep Firmware Current Keep your device firmware current with the latest improvements in BLE performance and security to support consistent and effective transmissions. --- ## Platform Differences for Mobile App Scanning Scanning behavior varies by mobile platform and app state: | Behavior | Android | iOS | |---|---|---| | **Scan interval** | ~15 minutes | ~5–30 minutes | | **Force-quit behavior** | Scanning continues in background | Background scanning suspends until app is reopened | | **Foreground** | Continuous scanning, real-time detections | Continuous scanning, real-time detections | | **Background** | Best-effort; detections sent when location is available | Best-effort; detections sent when location is available | :::tip Learn how [**Hubble Connect mobile app**](/docs/guides/hubble-connect) scans for your devices. :::