RTC Magazine

The challenge of RFID readers no longer consists of merely reading tags. Instead, now that the technology has moved past the stage of pilot programs and is being deployed for supply-chain management, these readers are taking on new strategic importance. The scope has widened to include issues such as integration into the corporate network, manageability, scalability, security, low total cost of ownership and especially avoiding obsolescence.

Adopters of radio frequency identification technology are continually challenged to accommodate new RFID tags, update their RFID systems with the latest technology and implement new protocols, including EPCglobal Generation 2, which allows more information to be stored on each tag, greater security, and better addresses noisy RFID environments with multiple interference sources (Figure 1). Since RFID readers do the bulk of the tag processing required, users are tasked with determining which readers will perform best through their ability to utilize new technologies, protocols and upgrades.

Recognizing that the reader is key to ensuring that RFID systems remain current with fast-changing technology, ThingMagic engineers made a critical commitment when designing the Mercury reader system. They decided to design an advanced software defined radio (SDR)-based reader platform for fixed, embedded and mobile readers. The result is an intelligent, network-ready reader that reads any tag.

Mercury RFID Reader Hardware System Architecture

Conventional RFID readers were unintelligent data radios, reading a single tag protocol in a single radio frequency and communicating with a PC via a serial interface. Today’s SDR-based RFID readers are agile, intelligent data readers, TCP/IP network nodes and data processors able to simultaneously read multiple tags while filtering out interference from other RFID readers and wireless devices.

The Mercury platform hardware consists of analog front-ends (AFEs), a DSP, a network processor, memory and communications ports (Figure 2).

The AFEs are essentially stateless; their hardware is designed to be protocol-neutral. They are, however, optimized by frequency band to meet the requirements of the radio regulations in the geographical region in which they operate, for example, FCC Part 15 regulations in the U.S. or ETSI EN302-208 regulations in Europe. They are connected via high-speed A/D and D/A converters to a real-time signal processing system that is currently based on a 600 MIPS Texas Instruments DSP. This DSP uses ThingMagic’s proprietary, real-time, signal processing software engine to manage all aspects of transmission and reception.

The AFEs are capable of fully general I/Q modulation and demodulation with bandwidths up to a Nyquist anti-aliasing filter limit of 5 MHz (double sideband), allowing up to 10 MHz of incoming signal spectrum to be simultaneously digitized and processed. Protocol-related software is loaded into the DSP, which then controls how the AFEs communicate with RFID tags. In turn, the DSP is controlled by a network processor, currently an Intel IXP42x running at 266 MHz. The Mercury4 was the first RFID reader to use an Intel processor, the result of close teamwork between Intel and ThingMagic. The main function of the IXP42x in this architecture is to initiate tag searches, load protocols and process the results. It also handles backend networking and high-level developer interfaces.

The DSP in both the Mercury4 and the Mercury5 is a high-performance, low-power Texas Instruments TMS320VC5502. It provides 600 MIPS of processing on parallel multiply-accumulate pipelines at a clock speed of 300 MHz. Using a high-performance DSP allows the reader to switch between protocols in real time and quickly separate signal from noise. The most common RFID tags have no battery and reflect power from the reader, resulting in weak and noisy responses that often require advanced signal processing to decode.

Coupled with the protocol-neutral AFEs, the high-speed DSP ensures that the reader’s hardware can read any tag that falls within its frequency band and regulatory setup, up to the limits of a tag subcarrier frequency of 5 MHz on either side of the transmitted carrier. This accommodates all Generation 2 waveforms.

Tag reading and writing is purely a matter of software. Once ThingMagic’s engineers have developed the appropriate protocol software, the Mercury platform can read and write to any tags that fall within the frequency band and regulatory regime supported by the AFE. Currently, Mercury readers can read and write to all variants of EPC Class 1 Generation 2 tags as well as EPC Generation 1 Class 1, Generation 1 Class 0, Class 0+, ISO 18000-6b and -6c and UCODE 1.19.

All Mercury readers have at least 64 Mbytes of DRAM and 16 Mbytes of flash memory so that third-party software and middleware can operate on the reader. This allows data processing to occur at the point of data capture for truly real-time operation, with no extra hardware at the edge of the network. This memory can also be used to buffer tag data in case of network disruptions or power outages.

A standard 10/100 BaseT Ethernet port is provided for connection to corporate networks. An RS-232 serial port is also available for user applications, including controlling an external device and debugging user code. Two general-purpose input and three general-purpose output ports (GPIOs) are accessible through the serial port. These GPIOs can be used to allow external events to trigger a response from the reader, allowing the reader to be customized for specific applications. GPIO signal levels are compatible with standard RS-232 signal levels.

While conventional RFID readers were essentially data radios, the Mercury4 is a full-fledged network device that can support mission-critical operations. In addition to managing a dynamic population of tags, then routing data into networks, databases and business applications, these readers speak TCP/IP natively. They also fully support standard network technologies such as DHCP, User Datagram Protocol (UDP)/IP over Ethernet, 802.11x, HTTP, SNMP and remote upgrades.

