The shift from wired to wireless vibration sensors for bearing condition monitoring has been underway for over a decade, but the proliferation of wireless protocols has made sensor selection more complex, not less. BLE, LoRa, and LTE each offer distinct tradeoffs in range, power consumption, data bandwidth, latency, and infrastructure requirements. Choosing the wrong protocol for a deployment context can result in a system that is either chronically offline, battery-depleted in months rather than years, or incapable of transmitting enough data to be diagnostically useful.
The Core Tradeoffs
All wireless protocols for IoT sensors navigate the same fundamental tension: radio frequency communication consumes power proportional to transmit power and time on air, and higher data rates require either more bandwidth (spectrum) or shorter range. No protocol dominates all three dimensions simultaneously.
- BLE: Short range, low power, moderate data rate
- LoRa: Long range, very low power, very low data rate
- LTE: Medium range, high power, high data rate
BLE: Bluetooth Low Energy
BLE operates in the 2.4 GHz ISM band with 40 channels of 2 MHz bandwidth each. Typical transmit power ranges from 0 dBm to +8 dBm, with peak current draw of 5–15 mA during transmission. At maximum transmit power and with a clear line of sight, BLE 5.0 achieves ranges of 100+ meters; in steel machinery spaces with walls and obstructions, practical range drops to 10–30 meters per hop.
BLE’s primary advantage for bearing monitoring is its ecosystem and power profile. The nRF52 and nRF53 family of BLE SoCs (Nordic Semiconductor) include hardware accelerators for signal processing, enabling computation of condition indicators (RMS, kurtosis, FFT peaks) on-sensor before transmission. This dramatically reduces the data volume that must be transmitted — instead of sending raw waveforms, the sensor transmits only computed indicators.
BLE’s data rate of up to 2 Mbps (BLE 5.0 coded: 125 kbps to 2 Mbps depending on PHY selection) is adequate for streaming short waveform bursts when full waveform upload is required. The coded PHY option trades data rate for extended range at the same power level, reaching 4× the range of 1M PHY at the cost of 1/8th the throughput.
Best use cases: Close-range installations (marine machinery spaces, small industrial facilities), applications requiring multi-sensor networks within a single room or hull compartment, battery-operated sensors requiring multi-year life.
BLE Mesh: Extending Range for Multi-Hop Networks
BLE Mesh (Bluetooth Mesh Profile) extends BLE from point-to-point to multi-hop broadcast networks. Messages are flooded through the network using a managed flood model — each node retransmits received messages with a configurable time-to-live, effectively relaying data across distances that a single BLE hop cannot cover. A 50-node BLE Mesh network can span several hundred meters through multiple walls.
The tradeoff is increased power consumption (each node participates in relaying for others) and latency. BLE Mesh is not suitable for low-latency applications or for high-bandwidth waveform streaming across multiple hops. It is well suited for distributed condition indicator reporting — periodic transmission of computed health metrics from sensors throughout a large asset.
LoRa: Long Range
LoRa (Long Range) modulation, commercialized by Semtech, uses chirp spread spectrum (CSS) in sub-GHz frequency bands. In North America, LoRa devices operate in the 902–928 MHz ISM band (LoRaWAN AU915/US915 plan), which provides better building penetration than 2.4 GHz and longer free-space range at the same power level.
LoRa’s spreading factor (SF7 through SF12) controls the tradeoff between range and data rate. At SF12 and 125 kHz bandwidth, LoRa achieves a link budget of approximately 157 dB (versus ~100 dB for WiFi) with a data rate of only 250 bps. At SF7, data rate rises to ~5.5 kbps but link budget decreases to ~137 dB. In practice, most industrial LoRa deployments operate at SF9–SF10 for a balance of range and data rate.
LoRaWAN networks operate over public infrastructure (The Things Network, Helium, carrier LoRaWAN) or private gateways. A single LoRa gateway with an omnidirectional antenna can cover an entire industrial campus or a 2–5 km radius outdoors, making it extremely cost-effective for widely distributed asset monitoring.
The critical limitation for vibration monitoring is bandwidth: LoRa cannot transport raw vibration waveforms in any practical sense. A 2-second vibration sample at 25 kHz sampling = 50,000 samples × 2 bytes = 100 KB. At SF9 (1.7 kbps effective throughput), this would take nearly 10 minutes to transmit — and LoRaWAN duty cycle restrictions (1% in EU, varies in US) would prevent it entirely. LoRa for bearing monitoring is strictly a computed-indicator protocol: RMS, kurtosis, crest factor, temperature, and envelope spectrum peaks can be encoded in tens of bytes and transmitted in a single LoRa packet.
Best use cases: Industrial facilities with widely distributed assets (pumps, fans, conveyors across a large plant), outdoor installations, situations where gateway infrastructure cost must be minimized, and where computed indicators rather than raw waveforms are acceptable.
LTE: 4G/5G Cellular
LTE (and its successors LTE-M and NB-IoT for IoT applications) provides wide-area connectivity using licensed spectrum through cellular carriers. LTE-M (Cat-M1) targets IoT applications with peak data rates of 1 Mbps uplink and moderate power consumption; NB-IoT achieves even lower power but at reduced data rate (250 kbps uplink max).
For bearing monitoring, LTE-M is the relevant variant. Its 1 Mbps uplink rate means a 100 KB waveform can be transmitted in under one second. This enables raw waveform upload from remote or mobile assets without the data rate constraints of LoRa. Peak current draw for LTE-M transmission is 200–500 mA — one to two orders of magnitude higher than BLE or LoRa. Battery life for LTE-M sensors is measured in weeks to months at frequent sampling intervals, rather than years.
LTE’s geographic coverage makes it uniquely suitable for mobile or remote assets: vehicles, vessels, assets in locations outside WiFi or LoRa gateway coverage. A bearing sensor on a mobile generator, a rail car, or a remote pump station can report directly to cloud infrastructure without local gateway infrastructure.
Best use cases: Mobile assets (vehicles, rail, vessels), remote assets without local infrastructure, applications requiring raw waveform upload, and high-criticality assets where latency in receiving bearing data must be minimized.
Protocol Comparison Summary
| Characteristic | BLE 5.0 | BLE Mesh | LoRa (US915) | LTE-M |
|---|---|---|---|---|
| Frequency | 2.4 GHz | 2.4 GHz | 902–928 MHz | Licensed band |
| Typical range | 10–100 m | 100–500 m (multi-hop) | 1–10 km | Carrier coverage |
| Peak data rate | 2 Mbps | <1 Mbps | 0.25–5.5 kbps | 1 Mbps |
| Tx current | 5–15 mA | 5–15 mA | 25–125 mA | 200–500 mA |
| Infrastructure | Gateway | Mesh + gateway | LoRaWAN gateway | SIM + carrier |
| Waveform upload? | Yes | Limited | No (impractical) | Yes |
| Best for | Close-range, marine | Large buildings | Distributed industrial | Mobile/remote |
Multi-Protocol Architectures
The most capable bearing monitoring deployments use multiple protocols in a tiered architecture. BLE collects data from sensors within a machinery space; a BLE-to-LTE gateway aggregates and uploads to cloud infrastructure. This combines the power efficiency and ecosystem of BLE at the sensor with the wide-area reach of LTE at the gateway — neither protocol alone achieves both properties.
Systems like Fault Ledger take a multi-protocol approach specifically because no single wireless standard addresses all deployment environments. Marine installations benefit from BLE’s low power and metal-space performance; railway rolling stock needs LTE for connectivity in motion; large industrial facilities may use LoRa for campus-wide sensor aggregation. A platform that supports multiple protocols avoids forcing the deployment environment to adapt to the sensor’s connectivity constraints, rather than the reverse.
For engineers evaluating wireless vibration sensors, the protocol selection should be driven by the specific combination of range, data rate requirements, power budget, and available infrastructure — with the recognition that raw waveform access (required for forensic analysis and deep diagnostics) effectively requires BLE or LTE, while LoRa works well for operational trending applications where computed indicators are sufficient. Visit Fault Ledger to explore how multi-protocol sensor design applies to your specific bearing monitoring environment.