Recently There Has Been a Lot of Interest in Proximity Readers, and Interfacing This Particular

Introduction

Recently there has been a lot of interest in proximity readers, and interfacing this particular device with LINX products. While it can and is being done, as an integrator, it is important to understand some of the pitfalls and hurdles associated with such a task. The purpose of this memorandum is to better educate resellers on proximity readers in general, clearly state LINX's position on our support for various proximity readers with different models of our products, and finally, to point out some specific areas where care must be taken when interfacing proximity readers to LINX terminals.

Background

Proximity readers are a type of RFID technology. RFID in general can be defined as Radio Frequency Identification. Like barcode, magnetic stripe, voice recognition, and other automatic identification technologies, RFID is an information acquisition technique. In this case, a sensing device emits a radio frequency to a specially designed card. The card then responds with another radio message. While RFID and proximity use basically the same underlying technology, the market generally refers to proximity technology as strictly RFID badge readers, and the term RFID by itself is used generically to describe RFID systems that employ tagging or labeling items for automatic identification.

Currently, there are basically two types of proximity card reader solutions: passive and active. Nearly all proximity cards used for access control and time and attendance are passive. Passive technology implies there is no battery or power source required in the card. In a passive system, when the card is held within the "proximity" of the reader, an RF signal is absorbed by a coil in the card and this in turn powers a transmitter on the card that allows the card to broadcast its unique ID to the reader. In an active proximity solution there is a battery on the card. Active technology is more expensive from an initial purchase and maintenance standpoint but the range of an active card is 3-15 feet, versus the 1-5 inches of a passive card.

The physical interface of a proximity reader to a device such as a data terminal, is always natively Wiegand. Wiegand is the specifications for the electrical elements that define the transfer of data from the reader to the controller. A common misconception is that Wiegand describes the card format. This is not at all the case. Wiegand specifies power requirements/limitations, and control of devices through a clock, ones, and zeros line. These elements are used to design functional electrical circuits that connect proximity readers to other devices. Because many controllers and data collection devices, (such as the LINX line of terminals) have no native Wiegand interface, a number of manufacturers produce proximity readers with on-board Wiegand to RS-232 and Wiegand to Magstripe converters.

Once the card data physically enters the control device, in our case the data terminal, the data itself will still have to be decoded. Currently, there are no across the board standards for how the data is encoded on the cards though almost all card formats provide three pieces of information: parity bits, facility codes, and identification codes. Parity bits are used for error detection. The identification code is usually the employee ID number (and most often printed on the badge). Site codes provide a means to better manage access to particular devices and areas by restricting access in logical groupings.

The most common encoding techniques for proximity cards are those employed by HID Corporation. For the most part all encoding techniques are considered proprietary, though most vendors and manufacturers of proximity readers will offer compatibility with some HID formats. The most often employed HID formats are: 26 Bit Format, 37 Bit Format, and Corporate 1000 Format. The main difference between the 26 and 37 bit format lies in the fact that HID controls the numbers to be generated in 37 bit format, ensuring that there are no duplicates produced (this is achieved by combining the ID with unique customer specific facility codes). In 26 bit format, it is the responsibility of the organization using the cards to insure they do not order duplicate IDs and there is no assurance that another organizations' cards may not overlap. Corporate 1000 format is available only at the discretion of HID to customers who can show a need for an unusually large number of cardholders.

In all cases, some amount of manipulation must be performed on the incoming data stream to extract the badge number and, if applicable, the facility code.

Proximity Readers and LINX Devices

LINX ETC- Has no means to support a proximity reader.

LINX II, III, IV, and V- Can support a proximity reader via the serial port. However, there is no generic coding solution that supports this. Depending on the proximity reader used and the type and amount of data being encoded on the card, interfacing can be tricky through LinxBASIC. LinxBASIC has no inherent data types or commands that support bit level manipulation and this type of processing seems to be common in decoding proximity cards. Furthermore, some of the cards allow card numbers that would require a double (double refers to a double precision floating point value, usually stored as 8 bytes) to directly assign them to a LINXBasic variable. LinxBASIC has no double data type and therefore these numbers must be split into two, manipulated separately, and then reassembled and represented as ASCII encoded binary. The end result is that while some of the code is reusable, a portion of it will probably have to change with each implementation. The amount of familiarity with LinxBASIC required to successfully use a proximity reader on LINX II, III, IV, and V is significant. Bringing the prox reader data in through a magstripe port, speeds up the handling somewhat since a portion of the initial coding sequence when interfacing via RS-232 is simply retrieving the data from the COM port. However, once brought into the terminal, the data still requires some type of decoding. On some magstripe prox solutions, specifically Keri, the amount of decoding required is minimal, but only when using the Keri card format. If you use the Keri reader model which decodes HID cards, then you must go through all the same decode algorithms required to decode HID cards. Be aware that using proximity readers with magstripe interfaces requires LINX to make modifications to the I/O board.

LINX VI- Can support a proximity reader via the serial port. Programming languages for the LINX VI are more flexible than LinxBASIC so the coding task is much easier, though still more difficult than many application level programmers are used to.

LINX VII/VIII- Will support a specific vendor's proximity cards natively. This vendor has not yet been selected. What we do know is that even when selecting a vendor such as HID, there are still multiple encoding standards available within any vendor's card offerings. Vendors generally recommend that you do not attempt to auto-detect the encoding being used, so we will probably fire off an event to a .NET container application indicating that a card is available, and then hand off the raw data to the application. Decoding a raw packet within the .NET programming environment will prove a much more manageable task, and here LINX may be able to provide some helper functions since we will have much more control and flexibility. (i.e. The developer sets a property saying which HID card type he is decoding and then we can present a .ToString method which will get the badge ID out of the raw stream.) With the LINX VIII in particular, many resellers may choose to implement the proximity reader as an external device that comes through the PS2 port as keyboard data since this requires no custom .NET components. This solution will require some decoding unless the prox reader is being used strictly for log-on to the machine (a lot of these types of utilities already exist), but the decoding should be insignificant.

Conclusion

While an exciting technology, proximity readers are for the most fairly proprietary in nature. Therefore, at this point LINX Data Terminals, Inc. can only offer its resellers support and consultation when interfacing our existing line of terminals with the various proximity devices on the market. Once LINX VII and VIII are available, we will offer an integrated solution, but utilizing this solution will require the customer to use a specific card or cards of a LINX defined encoding format. If you or your customers select a card format other than the LINX-supported one, you will be "on your own", although advice could and would be available from LINX. We will not however accept coding tasks associated with your card format selection.