Issue
Using access card types not natively supported by Continuum system
Product Line
Andover Continuum
Environment
- CyberStation
- CX9900/9940
- CX9702
- CX9680
- ACX5740/5720
- ACX701
- ACX781
Cause
Continuum has built in support for the most widely used Wiegand card types, occasionally a site might be using a card type for which Continuum has not built in support. In such cases the system must be configured using custom card functionality.
Resolution
Setting Up a Custom Wiegand Format
A custom format must be used when the card format is not one of the standard pre-defined formats. Only one custom format can be used in an ACX7xx controller and NC1(CX99xx), NC2(CX968x) using AC1 modules, up to four custom formats can be used with the ACX57xx and NC1/NC2 using AC1Plus modules.
- In each ACX700 and ACX780/781, NC1, NC2, ACX57xx create an InfinityNumeric point called AccessFormat (use this spelling exactly!). During the creation process, attach a manual array (log) with 22 entries to the point. If using more than one custom card definitions create InfinityNumeric points called AccessFormat2, AccessFormat3 and AccessFormat4
- Create the following InfinityProgram in each controller. The program should be type FallThru, and AutoStart. This program basically saves you from having to set each array value individually for each controller. The program, once created, can be copied to all other access controllers that need it.
In the following example the AccessFormat array is setup to allow the system to read the HID Corporate 1000, 35 bit card.Program Name: SetCustCrdArray FlowType: FallThru AutoStart: True Code: Set AccessFormat[1] to 35 ‘overall number of bits Set AccessFormat[2] to 0 ‘control mask Set AccessFormat[3] to 0 ‘ manufacturer’s code Set AccessFormat[4] to 0 ‘ start bit of man. Code (first bit is 0, not 1) Set AccessFormat[5] to 0 ‘ end bit of man. code Set AccessFormat[6] to 2 ‘ start bit of site code (NOTE: If the card has no site code set this field to 0) Set AccessFormat[7] to 13 ‘ end bit of site code (NOTE: If the card has no site code set this field to 0) Set AccessFormat[8] to 14 ‘ start bit of card number Set AccessFormat[9] to 33 ‘ end bit of card number Set AccessFormat[10] to 0 ‘ odd parity mask, first 16 bits Set AccessFormat[11] to 0 ‘ odd parity, next 16 Set AccessFormat[12] to 0 ‘ odd parity, next 16 Set AccessFormat[13] to 0 ‘ odd parity, next 16 Set AccessFormat[14] to 0 ‘ even parity, first 16 Set AccessFormat[15] to 0 ‘ even parity, next 16 Set AccessFormat[16] to 0 ‘ even parity, next 16 Set AccessFormat[17] to 0 ‘ even parity, next 16 Set AccessFormat[18] to 0 ‘ card number multiplier Set AccessFormat[19] to 0 ‘ card number divisor Set AccessFormat[20] to 0 ‘ start bit of issue code Set AccessFormat[21] to 0 ‘ end bit of issue code Set AccessFormat[22] to 0 ‘ decimal shift of issue code
- In each Door Configuration, select the Custom Wiegand card type. Other card types may also be selected.
- For each Personnel, select the Custom Wiegand card type, and enter the correct card number and site code.
If the card is not working, check the Event Log and determine the cause. For Invalid Card Parity errors, set all the parity masks to 0 and try again. For proximity cards, the parity check may be eliminated with little consequence.
NOTE: In controllers that support the HID Corporate 1000, 35 bit card natively (NC2 – CX968x and ACX2 – ACX57xx) the AccessFormat numeric is internally used by the system, any other custom card definitions must use AccessFormat2 – AccessFormat4
Control mask
Some Wiegand cards are encoded with the bits in one or more fields reversed and/or complemented. It is then necessary to operate on the fields when decoding the data in order to obtain the correct data.
In the AccessFormat array a control field is provided to configure the system so that the bits in a field in the access card data can be reversed and/or complemented.
The control mask is located at AccessFormat[2]
Control Mask
The bits of the control mask are used by the parsing routine in the controller to reverse or complement selected fields. Setting the appropriate bit to a 1 will enable the special action:
Example: To reverse the bits in the site code field set AccessFormat[2] = 8
Parity mask calculation
The table below shows the card format information provided by the manufacturer of a 32 bit Wiegand card. From the information provided by the manufacturer we can deduct the flowing about the format of the data on the card:
- The card data is comprised of the following 3 fields
A = Customer Code
B = Facility Code
C = Card Number - Bits 0 through 16 make up the even parity field. (The ‘X’ indicates that the bit is part of the even parity field)
- Bits 15 through 31 make up the odd parity field.
Note the overlap in the fields (bits 15 and 16 are members of both the even and odd parity fields), this is common as the fields are arbitrarily assigned by the card manufacturers.
Armed with the information provided by the manufactures we can calculate the parity mask which Continuum will need to use in order to perform the necessary parity check upon receipt of the card data transmitted by the card reader.
First, calculate the EVEN parity mask.
To better illustrate how the calculation is done we have added a new row to our table, in this row we are going to enter the even parity mask as a binary number.
What we do is write a 1 (one) in each bit that is a member of the even parity field and a 0 (zero) for bits that are not part of the even parity field.
The second step is to divide the bits that make up the field into groups of 4 which will make it easier to convert the binary number in the previous row to a hexadecimal number.
The even parity mask for this card is 0xFFFF8000
It should now be obvious how Continuum uses the mask when checking for even parity.
Upon receipt of the card data transmitted from the reader, Continuum applies the mask to the full 32 bit stream of data received, (a logical AND operation is performed) the mask acts like a filer that allows only the set bits in the even parity field to pass through, now all Continuum has to do is count the bits that passed through the filter and make sure the count is an even number, if the count is not an even number Continuum sends a parity error.
The Odd parity mask is calculated using the same procedure.
Here is an example for the calculation of the parity masks for a 35 bit card
A = Company ID Code
B = Card Number
P= EVEN PARITY
Even Parity Mask
0x76DB | (30427) |
0x6DB6 | (28086) |
0xC000 | (49152) |
0x0000 | (0) |
P = ODD PARITY
Odd Parity Mask
0x6DB6 | (28086) |
0xDB6D | (56173) |
0xA000 | (40960) |
0x0000 | (0) |
After calculating the parity masks you enter the decimal numbers into the appropriate fields in the AccessFormat array.
S = Site Code
C = Card Number
P= EVEN PARITY
Even Parity Mask
0xFFFF | (65535) |
0XE000 | (57344) |
0x0000 | (0) |
0x0000 | (0) |
P = ODD PARITY
Odd Parity Mask
0xFFFF | (65535) |
0xFFFF | (65535) |
0xF000 | (61440) |
0x0000 | (0) |
IMPORTANT:
If a custom card is configured with a bit count that is the same as the bit count of one of the cards that are supported natively, the parity masks MUST be entered in the AccessFormat array in order for the controller to be able to parse the custom card correctly, if not parity masks information is entered, the controller will generate an 'Invalid attempt, bad parity' event when the custom card is presented at the reader.