In the first article of this series, we provided a brief description of Android’s use of RFID. As part of that discussion, we pointed out that Android, by default, supports RFID solely through its implementation of NFC. We also pointed out that, although NFC expands the use of RFID to new types of applications, it implements only a subset of the RFID capabilities required by traditional enterprise RFID applications. This article will discuss some of those missing capabilities.
Support for the Full Range of Tag Technologies & Formats
RFID readers can be classified according to the frequency ranges in which they operate, and there are multiple tag types supported within each frequency range. The read ranges vary based on tag type, size, mounting surface, antenna design and more. General differences, however, are as follows:
Low Frequency (LF) - Operates at 120-150 kHz, with read range of up to 10 cm, unless you have a large tag.
High Frequency (HF) - Operates at 13.56 MHz, with typical maximum read range of up to 1 m. Consumer phones with NFC generally have a “near touch” range.
Ultra High Frequency (UHF) - Operates at various geo-regulated sub-ranges within 858-930 MHz, with maximum read ranges up to 12 m. (Gen3 tags may reach even further.)
Android’s RFID support through NFC currently focuses exclusively on HF readers, and the Android SDK provides classes for managing a number of common HF tag formats (e.g., ISO-1443-3A/B, ISO-15693, MIFARE Ultralight).
For the set of consumer-oriented applications at which NFC is currently aimed, Android’s focus on HF is appropriate. However, addressing the whole range of RFID applications in the enterprise space requires that we support LF, HF and UHF type readers. That’s because each type has a unique set of strengths and weaknesses, and selecting the most appropriate technology for a given environment involves trading off those strengths & weaknesses against various factors (e.g., tag costs, the need to minimize interference between multiple readers, required read range, material type).
In other words, there is no “one size fits all” type that works optimally for all environments in the enterprise space: We need to support the full set of reader types along with the most common tag formats for each type.
Functions and Interfaces for Handling Large Tag Populations
Android’s NFC is designed primarily for one-tag-at-a-time scanning and processing. However, in the enterprise space, RFID is often used in industrial and other commercial applications where there are a large number of tags to be scanned under varying types of conditions. In many cases the tags need to be read quickly and comprehensively by returning multiple tags within a single scan operation. Supporting these environments requires that we provide both users and applications with interfaces to advanced settings and operations beyond those currently available through Android’s SDKs. Here are some examples:
Power and Antenna Settings - Most commercial enterprise RFID readers have various software-accessible controls for adjusting the power level, antenna settings, and scanning algorithms in order to optimize reader performance and to avoid signal “collisions” between tags which prevent weak tags from being detected.
Duplicate Detection - RFID readers configured to scan for multiple tags simultaneously are capable of returning hundreds of scanned tags per second. Since RFID tags are designed to respond repeatedly during a scan, a single scan operation typically returns mostly duplicate scan data. Although some tag readers have configurable options to automatically suppress duplicate tags, it is not universally available. Furthermore, those RFID readers that do provide it sometimes limit some of the other functionality available while using it.
Other Advanced Scan Options & Metrics - Commercial RFID readers typically have other special options for multi-tag scanning operations that need to be made accessible. For example, UHF readers typically allow masks for selecting/deselecting tags from scan operations; options for including or excluding tag memory; selection of which memory bank to read; and options for including/excluding per-tag metrics such as RSSI (signal strength), scan time stamp, and tag read count.
In many environments it is useful (and in some cases, critical) to have access to the per-tag metrics above as well as summary metrics. Some of these metrics are provided by the RFID readers themselves, but others can be calculated by the generic RFID service.
Native-Level Controls & Services
Built-in Support for Hardware-Based Controls
In commercial environments, it is frequently desirable to map RFID functions to hardware controls such as buttons or “pistol grip” trigger add-ons rather than relying exclusively software- or touchscreen initiated actions. Although this capability can be implemented via custom software, a more desirable solution would be to incorporate such support into the general, OS-level RFID SDK and services so that each application writer can be unburdened from the task of developing their own proprietary solution.
Keyboard Wedge Support
In some instances, solutions developers and users would like scanned RFID data imported directly into generic applications as keyboard input rather than via APIs. Supporting this would require building a generic “keyboard wedge” mode into any Android-based RFID service.
Filling the Functional Gap: What’s Needed?
As we have demonstrated, native Android does not provide support for all the device types and functions needed for traditional enterprise applications. To fill these gaps to date, makers of enterprise Android devices and RFID components have created their own implementations with proprietary interfaces. What is needed is a set of common Android API extensions and supporting services for accessing the full range of functions across multiple mobile devices and RFID technologies. Addressing that need will be the subject of the next article.