Page Comparison

ScramblePad/MATCH Inputs

The typical ScramblePad or MATCH input terminal block provides the connection between the controller and a ScramblePad or MATCH Interface.
An example of such a connection is shown in Figure 1-9.

Figure 1-9: ScramblePad/MATCH Inputs

Table 1-6 shows absolute maximum cable distances allowed in feet and meters between the controller and any one or two ScramblePad combinations according to wire gauge:

Table 1-6: Maximum Cable Distances Between Controller and ScramblePad

In Table 1-6, the DS47L/DS47L-SPX keypads are abbreviated as L and the DS47L-HI (or weatherized version DS47L-HW) are abbreviated as H. The MATCH Interface is abbreviated as M. Items followed by asterisks (*) indicate cable capacitance must not exceed a total of 100,000 pƒ.

Table 1-7 shows absolute maximum cable distances in feet and meters between the controller and any MATCH and/or 1 or 2 ScramblePad combinations according to wire gauge:

Table 1-7: Maximum Cable Distances Between Controller and MATCH

In Table 1-7, the DS47L/DS47L-SPX keypads are abbreviated as L and the DS47L-HI (or weatherized version DS47L-HW) are abbreviated as H. The MATCH Interface is abbreviated as M. Items followed by asterisks (*) indicate cable capacitance must not exceed a total of 100,000 pƒ.

Table 1-7 is applicable for MATCH-powered 5VDC readers, as allowed by the MATCH Interface’s 28V/5V switch power supply efficiency. A reader drawing 200 mA at 5VDC translates to only about 40 mA at the MATCH Interfaces’s 24VDC input side. Because the MATCH uses a switching power supply, the load presented by two 5VDC readers is no greater than that for one 5VDC reader. Therefore, this table is valid whether one or two readers are powered by the MATCH Interface.

Overall shield or individual shielded pairs are acceptable. Color coded cable – black, red,green, white – is recommended. Pair one, the black and red wires, provides power to the ScramblePad or the MATCH Interface; pair two provides data communications between the Controller and the ScramblePad or MATCH Interface.

If two ScramblePads are installed at the same door – one for entry and the other for exit – they can share the same cable run. Connect the second ScramblePad to the removable connector of the first ScramblePad. For longer cable runs, provide a local auxiliary power supply to the ScramblePad or MATCH Interface.

• An Mx controller provides 12VDC power at the Wiegand terminal blocks, and 24VDC at the MATCH terminal blocks. For additional information, see “ScramblePad/MATCH2 Power Requirements”.

• AnMx-1or Mx-1-ME controller provides 12VDC power at its two Wiegand reader terminals, and 12VDC at its RS-485 OSDP readers terminal. (For the Open Supervised Device Protocol (OSDP), when an optional exit reader is needed, it is wired “through” the entry reader.) For additional information, see “Mx-1 Controller Power Draw Capacity”, or “Mx-1-ME Controller Standby Battery Capacity”.

Expansion Board Options

Several expansion boards are available for Mx series controllers. Expansion boards are used to enhance or expand the controller’s capabilities.

• For information about the expansion boards available for the Mx controller, see “Expansion Boards for the Mx Controller”.

• For the Mx-1-ME controller, see “Expansion Boards for an Mx-1-ME Controller”. (The Mx-1 controller has a compact plastic case which does not have room for any expansion boards.)

The ribbon cable used to connect these boards to the Controller board is the EBIC5, which can link up to five expansion boards.
All expansion boards have the same dimensions and shipping weight:

For detailed information about the setup and installation of expansion boards, see “Expansion Board Installation”.

Memory Expansion Boards

There are two different memory expansion boards available for Hirsch controllers: the MEB/CB64 and the MEB/CB128.

The MEB/CB64 supports 64,000 user records, expands the alarm and event buffers, or provides a combination of both records and buffers. This means that a portion of memory can be allocated to storing users while the remainder is used for buffering events. Normally, it takes twice as much space to store a user profile as it does to store an event (for example, the board can store two users or four events). Hirsch’s velocity security management program supports an option to allocate 20% of the board to alarm/event buffer usage. This option is irreversible.

