How to Build a Bluetooth Tracker That Sends Sensor Data Without a Gateway
Most BLE asset trackers are only as useful as the gateway infrastructure behind them. Remove the gateways, and you’ve got an expensive beacon shouting into the void. That’s the dirty secret of industrial BLE deployments: the tracker costs $10, but the gateway network to actually hear it costs $50,000 across a port or construction site, plus ongoing maintenance, power, and backhaul. And when the assets move between facilities, your fixed infrastructure stays behind.
But here’s what’s changed: the relay layer doesn’t need to be yours anymore. Passing smartphones, BLE mesh nodes, and even LEO satellites can now backhaul Bluetooth tracking sensor data from a self-contained device that costs under $20 in BOM and runs for years on a coin cell. No gateway hardware. No site surveys. No monthly cellular bills.
This guide walks you through building exactly that: a BLE sensor tracker that embeds temperature, humidity, and motion telemetry directly into its advertising payload, then uses ambient relay infrastructure to get that data to the cloud. By the end, you’ll have a prototype-ready design using off-the-shelf parts and firmware you can flash in an afternoon.
Architecture: The Three Relay Paths That Replace Your Gateway
The tracker itself is simple: an SoC with a BLE radio, a sensor or two on I²C, and a coin cell. It broadcasts advertising packets containing encoded telemetry. The interesting part is what receives those packets.
┌─────────────┐ BLE Adv ┌──────────────┐ Cellular/ ┌─────────┐
│ BLE Tracker │ ─ ─ ─ ─ ─ ─ ─ ► │ Relay Node │ ──Internet──► │ Cloud │
│ (Sensor + │ (broadcast) │ │ (MQTT/ │ Backend │
│ nRF52840) │ │ ┌──────────┐ │ HTTPS) │ │
└─────────────┘ │ │Smartphone│ │ └─────────┘
│ │Satellite │ │
│ │Mesh Node │ │
│ └──────────┘ │
└──────────────┘Smartphone relay: Any phone running your SDK-integrated app (or a partner’s) can scan for your advertisements in the background and forward them over cellular. This works well in warehouses, yards, or anywhere workers carry phones. Android’s BluetoothLeScanner with ScanFilter handles this reliably. iOS is trickier, and I’ll cover that in the relay section.
Satellite BLE (Hubble Network): The tracker’s BLE signal is received directly by LEO satellites. No terrestrial infrastructure at all. Requires Coded PHY (Long Range, S=8) at maximum TX power. Ideal for outdoor, remote, or in-transit assets.
BLE Mesh forwarding: Nearby mesh-capable nodes relay packets hop-by-hop until one reaches an internet-connected node. Best for dense indoor environments where you control some infrastructure but not all of it.
Choose based on your relay density and latency tolerance. Smartphone relay gives you sub-minute latency in high-traffic areas. Satellite gives you global coverage with multi-hour latency. Mesh gives you deterministic indoor coverage.
Selecting Hardware That Won’t Paint You Into a Corner
SoC: The Nordic nRF52840 is the default choice, and for good reason: BLE 5.0 extended advertising, Long Range Coded PHY support, 256 KB RAM, and a mature SDK (nRF Connect SDK / Zephyr RTOS). If you need the additional processing headroom of a dual-core architecture (say, for on-device ML on accelerometer data), step up to the nRF5340. Alternatives include the TI CC2652R and Renesas DA14695, but Nordic’s toolchain and community support make prototyping faster.
Sensors: For temperature and humidity, the Sensirion SHTC3 draws 0.2 µA in sleep and completes a measurement in under 1 ms, making it ideal for duty-cycled operation. The Bosch BME280 adds barometric pressure if you need altitude or weather context. For shock and motion detection, the ST LIS2DH12 offers hardware interrupt generation on configurable thresholds, meaning your SoC stays asleep until something actually moves.
Both sensors communicate over I²C. Keep the bus short and consider external pull-ups sized for the clock speed you’re actually using (100 kHz is fine here; no need for 400 kHz).
Power supply: Start with a CR2477 coin cell (1000 mAh, 3V). It’s cheap, widely available, and physically large enough to handle the pulse currents of BLE TX without excessive voltage droop. For production, evaluate LiSOCl₂ cells (ER14250) for higher capacity in cold-chain applications.
Antenna: A PCB trace antenna (inverted-F or meander line) keeps BOM cost at zero and works well with a proper ground plane. If you’re targeting satellite relay via Coded PHY, consider a chip antenna with a tuned matching network. You need every dB you can get.
For prototyping: Order an nRF52840 DK and a MikroElektronika Weather Click (BME280) or Accel Click (LIS2DH12). You’ll be flashing firmware by end of day.
Designing the Advertising Payload: Your 24-Byte Budget
This is where the engineering matters most. A legacy BLE advertising PDU gives you 31 bytes of payload. After the mandatory AD structure overhead (flags: 3 bytes, manufacturer-specific data header: 4 bytes), you have roughly 24 usable bytes for telemetry. Every byte counts.
Use the Manufacturer Specific Data AD type (0xFF) to define a custom telemetry frame:
Byte Map — Custom Telemetry Advertising Payload (Legacy, 24 usable bytes)
+--------+-------------------------------------------+
| Bytes | Field |
+--------+-------------------------------------------+
| 0-1 | Company ID (BLE SIG registered or 0xFFFF) |
| 2 | Packet type / firmware version |
| 3-4 | Temperature (int16, 0.01°C resolution) |
| 5-6 | Humidity (uint16, 0.01% resolution) |
| 7-8 | Battery voltage (uint16, mV) |
| 9 | Motion event flags (bitfield) |
| 10-13 | Sequence counter (uint32, dedup/ordering) |
| 14-17 | Device ID (uint32) |
| 18-23 | Reserved / checksum / future sensors |
+--------+-------------------------------------------+Encoding strategies that save bytes and battery:
Use fixed-point integers, not floats. A temperature of 23.45°C becomes 2345 as an int16, giving you two bytes, 0.01° resolution, and a range of −327.68°C to +327.67°C. More than enough for industrial use.
Pack boolean events into bitfields. Byte 9 gives you 8 independent flags: motion detected, freefall, tilt threshold, tamper, etc. One byte, eight signals.
The sequence counter (uint32) is critical for deduplication. Multiple relays will hear the same advertisement. The cloud backend uses this counter to collapse duplicates and reconstruct ordering.
The Device ID can be shortened to 3 bytes (16.7M unique devices) if you need the space. Or use the BLE MAC address and skip it entirely, but note that some relay paths strip the MAC.
When to use BLE 5.0 extended advertising: Extended advertising PDUs support up to 254 bytes, which lets you include full accelerometer waveforms, multiple historical readings, or larger device IDs. The catch: iOS background scanning does not reliably receive extended advertising data. If smartphones are your primary relay, stick to legacy PDUs. If you’re targeting satellite or mesh relays that you control, extended advertising opens up significantly richer telemetry.
Avoid iBeacon and Eddystone frame formats unless you specifically need compatibility with existing scanning infrastructure. Both waste 16+ bytes on UUID fields that provide no telemetry value.
Firmware: The Core Loop in Under 200 Lines
Build on the nRF Connect SDK (Zephyr RTOS). The firmware architecture is straightforward: a main thread that wakes periodically to sample sensors and update the advertising buffer, while the BLE controller handles advertising autonomously.
// Pseudocode — Main firmware loop (Zephyr RTOS)
void main(void) {
init_ble();
init_sensors();
while (1) {
// Sample sensors
temp = read_temperature(); // BME280 via I2C
humidity = read_humidity();
accel_flags = read_motion(); // LIS2DH12 interrupt flags
battery_mv = read_adc();
// Encode payload
payload = encode_telemetry(temp, humidity,
accel_flags, battery_mv,
seq_counter++);
// Update advertising data (no restart needed on nRF5x)
update_adv_data(payload);
// Sleep until next sample interval
k_sleep(K_SECONDS(SAMPLE_INTERVAL));
}
}Key implementation details:
Advertising configuration: Set the interval based on your relay environment. In a warehouse with constant smartphone traffic, 1 second is fine. For outdoor assets relying on intermittent relay contact, 10 seconds preserves battery while still providing reasonable catch probability. Set TX power to 0 dBm for smartphone relay scenarios; crank to +8 dBm (or the maximum your SoC supports) for satellite or long-range mesh.
Power management: The nRF52840’s System ON sleep mode draws ~1.5 µA with RTC running. Advertising runs in the SoftDevice (or Zephyr’s BLE controller) and wakes the radio only for TX events; your application code doesn’t need to manage this. Decouple sensor sampling from the advertising interval: you might advertise every 1 second but only update the sensor reading every 60 seconds. The payload simply repeats the last known values between updates.
OTA DFU planning: Even without persistent GATT connections, you can schedule brief connectable advertising windows (e.g., 30 seconds every hour, or triggered by a specific accelerometer pattern like three taps). This lets a technician with a phone push firmware updates in the field. Allocate flash for a dual-bank bootloader from the start. Retrofitting this later is painful.
Getting Data Through the Relay and Into the Cloud
Smartphone relay, the iOS problem: On Android, background BLE scanning with ScanFilter matching your Company ID works reliably and returns the full manufacturer-specific data payload. On iOS, Core Bluetooth in background mode will only discover devices advertising specific service UUIDs. It does not deliver manufacturer-specific data in the background scan callback unless the app was recently in the foreground. The workaround: include a 16-bit service UUID in a secondary AD structure (costs 4 bytes) so iOS discovers the device, then read the manufacturer data from the scan result. Test this extensively. Apple’s background BLE behavior changes between iOS versions.
Satellite relay (Hubble Network): Your tracker must use Coded PHY (S=8) for the link budget to close over a LEO satellite pass. This means longer TX times (~4 ms per packet vs. ~1 ms for 1M PHY) and higher current draw at max TX power. The trade-off is total infrastructure independence. Configure your firmware to alternate between standard 1M PHY advertisements (for nearby smartphone/mesh relays) and Coded PHY advertisements (for satellite windows) if you want to cover both paths.
Cloud pipeline: The relay, whatever it is, forwards the raw advertising payload plus metadata: relay GPS coordinates (from the phone’s location services), timestamp, and RSSI. Push this via MQTT or HTTPS to your ingestion endpoint (AWS IoT Core, Azure IoT Hub, or a custom broker). Server-side, decode the payload using the same byte map, and deduplicate using the sequence counter. Multiple relays hearing the same packet is a feature, not a bug. It gives you location triangulation data for free.
Power Budget: How Long Your Coin Cell Actually Lasts
Power Budget — CR2477 (1000 mAh) @ 1s Adv Interval
+-------------------------+----------+-----------+
| Activity | Current | Duty |
+-------------------------+----------+-----------+
| Sleep (SoC + sensors) | 2 µA | ~99.7% |
| Sensor read (I2C) | 500 µA | 5 ms/read |
| BLE TX (0 dBm, 1M PHY) | 5.5 mA | ~1 ms/adv |
| BLE TX (8 dBm, Coded) | 15 mA | ~4 ms/adv |
+-------------------------+----------+-----------+
Estimated life @ 0 dBm, 1s interval: ~18–24 months
Estimated life @ 8 dBm, 10s interval: ~24–36 monthsThe biggest lever is advertising interval. Going from 1s to 10s roughly halves your average current. In low-relay-density environments, this is the right call. A passing smartphone needs to be within range for only one advertisement, and even at 10s intervals, a 30-second proximity window gives you three chances.
Validate estimates with the Nordic Power Profiler Kit II. Measure actual current in your prototype, not datasheet typicals. Your PCB layout, LDO quiescent current, and sensor sleep current will shift the numbers.
Testing Before You Ship a Prototype
Use the nRF Connect mobile app (Android or iOS) to inspect your advertising payload in real-time. Verify each byte maps to the expected telemetry value. Change sensor conditions (hold the board, breathe on the humidity sensor) and confirm the payload updates.
For packet-level debugging, pair a Nordic nRF Sniffer dongle with Wireshark. Filter by your device’s advertising address and inspect raw PDU structure. This catches encoding bugs that the mobile app might mask with display formatting.
Range-test against your target relay scenario: measure RSSI with a phone in a pocket at 5m, 10m, and 20m. For satellite relay, you need clear sky and maximum TX power. Test outdoors, antenna pointing up.
From Prototype to Fleet: What to Build Next
You now have a self-contained BLE tracker that broadcasts sensor telemetry to any available relay, with no gateway, no cellular modem, and no monthly connectivity fee. The prototype uses under $20 in parts and runs on a coin cell for years.
From here, three paths open up. First, add location context by using relay phone GPS as a proxy position, or implement BLE direction finding (AoA/AoD) with compatible receivers for sub-meter indoor accuracy. Second, harden for production: design a custom PCB, add conformal coating for IP67, and qualify the battery for your operating temperature range. Third, scale the relay network: integrate your scanning SDK into existing workforce apps so every employee phone becomes passive BLE tracking infrastructure at zero marginal cost per relay.
The economics are straightforward. A cellular tracker costs $30–80 in hardware plus $3–10/month in connectivity. This BLE tracker costs $15 in hardware and $0/month if your relay layer is ambient smartphones. At fleet scale, that delta funds the entire project.
Hubble Network enables direct Bluetooth-to-satellite connectivity for sensor devices—no gateways, no relay phones, no coverage gaps. See how it works →