Skip to content

There are a large number of wireless solutions available, each with their own positive and negative attributes. Identifying the optimum wireless choice to employ for a given use case is critical to a successful implementation. Initially, the set of possible candidates is large:

  • ZigBee
  • IEE 802.15.6
  • ANT+
  • IEEE 802.15.4
  • Bluetooth Low Energy (BLE)
  • Bluetooth BR/EDR (Classic)
  • Wi-Fi
  • NIKE+
  • NFC
  • Proprietary

 

But when we start to filter using the obvious attributes that will be needed for most use cases, we quickly reduce this list. The biggest reduction is the need to connect to a smartphone (including iOS, Android, and Windows 10). Filtering for this attribute results in a much shorter list:

  • Bluetooth Low Energy (BLE)
  • Bluetooth BR/EDR (Classic)
  • Wi-Fi
  • NFC

 

The next attribute is range between wireless nodes. This quickly eliminates NFC from the list of viable choices: as implemented in a smartphone, NFC is usually limited to around 5 cm. Range is a function of the physical size of the NFC antenna, so physical constraints can come into play as well. And before we say “goodbye” to NFC, it should be noted that the NFC frequency of 13.56 MHz is so low that data throughput is highly constrained, so communications takes longer and usually consumes more power for that longer period.

And now we are down to three viable candidates:

  • Bluetooth Low Energy (BLE)
  • Bluetooth BR/EDR (Classic)
  • Wi-Fi

 

All three of the candidates work in the 2.4GHz band. This is the worldwide ISM band, and thus a good choice for navigating regulatory environments for any product that could have a global market. However, it also comes with two negatives.

  • The 2.4GHz band is “crowded,” meaning that it has a lot of potential interference (including signals from baby monitors, microwave ovens, cordless phones, etc.)
  • 2.4 GHz energy is absorbed by water molecules, so penetration through flesh (as in the case of an implantable medical device) can be limited.

 

Bluetooth BR/EDR (“Classic”)

Older radio design, usually thought of as being a “medium power” radio, due to its consumption of 112 mA, which is 37 times the power consumption of BLE. This large power draw is why Bluetooth audio headsets have large rechargeable batteries that need frequent recharging.

Bluetooth Classic supports many different modes of operation, topologies, and data types, including complex and large software stack and interfacing needs.

  • The throughput of Bluetooth Classic is its main feature. At about 2 M bits per second, it is suitable for high-quality audio.
  • Operating range is 10 to 30 feet at approx. 20 dBm.
  • Works with Google Android platforms and Microsoft Windows without any additional licensing, however Apple iOS platform requires licensing and royalty fees for any device connecting to the iOS device (more information on the approval process can be found on the Apple website).
  • Due to it being a fully mature protocol it is now mostly ignored by Bluetooth SIG, with the majority of ongoing development effort now focused on BLE.

 

Wi-Fi

Wi-Fi (IEEE 802.11b/g) has gone though a lot of changes over the years and has reached maturity and ubiquity. Because of their similar power draw to Bluetooth Classic, but with a much greater range and a throughput that is 27 times greater than Bluetooth Classic, the latest generations of Wi-Fi radio have largely replaced Bluetooth Classic radios.

  • With a range of 150 to 300 feet at a power output of +17 dBm, the latest Wi-Fi single chip radios pull about 140 mA and support a throughput of 54 M bits per second, suitable for all data communication applications including streaming video. These devices also support low power modes that, when not in use, pull <1 mA.
  • Works with both Apple iOS, Google Android, and Microsoft Windows platforms without any additional licensing.

 

Bluetooth Low Energy (v4.0 – v4.2)

Is the most recent entry in this set of candidates, and as such it has improvements designed into the radio and the protocol to address deficiencies discovered in older protocols:

BLE is very low power (in the range of 3 mA to 9 mA, depending upon the manufacturer).

  • With an RF output power of +4 dBm the operating range is 250 to 300 feet (line of sight).
  • Coexistence with other RF sources of interference is excellent, as it continuously and automatically shifts the frequency being utilized to move away from any other sources of RF.
  • Both standalone “system on a chip” (radio plus CPU) and radio interfacing to a host CPU model are available. Neither of these models require any specialized protocol stack or software interfacing.
  • Throughput is designed to support small data sets with low throughput needs. However, its maximum throughput is compatible with smartphones at 77k bits per second, suitable for low quality audio.
  • Connection occurs very rapidly with the radio able to “wake up,” discover another other radio, send a data packet, and return to low-power “sleep” mode – all within 3 mS.
  • Very simple mode of operation with only 5 possible states and a fixed star topology.
  • Works with Apple iOS, Google Android, and Microsoft Windows 10 platforms without any additional licensing.

 

Bluetooth Low Energy (v5)

The latest release of BLE has begun rolling out to the embedded market with some excellent new upgrades, including:

  • Higher throughput (> 200 kbps)
  • Extended Range (over a km)
  • Improved security
  • Mesh topologies

 

We will start to see this release broadly adopted across the smartphone market in the coming months.

 

Conclusion

BLE is the “must-have” feature on just about every new device being developed today. Due to its large-scale adoption in so many industries, the Bluetooth SIG is focusing all of its attention on improving BLE. Consequently, BLE just keeps getting better.

BLE will be present in smartphones for the foreseeable future. Only for applications where very large throughput values are needed should certain lower power Wi-Fi radios be considered instead. Bluetooth Classic has had its time, but because of its high-power requirements for lower throughput, combined with the license encumbering of developing with it for iOS, it is no longer a viable option for new designs.

 

This is your Header

Safe. Secure. Effective.

One Stop for Medical Device R&D, Product Development, Contract Manufacturing, and Postmarket.