This post entry provides a detailed description of how to develop an NFC pairing solution for audio devices. For that, we will describe in detail an audio speaker prototype made by NXP. This post entry has been structured as follows: Use cases for Bluetooth and Wi-Fi pairing via NFC As the number of connected devices grow, the more important it becomes to connect them in a simple way. At the same, it is required to provide a consistent and pleasant user experience. NFC pairing is one popular NFC use case, just bringing two NFC-enabled devices close together is all it takes to create a connection. For instance: To connect to your TV, to transfer a video from your phone, or sharing screens between your tablet and the TV. To connect to your camera to transfer pictures. To connect your phone to a wireless speaker. To connect your new devices to the home network. To connect to your wearables to read your heart rate. Or, to set-up a multi-audio system with NFC. Precisely, this post will guide you through the implementation of the NFC pairing solution for a multi-audio system. Benefits offered by the NFC pairing solution There are several benefits to consider adding NFC to your consumer device. First, from the consumer perspective: It provides a faster and simpler way to link wireless devices, only one touch. The credentials for establishing this connection are exchanged in a secure way. The device is identified instantly, without conflicts. In addition, from the manufacturer perspective, the benefits come mainly from: Making the device more attractive, by adding a new feature. And making the device easier to use, reducing the cost associated to customer technical support. Overall, NFC pairing is an interesting solution since it combines the simple, one-touch setup of NFC with the higher speed, longer distance communication of BT or Wi-Fi networks Pair and unpair Bluetooth headsets with just a tap with NFC NFC pairing process steps To pair and send music to a BT headset is as simple as: Select and play a music track in our phone. Tap the BT headset with the phone. When doing so, the BT pairing credentials are exchanged securely via NFC without any manual settings. The phone automatically initiates a BT connection request. After a second, audio is streamed via BT to the headset without entering any manual configuration. Furthermore, this is not only restricted to phones and headsets, but in general between any two NFC-enabled devices. Therefore, it is also possible to pair and send music to two Bluetooth headsets at the same time, creating what is known as “a silent disco”. Again, the process is simple: First, tap the two headsets with NFC capabilities. When doing so, the headsets automatically exchange the pairing credentials. The headsets establish a BT connection. And audio is streamed between them without requiring any manual setting. Similarly, instead of creating a silent disco, wireless speakers can be paired together via NFC to create a multi-audio system. As such, NFC offers a real one-touch solution. It works with any NFC phone and no dedicated app needs to be installed. NFC unpairing process steps To stop sending music and un-pair the headset is easy as well. A second tap is the only action required to disconnect the headsets. After the tap, the second headset automatically de-activates the audio streaming and switches off. Best of all, we have instant identification of the device to be disconnected. Therefore, zero chances to unpair the wrong device as might happen through the phone settings, where we can unintentionally pick the wrong one. Multi-audio wireless speaker demo with NFC pairing capabilities During the rest of this post, we will tear-down an NFC multi-audio wireless speaker prototype developed by NXP based on PN7120 NFC controller solution. Hardware architecture This demo consists of two speakers with the same components, and therefore, the same functionality. If we dismount one of the speakers, the components we can find in the device PCB are: A system on chip solution, with an application processor, embedded flash memory and BT wireless connectivity. A system crystal clock, the BT antenna and two audio speakers A power supply unit, which includes three 1.5V batteries providing a stable 1.8V output. A NFC reader module, based on PN7120 chip, with an integrated antenna and a compact form factor. Application circuit for Bluetooth power on by NFC triggering If we have a closer look to the power unit interface, we see that: The VBAT pin is directly connected to the batteries. (PN7120 it supports a wide range of power supply voltages, from 5.5V down to 2.75V) The pad supply (PVDD), for the host interface operation, is connected to the 1.8V from the PMU. A wake-up trigger is built so that the BT controller is powered when an RF-field is detected. Regarding the host interface between the NFC controller and the main system MCU: The PN7120 module is connected to the BT controller via I2C slave interface. It supports standard, fast and high speed I2C modes (100 kHz SCL, 400 kHz SCL, 3.4 MHz SCL) The corresponding pull-up resistors are connected on the data and clock lines (SDA and SCL). The IRQ pin is used for ensuring the data flow control between PN7150 and the BT controller. The VEN (RESET) pin, used for setting the device in hard power down mode. And, in respect to the antenna interface: The PN7120 VGA package Some discrete components for the antenna matching And the antenna coil surrounding the PCB edge. Software architecture and NCI interface In this section, we detail the solution software stack and how the NFC application logic works within the overall system. Using the block diagram, we have added the software blocks in orange.First, the PN7120 module includes: The NCI firmware & transport mapping layer for I2C communication (nothing to take care of from the developer side, since this firmware already comes embedded in the chip). Similarly, the host controller side requires: The NCI driver & transport mapping layer to communicate with PN7120 On top of these layers, the application logic for the BT pairing is implemented. Finally, the BT stack for the audio streaming, , but this software piece is not detailed here as it is out of the scope of the NFC implementation. NFC controller interface (NCI) specification details NCI describes the internal interface between an NFC Controller and the main host platform (in this case, between PN7120 and the BT chip). NCI is defined by the NFC Forum organization. As such, it provides manufacturers with a standard interface they can use for whatever kind of NFC-enabled device they build (making integration easier, saving time and effort). The next figure represents the NCI architecture: At the bottom, we find the transport mapping blocks, which map the NCI protocol to an underlying physical connection (I2C, SPI, UART, etc) The NCI core defines the messages, commands and data format for the different communications On top, the NCI modules implement specific functionalities, like the RF discovery which configures the NFC controller to communicate with other NFC tags or devices. From the overall NCI architecture, this implementation makes use of: The transport mapping is the I2C block The RF discovery is configured so that the speaker iterates between the reader, card and P2P modes NFC controller interface: RF Discovery PN7120 firmware can combine the three NFC modes of operation using the RF Discovery as defined in NCI spec. The RF discovery is a cyclic activity which activates various modes of operation. This consists of a loop which alternates two phases: The polling and the listen phases. In the polling phase, the PN7150 acts as Reader or NFC Initiator for the P2P mode, searching for passive tags or an NFC target device. If no card or target was detected, it enters a listening phase, to potentially be activated as card or P2P target If no device to interact is detected in the polling or listening phase, it switches back to polling phase after a timeout. All RF technologies supported by PN7120 can be independently enabled within this discovery loop. However, the PN7120 is in poll phase generates RF field and consumes current. Therefore, the more technologies to be polled, the larger the average current consumption. Multi-audio speaker prototype: RF dscovery configuration To enable the speaker-to-speaker pairing functionality, each of the speakers needs: To have the capability to discover a remote speaker and initiate a pairing operation. Or the other way around, be discovered by a remote speaker to complete a pairing operation. To accomplish this, the speakers need to sequentially move from polling and listening phases. As such, the discovery loop configured in the application iterates between reader, P2P and card modes.During the polling phase, the speaker generates an RF field, and uses an NFC-A polling sequence looking for: A remote card or device in card emulation. If found, the NDEF data with the pairing info will be retrieved and processed. Next, it looks for a remote P2P device. If found, it pushes an NDEF message with the pairing info to this remote peer. On the other hand, during the listening phase, the speaker turns off its RF field and waits to be discovered by a remote device: If it is discovered while operating as P2P target, it will pull an NDEF message coming from the remote speaker. If it is discovered while operating in card mode, its NDEF message will be read by the remote speaker. The precise communication that takes place between the two speakers will differ every time. It will depend on the polling loop status of both speakers at the instant they are tapped. Application logic Until now, we have described how both speakers are discovered, and therefore, how they can start a communication to exchange pairing data via NFC. The next step is to describe which data and which data format is used to exchange the pairing details. NFC Forum specifications The NFC Forum organization defined a set of specs explaining how to exchange pairing data over NFC in an interoperable way with just a tap, independent of the manufacturer and without installing any dedicated application for it. These are: Connection handover: This spec defines how two NFC devices can negotiate and activate an alternative communication carrier. NDEF: The NDEF spec defines a message format to exchange data between NFC devices, including pairing data. Tag 1 Type to Tag 5 Type specs: These specs define how NFC devices can interact with five different types of tag technology. As a result, any NDEF message store in any of these five types of tags will be processed by any NFC-compliant device. NFC pairing: Static handover As mentioned earlier, how pairing data is transferred between the two speakers will depend on the discovery loop status. The static handover takes place when: One speaker is in reader mode / polling mode. (left hand side) The other speaker is in card mode / listening mode, showing a Type 4 Tag with an NDEF message on it (right hand side). The process is as follows: The speaker in reader mode activates RF field and generates a NFC-A polling sequence. The remote speaker in card mode responds to the polling command. The reader retrieves the NDEF data from the remote speaker, using the commands as defined in Type 4 tag NFC forum spec. The reader processes the carrier data from the NDEF message and establishes a BT connection according to BT protocol. The speaker in card emulation mode deploys a Handover Select NDEF record, advertising its BT carrier. In The NDEF message, we store: The BT device address (MAC address) Bluetooth local name (Friendly name for the user) Class of the device (e.g. headset, mobile, etc) This is the carrier data that will be used by the application to trigger the BT connection. After this proces, both devices start streaming music over BT. NFC pairing: Negotiated handover The other possibility is that when both speakers are tapped, they find themselves during the P2P operation. In such a situation, the pairing process will be conducted according to the Negotiated handover mechanism. One of them will take the role of initiator, the other the target role: The initiator will poll for target devices The target will respond to the initiator command The initiator will send a handover request message, with the carrier details The target will respond with a handover select message, indicating the selected carrier option. On the received data, the initiator will establish a connection according to BT protocol. After that, both devices start streaming audio over BT. In this case, both speakers exchange data with their alternative carrier capabilities, could be more than one. The initiator communicates to the target device its carrier capabilities with a Handover request record followed by an NDEF record per each available carrier (in this case, just one BT carrier). After that, the target replies to the initiator with the selected carrier to be used for the out of band data transfer. As before, the BT configuration in the NDEF message includes fields such as: BT address, device class, BT local name, and optional data if secure pairing according to BT spec is required.The key here is that, this negotiation protocol and these message formats are specified and defined in the NFC Forum specs, so they offer an interoperable solution for any compliant-platform Support package This section details resources and information provided by NXP you can use to replicate your own multi-audio speaker solution with NFC pairing capabilities. PN71xx family of NFC controllers PN71xx family are solutions integrating an RF frontend together with an embedded microcontroller with dedicated FW and NCI interface. They fully comply with the NFC Forum, include Linux®, Android™, and WinIoT drivers and sample code for bare metal and RTOS integration. Additionally, they support direct supply from a battery, different power states and an ultra-low power polling loop. Their features make it ideal for NFC integration into any application, especially those with OS system. Hardware support From a hardware point of view, several demokits are available to evaluate PN71xx family. They interface into popular platforms, such as: Raspberry Pi BeagleBone Black Any board featuring an Arduino compatible header like LPCXpresso or Kinetis Freedom among others. In case you have to evaluate PN71xx into any other platform, these kits can be reused, The PN71xx board provides all required signal pins easily accessible so that you can design and build your own interface board for your target platform. Software support From a software support point of view, device manufacturers can easily integrate PN71xx family in Linux, Android and Win IoT systems through the available SW drivers. But also, NXP supplies a set of code examples running on LPC and Kinetis MCUs for Bare metal RTOS integration. Precisely, the demo presented in this post, leverages on the NullOS/RTOS SW examples. The software example for PN71xx integration into RTOS / Bare metal system is made of 3 components: The NXP-NCI module offers an API for configuring, starting and processing the NFC device discovery The NDEF library offers an API for processing NDEF data over reader, card and p2p modes: The transport mapping layer providing HW abstraction for the host – NFC controller connection On top of it, developers can implement their own application. Available resources PN7120 product website: www.nxp.com/products/:PN7120 PN7120 demokits: www.nxp.com/products/:OM5577 PN7120 product website: http://www.nxp.com/products/:PN7150 PN7120 demokits: www.nxp.com/products/:OM5578 Reference source code and related documentation: https://www.nxp.com/doc/SW4325 and http://www.nxp.com/docs/en/application-note/AN11990.pdf Video recorded session
View full article