The MEB/CB128 supports up to 128,000 users, expands the alarm and event buffers, or provides a combination of both users and buffers.

Install only one Memory Expansion Board type for code expansion in a controller at a time.

Figure 1-10: Memory Expansion Boards (MEB/CB128 and MEB/CB64)

The newer CCM V7.0 can diminish the number of events that an expansion board can successfully buffer, because the event string is up to four times longer. For example, a buffer that could comfortably store 4,000 events with the previous CCM (V6.6 and earlier) now buffers only 1,000 events using the V7.0 CCM.

CCM 7.0 now supports increased User and Alarm/Event capacity for up 132,000 user records. With CCM 7.0, the capacities of the Expansion Boards are additive, rather than in lieu of the base memory.

Neither the MEB/CB64 nor the MEB/CB128 are supported by CCM 6.x. They must be installed in controllers equipped with CCM 7 boards.

Older boards—the MEB/CE4, MEB/CE16, MEB/CE32, and MEB/BE—still work with CCM 7.0, but at reduced capacities. If a controller has one of these boards and is upgraded to CCM 7.0, it might also be necessary to upgrade the memory expansion boards. Upgrading memory boards can provide the added benefit of increasing expansion board capacity, because the Code Expansion (CE) and Buffer Expansion (BE) can now reside on a single board—the MEB/CB64 or the MEB/CB128.

Table 1-8 describes the maximum user capacities for each memory board type as a function of both IDF and CCM version. Note that your system’s actual capacity could be less, as explained in “Velocity Features that Reduce Available Memory”.

Table 1-8: Memory Board User Capacities

Maximum User Capacities	CCM 6.6 IDFs 1, 2, 3	CCM 6.6 IDFs 4, 5, 6	CCM 6.6 IDF 7	CCM 7.0 All IDFs
Base Controller	1,000	500	250	4,000
With CE4	4,000	2,000	1,000	5,000
With CE16	16,000	8,000	4,000	8,000
With CE32	32,000	16,000	8,000	20,000
With CB64	N/A	N/A	N/A	68,000
With CB128	N/A	N/A	N/A	132,000

The allocated user memory is the memory that is currently dedicated to users. The projected maximum user capacity is the amount of memory the CCM can auto-allocate to users as additional users are enrolled. 1024 is the base allocated user memory. If you add more than 1024 users, more memory is allocated in units of 256. So, if you add 1025 users, it increases the total memory to 1280; if you add 1281 users, it increases it to 1536, and so on.

There is a feature in Velocity that enables the operator to allocate 20% of MEB/CB expansion memory to the buffer. If the operator selects this setting, the host buffers increase the capacity and the projected maximum user capacity is slightly lower. The minimums are then 1560 buffer events and 1024 users. These values do not decrease, no matter how much extra memory is allocated.

For information about setup and installation of the memory expansion boards, see “Memory Expansion Boards Installation”.

Note
Removing an installed memory expansion board from the controller will lose all codes.

Velocity Features that Reduce Available Memory

---

There are several places in this document which list the capacity of the various controllers and memory expansion boards to support user records or alarms and events. These capacities assume that you are running a version of Velocity which only uses data structures of a certain size. Your system’s capacity could be reduced by up to 50% when using any of the following features (which require larger data structures):

Feature	Initially Released in
Timed anti-passback	Velocity 3.1 and CCM/CCMx firmware 7.4.25
Multiple access zones	Velocity 3.6 and CCM/CCMx firmware 7.5.28
PIV, PIV-I, or PIV-C cards	Velocity 3.6 SP2 and CCM/CCMx firmware 7.5.64

Alarm Expansion Boards (AEB8)

---

To expand the line module input capacity of the controller, use the Alarm Expansion Board (AEB8). These provide an additional 8 line module inputs per board.

Expansion line module inputs are used for a variety of security monitoring functions. In intrusion detection applications, they normally monitor interior motion sensors, perimeter doors and windows for forced entry or intrusion into a protected area; however, they are generally not employed for door access control applications.

