How to use NFC in a tablet without a built-in reader

Enabling NFC applications on tablets without built-in NFC capability

Sep 5, 2018 - 8 minute read

The all-in-one nature and large touch screens currently offered by tablets at very competitive price points makes them a highly appealing choice for lots of situations - displaying product information microsites, powering brand activation points, and simply being the brains behind kiosks of all varieties. Unfortunately, while these tablets offer lots of connectivity options and plenty of sensors, one thing they often forgo is NFC capability. Further, even if the tablet does have NFC, actually using it often requires the tag to be tapped on the back of the tablet, which is highly impractical for a significant proportion of NFC applications. So, how then, does one use NFC on a tablet without a built-in reader in a practical location?

At the end of the day, regardless of what specific technology is used, fundamentally, in order to add NFC capability to a tablet reader, we’re going to have to do two things: connect an external NFC reader peripheral to the tablet and install an application to talk to it. Unfortunately, with the multitude of connectivity options presented by modern tablets and the multiple different readers on the market, figuring out what makes the most sense for a given application can be a little tough. To help with that we’re going to give a run-down of the main ways to accomplish this task:

USB NFC Readers

The cheapest and most available NFC readers on the market are those that connect to their host via USB. In addition to their advantages in price and availability, USB NFC readers also offer a very reliable connection that isn’t vulnerable to congested radio frequencies (a common problem with Bluetooth readers as we will see later). Unfortunately, historically, there has been a major stumbling block - charging. Traditionally, Android tablets have only been able to act as a USB host through a USB On-The-Go cable or charge themselves, but they couldn’t do both at once. There are a few unusual tablets that have ways around this limitation either via an auxiliary charging method like the Nexus 10’s Pogo pins or a special proprietary peripheral like the LAVALink SimulCharge adapters that work with certain Samsung tablets. As a result, in many cases, the tablet and the reader had to both be powered solely by the tablet’s onboard battery, which was only really practicable for short-duration events. Quite conveniently, this limitation is starting to disappear with the adoption of USB-C. With USB-C, for around 20 dollars, it is now possible to buy standard off-the-shelf hubs that are also capable of powering their host devices. Unfortunately, USB-C adoption has been a bit slower in the tablet space than it has been for other electronic devices, but, as new tablet models with USB-C support start saturating the market, pairing such a tablet with a hub and USB NFC reader will become a steadily more attractive option.

As for the readers themselves, there are a large number of different USB readers that could be used with a tablet, many with quite similar specifications. Instead of trying to base a reader decision on these specifications, most of which are inconsequential for practical applications, it makes more sense to select a reader based on the available applications and SDKs for integrating with the reader. Unfortunately, the majority of these USB readers are primarily targeted at desktop usage, so the availability of first-party support for Android devices, tablets included, is either limited or non-existent. For example, the ubiquitous ACR122U made by ACS has a handful of of second- and third-party libraries and apps developed for it, but ACS themselves only distributes a basic SDK as a precompiled JAR with an example app built using the deprecated Eclipse-based ADT instead of providing a Maven repo and Android Studio project. While there are some other examples out there for this reader, they are mostly very limited in either functionality or support (if indeed there is any support offered at all). All that said, if your application is quite simple and you have significant development resources at your disposal, these disadvantages may not matter when weighed against the ready availability and low cost of the ACR122U.

At the other end of the spectrum for Android support sits TapTrack’s TappyUSB NFC Reader. While the Tappy is a bit more expensive than the ACS offering, it comes with an modern first-party open-source SDKs with support as well as a host of example applications that cover many common use cases. In fact, for many common use cases such as brand activation touch points, one of these example applications may be sufficient without any additional development needed at all.

Bluetooth NFC Readers

