A topic that is beginning to come up more and more these days is the difference between an NFC reader chip and an NFC controller chip. This would be something considered by those who require an NFC reader for a custom application where the off the shelf reader is not feasible for some reason. I decided to write a knowledge base article about this very important distinction. The designer must pay close attention when selecting which one is the best option for the project. Considerations such as cost, level of firmware development, size, and power consumption will be reviewed here.
NFC Reader vs NFC Controller
The first NFC chips that were commercially marketed were simply 13.56 MHz reader front ends. They implemented only a small part of the ISO 14443 standard, part two only. In total there are four parts to this standard, and the key difference between an NFC reader and a controller is that a controller handles all parts of the ISO standard while a reader will require the designer to implement a lot of it in the host controller firmware.
Essentially, an NFC reader simply takes data, and transmits it using the modulation and signaling specified in ISO 14443-2, It also receives data sent to it using this standard. An NFC controller however goes a few steps further and handles the the messy parts of the anticollision and selection process as well as the additional framing required when using different tag technologies and NFC operating modes such as card emulation and peer to peer. The takeaway here is that using an NFC reader chip requires a much more advanced level of NFC knowledge.
Using an NFC controller vastly reduces development time and is the main reason semiconductor companies developed them. What makes an NFC controller so advantageous is the microcontroller it includes that handles additional NFC protocol implementation, further relieving the designer of ominous firmware development.
There are three additional complexities handled by the NFC controller:
- The ISO 14443-3 anticollision procedure
- The ISO 14443-4 transmission protocol
- Additional framing and CRCs required by specific initiator/target configurations
The anti collision procedure is how industry standard tags are detected and selected for communication. It also covers how to read the Unique Identifier (UID). The transmission protocol is a half-duplex communication method that addresses the needs of the contactless environment.
Depending on what tag technology or target configuration the reader is communicating with, an NFC controller will automatically handle the required protocol and framing implementation specified by the NFC Forum. Such implementations vary in complexity, but the main point is that using an NFC controller will make managing this transparent from the perspective of the designer’s firmware. Designers must still discern tag technologies according to the industry standards (SAK, SEL_RES bytes) and send the appropriate tag commands with correct structure, but that data is automatically framed and transmitted by the NFC controller in a way the target will understand. Of particular utility is the automatic checking of CRCs of incoming data received by the NFC controller, something that the designer’s firmware would have to handle on its own is using just an NFC reader chip. By including an additional embedded controller, the TappyUSB and TappyBLE readers bring a lot more to the table, allowing developers to work with NDEF formats without worrying about the various tag technologies and NDEF formatting standards. There are also some other useful features such as DESFire support, on board encryption/hashing, and NFC passport decoding as seen in the figure below.
This is where the NFC reader chip is advantageous. With the integrated microcontroller that relieves the designer of a lot of firmware implementation, NFC controllers are about twice the price of NFC reader front ends. To put it in perspective, even the ACR-122U, a very cost effective and widely used NFC reader, uses an NFC controller as its chip, presumably for the reduced complexity required in the host controller firmware. NFC experts however sometimes recommend reader chips since they know the anticollision and transmission protocol well enough to implement such firmware.
Again we must return to the internal microcontroller that simple NFC reader chips don’t have. Even a simple 8-bit microcontroller will have an Arithmetic Logic unit (ALU), RAM, program memory, counters, port controllers and timers. This level of integration makes the NFC controllers consume more power than their reader counterparts. That said, having the host controller handle all the extra firmware necessitated by an NFC reader chip may consume a comparable amount of power, however this is theoretical and highly dependent on the setup. In general it’s safe to say that from a datasheet perspective, NFC controller chips consume more power than reader chips do.
The difference in size would be influenced by the power, however ultimately this would depend on the manufacturer. For NXP, the PN512 reader chip is available in a reduced package size that its NFC controller, the PN532, is not. Although it saves only a few millimeters of width and length, at TapTrack we have see applications where this much space saved made the difference.
All in all, the extra cost and power consumption of the NFC controller is worth it if it is economically viable in the intended application. The main reason of course is speed to market. By letting the NFC controller do the heavy lifting for you, the designer can reach market readiness much faster. Keep in mind that even if the cost of the NFC controller hurts in the pilot/proof-of-concept phase, once the true scope of NFC functionality is determined, the true complexity of the firmware needed for a simple reader chip can be more clearly defined. For example, if your application uses a UID only system, whereby the UID of the tag is the only piece of information needed, then using a controller to start simplifies the prototype, and if your product gains traction in the market migrating to a less expensive reader chip solution is not too painful since only the UID detection procedure needs to be implemented, something that can be budgeted and even outsourced when a product is being taken from beta stage to market.