General Computing in Sensor Environments
The ‘Internet of Things’ is certainly an emerging buzzword these days. The IoT ranges from sports & activity tracking, to the consumers home, all the way to the ‘Industrial Internet’ as GE puts it. And while many applications are already deployed, the ecosystem is still in early days. Today we are at the point of single-use hardware and sensors, using varied, sometimes proprietary standards and protocols.
We’ve seen this before. When the handheld electronics market emerged, there was an array of single-use hardware devices. The cellphone, PDA, iPod, GPS, portable gaming device and digital camera are all examples. And then something happened; the smartphone came out. And while it was called a ‘smartphone’, it was more accurately the first general purpose computer that we carried around in our pockets. This computer quickly wiped out vast industries that were built upon the niche hardware that came before it. Take a look at the stock prices of Garmin, Nintendo, Nokia, Palm, or Kodak to get a clear picture of how the value chain was disrupted.
We are at a similar point in time for the low-cost, low-power sensor market. There is a wide array of competing standards and protocols, all doing one or two things well. Most require specialized hardware to interact with, such as the RFID ‘interrogator’, a device that reads data from RFID tags. And while we are passing electronic signals back and forth, we have not yet reached the stage of general computing.
What is General Computing?
There is no one definition of General Computing. However, historically there have been a few clear signs when computing models have moved from specialized niches to general application.
- A stack is established, with multiple layers of software communicating but independent of each other (ie, the internet, or modern operating systems)
- Standards and Protocols are agreed upon, and hit some level of critical mass
- Robust software development tools and API’s make building at each layer of the stack possible
- Platforms emerge, enabling 3rd parties to innovate and build varied use cases
How do we enable general computing for low-power, low-cost sensors?
We must look to the above signals to generate progress towards general computing. Specifically, for IoT to thrive, we must be able to install wireless, large scale networks of heterogeneous devices. The sensors must able to communicate directly with more full featured computers, while still allowing for software tools, APIs and platforms to be built. Additionally, because of the large scale installations, power, cost and size requirements must accommodate a wide range of use cases.
These sensors must fit the following requirements:
- Low cost, to enable broad scale installation
- Wirelessly networked with ranges accommodating the use-case
- Low power requirements, ensuring maintenance and battery costs don’t overwhelm the total cost
- Small physical size, enabling flexible installation
- Robustness of data transfer, avoiding extra power to succeed and making complex installations easier.
- Interface directly with general purpose computers
- Enable full software development, API’s and platforms, either directly or through connected devices (i.e., Smartphones)
With all that in mind, let us go through a quick technical overview of how Bluetooth Low Energy compares to other similar wireless protocols, and see why it may be the best general choice available.
ZigBee, a cousin of WiFi, descends from the IEE802 standard. Introduced in 2002, it has enjoyed the support of companies like Panasonic, Samsung and Sony. It enjoys a practical range of ~100 meters, enabling full coverage of a house, and with the ability to mesh nodes together, coverage of larger areas as well. Many times ZigBee is used as a backbone technology, syncing & controlling many different nodes.
Unfortunately, ZigBee lacks in a few areas. Most importantly, where remote controls and other proprietary hardware have implemented ZigBee, smartphone’s have not; thus requiring some intermediate standard (wifi/ethernet) to transmit data to the phone. Additionally, the lack of signal robustness and higher power requirements, make ZigBee more costly and error prone in complex enterprise environments.
NFC (near field communication) has always enjoyed the majority of discussion regarding contactless transactions or ‘Personal Area Networks’. And while the promise of NFC in the US has always been great, the results have not. A decade of false starts, especially relating to payment systems, have rendered industry suspicious and fatigued.
NFC suffers a few disadvantages as compared to BLE. First, the max range of NFC is on the order of 5-10 cm, requiring immediate proximity to the sensor. Compare that with 50-100 meters for BLE, and you get a much larger set of use-cases. Second, peak power consumption is higher for active NFC tags than BLE, requiring more power than the commonly used watch battery (CR2032) can provide. Passive NFC tags, while requiring no battery, demand manual instigation before passing data, thus closing many desired use-cases. However, because of the immediate range and robust Android support, some use cases may be better tailored for NFC now and into the future; especially when a literal tap is preferred.
Finally, NFC has been slowed by the lack of iOS support. Market fragmentation, especially in highest end segments, must be addressed before full scale installations occur.
A comparison between RFID and BLE is actually a bit of a misnomer. While RFID is generally defined as a wireless transfer of data using radio frequencies, it’s most closely associated with identifying and tracking tags targeted at high-volume, low-cost tag applications. RFID, similar to NFC, supports both active and passive tags. Active tags are powered, boosting the range to ~100 meters and providing more robust signals. Passive tags are not powered, requiring an ‘interrogator’ to pass power to the tag. Passive tags are extremely cheap and require little maintenance, making them particularly successful in proprietary industrial installations.
Recently, the definition of RFID has started to expand, potentially encompassing BLE as well. Seeing BLE as a subset of RFID makes a lot of sense especially when consumers and consumer mobile devices are involved. As the RFID journal states:
"The combination of functionality, low cost and pervasive adoption will make BLE handsets an attractive option for many monitoring systems that are currently the target for RFID technologies"
RFID tags are cheap to install and good at what they do, but they also serve as an example of specialized hardware; the tools, platforms and device adoption never materialized.
Many industries move from single-use niche hardware and standards to a general computing model, where a range of hardware, software and platforms can flourish. The convergence of mass scale smartphone adoption with the right hardware built in, combined with lowering cost and power requirements of BLE sensors, will enable the start of a coherent, addressable general purpose network. It’ll be fun to watch what gets built.
Next up: We’ll talk in more detail about how smartphones interact with BLE devices, and some interesting applications we’ve already seen built.