Bluetooth NFC readers are somewhat less common than USB ones, but there are still several available on the market. Prior to the adoption of USB-C, these were your only options for broad tablet compatibility if it was necessary to charge the tablet while using the reader. Now that USB-C is being broadly adopted, Bluetooth readers are becoming less compelling for NFC kiosk applications, but their wireless functionality does enable some usecases for which the cable of a USB reader presents a problem. Additionally, if one has already purchased tablets for an application and they do not support USB-C charging hubs, getting Bluetooth NFC readers may make more sense than replacing the tablets.

While they can perform quite admirably and do offer excellent flexibility in positioning, Bluetooth readers have a couple of distinct disadvantages compared to their wired cousins. Firstly, while USB is usually very reliable on all devices, Bluetooth performance can be highly variable from device-to-device and can be impacted by difficult-to-debug, seemingly unrelated factors. For example, here at TapTrack, we’ve seen tablets that repeatedly lose their connection to a Bluetooth reader, but only when they also have WiFi enabled. Exacerbating this issue is the fact that the Android Bluetooth driver itself is, in our experience, not particularly reliable and is prone to failing in ways that are difficult-to-detect or completely silent and, unfortunately, sometimes only fixed by rebooting the tablet. Additionally, regardless of what host device and reader you use and how reliable it may be, Bluetooth performance is always going to be degraded in the presence of significant amounts of radio interference. Unfortunately, the 2.4GHz frequency that Bluetooth operates at is extremely congested with signals from other Bluetooth devices, signals from devices using WiFi, and noise thrown out by microwave ovens all contributing to the problem.

From a reader option standpoint, the story is largely the same as it is for USB readers. There are a handful of readers out there, but the most commonly available one is again an ACS offering - the ACR1255U-J1. Once again, there is a somewhat outdated SDK offered by ACS themselves and a handful of second- and third-party example programs and SDKs on offer from other groups and individuals with varying levels of functionality and support. That said, once again, if your application is fairly straight-forward and you have significant development resources, the ACR1255U-J1 might be a logical choice.

On the other hand, if you’re looking for a more plug-and-play solution, TapTrack’s TappyBLE NFC reader with its host of open-source SDKs and example applications may be the more attractive option. In addition to the SDKs and support, the TappyBLE also offers a relatively unique feature - heartbeat mode. When you use a TappyBLE with heartbeat mode enabled, the application and the Tappy will maintain a ‘heartbeat’ of messages back-and-forth and initiate a disconnect/reconnect cycle and raise an alert if the heartbeat fails. Often the disconnect/reconnect cycle will resolve some Bluetooth issues that would otherwise require staff intervention, and, if the issue is not resolved, you at least have a mechanism for informing staff that the tablet needs servicing.

Headphone Jack Readers

NFC readers that connect via a tablet or phone’s headphone jack used to be more popular than they are today, but they still occasionally crop up, particularly in mobile cash register applications. Headphone jack readers are usually the cheapest option for NFC readers, but their performance in all other aspects is generally abysmal. From a compatibility perspective, the headphone jack readers are generally only tested on a handful of devices and often there is a significant lag between new devices being released and the reader manufacturer performing the tests and updates necessary to extend support to that device. Granted, sometimes devices that are not officially supported by a reader will still work, but it is nowhere near as likely as with a Bluetooth or USB reader. Further, headphone jack readers are powered by an onboard battery that is generally very small. As a result, in order to achieve an acceptable battery life, the readers use very low power reader chips with very brief scanning cycles, which results in scanning range and speed that are unimpressive at best. Finally, headphone jack readers may or may not provide a good user experience placement-wise, depending on how the reader and tablet you are using are built. In any case, headphone jack readers certainly don’t provide positioning convenience that comes close to the nearly-unlimited flexibility of a Bluetooth reader or even that of a USB reader. Taking all these disadvantages into account, here at TapTrack we generally try to guide people away from headphone jack readers.

Last Updated: Sep 5, 2018
Originally Published: May 17, 2015

Luke Van Oort

Chief Developer, fan of immutable data structures and functional reactive programming. Cooking hobbyist and cycling enthusiast.

Share on: LinkedIn, Twitter, Google+