Each line module input, whether connecting to a base alarm on the controller board or an expansion alarm on an AEB8, must be routed through a line module.

Up to four AEB8s can be installed in a controller.

Figure 1-11: Sample AEB8 Board

The wiring and settings of the AEB8 are shown in Figure 1-12.

Figure 1-12: Alarm Expansion Board (AEB8)

As Figure 1-12 shows, the shield should be floated at the line module. Also, it is recommended that line module inputs be wired NC.

The AEB8 has four address jumpers. Each jumper allocates a range of eight addresses. This addressing scheme enables up to four AEB8's to reside in one controller. (For the M16, which has 16 inputs on the base controller board, two additional AEB8s can be added to the controller for a total of 32 inputs.)

For more about line module inputs, see “Request-To-Exit Devices (RQE)”. For more information about DTLM, MELM, and SBMS3, see “Line Modules”. For information about setup and installation of the AEB8, see “Alarm Expansion Board (AEB8) Installation” .

Relay Expansion Boards (REB8)

---

To expand the control relay capacity of the controller, use the Relay Expansion Board (REB8). This provides eight additional 2 Amp Form C dry relay outputs, rated for 24VDC. These relays are socketed and removable.

Figure 1-13: Relay Expansion Board (Physical View)

Up to five REB8s can be installed in an Mx or Mx-1-ME controller.
The wiring and settings of the REB8 are shown in Figure 1-14.

Figure 1-14: Relay Expansion Board (REB8)

Unlike the large heavy-duty door relays used to switch electric lock or strike power at 10 Amp loads, the expansion relays are normally used for signal level switching or pilot duty. Such switches, when closed, provide an input to a low-voltage sensing circuit like the one shown in Figure 1-15:

Figure 1-15: Alarm or Pilot Relay Circuit For Low-Power Switching

Some sensing circuit terminals also provide a power source. In this case, a separate power source (marked by an asterisk in Figure 1-15) is not required.

However, the switch can also be used to activate the coils of a remote heavy-duty relay like this:

Figure 1-16: Remote Relay Circuit for Heavy-Duty Output Device

The examples above connect across the NO and C terminals so no power is consumed when the device is in the normal state. This is the case in applications like elevator control where the control relays provide a contact closure to elevator control equipment only.

