Skip to main content
For the complete documentation index, see llms.txt.

Hubble Network developer documentation: integrate Bluetooth devices with terrestrial and satellite connectivity.

Your Custom Device

When integrating the Device SDK, you may need to consider these real-world factors that affect your chip selection, hardware, and application design.

Common Questions​

1. What proprietary device data can be sent in the payload?​

Hubble supports custom payloads up to 13 bytes for telemetry or meter readings, sensor readings like temperature or humidity, device-level GPS data (if available), etc. Device detection location data is appended to every capture by the Terrestrial Network.

Review the Custom Payload user guide for examples.

2. How to keep device data secure?​

Hubble encrypts data transmitted on the network end-to-end. In addition, you can encrypt the device’s custom payload so Hubble cannot read it.

Learn more in our Network Security guide.

3. How frequently to advertise?​

This depends on the battery life of your product and your use case. For tracking applications you may want to advertise the payload multiple times per minute, while other use cases can accommodate a lower frequency. If you broadcast on multiple protocols, you can alternate between Hubble and others based on your requirements.

4. How often to generate a new payload?​

You may generate between 1 and 1,024 new payloads per day. If your data hasn't changed, you are not required to generate a new advertisement — but you must rotate at least once every 24 hours to maintain encrypted transmission.

The 1,024 limit is set by the sequence number field size. Exceeding it risks nonce reuse, which undermines the security of your transmissions. Learn more in the Time Management guide.

5. What radio power output to use?​

Transmit power (Tx) of at least +4 dBm (2.5 mW) is recommended to ensure reliable connection to the Terrestrial Network. Transmit power of 20 dBm (~100 mW) is recommended to ensure reliable connection to the Satellite Network. A power amplifier may be required depending on your device.

6. How to maximize detections on the network?​

Based on your business use case, optimize for broadcast frequency and Tx vs. device battery life and expected battery degradation over time. Learn more in the Transmission Guidance summary.

7. What is the Hubble Device SDK power draw?​

Hubble's protocol leverages the standard Bluetooth stack for beaconing. There is no additional power draw when using the Hubble Device SDK to generate the advertising packet. Developers own power optimization at the application level for the selected chip.

8. Is clock drift on the device an issue?​

When using unix time counter mode (time-based encryption), packet encryption using the SDK depends on accurate time for operations such as generating time-based ephemeral IDs (EID). We recommend at least a 500PPM clock accuracy to control drift. A tolerance of ±1 epoch is permissible, which aligns with a ~24-hour precision window under standard rotation cycles, though this window scales relative to the configured counter duration.

Mitigate clock drift on the device by incorporating a time synchronization protocol. (Terrestrial Network scanning gateways do not manage or refresh device time.) See the Timing Management guide for more details.

9. How much flash/ROM space and RAM is required?​

Several factors may affect application size and RAM requirement: chip/RTOS combination, type of application build, cryptographic approach, and custom design requirements.

For example, a simple device beaconing on Terrestrial Network using the Zephyr Quick Start Sample (provided in the Device SDK) requires approximately:

  • ~1.9 KB of flash/ROM space
  • ~23 bytes of RAM

For a device advertising on both Satellite and Terrestrial Network, a representative sample application requires approximately:

  • 13-15 KB of flash/ROM space
  • <1 KB of RAM

Note that these are very simple applications where encryption is already present in your firmware.

10. What frequency band does Hubble operate in?​

Hubble operates in the 2.4 GHz ISM band (2400–2483.5 MHz). To ensure compatibility, your Bluetooth chip must be compliant with Bluetooth Low Energy (BLE) specifications.

11. What is the typical data throughput rate?​

The typical data rate is approximately 0.4 kbps when using Terrestrial Network BLE advertising. This rate is intentionally optimized for long-range, low-power transmission to maximize battery life in constrained environments.

12. Does Hubble support bidirectional device communication?​

No. The Hubble Device SDK currently supports one-way data transmission only (uplink from your device to the cloud).