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:
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:
Precisely, this post will guide you through the implementation of the NFC pairing solution for a multi-audio system.
There are several benefits to consider adding NFC to your consumer device. First, from the consumer perspective:
In addition, from the manufacturer perspective, the benefits come mainly from:
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
To pair and send music to a BT headset is as simple as:
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:
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.
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.
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.
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:
If we have a closer look to the power unit interface, we see that:
Regarding the host interface between the NFC controller and the main system MCU:
And, in respect to the antenna 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:
Similarly, the host controller side requires:
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.
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:
From the overall NCI architecture, this implementation makes use of:
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.
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.
To enable the speaker-to-speaker pairing functionality, each of the speakers needs:
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:
On the other hand, during the listening phase, the speaker turns off its RF field and waits to be discovered by a remote device:
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.
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.
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:
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:
The process is as follows:
The speaker in card emulation mode deploys a Handover Select NDEF record, advertising its BT carrier. In The NDEF message, we store:
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.
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:
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.
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
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 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.
From a hardware point of view, several demokits are available to evaluate PN71xx family. They interface into popular platforms, such as:
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.
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:
On top of it, developers can implement their own application.