Proximity Readers and LINX Products

inspectorwormsΗλεκτρονική - Συσκευές

27 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

74 εμφανίσεις



• Revision Date: November 19, 2002

䅲瑩c汥′l

Proximity Readers and

LINX Products

625 Digital Drive, Plan
o, TX 75075 Tel: (972) 964
-
7090 Fax: (972) 964
-
7643 Web Page: www.linxdata.com

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 h
urdles 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
finall
y, 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
r
adio 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 t
agging 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
techno
logy 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 a
llows 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 rea
der 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 use
d 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 prox
imity
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 usual
ly 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 tho
se 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 B
it 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 ov
erlap. 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 b
adge 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 so
lution 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 as
sign 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 i
s 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
throug
h 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 d
ecoding. 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 alg
orithms 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 se
lected. 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 rea
ders 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.