SDR-Based Reader Architecture

By using an SDR-based architecture, readers can continue to be updated without the risk of being rendered obsolete. New tag protocols and features can be easily incorporated to existing hardware with a firmware update.

ThingMagic pioneered the use of SDR for RFID applications. An SDR uses software to modulate and demodulate RF signals. It performs the majority of signal processing in the digital domain, most commonly in a DSP. SDR-based RFID readers can receive and transmit new forms of RFID communication protocols simply by running new software on existing hardware.

An SDR-based RFID reader consists of an RF analog front-end that converts RF signals to and from the reader’s antennas into an analog baseband or intermediate frequency (IF) signal, as well as A/D converters and D/A converters that convert these signals to, and from, a digital representation that can be processed in software running on the reader’s DSP.

SDR-based readers store all protocol information in software, and use protocol-neutral hardware to generate and detect radio waves. Conventional readers create protocols by adding hardware, so that changing protocols requires physically swapping out components in every reader in the field. For example, in a distribution center with 100 doors and a reader at each door, that would require swapping out components in all 100 readers. Clearly, the use of an SDR architecture can save considerable time and money.

There are other significant benefits of SDR-based readers. With the addition of standard networking capabilities, including remote management, large networks of deployed SDR-based RFID readers can be upgraded in a matter of minutes from a remote console in a customer’s network operations center, becoming instantly capable of reading new types of tags.

An SDR architecture can also be used to implement non-RFID functions. In the EU, the radio can be used to detect RF interference from non-RFID sources, a distinctly non-RFID function. This feature is called Listen Before Talk (LBT) and is required for European deployments. When operating in LBT mode, a reader first listens and tries to detect any RF signals in its channel. If it does detect such signals, it waits and tries again. If no other signals are present, the reader begins interrogating tags.

The MercuryOS

All Mercury readers run ThingMagic’s MercuryOS reader operating system. It defines the company’s implementation of SDR and enables the hardware to easily adapt to new and changing RFID tag communications standards (Figure 3). For example, MercuryOS 2.3 Tesla, released in late 2005, upgraded the large deployed base of ThingMagic’s RFID readers to use an important new RFID tag protocol, the Class 1 Generation 2 standard created by RFID standards body EPCglobal. This upgrade was certified by EPCglobal as complying with all aspects of the Generation 2 protocol, including Dense Reader Mode, which helps many RFID readers interoperate in one location.

Since Mercury readers are full-fledged network devices, they could easily be remotely updated with the Tesla upgrade. This is a key proof point for the benefits of SDR in RFID: all other non-SDR-based RFID readers had to either be replaced, or required the installation of new circuit boards, in order to work with the Generation 2 standard. The latest major upgrade to this software, MercuryOS 2.4 Yagi, is scheduled for release this month. It improves overall tag reading performance by up to 400% and enables the Mercury5 to read 180 unique RFID tags per second, far more than other RFID readers.

The MercuryOS consists of two parts: a user-programmable network operating system based on Linux, and a real-time SDR system. The network OS uses a full Linux 2.4 kernel, the same one used on many PCs and servers, but compiled for a different processor. This OS enables high-performance threading, scheduling mechanisms, memory protection and networking.

The company’s engineers also developed a Reader Query Language (RQL) server as a simple but general network protocol that allows the use of syntax similar to Structured Query Language (SQL) to perform tag operations. No client software is required other than a standard Telnet application. Additional RQL commands that are not included in SQL allow RQL to support time-based operations. The server also provides tag-specific data (id, protocol_id) as well as event metadata (antenna_id, read_count, frequency) and enables time-synchronized operations.

Developers can also use APIs, giving them a powerful way to customize Mercury readers to suit their needs, by enabling access to higher-level functions beyond what is available via RQL. Developers can write customized APIs, as well as use APIs created by ThingMagic. With the release of MercuryOS 2.3 Tesla, the ability to use Windows-based APIs is included, offering the flexibility to program in either Linux or Windows environments.

The onboard Web server supports typical Web server functionality, including CGI scripting. It can be used to serve static content such as help pages, dynamic read-only content such as status pages, forms to update settings and client-side Java applets. The Web server can be used to upload firmware, configuration files and user programs, and to perform firmware updates. The radio features of the SDR are controlled by the Mercury OS server. Protocol modules are stored in flash memory, which can be expanded to include as many additional protocols as required over time.

By using an innovative SDR-based design, networked RFID readers can be quickly and remotely upgraded with a single keystroke. This replaces the laborious handling of every deployed reader. In environments with dozens, or even hundreds, of deployed RFID readers, the upgrade efficiency delivered through SDR-based design dramatically increases ROI and maintains a reasonable total cost of ownership.

ThingMagic
Cambridge, MA.
(866) 833-4069.
[www.thingmagic.com].