The Complexities of Data Exchange
Interoperability has always been a big challenge when developing connected devices that take advantage of cutting-edge mobile phones. In my last blog post about Bluetooth® World 2017, I talked about the potential challenges of partial adoption of the Bluetooth 5 specification:
“None of the features of BT5 are mandatory, so it remains to be seen what portions of the spec the handset developers will support. Without widespread mobile support of the full spec, interoperability concerns could arise, although portions of the spec could still be utilized in custom device-to-device systems.”
This statement is also true for older versions of the Bluetooth® specifications. Throw into the mix various capabilities or restrictions around near-field communication (NFC), wireless charging, Wi-Fi Direct, audio input/output jacks, and kinematic sensors on all iOS and Android devices on the market and you start to see a Venn diagram that looks more like a minefield. So what’s a company to do when designing a new cutting-edge IoT product?
One particular example of an interoperability challenge is some recent work we did for Osmosis, a Seattle company that specializes in using leading-edge digital technology to enable venues to create highly personalized experiences for their fans. They wanted to create a near-field communication (NFC) tap-like experience for data exchange between mobile phones and a custom touchpoint. This sort of interaction might seem ubiquitous and easy with the rising adoption of mobile payment and access cards commonly used for keycards and transit payments. Unfortunately, the reality is that even after Apple enabled read-only access for NFC tags (on an app-by-app basis) in iOS 11, they still restrict bidirectional NFC data exchanges to Apple Wallet only—meaning that a significant portion of the end-user market can’t use NFC. Android, on the other hand, allows applications to implement bidirectional data exchange via NFC. To support the full market, we needed a novel solution.
The first step towards accomplishing Osmosis’s goal was to brainstorm all of the possibilities for communication transports. What technology would be suitable for the end goal? Wi-Fi, Bluetooth® Classic, Bluetooth® Low Energy (Bluetooth® LE), high-frequency audio, and optical solutions were all options that were discussed initially. Clarifying desired user scenarios and possible data exchanges revealed requirements for use in direct sunlight, noisy environments, crowded environments, and temporary locations that may not have much infrastructure. These requirements helped us narrow the field of possible technologies and downselect to Bluetooth® LE for initial investigations.
From there, we explored specific questions about the technical possibilities of Bluetooth® LE on iOS and Android. How could we quickly identify a device in front of the tap-point? How quickly could we communicate between devices? What existing resources could be utilized, and what limitations existed with those resources? Given the possibility that the potential solution might not provide enough compatibility with the vast mobile handset market, it was incredibly important to do proof of concept (POC) development. This iterative process with parallel efforts to inform our decisions, would de-risk the product concept without spending lots of money or time.
We conducted research and experiments [most of which was conducted in radio frequency (RF) shielded enclosures or our RF chamber] surrounding device advertisements to determine how we could quickly discover a relevant device. This testing also informed a series of questions:
- What information could we put into an advertising payload and how did that vary between Operating Systems?
- How fast could a mobile device advertise and for how long for each OS?
- What would happen if the mobile device was asleep or if the Osmosis app was backgrounded?
- Did the performance change if the app was further in the background?
- What other identifications (such as manufacturer and device IDs) could be used?
- How consistent were the received signal strength indicator (RSSI) measurements from handset to handset?
Requirements for database storage and a network backhaul on the Osmosis device also helped inform the decision that the end product would be an embedded Linux device. With this stake in the ground, we started POC development with a Raspberry Pi. Using an off-the-shelf component allowed us to get started quickly and cheaply, and meant software components developed for the POC could later be ported into a functional prototype. We created basic Bluetooth® LE peripheral apps in Android and iOS to run on a wide range of handsets and scripted the Linux Bluetooth® stack (BlueZ) to scan, discover, connect, exchange bi-directional data, and disconnect; allowing us to evaluate initial timing.
With testing, initial timing (from discovery to disconnect) was between 2.5 to 4 seconds depending upon the handset. Realizing how sluggish this felt from a UX perspective, we updated our requirement to 0.5 seconds for a tap transaction and started dissecting the stages of individual transactions to identify the highest latency components. Some of the largest contributors included:
- A disconnect timeout in the BlueZ stack (due to Bluetooth® Classic peripheral drivers)
- BlueZ’s insistence on full Bluetooth® LE service discovery upon connection (the only service we were interested in was Osmosis’s custom service)
- The Bluetooth® radio used
Isolation of those factors helped us quickly optimize the tap timing to 300–400 ms through creation of a custom, lightweight BlueZ alternative that we dubbed “NearBLE” (Near-field Bluetooth® LE). This solution unlocked the desired tap experience across a wide range of mobile phones and operating systems.
“Using NearBLE and Near Field Communications interchangeably makes the simple user experience of tapping a device consistent across any platform. This is key to drive global adoption. Now, we can enable ‘touch to activate’ on everything from iPhones to e-textiles. As a result, brands can create more value in these experiences across their consumer base.”
– Russ Stromberg, CEO, Osmosis
Plan Ahead for Interoperability
Interoperability can be challenging and often has many pitfalls, so when developing a connected device it is incredibly important to take a very deliberate and regimented approach. Brainstorm potential solutions, clearly define requirements, and create proof of concepts to rapidly validate the idea before carrying the design forward. Focus on what is important upfront and don’t neglect the interoperability until the last possible moment. Without these initial efforts you run the risk of making a very costly mistake.
News
Insight