There is almost no distance limitation for the cable between the REB8’s terminal block and an isolation relay. If a powered device is being activated or energized, use the ScramblePad distance limitations (see Table 1-6 in section “ScramblePad/MATCH Inputs” as a good measure of distance capability. However, for accuracy, voltage drop calculations should be made for the specific load, cable, and distances involved, similar to lock calculations in section “Typical Door Relay Outputs”.

The REB8 is equipped with a Master Relay Override DIP switch. This switch can override all relays ON or all relays OFF. In the OFF position, relays cannot be activated by the controller until the Master Override OFF is returned to the normal operating position.

For information about the setup and installation of the REB8, see “Relay Expansion Board (REB8) Installation”.

RS-485 Readers Expansion Board (RREB)

---

The RS-485 Readers Expansion Board (RREB) is the component of Identiv’s end-to-end FICAM solution which provides eight independent RS-485 communication ports, for fast processing of PIV or PIV-I credentials at FICAM-compliant smart card readers (which are part of a physical access control system) using the bi-directional Open Supervised Device Protocol (OSDP). Each port is capable of supporting a door with both an entry reader and an exit reader.
The following figure shows an RREB, and identifies its connections.

Figure 1-17: Connections on the RS-485 Readers Expansion Board (RREB)

Government agencies transitioning from a traditional PACS to FICAM will need to replace their old readers and upgrade their version of the Velocity software, but the RREB (in conjunction with the SNIB3) enables them to reuse their existing wires and door controllers (including the M2, M8, and Mx series). The RREB:

• provides the necessary connections to FICAM-compliant smart card readers (which are part of a physical access control system), for two-way communication with the SNIB3 communications expansion board

• uses standard RS-485 wiring (two-pair stranded and twisted 18 AWG wires, with an overall shield) to readers

• has the same form factor as other expansion boards, and draws power through the controller’s EBIC5 ribbon cable

Example Wiring Diagram for an RREB

---

The following figure shows an example wiring diagram for an RREB and a pair of Identiv’s uTrust TS Government Readers, which are the entry reader and the optional exit reader for a door. Note that:

• The exit reader is wired through the entry reader for a door, so it shares an RS-485 port on the RREB.

• On the exit reader, a jumper wire is needed between P1.1 and P1.4 (or between the orange and the black wires on the pigtail model) to designate that it is the exit reader.

• All of these readers have a default OSDP Address of 0, which is the correct value when they are used as the entry reader for a door. If a door also requires an exit reader, then adding a jumper wire between P1.1 and P1.4 (or between the orange and the black wires on the pigtail model) changes the default OSDP Address to 1, which is the correct value for an exit reader. Be sure that you specify the correct OSDP
  Address when you configure each reader in a FICAM-capable version of the Velocity software.

• The diagram shows power being supplied to the readers from the RREB. But depending on the types and quantity of readers being used, you might need to power some of the remotely located readers from an external power supply. For more information, see “Power Provided at the RREB’s RS-485 Terminal Blocks”.

Figure 1-18: Example Wiring Diagram for an RS-485 Readers Expansion Board (RREB)

The following table lists Identiv’s FICAM-capable High Frequency TS readers (which appear in the Readers > uTrust TouchSecure > Government FICAM category of the Product Catalog for Hirsch by Identiv Physical Access Control Solutions).

Figure 1-20: SNIB2 Board

The SNIB2 includes an RS-232 and RS-485 as well as an Ethernet port. In addition, SNIB2 supports full encryption from the host to the last downstream controller. The SNIB2 also offers XBox functionality with support for global I/O from the master SNIB2 downstream to all attached slave SNIB2s. The SNIB2 supports both an Ethernet or RS-232 connection between the host PC and the master SNIB2. Downstream connections from the master SNIB2 to slave SNIB2s must be RS-485.

The SNIB2 is a controller-resident communication board that enables a host PC running Velocity (version 2.6 SP2 or higher) to program, monitor, and control up to 63 SNIB2-resident controllers per SNIB2 Ethernet port. A NET*MUX4 is required whenever there are more than 16 controllers. Additional NET*MUX4s may be required to ensure that there are never more than 16 controllers per port.

Figure 1-21: SNIB2 Connections

For more information, see “SNIB2 Cabling”. Each connected controller must have its own SNIB2 (or SNIB3) board installed. The SNIB2 provides RS-485, RS-232, and 10/100BaseT Ethernet ports. The SNIB2 supports the XNET2 protocol.

Physically, the SNIB2 board differs from the original SNIB in that it has:

• Three switch banks (SW1, SW2, and SW3)

• An Ethernet RJ-45 connector with its accompanying daughterboard

• Three pairs of status LEDs (see “Controller and SNIB2 LED Diagnostics”)

With the SNIB2 board, a host PC running Velocity can program, monitor, and control up to 63 controllers with NET*MUX4 (as shown in Figure 1-22), or up to 16 without NET*MUX4. The SNIB2 provides a downstream/multi-drop RS-485 port as well as an upstream 10/100 Mbps Ethernet port and an RS-232 port for direct host connections (not dial-up).

Figure 1-22: SNIB2 to Controller Using a NET*MUX4

If required, you can add a second level of NET*MUX4s to create additional controller runs; however, Hirsch does not support more than two levels of NET*MUX4s.

Figure 1-23: NET*MUX4 Second Level Support

Benefits of SNIB2

The SNIB2 provides these functional advantages over the original SNIB:

• AES encryption

• Ethernet connectivity (if required)

• XBox functionality

• Higher serial communication speeds

Each of these features is explained below.

AES Encryption
The SNIB2 employs AES-Rijndael asymmetric 128-bit block data encryption.

The National Institute of Standards and Technology (NIST) has awarded the SNIB2 AES Certificate #280.

Ethernet Connectivity
A standard RJ-45 Ethernet port is included on the SNIB2. This enables the connected controller installed with a SNIB2 to communicate with the server using TCP/IP over 10BaseT or 100BaseT Ethernet networks. This eliminates the need for external device servers for LAN connectivity.

XBox Functionality
The SNIB2 also incorporates full XBox gateway functionality, thereby eliminating the need for an XBox. This enables the SNIB2 to function as a gateway for up to 63 controllers (with inclusion of the NET*MUX4), and provides the ability to globalize certain features.

Globalizing is the task of connecting two or more controllers so credential user management and control zone information can be shared amongst all connected controllers.

Globalization can only be performed within a local XBox node. One SNIB2 acting as an XBox cannot talk to and share information with another XBox or another master SNIB2.

Higher Serial Communication Speeds
Communications between multidropped SNIB2s are now supported at speeds up to 115,200 bps with Cat5/Cat6 cable.

When using one or more NET*MUX4s, the maximum SNIB2 speed is limited to 9600 bps. When combining SNIBs and SNIB2s, the maximum speed is limited to the lower SNIB speed – that is, the lowest speed that all connected devices have in common.

Communications become less robust as baud rates increase, wire gauge decreases, and distances increase. Most tables for wire gauge and distance in this document are based on 9600 bps.

At higher baud rates, maximum distances are decreased and minimum wire gauge is increased. It may not be possible to implement the higher baud rates supported by the SNIB2 if you have long wire runs or small wire gauges.

For more information about setup and wiring of any SNIB board, see “Secure Network Interface Boards (SNIB2 or SNIB3)”. For installation instructions, see “Secure Network Interface Board (SNIB2 or SNIB3) Installation”.

SNIB2 Network Configuration Options Overview

The SNIB2’s Ethernet port provides high-speed TCP/IP communication over an Ethernet network between the host computer and the controller as shown in Figure 1-24.

Figure 1-24: SNIB2 Ethernet Connection Using XNET2

In a multiple controller sequence, the configuration can look like Figure 1-25.

Figure 1-25: Multiple Controller Sequence Using SNIB2

This enables communication between the controller with the master SNIB2 and host PC at 10/100BaseT. Speeds between the master SNIB2 and other connected downstreamSNIB2s range up to 115200 bps when using Cat5/Cat6 cable. Speeds between a master SNIB2 and downstream SNIBs are limited by the top speed of the older SNIBs (38400 bps).

Higher baud rates are also more dependent on the number of twists per foot, so capacitance specifications must be strictly followed: total wire run per port is not to exceed a total of 100,000 pf.

Before the Velocity server can communicate over Ethernet with a SNIB2, you must first configure the SNIB2 through Velocity. For more about this, refer to “Configuring a Master SNIB2 in a Different Subnet”.

Whenever an Ethernet connection is employed between the host and the SNIB2, Velocity views the SNIB2 as an XNET port because the SNIB2 includes XBox functionality. The host communicates with the Ethernet-connected SNIB2 using AES-encrypted XNET 2.

Controller-to-controller speeds range from 9600 to 115200 bps. For each string of controllers, the first (master) SNIB2 with the Ethernet connection must be assigned the same address as the XBox port.

For more about this, refer to “Configuring a Master SNIB2 in a Different Subnet”.

SNIB3

The Secure Network Interface Board v3 (SNIB3) is an update to the previous SNIB2 board. The SNIB3 is based on a new, more powerful hardware platform that supports IPv6 as well as IPv4.

The SNIB3 also supports more robust encryption (with a 256-bit key length) through the XNET3 protocol. For compatibility with older SNIB2-equipped controllers, the SNIB3 can run in XNET2 mode using 128-bit AES encryption. (If you are using SNIB2 boards in some of your controllers, you cannot use the XNET3 protocol, and those controllers must be downstream slaves to a master SNIB3, connected using the RS-485 port, as
shown in Figure 1-28.)

The SNIB3 includes one available RJ-45 Ethernet port (connector 1) that is used to connect the Velocity host to this board. When the SNIB3 is in a master configuration, it supports RS-485 serial connectivity to downstream SNIB2 or SNIB3 slave controllers.

The main components of the SNIB3 are shown in Figure 1-26.

Figure 1-26: Main Components of the SNIB3 Board

Benefits of the SNIB3

The SNIB3 provides these functional advantages over the previous SNIB2:

Faster Ethernet Speed
The standard RJ-45 Ethernet port included on the SNIB2 enables the connected controller to communicate with the Velocity host using TCP/IP over 10BaseT or 100BaseT Ethernet networks. The SNIB3’s RJ-45 Ethernet port is capable of 10BaseT, 100BaseT, or 1000BaseT (gigabit) speeds.

IPv6 Addressing
The SNIB3 supports version 6 of the Internet Protocol, which uses 128-bit addresses to identify and locate devices on the Internet. (The previous IPv4 used 32-bit addresses.)

AES Encryption with 256-bit key length
The SNIB3 supports more robust encryption (with a 256-bit key length) through the XNET3 protocol. For compatibility with older SNIB2-equipped controllers, the SNIB3 can run in XNET2 mode using 128-bit AES-Rijndael asymmetric data encryption.

FIPS 140-2 Certification
The SNIB3’s cryptographic modules use the OpenSSL library, which has been certified by the National Institute of Standards and Technology (NIST) to meet their Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules. (The Velocity software uses Microsoft’s BCRYPTPRIMITIVES library, which also has been certified by NIST to meet FIPS 140-2.)

Hardware Security Authentication Module (SAM)
The SNIB3 has a Security Authentication Module (SAM) for securely storing keys. One application for this module is to secure firmware downloads, using a TRN format as used on Touch Secure readers. In this method the firmware is first verified for authenticity by using the SAM keys before downloads are allowed.

SNIB3 Power Rating

SNIB3 Network Configuration Options Overview

Be aware that the SNIB3 is backwards compatible with the SNIB2, but not with the original SNIB. Each connected controller must have its own SNIB2 or SNIB3 board installed. The SNIB3 provides both an RS-485 port and a 10/100/1000BaseT RJ-45 Ethernet port.

If you are using only SNIB3 boards in all of your controllers, you can use either the XNET2 or the XNET3 protocol, and the downstream controllers in your security network can either be connected directly using the RJ-45 Ethernet port, or be connected to a master

SNIB3 using the RS-485 port. These options are shown in Figure 1-27.

Figure 1-27: Example Network Configurations Using Only SNIB3 Boards

If you are using SNIB2 boards in some of your controllers, you cannot use the XNET3 protocol, and those controllers must be downstream slaves to a master SNIB3, connected using the RS-485 port, as shown in Figure 1-28.

Figure 1-28: Example Network Configuration Using SNIB2 and SNIB3 Boards

The SNIB3 also supports connections to the NET*MUX4,as explained in“Using NET*MUX4s with SNIB3s”. This enables more controllers to be managed through a single network port, but it limits the data communication speed to 9600 baud.

Power Supplies

Locks and other output devices require separate power supplies to function. While DIGI*TRAC or Mx series controllers can power a number of ScramblePads and MATCH interfaces (see “ScramblePad/MATCH Inputs” for more information), a separate power supply can be used to power ScramblePads and MATCH interfaces which require more current than the controller can provide.

When using an external power supply, make sure that it is UL-listed and has the required capacity.

Powering ScramblePads/MATCH Interfaces Locally

Ordinarily the controller provides sufficient power to operate attached ScramblePads and/ or MATCH interfaces; however, there are conditions which require more power than the controller can supply. This usually occurs when readers connected to the MATCH draw more current or require a different voltage than the MATCH can supply, or if the wire run between the Controller and the MATCH is more than 1800 feet (549 meters).

When this happens, connect a local 24V DC power supply to the ScramblePad or MATCH’s connector as follows:

• Use the black wire from the controller. Do not use the red wire.

• Wire from the power supply to the respective G and + terminals on the ScramblePad or MATCH.

Figure 1-29 provides a view of this arrangement:

Figure 1-29: Powering the ScramblePad Locally

Figure 1-30: Powering the MATCH Locally

When powering locks and other output devices, always read the device’s manual before proceeding.

For information about using power supplies to power locks, see “Locks/Strikes”. For information about powering other output devices, see “Remote Output Components”.

For more detailed information about local power, see “Powering ScramblePads/MATCH Interfaces Locally” and see “Powering the MATCH Locally”.

Using the PS2 Power Supply

The PS2 power supply is a companion product to the DIGI*TRAC Controllers. It is designed to power electrified locks or magnetic locks and provide auxiliary power to ScramblePads and MATCH interfaces. The PS2 incorporates several unique features:

• High inrush capacity, up to 16 Amps current on each of its two powered outputs. This enables the PS2 to be used to power the Von Duprin electrified Panic Devices as well as other electrified locking hardware with heavy surge requirements.

• Continuous duty holding current capacity is limited to 500 mA total or 250 mA from each powered output. This covers most 24V DC locks on the market.

• Dual battery standby packs – one for the controller and one for the locks. Both batteries must be installed to operate surge locks. Both batteries share the responsibility of unlocking locks and operating controllers during AC power failure. They are float charged by a unique circuit that balances power demand between controller operation and lock operation to maximize the charge rates at all times.

• Power connector for locally powering ScramblePads or MATCHs at the controlled door. PS2-supplied keypad power is 500mA @ 28VDC.

• The optional PS2H adds high security supervision on a lock relay cable run. This prevents bypassing of the access control system by shorting the lock cable to cause the lock to actuate, or by jumping the cable with a battery strong enough to unlock the lock.
  

Image RemovedImage Added

Figure 1-31: Illustration of the basic PS2 Power Locking System wiring plan

As shown in the above diagram, when a valid code is entered or an RQE device is activated, the DIGI*TRAC controller's door relay trips, completing the circuit to the input on the PS2. Whenever the PS2 input sees a circuit closed, it simultaneously trips the associated power and dry relay contact. The power relay is allocated for a 24 VDC lock and the dry relay can be used for alarm shunting, camera call-up, and other uses.

The maximum distance (in feet) for the lock power cable is a function of the wire gauge and lock current:

DISTANCE=WGV/LockInrushCurrent

Here:

WGV is the Wire Gauge Value that can be calculated using this table:

Wire Gauge	22	20	18	16	14	12
WGV	123	198	312	500	794	1258

and the LockInrushCurrent can be calculated using this formula:

LockInrushCurrent = LockVoltage/ImpedanceofLockCoil=24V/ΩLockCoil

Obtain the Impedance of the Lock Coil from the lock or strike manufacturer’s data. This will provide you with the maximum cable distance between a lock/strike and the PS2.

Always calculate cable distance based on Lock Inrush Current, not lock holding current.

If the necessary wiring distance is longer than the calculated maximum, either:

• Choose a larger wire gauge and recalculate

• Install the PS2 closer to the lock

For example, if you are using a 24 VDC lock with a lock coil impedance of 10 ohms connected to the controller by 18 AWG lock cable, then maximum distance would be calculated in this manner:

LockInrushCurrent = 24V/10Ω=2.40

Distance= 312/240=130 feet

There is also a keypad power connection for powering ScramblePads and MATCH interfaces locally instead of directly from the DIGI*TRAC Controller. If ScramblePads are powered by the PS2, these are the maximum cable lengths allowed in feet (and meters):

Table 1-11: PS2-to-ScramblePad Cable Distances

AWG	DS37L DS47L	DS37L-HI DS47L-HI	2 DS37L 2 DS47L	DS37L + DS37L-HI DS47L + DS47L-HI	2 DS37L-HI 2 DS47L-HI
22	750 (230)	450 (138)	375 (115)	275 (84)	225 (69)
18	1800 (549)	1150 (350)	925 (282)	700 (213)	575 (175)

The ScramblePad must be powered by the DIGI*TRAC Controller for UL294 installations.

The relay contact ratings for RELAY 1 and RELAY 2 are as follows:

• Power Contacts: 24V DC unregulated (18V-27V), 16A Inrush current for 0.5 second, 0.3A continuous holding current.

• Unpowered Contacts: 10A resistive at 24V DC