User guide
Table Of Contents
- 1. Introduction
- 2. Specifications and Requirements
- 3. Installation
- 4. System Overview
- 5. How to Set Up a Site
- 5.1 Adding Time Zones
- 5.2 Adding Holidays
- 5.3 Adding a Network
- 5.4 Adding Access Control Panels
- 5.5 Configuring the Doors
- 5.6 Configuring the Readers
- 5.7 Configuring the Inputs
- 5.8 Adding a Camera
- 5.9 Adding Panel Links
- 5.10 Creating Groups
- 5.11 Adding Users and Cards
- 5.12 Adding Departments, Users, and Visitors
- 5.13 Adding Access Areas
- 5.14 Adding Global Antipassback Rules
- 5.15 Car Parking
- 5.16 Adding Operators
- 5.17 Creating Elevator Control
- 5.18 Creating Status Maps
- 6. ViTrax™ Video Integration
- 7. Manual Operation
- 8. AxTraxNG™ Reports
- 9. Administrator Operations
- A. Firewall Configuration
- B. SQL Service Settings
- C. Network Configuration
- D. Restoring Factory Default Settings
- E. Configuring User Counters
- F. Cross Platform Camera Setup
- G. Enrolling Cards using MD-08 Desktop Reader
- H. SQL Server Installation Troubleshoot
- I. AxTrax.NET Watchdog
- J. Adding Custom Wiegand Formats

Adding Custom Wiegand Formats
AxTraxNG™ Software Installation and User Manual 135
then in reversed bits format, it is 4C 91 A6 2C, which is represented as:
01001100 10010001 10100110 00101100 in binary.
All the bits in the protocol are represented with ‘Z’.
Card number is represented in the protocol as a BCD code (each nibble
represents one decimal character). For example, if the number (decimal) is
658723, then it is represented in binary as: 01100101 10000111
00100011.
All the bits in the protocol are represented with ‘B’.
J.2 Facility Code
If supported in the card, the software must know where it is placed inside the
bit array and how many bits it takes.
Of the 5 representation options presented in J.1, only the data format can be
used with the Facility code; however, all the bits in the protocol are
represented with ‘F’ to differentiate it from regular data.
J.3 Authentication
Usually the array of bits that represents the card number also contains an
authentication mechanism that checks that the data was transferred correctly.
AxTraxNG™ supports several types of authentication mechanisms as follows:
Even Parity – One bit provides authentication to either several bits
proceeding or following it (according to the defined protocol). This bit
makes the total number of related bits an even number.
The Even Parity bits in the protocol are represented with ‘E’ and all the bits
that they verify are represented with ‘1’.
Odd Parity – One bit provides authentication to either several bits
proceeding or following it (according to the defined protocol). This bit
makes the total number of related bits an odd number.
The Even Parity bits in the protocol are represented with ‘O’ and all the
bits that they verify are represented with ‘1’.
CheckSum – The number of bits (usually 8) provides the sum of the
previous bytes.
Checksum bits in the protocol are represented with ‘S’ and all the bits that
they verify are represented with ‘1’.
CheckXor – The number of bits (usually 8) provides a logical XOR value of
the sum of the previous bytes.
CheckXor bits in the protocol are represented with ‘X’ and all the bits that
they verify are represented with ‘1’.
J.4 Creating New Rules
Using the above principles, we can create new rules for the AxTraxNG.