Home Internet of Things Aerospace Apparel Energy Defense Health Care Logistics Manufacturing Retail

The State of Reader Interfaces

UHF RFID companies can do more to ease the job of application developers.
By Ken Traub
Jul 21, 2014

While I was at RFID Journal LIVE! in April, I visited most exhibitors of passive ultrahigh-frequency RFID to assess how their products support software development. I focused especially on the ease with which application software can get the data it needs from RFID readers. This is crucial to allow developers to focus on the business side of their applications.

GlobeRanger, InSync Software, OATSystems and RFID Global Solution each offered mature middleware—software that interfaces with readers and provides a sophisticated environment for creating RFID-based applications. Each vendor markets to specific industries, which promotes adoption in those verticals. But application developers in other sectors may not realize they could use one of these middleware products as well.

Developers can also interface directly with readers to build applications, but three of the four options available have disadvantages. Most readers have a proprietary interface, application toolkit or application programming interface (API). These are relatively easy to use, but change your reader vendor and you have to rewrite all the code that "talks" to the reader.

For this reason, many readers also support GS1's Low Level Reader Protocol (LLRP), a standard interface that is the same regardless of vendor. But as the name suggests, this is a low-level interface, which means managing even a simple tag read is complex. Many of the vendors I spoke with reported that few customers use LLRP.

Another type of low-level interface supported by some readers is called a "wedge," which is good for an application that reads a single tag when a user presses a button. The wedge interface delivers the tag contents to a host computer in a way that simulates keyboard input.

All three of these interface types share a big disadvantage: The application gets just the binary contents of the tag's Electronic Product Code (EPC) memory. But an application needs to have the data decoded as an application-level identifier—for example, a Serialized Global Trade Item Number (SGTIN). An interface giving an application the binary contents is like a bar-code reader providing only the pattern of black and white bars without decoding it.

The fourth kind of interface is based on another GS1 standard called Application Level Events (ALE). Using ALE, the application just states what data it wants. ALE delivers the data fully decoded, in a format most application programming languages are designed to understand.

Only a few vendors I spoke with—notably Harting and Mojix—said their readers support ALE; Intermec and Motorola (now Zebra) offer limited support on some models. Many vendors had not heard of ALE or did not understand its benefit to application authors. I think this is a shame, because readers with the ALE standard could help foster RFID adoption and the development of innovative applications.

Ken Traub is the founder of Ken Traub Consulting, a Mass.-based firm providing services to com­panies that rely on advanced software technology to run their businesses. Send your software questions to swsavvy@kentraub.com.

  • Previous Page
  • 1
  • Next Page

Login and post your comment!

Not a member?

Signup for an account now to access all of the features of RFIDJournal.com!

PREMIUM CONTENT
Case Studies Features Best Practices How-Tos
RFID JOURNAL EVENTS
Live Events Virtual Events Webinars
ASK THE EXPERTS
Simply enter a question for our experts.
TAKE THE POLL
JOIN THE CONVERSATION ON TWITTER
Loading
RFID Journal LIVE! RFID in Health Care LIVE! LatAm LIVE! Brasil LIVE! Europe RFID Connect Virtual Events RFID Journal Awards Webinars Presentations
© Copyright 2002-2014 RFID Journal LLC.
Powered By: Haycco