Pilot Framework
Evaluate coverage, prove device connectivity, test in the real world, and confirm your backend integration: four steps for validating Hubble Network in a live pilot before ramping up in production.
Validation Phases
Rolling out on Hubble Network follows four validation phases, followed by a production ramp:
| Phase | Goal | Primary Tool | Timing |
|---|---|---|---|
| Coverage Validation | Evaluate network coverage without updating any devices | Network Explorer | Day 1 |
| Technical Validation | Flash updated firmware on a dev board to confirm network connectivity | Dash Quick Start, Github Repository | Week 1 |
| Network Validation | Deploy devices in the real world and measure live performance | Your own hardware | Weeks 2–3 |
| Platform Validation | Confirm your backend can ingest Hubble data via API and/or webhooks | REST API + Webhooks | Week 4 |
| Ramp in Production | Roll out Hubble connectivity across your production devices | Dashboard + Cloud API | Post go/no-go decision |
This plan is optimized for an asset tracking use case, but is also relevant to use cases where transmitting micro-telemetry from the device is the priority.
1. Coverage Validation
Goal: Evaluate expected Hubble Terrestrial coverage across your key deployment geographies without updating any devices yet.
Tool: Network Explorer — coverage is measured as detections per 24-hour period and expected time between detections.
What to do:
- Assess coverage density — Select locations that matter to your deployment: warehouses, distribution hubs, customer sites. Review expected detections per 24-hour period.
- Customize a virtual device — Use expert mode to adjust Tx power and advertisement interval to match your target hardware profile and calibrate performance expectations.
- Map key routes — Trace routes between locations to evaluate coverage in transit. Test urban, suburban, and highway segments that reflect your real-world use cases.
- Export results — Share coverage data with your team to align on whether network density meets your minimum requirements before proceeding.
Go-forward decision: Your critical coverage areas and key routes show meaningful detection density.
2. Technical Validation
Goal: Flash updated firmware using the Hubble Device SDK on a dev board or your own hardware to confirm device connectivity to the Terrestrial Network.
Tools:
- Hubble Dashboard — Dash Quick Start ("Add a Device")
- Device SDK — open source on GitHub
- Chip Reference Apps — Zephyr and FreeRTOS projects for supported chipsets
- Hubble Connect — mobile app for scanning and verifying device advertisements
What to do:
- Try Dash Quick Start — Use the one-line provisioning flow using your terminal to get a developer kit beaconing on Terrestrial Network in minutes. This is the fastest path from unboxed kit to first detection.
- Use a chip reference app — Clone the reference repo for your chipset for a fully functional starting point with flashing instructions. Supports Zephyr and FreeRTOS.
- Port the
ble-beaconsample — Enter the secret device key generated during device registration, then build and flash to the board. - Verify with Hubble Connect — Install the mobile app and log in with your dashboard credentials. Scan for your device to confirm it is advertising on the network and view a live JSON packet snapshot.
- Advanced lab testing — Use the
ble-networksample file to create a shell interface on your board. This lets you program the device and test custom commands without reflashing between iterations.
Go-forward decision: Your dev board or hardware registers detections using Hubble Connect.
3. Network Validation
Goal: Collect real-world detection data in the field to validate that live network performance meets your coverage expectations for your device.
What to do:
Define success criteria before you start. For example: minimum detections per day and in key areas of interest, and acceptable gap windows between detections.
Bring your own hardware:
- Integrate the Hubble Device SDK to a custom instance of your existing BLE application. Browse Reference Applications for a starting point.
- Configure the custom payload to return your proprietary device data; optionally apply customer-managed payload encryption.
- Flash a handful of devices and deploy them in real operational conditions.
- View packet data in your Hubble Dashboard. Or ingest data directly into your backend via webhook or API pull, and map devices using
device.id,device.name, and custom tag key-value pairs. - Compare Hubble-connected devices against a non-Hubble control group to evaluate differences in detection frequency and geographic coverage.
Go-forward decision: Real-world detection results meet expectations for your target use cases. Target: ≥80% of expected detections achieved across your test scenario.
If results are unexpected: Share with your Hubble contact your hardware stack, device configuration (Tx power, advertisement interval), deployment geography, and test duration. Single-day tests can be misleading; co-located devices may exhibit different behavior. Review Transmission Guidance for more details on what to expect.
4. Platform Validation
Goal: Confirm that your backend can ingest Hubble data via REST API and/or webhooks, and that integration fits your existing data pipeline.
Tools:
What to do:
- Choose your integration strategy — Webhooks push detection events to your endpoint in real time. The REST API supports polling for batch pulls. Most teams use webhooks as the primary path.
- Review the JSON payload — Each packet includes: location, timestamp, RSSI, sequence number, and up to 13 bytes of custom micro-telemetry from your device.
- Confirm security requirements — Hubble provides AES-256 end-to-end encryption at the device layer, TLS in transit, and data encrypted at rest in the cloud. Per-device cryptographic keys are provisioned via the Cloud API.
Go-forward decision: Your backend can ingest Hubble data with minimal integration lift, and your Cloud/Infrastructure team approves the API.
Go / No-Go Decision
Evaluate across all four phases:
| Phase | Success Criteria |
|---|---|
| Coverage | Network Explorer predicts 2+ detections per route / area of interest |
| Technical | Your device beacons on the terrestrial network and your custom payload is transmitted and readable via the Dashboard or API |
| Network Performance | ≥80% of expected detection rates achieved in real-world test scenario — both in transit and at locations of interest |
| Platform | Your infrastructure team evaluates and approves Hubble's API and webhook integration |
If all four are green, you have what you need to move forward.
Ramp in Production
You've completed validation and are ready to roll out Hubble connectivity across your production device fleet. Here are a few areas to focus on:
Firmware
Update your production firmware application to include the Hubble Terrestrial Network SDK, tailored to your custom device requirements. Calibrate your device configuration (Tx power, advertisement interval) to balance detection performance against battery life if your device is unpowered.
Provisioning
Each device requires a unique cryptographic key generated by Hubble and provisioned on the device during production.
Ensure your manufacturing process securely provisions devices with secret keys generated at registration time via the Cloud API. Keys should never be shared across devices or stored insecurely in firmware. If you're working with an ODM for manufacturing devices, review best practices to enable secure device registration.
Backend
- Determine whether packet filtering applies to your use case to reduce noise in downstream processing and streamline integrated workflows.
- Add redundancy and fallback strategies to your data ingestion pipeline. If you need to rotate webhook endpoints, follow the secure webhook migration guide to avoid data loss during the transition.
Monitoring
Use the Hubble Dashboard to monitor your device count as it ramps.
Remember that devices transition from registered to active the first time it transmits a packet on the network. It becomes inactive if it has not been seen by the network in 7 days.