hand geometry unit technical manual - handpunch

Hand Geometry Unit Technical Manual

ATR Systems, Inc. • Tel 215.443.8720 • Fax 215.443.8709 • [email protected] • www.HandPunch.com

This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy, and, if not installed and used in accordance with the Installation Manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user will be required to correct the interference at the user’s own expense.

This Class A digital apparatus meets all requirements of the Canadian Interference-Causing Equipment Regulations.

Cet appareil numerique de la classe A respecte toutes les exigences du Reglemente sure le materiel brouilleur du Canada.

© 2005 Ingersoll Rand Company – ALL RIGHTS RESERVEDDocument Part Number: 70100-6006 – Revision 2.7 – June, 2005

HandKey, HandReader, HandPunch and BackHand are trademarks of Recognition Systems, Inc and the Ingersoll-Rand Corporation.

Windows is a trademark of Microsoft Corporation.

The trademarks used in this manual are the property of the trademark holders. The use of these trademarks in this manual should not be regarded as infringing upon or affecting the validity of any of these trademarks.

Recognition Systems, Inc. reserves the right to change, without notice, product offerings or specifications.

No part of this publication may be reproduced in any form without the express written permission from Recognition Systems, Inc.


Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Scope of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9User Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Organization of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Other Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

DLL Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Function Key Compiler Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Operations Manual for Specific Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11How Commands and Responses are Named . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Introduction to Hand Geometry Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Descriptions of Hand Geometry Unit Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

HandPunch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13HandPunch Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13HandKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13HP-2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14HP-3000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14HP-4000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14HK-II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14HK-CR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Introduction to Hand Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Verification Versus Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Basics of HGU Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Threshold Levels: False Accept and False Reject Considerations . . . . . . . . . 17

Basic Concepts of HGU Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Operating Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Command Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18ID Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Transactions Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Time Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Events and States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Door Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Card Reader Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Other Outputs and Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

System RAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20NV-RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Revision 2.7 Page 1


System Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Operation Without a Host Computer System . . . . . . . . . . . . . . . . . . . . . . 22HGU Does Host-Initiated Verifications . . . . . . . . . . . . . . . . . . . . . . . . . . 22HGU Just Returns Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Host Polls for ID Entry but Makes the Access Decision . . . . . . . . . . . . . 22

Introduction to HGU Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Physical Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Networks: RS-422 and RS-485. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Ethernet and TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Overview of the Command Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Typical Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Access Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Time and Attendance Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Communicating with an HGU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Physical Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Notes on Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Networks: RS-422 and RS-485. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Masters and Slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29HGU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Connection to an HGU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Regarding Ethernet Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30HGU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Connection to an HGU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Grounding and Shielding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Preliminary Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Regarding Ground Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Regarding Model F Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Systems with Floating Power Supplies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Earth Ground All Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Carry a Ground Line to Each Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Grounding with Grounded Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . 35Choice of Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Character Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Page 2 Revision 2.7


Start of Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Frame Check Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Pre-Frame and Post-Frame Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Character Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Packet Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Packet Start Timeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Receiver State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40False Starts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Data Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Communication in High-Level Languages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Structure Alignment, Byte Ordering, and Packing . . . . . . . . . . . . . . . . . . . . . 44Bit-Level Maniuplations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Controlling a Data Converter (DC-101/102) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Network Side Transmitter Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45RS-422 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45RS-485 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Notes for Windows Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Windows and RS-485 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Windows NT and DOS Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Programming your Modem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Select the Right Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Other Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Setting Up an Ethernet Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Gateways and Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Notes Regarding DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Troubleshooting a Communication Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Configuring a Unit for Serial Communications . . . . . . . . . . . . . . . . . . . . . . . 50

Model E HandPunch Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Model E HandKey Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Model F Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Revision 2.7 Page 3


Hand Geometry Unit Inner Workings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55What Happens When an ID is Entered for Verification . . . . . . . . . . . . . . . . . . . . 55Results Buffer and Template Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Results Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Template Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Validation of the ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Time Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Holidays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58HP-4000 Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Hand Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Successful Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Failed Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Obstructed Image Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Inability to Read Hand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Template Does Not Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60ID Lockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Door Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Templates and Scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Transactions Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Setup Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Events Controlling Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Controlling a Bell – HandPunch Units Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Function Key Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Transactions Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Retrieving Decision Menu Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66ID First, ID Last, Data Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Explicit Punch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Other Special Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Explicit Punch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Department Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Command Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

HP-4000 Only Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

The Message Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Sending Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Removing Messages for a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Clearing the Entire Message Pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69How to Know When a User Has Read All Pending Messages. . . . . . . . . 69Order of Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

User Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Page 4 Revision 2.7


Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Values in a Time Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Calculating Start and Stop Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Active and Inactive Time Intervals – Current and Non-Current Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Stop Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Midnight Crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Packing Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Amnesty Punches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Reconciliation of Time Restriction Controls . . . . . . . . . . . . . . . . . . . . . . . . . 71Restricting User Access to Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Contents of the Extended User Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Extended User Data Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Managing the Extended User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Deleting Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Setting Only the XUD Portion of an Extended User Record . . . . . . . . . . 73Setting Only the User Data Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Retrieving a User Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Compatibility with Model E User Record Commands. . . . . . . . . . . . . . . . . . 74HereIsUserRecord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74SendUserRecord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74RemoveUserRecord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Special Troubleshooting Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74The Status Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Model E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Model F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

New Features for Model F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76The Troubleshooting Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Modem Debug Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Display Message Code Output Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Real-Time Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Commands, Responses and Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Functional Groupings of Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Status Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Hand Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80User Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80User Database Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Transactions Log Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Revision 2.7 Page 5


Hardware Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Ancillary Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Function Key Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82HP-4000 Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Special Commands and Undocumented Commands . . . . . . . . . . . . . . . . . . . 82

Command and Response Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Datalog Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

TA Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Time & Attendance ID Verified Datalogs . . . . . . . . . . . . . . . . . . . . . . . . . . 200Function Key Data Collection Datalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Supervisor Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Datalog Format Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Examples of Standard Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Checking Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Unit Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Setup Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Command Menu Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Door Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Auxiliary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Time Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Where Will IDs Be First Entered Into the System? . . . . . . . . . . . . . . . . . . . 221When and Where Will the Enrollment Happen? . . . . . . . . . . . . . . . . . . . . . 222To Which Units Will Users Be Distributed? . . . . . . . . . . . . . . . . . . . . . . . . 222How Will Templates Be Updated? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Removing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Changing User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Remote Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Remote Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Turning an Output On or Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Retrieving Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

The Basic Methods of Retrieving Transactions . . . . . . . . . . . . . . . . . . . . . . 226Handling Communication Errors Without Losing Datalogs . . . . . . . . . . . . 226

Page 6 Revision 2.7


Handling Menu-Initiated Punches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228When Does Data Collection Terminate? . . . . . . . . . . . . . . . . . . . . . . . . 228Identifying HP-4000 Custom Data Viewing Versus Actual Punching. . 229Firmware Dated After 4/18/2000 – PROM Revision 60 . . . . . . . . . . . . 229Firmware Dates Prior to 4/18/2000 – PROM Revisions 59 and Earlier. 229

User Database Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Complete Backup of an Entire Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Examples of Packing and Unpacking Binary Data Fields . . . . . . . . . . . . . . . . . 235

High Bit in Type Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235User Record Authority Field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236HP-4000 Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237DOW Masks for Time Zones and Time Intervals . . . . . . . . . . . . . . . . . . . . 238Holiday Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Bell Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Function Key Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Reverting to “Cleared” State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Marking the Beginning and End of Data Collection . . . . . . . . . . . . . . . . . . 241Modification to Hand Verification Datalog . . . . . . . . . . . . . . . . . . . . . . . . . 241

HP-4000 Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Adding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Removing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Clearing All. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

User Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Removing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Sending Only the Extended User Data to an Existing User Record . . . . 243Sending Only the Data for Function Key Menu Display . . . . . . . . . . . . 243Retrieving a User Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Miscellaneous Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Connector Pinouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Model E Terminal Strips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Model F Terminal Strips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Model F Additional Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

RJ-45 RS-232 Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248RJ-11 RS-422/RS-485 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248RJ-45 Ethernet Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Power Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

LCD Character Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Behavior on Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Revision 2.7 Page 7


Types of Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Data Displayed on Reset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Model F Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Model E Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Additional Reset Display Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Reset Datalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Firmware Dates 4/26/99 to 4/19/00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Firmware Dates 4/20/00 and Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Data Integrity Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Model Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Auxiliary Keypad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Duress Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Y2K Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259CRC Generator Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259PC Serial Port Pinouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261RS-232 Electrical Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261RS-422/RS-485 Electrical Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Hand Reader DIP Switch Settings for RS-422/RS-485 Connection . . . . . . . . . 262Card Reader Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Wiegand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Input Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Output Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Magstripe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Input Timing and Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Output Timing and Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Hand Punch 4000 Integrated Bar Code Sensor . . . . . . . . . . . . . . . . . . . . . . 266Symbologies and the ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Basic Symbol Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Uniformity of Widths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Optical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Defects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Symbol Grade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Specifications Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Page 8 Revision 2.7


1.0 Introduction

1.1 Scope of this ManualThis manual explains how to communicate with a Hand Geometry Unit (HGU). The communication protocol, hardware, commands, responses, data structures, and keypad menu setup which pertains to communication are discussed in detail. This manual also provides supplementary information that may be useful in communicating with a reader, as well as examples of how common tasks are accomplished using the HGU command set.

Topics not covered in this manual are installation and setup, the function key compiler, and using the DLL. These items are covered in other manuals from Recognition Systems, as described in Section 1.4 on page 10.

1.2 User BackgroundIt is assumed that the reader of this manual has some familiarity with the basic operation of the HGU, such as how to enter an ID, how to place one’s hand for verification, and with the HGU installation process such as how to apply power to the unit and how to connect serial cables to a PC. Refer to the Installation and Operations Manuals for the specific models with which you are working as necessary.

This is a technical document, and some experience with computer programming is assumed. Experience with serial communications and databases is probably necessary to design and implement a successful application program. However, no experience with any specific programming language is needed to understand most of the content of this manual. The HGU commands exist outside of any particular programming language.

Some examples of how to manipulate the bits in some data structures are given in a simplified pseudo-code resembling the C programming language, and there is a sample program provided to calculate CRCs that is in the C language.

1.3 Organization of this ManualThis manual is divided into 10 sections following this introduction.

Section 2.0 beginning on page 13 describes the various models of HGU produced by Recognition Systems, Inc., what they have in common, and how they are different. This section also describes which models support which commands and provides some information on past versions of the products which may have had firmware upgraded or changed in more recent versions.

Revision 2.7 Page 9


Section 3.0 beginning on page 27 describes how to communicate with a HGU. All aspects of the communications protocol and hardware are discussed, as well as how to configure the communications-related aspects of the HGU from the keypad menus. The correct technique for controlling a data converter, the driver box for RS-422/RS-485 network communications, is described. Suggestions for using a modem to communicate with a HGU are given. Communications using the Ethernet/TCP/IP adaptor is also described.

Section 4.0 beginning on page 55 describes some details of how the HGU works internally. This section is meant to provide a sense of how data flows through the units so that it will be clearer the way the commands work, where their data comes from or goes to, and what the various status flags the HGU provides mean.

Section 5.0 beginning on page page 79 contains a summary of commands (grouped by function), then a detailed description of each command, response, and data structure used in HGU communications. This section is the main reference section of the manual. The explanations of the commands and responses given in this section rely on the information provided in Chapter 4.0.

Section 6.0 beginning on page 217 gives examples of typical application tasks and which commands can be used to carry them out.

Section 7.0 beginning on page 245 is a general reference section in which several miscellaneous topics are discussed. Year 2000 issues are also discussed in this section.

The Appendix on page 259 has several useful facts about electrical specifications of the serial connections, serial port pinouts on the HGU, and on the PC, etc.

1.4 Other Related Documents

1.4.1 DLL ManualRecognition Systems provides a Windows DLL containing functions which send all the HGU commands. This document may supplement the DLL Manual by providing a more detailed description of how the HGU carries out various commands.

1.4.2 Function Key Compiler ManualIf you need to set up a function key menu, you will need the Function Key Compiler Manual. The Function Key Compiler Manual explains the scripting language used to define the menus, as well as how to use the compiler program which translates the text script into the binary image that is loaded into the hand geometry unit.

This document describes the commands to send the function key menu data, which is the output of the function key compiler, to the HGU, but it does not describe how to set up menus.

Page 10 Revision 2.7


1.4.3 Operations Manual for Specific ProductsThis manual does not describe how to install or operate a HGU. Each HGU product has a specific installation and operation manual. Please refer to the Installation and Operation Manual for the specific HGU.

1.5 Notational ConventionsNumbers that appear simply as numbers are in decimal. Numbers that have an H after them are hexadecimal. For example, 1234 is decimal, while 53H and 0AF35H are hexadecimal.

1.6 How Commands and Responses are NamedCommands may be referred to in several ways. Each command is given an English name, such as HereIsSetupData, a hex number (3DH), and an ASCII character (‘=’). Typically, this manual will use the English name and the hex number whenever a reference is made to a command. However, in some lengthy discussions where the same command is mentioned repeatedly, the ASCII character may be used as a shortcut to make the text easier to read.

The words “Here is” and “Send” appear frequently in command and response names. “Here is” indicates that the sender is sending data to the receiver. “Send” indicates the sender is commanding the receiver to send data. Unfortunately, some commands and some responses have the same name, and it is necessary to bear the context in mind when looking at a command or response name.

Revision 2.7 Page 11


Blank page.



2.0 Introduction to Hand Geometry UnitsThis chapter is an introduction to the HGU for programmers who may be encountering one for the first time. Some fundamental concepts and terms are introduced, and a broad overview of how the HGU works is presented. This information will provide a foundation for understanding what the HGU commands do and which one to use at what time.

2.1 Descriptions of Hand Geometry Unit ModelsThe overwhelming majority of Hand Geometry Units in service are either Model E units or Model F units. Model E units are in a beige metal housing. Model F units have a gray plastic housing. Most of the basic operations of the two models are the same, but it is important to bear in mind the differences. Below we will describe the Model E types and the Model F types. A Feature Summary Matrix follows the model descriptions (see Table 1 on page 15).

2.1.1 HandPunchThis is the Model E Time and Attendance (T&A) unit. It has outputs and inputs which may be used to control a door and a bell, and it supports card reader input, typically in MagStripe format. It has the same user/transaction capacity options as the HandKey. Since T&A units are almost always used with a host PC, it has limited command menus to provide a simpler interface. The host PC can provide most of the setup configuration programming capability.

2.1.2 HandPunch PlusThis unit was introduced as a transition from the Model E product line to the Model F product line. It has four function keys and many of the commands supported in the HP-3000. The HandPunch Plus supports the function key menu system. Aside from having four function keys, its hardware capabilities are the same as the HandPunch.

2.1.3 HandKeyThis is the Model E Access Control unit. It has outputs and inputs which can be used to control a door or optionally reconfigured to provide card reader data output to an access control panel. It has a full-featured command menu which allows it to be programmed stand-alone, without needing a host PC. It has the same user/transaction capacity options as the HandPunch.



2.1.4 HP-2000The HP-2000 is one of the Model F T&A units. This is a limited feature unit intended for low-cost, small applications. It has a limited user memory and does not support expanded memory options. It does not support RS-422 communications and so cannot be used in a network. It does not support card reader input or output, and all time restrictions have been disabled. It does support the use of function key menus and has two function keys.

2.1.5 HP-3000The HP-3000 is similar in capability to the HandPunch. It has all the features of the HandPunch, and also has some additional auxiliary outputs and inputs. It supports function key menus and has two function keys. There are three user memory options available.

2.1.6 HP-4000The HP-4000 does everything the HP-3000 does and adds several new features. Messages may be loaded into the unit which will be displayed when a particular user punches, and user’s names can be shown when they punch as well. Data can be stored in a user’s database record and accessed through the function key menus. An alternate time restriction format has been introduced which provides more flexibility than the time zone method used in other models. There are ten function keys, and access to them can be controlled on a per-user basis.

Due to the increased amount of memory needed for a user record, the HP-4000 has a lower user capacity for a given amount of memory than the HP-3000, and therefore is only available with the two larger memory options.

2.1.7 HK-IIThe HK-II is similar in capability to the HandKey. It has a full command menu and can be completely configured in stand-alone mode without using a host PC. Full door controls are provided, or the units can be configured to send card reader data to an access control panel. Function key menus are supported, although of limited usefulness on an Access Control application. There are two function keys.

2.1.8 HK-CRThe HK-CR is intended to provide a biometric supplement to an existing card-based access control installation. Most features have been disabled except the ability to read a hand and output an ID to an access control panel. There is no support for door controls or time restrictions in this model.



Table 1: Feature Summary Matrix

Feature HP HP-Plus HP-2000 HP-3000 HP-4000 HK HK-II CR

User Capacity

SA-256SB-3,328LA-9,728LB-27,904

SA-256SB-3,328LA-9,728LB-27,904

512 A-512B-9,728C-32,512

B-530C-3,498

SA-256SB-3,328LA-9,728LB-27,904

A-512B-9,728C-32,512

A-512B-9,728C-32,512

Transaction Capacity

3,185 3,185 5,120 5,120 7,680 3,185 5,120 5,120

Aux Inputs 1 1 0 2 2 1 2 0

Aux Outputs 1 1 0 3 3 1 3 2 (limited)

Door Controls

Yes Yes No Yes Yes Yes Yes No

Time Restrictions

Yes Yes No Yes Yes Yes Yes No

Bell Schedule

Yes Yes Yes Yes Yes No No No

Messages No No No No Yes No No No

Function Keys

None 4 2 2 10 None 2 2

Validation Strings

n/a n/a No No Yes n/a No No

User Data Fields

n/a n/a No No Yes n/a No No

User Messages

No No No No Yes No No No

RS-232 Host Coms

No No Required Optional Optional No Optional Optional



2.2 Introduction to Hand Geometry

2.2.1 TemplatesAll the RSI Hand Geometry Units share a common core operating principle. Each converts an image of a hand into a nine-byte entity called a “template,” which contains the most statistically significant information which distinguishes that hand from other hands. When each user is enrolled, their template is stored in the HGU along with a five-byte ID number (up to ten BCD digits).

The HGU obtains the image of the hand from a CCD camera. The hand is illuminated by a brief pulse of infrared light from an array of LED’s, and the image is transferred into the HGU memory where it is processed into the nine-byte template. This template is compared to the reference template acquired during enrollment. Some other biometric devices on the market store the entire image of the feature they are using, but the HGU stores only the most statistically important information from the processed image. This results in far less memory being required for the user database and allows the HGU to operate without direct control of a host computer system to provide a large offline storage mechanism.

2.2.2 Verification Versus IdentificationLike most commercially viable biometric products on the market today, the HGU does identity verification, not identification.

• Verification begins with presenting the HGU an ID number, and the HGU’s job is to validate that the hand being shown matches the hand enrolled for the given ID.

• Identification is the attempt to determine, without any additional information, whose hand is being shown.

This distinction is important from an application programming standpoint because it means that all hand verifications must begin with an ID number (or a known template).

2.2.3 Basics of HGU UseBefore anyone can be verified, they must be enrolled. Enrollment is the process of giving the HGU an ID number and showing the HGU the hand of the person with that ID. The HGU takes a series of images of the person’s hand, averages them together, and stores that average template in the newly created record in the user database. That template serves as the baseline reference for future verifications.

After a user is enrolled, his ID can be presented to the HGU and the verification process begins. The verification compares the template stored in the HGU for the given ID to the template generated from the hand being presented to the unit. The difference between the two templates is quantified as a “score” for that hand reading. Higher scores mean the two templates are more different; a perfect match would be a score of zero.



Once a hand has been verified, the HGU may do a variety of things. Units meant for access control applications typically turn on an output which is used to unlock a door. Units meant for time and attendance applications may print a receipt or start a menu for data collection.

2.2.4 Threshold Levels: False Accept and False Reject ConsiderationsThe system operators must decide what threshold score constitutes an accept. The trade-off is that for higher thresholds, the chances of someone verifying against someone else’s hand (called a “false accept”) increase, but for lower thresholds, the chances of someone not matching their own enrollment template (a “false reject”) increase. Different systems are concerned with different types of security, so thresholds may be set higher or lower to suit the situation. The HGU allows a system global threshold to be set as well as thresholds for individual users.

The HGU is designed so that the probability of a false accept is equal to the probability of a false reject when the threshold is set to 100.

2.3 Basic Concepts of HGU OperationsIn this section, the fundamental concepts needed to understand the details of how the HGU works are presented. These concepts will be further elaborated in the other sections in this chapter. The HandPunch 4000 has some additional features not present in the other models, and those features are explained in a separate subsection.

2.3.1 Operating ModeThe normal mode of operation is for the HGU to wait for an ID to be entered, either at the keypad or by an attached card reader. While in this mode, the unit displays “ENTER ID” if it is a HandPunch unit, or “READY” if it is a HandKey unit.

Model F units allow this “ready” string to be reconfigured.

2.3.2 Command ModeIn addition to the normal mode of operating, where the HGU is recording accesses or punches, there is the command mode. This mode is for configuring the unit from the keypad, and is accessed by pressing the Enter and Clear key either simultaneously or quickly one after the other.

There are 5 menus available in command mode, each of which contain different types of operations. Users are granted permission to access the menus (or not) by an authority level in their user database record. Refer to the operating manual for a specific HGU for further details on how to use command mode. In a later section, we will briefly explain how to use command mode to configure the communications-related aspects of the HGU.



A person using the HGU in command mode is sometimes called an “operator” (as opposed to a “user”) and command mode is sometimes called “operator mode.”

2.3.3 User DatabaseAs mentioned above, the HGU has an internal database which holds users’ templates. This database is keyed by the 5-byte user ID, and the data it contains is the 9-byte template, a byte indicating the user’s time zone, and another byte which holds both the user’s reject threshold and authority level. To distinguish this 16-byte record from the larger records in the HP-4000, this 16-byte record is called a Basic User Record.

• The time zone is a number indicating when the user is allowed to use the HGU (see Section 2.3.7 on page 19).

• The reject threshold is the maximum score this user can receive in hand verifications and still be accepted.

• The authority level indicates which, if any, command menus the user is allowed to use.

The size of the user database varies from model to model, and also with the memory option purchased.

2.3.4 ID EntryTo use the HGU, a user enters his ID. This can be done either from the keypad or by using a card reader. The HGU goes through a series of decisions about whether this user is allowed to use the HGU at the present time, then images the hand and takes appropriate action based on the results of the verification attempt.

2.3.5 VerificationVerification is the process of checking that the template calculated from the hand presented to the HGU matches the reference template for the ID given (or the template explicitly provided by the host PC in the case of a certain type of remote enrollment).

Every verification is the comparison of two templates. If the difference between them is less than the specified threshold, the verification is successful. This is called an “accept.” If the difference exceeds the threshold, the verification fails; this is called a “reject.”

2.3.6 Transactions LogEvery HGU maintains a record of all transactions that occur. These are sometimes referred to as “datalogs.” These will be fully explained in following sections.



2.3.7 Time RestrictionsOne of the primary responsibilities of the HGU in both Access Control and Time and Attendance applications is restricting the times at which users can open the door or punch. The basic way this is controlled is by creating a set of schedules called “time zones” which consist of a set of start and stop times and day-of-week specifications. Each time zone is assigned a number, and each user is assigned to one time zone by placing that time zone’s number in his user record. Time zones are explained in Section 4.5.1 on page 58.

Following a complete reset, all time zones are set to allow access at any time.

2.3.8 Function KeysThe F series of products (and the HandPunch Plus) have function keys for setting up custom operations. The Function Key Compiler Manual explains how to do this, and nothing further about it will be presented in this manual. However, there are three points about the function keys which need to be mentioned here.

First, a host PC application may be required to send data from the function key compiler to a HGU. Second, it is important to understand how the menu system alters the normal ID entry and hand verification sequence. Finally, the HGU can be configured to trigger certain outputs when function keys are pressed. References to the function keys will therefore be appearing in several places later in this manual.

2.3.9 Events and StatesA useful way of thinking of how the HGU works is that it waits for events to happen, then responds to them by taking some specific action. The action taken may be fixed by the HGU, or it may be configurable by the programmer or operator.

Most events are internal to the HGU and are not documented. However, there are a few especially important events which set certain status flags, cause a transaction to be logged, or cause an output to turn on. These are explained in Section 4.11 on page 64.

The HGU can also be thought of as being in various states, and moving from state to state in response to events which occur. A set of states and the events which cause the HGU to make transitions from one state to another is called a “state machine.” This way of describing the HGU will be used in this manual when it is necessary to give a very precise description of a complicated aspect of the HGU’s behavior.

2.3.10 Door ControlsFrequently, a HGU is used as the decision-making point for whether a door should be opened. To facilitate this, a set of inputs and outputs has been specifically assigned to this task on most models – the HK-CR and HP-2000 are exceptions.



These signals can turn on a lock and monitor the state of the door. There is a simple state machine associated with door controls, and it will be presented in Section 4.7 on page 61.

2.3.11 Card Reader InterfaceOften, a HGU must be integrated into a system which requires it to receive data from a card reader, or to send data to another device as if the HGU were a card reader. Some installations require the HGU to do both card input and output. Most HGU models have a set of inputs and outputs which can be used for this purpose. In all cases, when card input is supported, it has two inputs specifically dedicated to it. However, the card reader outputs are shared with other outputs, and the HGU must be specifically configured to use those outputs as card reader outputs.

The format of the card data that is accepted by or sent by the HGU varies greatly, and many custom formats exist. The default formats are 26-bit Wiegand for HandKey units, and ABA Track-2 Magstripe for HandPunch units. The details of the card formats are given in Section 9.6 on page 263.

2.3.12 Other Outputs and InputsDepending on the model and the way it is configured, an HGU may have as many as three outputs and two inputs, besides those assigned to door controls or card reader data. These are referred to as “auxiliary” inputs or outputs, or simply as “AuxIn1,” “AuxOut1,” etc.

2.3.13 Memory

2.3.13.1 System RAMThe system RAM holds the user database, the transactions log, all the HGU program variables, the function key menu definition table (on those models which support it), and, on the HP-4000, the message data. This memory is protected against power loss by an on-board power management circuit which switches the RAM’s power to a lithium battery when main board power is lost.

2.3.13.2 NV-RAMIn addition to the system RAM, there is a small amount of nonvolatile memory (an EEPROM) which holds configuration information and calibration information. This memory is allocated in 128-byte blocks.

Model E products use one 128-byte block of this memory to hold setup data. This is referred to as the Basic Setup Data. Model F series products have an additional 128-byte block called the Extended Setup Data, in addition to the Basic Setup Data. See Section 5.6 on page 173 for more details on Basic Setup Data. See page 185 for more details on Extended Setup Data.



All products use an additional 128-byte block to hold factory configuration and calibration information. This block is not accessible to the end user or the application programmer.

2.3.14 Power ManagementHand Geometry Units are designed with two levels of power backup. The first level provides data retention through a loss of external power. This is what the lithium battery on the main board is for. This battery provides power to the SRAM at all times when the external power is lost. There is a power management circuit which is responsible for switching the SRAM power supply to the battery when external power is lost. This circuit has been extensively tested for switchover time and hysteresis under slowly decaying power input, and no failures have occurred from these causes. However, the lithium battery does have a finite lifetime, and it is recommended that it be changed every two to three years.

In addition to the lithium battery, there is an option available which provides backup power so the unit can continue functioning normally when main power is lost. On Model E units, this battery is connected to the external power inputs on the terminal strip. On Model F units, the battery is located inside the housing and is connected to the top panel. On the Model F units, there is an additional board which provides circuitry to quickly and reliably switch to battery power when external power is lost. This circuit prevents instabilities in the power supply when the external voltage is dropping slowly.

There are technical notes available showing the details of battery installation on both Model E and Model F units. Please contact RSI Customer Response to obtain these notes.

2.3.15 System ConfigurationsAlthough there are many ways to configure an HGU system, there are a few typical configurations which should be mentioned. Two of the most important decisions to be made are:

• Who controls the decision about accepting or rejecting?• Who decides when a hand verification starts?

Either the HGU or the PC may do either of these, and the four resulting scenarios are described below.



2.3.15.1 Operation Without a Host Computer SystemSome applications have the HGU operating entirely on its own. ID entry at the HGU initiates the verification process, and the HGU makes the decision by itself of whether the presented hand is accepted or rejected, based on the reference template in its own user database. There is no host PC involvement in this system, except possibly occasional retrieval of the transactions log.

2.3.15.2 HGU Does Host-Initiated VerificationsSome applications have the host PC initiate the verification process but allow the HGU to make the verification decision. When the host PC decides it is time to do a verification, it sends the ID to the HGU, and the HGU proceeds to read the hand as if the ID were entered locally.

2.3.15.3 HGU Just Returns TemplatesOther applications have the entire process controlled by the host PC. It determines which user is about to present his hand, finds the template for that user from a database it owns (meaning it is not stored in the HGU, but on a hard disk file on the host PC), and sends just the template to the HGU. The HGU compares the presented hand to the given template and returns a score to the host PC, which then makes the decision to accept or reject, and what action to take based on the result. Similarly, enrollment may be initiated locally at the HGU or remotely by the host PC.

2.3.15.4 Host Polls for ID Entry but Makes the Access DecisionFinally, a host PC may poll the HGU to see when an ID is entered at the keypad, then initiate the verification process itself, retrieve the result, and decide whether to grant access. Typically, in this configuration, the HGU never has any users enrolled in its local database.

2.4 Introduction to HGU Communications

2.4.1 Physical ConnectionFour types of physical connection are supported between the host PC and the HGU. A brief description of each of these configurations is given here. More complete technical information is in Section 3.0 on page 27.

2.4.1.1 RS-232This is the simplest physical connection between a host PC and a HGU. The PC’s RS-232 port is connected directly to the RS-232 port of a single HGU.

This connection is supported only on F series products. Although the E-series has an RS-232 port, it is dedicated to printer output and cannot be configured for host PC communications. However, it is possible to connect a host PC to monitor HGU printer output.



2.4.1.2 Networks: RS-422 and RS-485This is the preferred way to connect readers to a PC a significant distance away, and is the only way to connect a network of readers together. This type of connection is supported on all HGU models except the HP-2000.

Both RS-422 and RS-485 support networks and long-length cables. Electrically, they are virtually identical. (See the appendix for specifications.) Both types of connection send data over differential pairs for high reliability in noisy environments. The difference between them is that RS-422 is a four-wire link, while RS-485 is a two-wire link. In fact, RS-422 is often called “four-wire RS-485.” Since an RS-422 link consists of four wires, and each channel is one pair of wires, the RS-422 link can support two channels simultaneously, which means it is capable of full-duplex communication. However, communication with the HGU does not require a full duplex link since each command generates exactly one response, and slaves on the network never initiate any communications events. This means it is possible to use a half-duplex physical link such as RS-485, which has only one pair of wires. This has some important practical implications which will be discussed later (see Section 3.5 on page 45).

Electrically, RS-422 and RS-485 are both very different from RS-232. RS-232 is single-ended, bipolar (both positive and negative voltages are used), and allows voltages up to +/- 12V on the wires.

RS-422 and RS-485 are differential, unipolar, and only uses voltages up to +5V (however, significant common-mode voltage is allowed). This means that an adapter must be used to convert the signals present at the PC serial port to the requirements of the RS-422 or RS-485 link. RSI provides an adapter called a data converter for this purpose. There are also RS-422/485 boards available which plug directly into slots on a PC motherboard.

2.4.1.3 ModemHand Geometry Units may be purchased with a modem installed. This is useful if a HGU must be located very far from a host PC, or if it is not practical to physically connect the HGU to the PC. The modem is connected via an internal RS-422 link to the main board of the unit which contains it and it acts as a master. A network of slaves may be connected to a modem. This is explained further in Section 3.1 on page 27. However, it is not possible to establish a master/slave network of HGU’s through a modem link. This is mainly because the modems in the HGU’s are answer-only, so there is no way to initiate a connection from a HGU.

2.4.1.4 Ethernet and TCP/IPHand Geometry Units may be purchased with an Ethernet adaptor installed. As with a modem, this is useful if it is necessary to locate the HGU very far from the host PC. The Ethernet adaptor is connected to the main board of the unit which houses it via the RS-422 lines and it acts as a master. A network of slaves may be connected to the Ethernet adaptor. This is explained further in Section 3.1.4 on page 30.



Please note that the Ethernet adaptor actually communicates using TCP/IP. The IP address is assigned by a command menu. The adaptor supports the use of a gateway, whose address is also assigned by a command menu. Units can be ordered with an optional command menu enabled which allows a subnet mask to be set. The Ethernet adaptor does not support the UDP protocol.

Although it is possible to have a network of units connected to an Ethernet unit, and it is also possible to have a network of Ethernet units, it is not possible to have a master/slave configuration through the Ethernet adaptors. This is because each Ethernet adaptor is actually an RS-422 bus master. The intent is that there is a PC somewhere on the Ethernet network which is the effective master of the RS-422/485 network.

2.4.2 Overview of the Command ProtocolRegardless of the type of physical link, there is a common command protocol. This protocol is described fully in Section 3.0. In brief, each network has exactly one master which is allowed to initiate communications by sending a command packet.

The command packet contains the address of the slave the command is being set to, the length of the data being sent, the actual data, and either a CRC or checksum for packet integrity checking. When a slave receives a command, it issues a response packet. The format of the response packet is the same as the command packet.

An important point to remember is that only the one station designated as the master may initiate commands. Slaves must be constantly monitoring their receive ports for commands from the master, but the master can be assured that it will never receive an unexpected data packet from a slave. This restriction is necessary because RS-422/485 has no way of handling collisions on the network, so one station must be designated as the only one which can initiate communications.

The HGU command protocol is connectionless; that is, each command/response pair is independent of the others before and after it, and there is no protocol for establishing or terminating a link with another station. When an Ethernet adaptor is used, the TCP connection must be established, and when a modem is used, a phone line connection must be established, but the underlying HGU commands are unaware of this. The concept of a “channel” which exists in the RSI DLL is related to the Windows API idea of opening a communication port and has no meaning to the hand reader.



2.5 Typical Applications

2.5.1 Access Control SystemsOne of the two main applications of the Hand Geometry Unit is in access control systems. This is where the unit is used to control physical access to a room or building, usually by means of actuating some sort of lock. Typically, each user in such a system is assigned an ID and a set of times they are allowed access to the controlled area. To gain access, users must present their ID number to the unit, which then verifies their identity based on their hand geometry. If the identity is verified, the unit will turn on its lock output, which allows the door to be opened.

The basic philosophy of such a system is security. The HGU participates in this system by adding the security of the hand reading, but also has some other security features. First, the ID number of a user is concealed as it is typed in. The secrecy of the ID numbers is a significant part of the security of most access control systems. The HGU also keeps a log of all activity, which can be examined later if necessary to see who gained access at what time. The units have tamper switches to warn if their attachment to the wall has been compromised, which would allow access to the communications and lock control circuitry. It is recommended for access control systems that the thresholds for identity matching be set somewhat lower to reduce the probability of a false acceptance.

Since administering the user database of a large installation can be difficult using only the menus available at the HGU, it is very common to have a host PC connected to the HGU network which provides database management functions. These systems can also be constantly polling the HGU network to check their status and retrieve their transactions.

Another type of architecture in access control systems is one where a host PC actually makes the access decision and controls the door locks. The HGU can be used in this type of system as well. The ID is passed to the host system, which then retrieves the biometric data from a database, sends it to the HGU, and tells the HGU to verify the person. The HGU returns the result of the verification and the host system decides whether the match is close enough to grant access.

2.5.2 Time and Attendance SystemsIn Time and Attendance systems, the two main objectives, aside from verifying people’s identities, are to minimize the amount of time people spend standing in line punching and to be sure that punches are never lost.

To reduce the amount of time people spend standing in line, card readers are often used. But if keypad ID entry is desired, the ID is displayed on the LCD to help the user be sure the ID is entered correctly. Thresholds for template matching can be set somewhat higher to reduce the probability of a false reject.



To prevent data loss, the HandPunch units will stop accepting punches when their datalog buffer becomes full. There is a warning displayed when it reaches 80 percent capacity. It is recommended that the units be polled frequently to retrieve all transactions before they get full.



3.0 Communicating with an HGUThis chapter provides full technical details on each mode of communicating with an HGU. Each physical connection is discussed in depth. The communication protocol is fully described, and the use of the data converter for interfacing to an RS-485/RS-422 network is explained. Information is given about how to use the command menus at the HGU keypad to configure the HGU serial ports.

For more information on setting up the hand reader in each of these modes, as well as detailed wiring diagrams, refer to the Installation and Operation Manual for your specific product. In addition, refer to the Appendix on page 259 of this manual for useful pinout information and electrical specifications of the protocols the HGU supports.

The first section in this chapter will describe the various possible physical connections to an HGU and some of the implications of each. The second section describes the communications packet protocol and timing. The third section discusses some common problems encountered when attempting to communicate with HGU’s through high-level languages. The last three sections describe details specific to establishing RS-422, modem, and Ethernet connections to HGUs.

3.1 Physical Connection

3.1.1 RS-232Historically, one end of the RS-232 link is designated the Data Terminal Equipment (DTE) and the other end is designated the Data Communications Equipment (DCE). The difference is which equipment is driving the TX line and which is driving the RX line. The DTE output data goes onto the TX line and the DCE receives data input on the TX line. The DCE output data goes onto the RX line and the DTE receives data on the RX line. Typically, computers are DTE and modems are DCE.

The F series HGU RS-232 port, when configured for host PC communication, is wired as a DCE since it is receiving data from the PC. That means the PC’s TX line is connected to the HGU’s RX line, and the PC’s RX line is connected to the HGU’s TX line. When the HGU’s RS-232 port is configured for printer output, it is, of course, a DTE and the printer is the DCE.

RSI provides an adapter which plugs into a standard PC 9-pin serial port and receives an RJ-45 cable which can plug into the RS-232 port on the HGU.

3.1.1.1 Notes on CablesPlease note that the RS-232 electrical specification imposes some severe limits on cable length. The RS-232 connection was developed for connecting computers to peripherals a short distance away, such as modems and printers. RSI does not



recommend using a cable longer than 50 feet for an RS-232 connection, although with special low-capacitance cables, it may be possible to achieve a reasonably reliable link with cable lengths up to 200 feet, depending on the baud rate.

Also, please note that although the RJ-45 connector on the RS-232 port is the same type of connector that is commonly used for wiring Ethernet connections, it is not an Ethernet connection and will not benefit from cables meant for Ethernet. The special shielding and pairing that is designed into high-quality data cables relies on a certain electrical design and a certain pinout on the connectors, and the RS-232 port does not have this design. Using an Ethernet data cable will not help the reliability of the RS-232 port and may in fact actually hurt it. A simple flat ribbon cable is adequate for the RS-232 port connection.

3.1.2 Networks: RS-422 and RS-485

3.1.2.1 Masters and SlavesOne station on an RS-422/485 network is designated the Master; all the others are designated Slaves. The difference is that the Master always initiates every communication event, while the Slaves only send data in response to commands received from the Master. This distinction is important because the RS-422/485 electrical connection, unlike Ethernet, has no way of resolving the collisions (two stations attempting to start sending at the same time) that would occur if slaves were allowed to initiate communications asynchronously. When a PC is connected to a network of HGUs, the PC is typically the master. This is the configuration assumed by all RSI software applications and the DLL.

It is also possible to have a network of HGUs without a PC. In this case, one of the HGUs is designated as the master by programming it at the keypad. This is referred to as “Master Mode” in the Installation and Operations Manuals, which should be consulted for further details. If a HGU is designated as the network Master, there is no configuration supported by RSI for connecting a PC to the network.

3.1.2.2 Network TopologyThe physical topology of this type of network must be point-to-point with the Master physically located at one end of the chain. Star configurations are not permitted. See the specification in the Appendix for a detailed description of limits on cable lengths and stub lengths.

On an RS-422 link, the Master’s TX output is connected to the RX input of every slave. The slaves have all their TX outputs connected together, and to the Master’s RX input. In other words, one channel is used for Master-to-Slave communication, and the other is used for Slave-to-Master communications.



3.1.3 Modem

3.1.3.1 HGU ConfigurationHand Geometry Units automatically detect the presence of a modem option and configure themselves appropriately. No further setup should be required to get a modem HGU to work, except that since the RS-422 link is used, the DIP switches on the HGU motherboard must be set for the RS-422 network configuration.

Auto-detection will set the reader as follows.

• For all E series products, the baud rate on the network channel will be set to 2400 baud.

• For F series products, it will be set to 9600 baud.• For the HP-2000, the RS-232 port will be disabled since the modem communicates

with the HGU via the RS-422 lines (refer to Section 3.1.3.2 for detailed information).

3.1.3.2 Connection to an HGUThe physical connection of the modem to the HGU can be a bit confusing. It is not necessary to have a full understanding of this topic to successfully communicate with a modem HGU. However, setting up a network with a modem may require you to read this section.

Although a modem is physically housed inside a particular HGU, it is probably best to think of it as being different from the HGU. The modem is internally connected to the HGU which houses it via the RS-422 lines (not RS-485 – we’ll see why soon). This is just like a little network with the modem as the network master and the HGU housing it as the slave. This makes sense, because the modem is, in a sense, nothing more than an extension of the host PC.

The RS-422 lines coming out the back of a modem HGU are a tap into the connection between the modem and the HGU. The TX lines are for the HGU-to-modem channel, and the RX lines are for the modem-to-HGU channel. Therefore, additional HGUs added to this network should have their TX lines connected to the modem HGU’s TX lines, and their RX lines to the modem HGU’s RX lines. Remember – the modem itself is the network master.

RSI does not support an RS-485 link with a modem because modems do not provide any way of signaling when it is time to turn off the transmit driver. If it is not clear what this means, refer to Section 3.5.



3.1.4 Ethernet

3.1.4.1 Regarding Ethernet TerminologyStrictly speaking, the “Ethernet” adaptor provided for the HGU is not simply an Ethernet adaptor, but an Ethernet adaptor with a TCP/IP protocol stack. To communicate with the unit, you must have a TCP/IP stack on the host machine and a physical Ethernet connection. Although most of the programming issues related to using the Ethernet adaptor are actually TCP/IP issues, not Ethernet issues, we refer to the adaptor as an “Ethernet adaptor,” even when we are discussing some aspect of the system that may actually pertain to TCP/IP and be totally unrelated to Ethernet.

3.1.4.2 HGU ConfigurationAs with a modem, an HGU with an Ethernet adaptor installed will automatically detect the presence of the adaptor and configure itself appropriately. Since the Ethernet adaptor communicates with the main board in the unit through the RS-422 bus, the DIP switches must be set to allow RS-422 communication, not RS-485.

The IP address of the unit must be programmed before the adaptor can be used. In addition, if necessary, the address of the gateway to which the unit is connected may have to be programmed. If there is no gateway in the network, set the gateway address to 0.0.0.0. Optionally, units can be ordered which have a menu enabled which allows programming a subnet mask if this is needed.

Auto-detection will configure the reader as follows. The baud rate will be set to 9600 and the address will be set to 0. For HP-2000 units, the RS-232 port will be disabled and communications will be through the (internal) RS-422 bus.

The unit which houses the Ethernet adaptor must always be set to address 0. (We are referring here to the address in the Recognition Systems communication protocol.) This is so that the Ethernet adaptor can query the unit to obtain the IP address, gateway address, and, if enabled, the subnet mask. Although the command menus may allow changing the address of an Ethernet unit, the address will revert to 0 the next time the unit is power cycled, and it is recommended that the address not be changed. In addition, the baud rate from the Ethernet adaptor to the RS-422 port is fixed at 9600 baud, so changing a unit’s baud rate, either from the command menu or with the host setup data commands, will cause that unit’s communication to stop working.

3.1.4.3 Connection to an HGULike the modem, the Ethernet adaptor communicates with the main board of the unit in which it is housed by the RS-422 lines. All the comments in regarding the connection to the modem in the previous section apply to the Ethernet module as well.



3.2 Grounding and ShieldingThis is an extremely important—and often overlooked—aspect of hard-wired serial communication systems. If the sending and receiving stations do not agree on the ground reference for the signal voltages, communication errors or a total inability to communicate may be observed. If the voltages are very different, it is even possible to damage the units.

The subject of grounding can be complicated, and the full circuit of a system, including power supplies and often even the building line power wiring, must be understood. It is strongly recommended that a qualified electrician or electrical engineer familiar with this subject be consulted when designing the wiring of a HGU network installation. Always adhere to any applicable electrical codes. Recognition Systems will not be responsible for damage done to units due to improper wiring.

3.2.1 IntroductionGrounding is mainly a concern in RS-422 and RS-485 network systems. For modem and Ethernet units, grounding between the host system and the remote HGU is largely irrelevant. Modem units are connected only to the phone line, and the Ethernet electrical signals are coupled through transformers. However, if a modem or Ethernet unit serves as the master of an RS-422 network, the considerations in this section are just as important as in a system where a host computer is the network master.

RS-232 systems have only one host computer and one HGU. The ground signal is carried in the RS-232 wiring, and the wiring is limited to a relatively short distance, so there is little chance that a grounding problem will manifest itself. So only systems which have RS-422 or RS-485 network connections need to pay close attention to grounding.

Since RS-422 (in this section, everything said about RS-422 will be taken to apply to RS-485 as well) connections are often described as differential pairs, it is sometimes forgotten that they are still DC-coupled and referred to the ground of the unit. It is therefore important in an RS-422 network that all units somehow have their grounds all connected to a common reference point. In this section, we will discuss several ways to do this, depending on the power supply configuration.

3.2.2 Preliminary Notes

3.2.2.1 Regarding Ground ConnectionsMany of the solutions that follow in this section suggest connecting the grounds of units together. Please note that before connecting grounds together, it is strongly recommended that the potential difference between the grounds be measured, both AC and DC. If it is too large (more than a few volts), there is a chance that the ground of one unit was somehow connected to the hot side of the AC power line. This can



happen if the building power is wired incorrectly. Connecting the grounds of these units in this case can be dangerous.

In addition there should be very little current flowing through the ground path. As with the ground potential difference, this too should be measured both AC and DC. If more than a few milliamps is flowing, something may be wrong with the power supply wiring somewhere in the network. This is particularly likely with AC-input power supplies on Model F units. The ground shield on the serial communications lines should not be a major current flow path, but rather simply establishes a common voltage between two units.

3.2.2.2 Regarding Model F Power SuppliesIn Model F units the power supply input negative lead is not directly connected to the main board ground. These units are designed to accept either AC or DC at their power supply inputs.

This is low-voltage AC power. Do not connect the unit directly to a high-voltage power line under any circumstances. Refer to the Installation and Operation Manuals for details.

Since Model F units have a bridge rectifier in their power supply input, the main board ground is connected to the power supply negative side by a diode. This typically does not affect systems which apply DC power to the HGU, and the power supply ground may be connected to the board ground safely.

However, for AC power installations, the main board ground must not be connected to either of the power supply inputs, as this will short out one of the diodes in the bridge rectifier. This can make establishing a common ground point difficult, since the phases of the AC power inputs to different units on the network may be different.

One way to solve this problem is to ensure, if possible, that the V- input is connected to earth ground for every unit. This is normally something that can be achieved easily, since the secondary side of power supply transformers is totally floating. On HandKey units, the V- input is clearly labeled on the rear terminal strip. On HandPunch units, the power input is a barrel connector. The outer ring of the barrel connector is the negative side, but there is no terminal strip connection. Earth grounding must be accomplished at some other point in the power supply than at the HandPunch power input.

3.2.3 Systems with Floating Power SuppliesA floating power supply provides power output which is on the secondary side of a transformer, and neither the V+ nor V- line has a low-impedance path to any external ground reference. The two-prong power supplies provided with most HGU’s are floating power supplies. Systems with floating power supplies can theoretically have their “ground” (the V- lead) at any potential relative to each other. This is the



configuration which most often leads to severe communication errors, or even damage to the communication circuits, if some attempt is not made to bring the grounds of all the units on the network to the same potential. There are two ways to do this.

3.2.3.1 Earth Ground All UnitsThe first method of establishing a ground reference is to connect each unit’s main board ground to earth ground. Earth ground is found on the third pin on standard AC line sockets (in the United States, this is the round one in the middle). If the building wiring is functioning correctly, this should be a low-impedance path to a true ground, which then serves as a common reference point for the units.

If this method of grounding the units is used, it is not necessary to connect the units in the network together with a ground line in the communication cable. Indeed, doing so could create ground loops—large-area loops which provide a good coupling to external magnetic fields—which may actually make the problem worse. If a magnetic field, such as that from a lightning strike, induces a voltage in the ground loop, it is possible for large currents to flow around the loop, which can raise the ground potential of some units relative to others. So if the shield is connected to any ground at all in this configuration, it should be connected only at one end to prevent the formation of ground loops.

For systems with multiple units on a network, there will be a series of cables daisy-chained between the units, and the shield of each leg of the network should be connected to ground at only one end. It does not matter which end. An example of this method of grounding is shown in Figure 1.

Figure 1: Communication Shielding With All Units Earth Grounded

All units are connected to the same earth ground. Each shield ground is connected to only one unit, then interrupted to prevent the formation of ground loops. For an RS-485 installation, the circuit as shown is all that is needed. For an RS-422 installation, there is another pair of lines (Master Rx, Remote Tx) which would be wired similarly. It does not matter significantly which unit’s GND is used for a particular shield, as long as the path is broken from unit to unit.



3.2.3.2 Carry a Ground Line to Each UnitThe second method of establishing a ground reference in a system with floating power supplies is to use the ground line in the RS-422 cable to establish a common reference voltage for the communication signals. This line should be connected to the negative power terminal on the data converter or the gound line in the RS-232 port from the host PC system. It should then be carried to one of the ground terminals on the back of each unit in the network. An example of this method of grounding is shown in Figure 2.

Figure 2: Communication Shielding Carrying a Single Ground to Each Unit

If no earth ground is available at the units, this is the only possible method of connecting the grounds. Even if an earth ground is available, depending on the building’s power wiring and other environmental issues, this method may be superior to the previous one, since it establishes the ground of each unit independently of the building power lines. Local variations in grounds between buildings, or from one point to another in a very large building, (perhaps due to elevator motors or other large-current drawing machines) will have no effect on the communication network if this configuration is used.

However, the power supplies must be truly floating, with no hidden paths back to the high-voltage side of the transformers, or to earth ground. Since this is difficult to achieve (there is always some parasitic capacitance between the primary and secondary in any transformer), this method may be more susceptible to high-frequency transients in the high-voltage side of the power lines than the earth-grounded method.

The master unit’s ground establishes the ground for the entire system. The main board ground points are connected to the shield ground at each unit, but are not connected to earth ground. The ground point on the master can be the data converter power supply negative terminal, or the GND pin on the RS-232 cable. If the master is an HGU, its main board ground can be used. This configuration should only be used if the power supplies to the units are truly floating, otherwise ground loops will be created, and differences in local grounds may cause large currents to flow through the cable shield.



3.2.4 Grounding with Grounded Power SuppliesA grounded power supply has one of its outputs connected to earth ground. This makes it somewhat easier to establish a common ground voltage on units at different locations, but some care must be taken. The ground on the power supply output is only as good as the ground at the line power wall outlet. Although most electrical codes require that this ground be very low resistance, in actual fact many outlets do not have good earth grounds at all.

Assuming the ground is a good one, this configuration is no different than earth grounding all units, as described in the previous section and illustrated in Figure 1 on page 33. Care should be taken not to create ground loops with the serial cable shields, using the technique described above of interrupting the cable shield at each unit.

3.2.5 Choice of CableIn general, best results will be realized with low-resistance, low-capacitance, low-inductance, shielded, twisted pair cable. The transmit pair and receive pair should each be put on a twisted pair, so that TX+ and TX- are twisted together, and RX+ and RX- are twisted together. Ideally, each of these pairs should be individually shielded. An outer shield may also surround the two twisted pairs.

It is not usually necessary to go to these extremes in selecting a cable, and testing in RSI labs has shown nearly perfect signal transmittion and reception at 9600 baud over 5000 feet of standard four-conductor flat telephone cable. However, in environments with unusually high electrical or magnetic noise, choosing shielded twisted pair cable can have a dramatic impact on communication reliability, provided the proper grounding and shielding configuration is used.

Tighter twists with smaller wires will provide better immunity to external noise than larger twists with larger wire. The tradeoff will be that smaller wire will have higher inductance, and more twists per foot will raise the interconductor capacitance.



3.3 Communication Protocol

3.3.1 Character FormatRegardless of the physical link, characters are always constructed as follows.

• 1 start bit• 8 data bits• No parity• 1 stop bit

3.3.2 HandshakingThis refers to the ability of stations on a link to signal each other about their state of readiness to send or receive characters. HGUs do not require and do not provide any means of handshaking.

3.3.3 Baud RateThe baud rate is selectable based on the series of which the HGU is a member.

• F series: 300, 600, 1200, 2400, 4800, 9600, 19200, 28800.• E series: 150, 300, 600, 1200, 2400, 4800, 9600, 19200.

Some E series documentation indicates the HGU is capable of communication at 38400 baud; however, it is not usually possible to achieve reliable communication with the HGU at this speed.

The default baud rate is 9600 baud, except for E series modem units, which default to 2400 baud. If a different baud rate is desired, it may be selected from the keypad or by sending the setup data to the unit.

3.3.4 Packet FormatIn this section the communication packet is described. A communication packet is the smallest unit a HGU can use to communicate. There are command packets and response packets, but they share the same format as described in this section.Table 2 on page 37 summarizes the format of a communication packet. Each of the fields is described in further detail below.



3.3.4.1 Start of FrameEvery communication packet begins with the byte 0AH.

3.3.4.2 AddressFollowing the Start-of-Frame character is the address of the station to which the packet is directed. The address field is one byte long.

Each HGU has an address. Addresses must be unique – each HGU must have a different address from every other HGU on the same physical link.

Two addresses are special. Address 0FFH is reserved for the network master, and address 0AAH is reserved for broadcast packets. Typically, PC programs will be the master and so will never direct a packet at address 0FFH, but this is the address that slaves will use when responding to the commands from the master. So PC programs typically are address 0FFH.

It is not recommended that broadcast packets be used. The reason is that there is no response to them, so there is no way to be sure that every HGU on the network properly received the packet.

3.3.4.3 TypeEvery packet, whether a command or a response, has a unique type. This indicates which command or response is being sent. (Some responses may have the same type as some commands. Since any particular station always knows whether it is sending or receiving, there is no ambiguity.) The types are listed in Section 5.0 on page 79.

The type byte actually serves a dual purpose. The lower 7 bits contain the packet type, and bit 7, the MSB, is used as a flag indicating whether the next field, the length field, contains one byte or two bytes.

Failing to set the MSB of the type byte when a two-byte length is being sent is a common cause of communications errors in custom applications – be sure to set the MSB of the type field appropriately.

Table 2: Communication Packet Format

Field Description

Start of Frame 0AH indicates the start of a packetAddress the address to which the packet is being sentType the command or response typeLength the number of bytes in the data fieldData the data being sent – may be 0 bytesFrame Check Sequence CRC or checksum



3.3.4.4 LengthThis field indicates the number of bytes in the Data field, which follows. It may be one or two bytes long, as needed. Some packets have no data and the length field is set to zero.

Note that although packets with 256 bytes of data or more obviously require a two-byte length, packets with 255 bytes or fewer do not require a one-byte length. Applications may send two-byte lengths with every packet. However, the HGU will always select the shortest possible length field when it sends packets, so an application program must be prepared to receive one-byte lengths and two-byte lengths.

3.3.4.5 DataThis is a series of bytes, the number of which is specified in the length field, described above. Some packets contain no data, while others may contain up to 4096 bytes of data. No packet contains more than 4096 bytes of data.

3.3.4.6 Frame Check SequenceThe Frame Check Sequence (FCS) is a one-byte checksum or two-byte CRC. This is used to validate the contents of the packet. Which mode is used is controlled by the two SendStatus commands, described on page 141 and page 142. It is strongly recommended that CRC be used rather than checksum.

The FCS, whether CRC or checksum, is calculated beginning with the address field and ending with the last byte of the data field, or the last byte of the length field if there is no data in the data field.

3.3.4.6.1 CRCThe CRC method of frame checking is the more reliable technique and is what RSI recommends for all applications. It is approximately 256 times less likely to allow an undetected communications error than the 8-bit checksum, and well worth the slight additional code necessary to implement it.

The CRC used is the CRC-CCITT specification. The Appendix provides a C function which can generate the table for performing CRC calculations (see Section 9.1 on page 259). It is strongly recommended that this table be used.

3.3.4.6.2 ChecksumThe checksum is the less preferred method of frame checking. It is strongly recommended that new applications use the CRC frame check method. The capability to perform checksum frame checking is provided only for backwards compatibility with previously written applications.

The checksum that is sent with a packet is zero minus the 8-bit sum of all the data from the address field to the last byte before the FCS field. To validate a received packet,



the receiver should calculate the 8-bit sum of the received packet, then add the result to the checksum in the received packet. The sum should be zero.

The negative of a binary number is not the same as the inverse. The negative of 00000001 is 11111111, but the inverse of 00000001 is 11111110. The correct value to send with a packet is the negative of the sum of the packet bytes.

3.3.5 Pre-Frame and Post-Frame PaddingIn order to allow a small amount of time for turning the output drivers on and off in an RS-485 implementation, the HGU sends 0FFH before and after every packet. These values are not part of the packet protocol. It is quite likely that these bytes will appear garbled at the receiver, since the output driver is turned on or off as these bytes are being sent.

Some older versions of HGU documentation implied that these bytes are guaranteed to be present. They are not. In some situations these padding bytes may appear to be present with 100% reliability, but their presence should not be relied upon in receiver software. See Section 3.5 on page 45 for more information on this.

3.3.6 Timeouts

3.3.6.1 Character TimeoutOnce a HGU receives the address byte of a packet, all the remaining bytes of the packet must follow with no more than a 100 ms delay between them. This timeout is independent of baud rate. If more than 100 ms elapses between characters, the HGU will revert to the state where it is waiting for the Start of Frame byte.

The actual character timeout value is a random time from 100 ms to 200 ms. Times longer than 200 ms are guaranteed to cause a timeout; those less than 100 ms are guaranteed not to, but those between 100 ms and 200 ms may or may not, depending on internal software delays in the HGU. To be safe, ensure that no more than 100 ms elapses between characters. In this manual, we will always refer to the character timeout being 100 ms, with it understood that there is some variability in the actual time.

3.3.6.2 Packet TimeoutThere is no time restriction in the HGU on the total amount of time taken to receive a packet other than that implied by the character timeout. The total time to receive a packet depends on the baud rate, and it is recommended that applications not qualify incoming packets by the total receive time.



3.3.6.3 Packet Start TimeoutThe units receive the Start of Frame and address bytes differently than the data bytes. There is no timeout limit between the SOF character and the address byte. The timeout testing begins with the length byte, which must be received within 100 ms after the address byte is received.

3.3.7 Receiver State MachineIn most cases it is not necessary to have such detailed knowledge of what the HGU is doing internally as is shown here. However, for designing a low-level driver to communicate with the units, it may help to know exactly what they are expecting the other communication station to do and what they will do in response to various data.

The state machine shown in Figure 3 on page 41 is the full description of how the HGU receiver works. The states are WSOF, WADR, TYPE, LEN, DATA, FCS, and OK. They are explained in the text. The timeout event is when the 100ms - 200 ms intercharacter timer expires. This timer is reset each time a character is received. Note that the states which begin with a W do not have a transition on a timeout event.



Figure 3: Receiver State Machine

The states in Figure 3 correspond to the fields in the communication packet. In the WSOF state, the unit is waiting for the Start Of Frame character, 0AH. In the WADR state, the unit is waiting to receive either its address or the broadcast address. In these two states, the unit will wait indefinitely with no timeout until some character is received.

The remaining states represent receiving the command type, length, data, and FCS (CRC or Checksum). The final state, OK, represents the unit starting to take action on the command received.



3.3.8 False StartsSince the Start of Frame (SOF) character, 0AH, is allowed to appear in packet data, it is possible for an HGU (or an application program) to falsely interpret an incoming 0AH in a data region of a packet as a start of frame indication. Unfortunately, this is a weakness in the communication protocol that must be coped with. The good news is that in practice, this does not happen very often, and there is a fairly simple solution when it is happening, but it is something to bear in mind as a possibility if a difficult communication failure is being investigated.

Most of the time a false SOF will cause no harm. When a false SOF is detected, the next byte is assumed to be the destination address. If this happens to match the address of the receiver, then the receiver will begin receiving a packet, starting with the length field. In this case, one of three things may happen.

• First, there may be no further data received, in which case the receiver will time out.

• Second, the false length field may be received, but indicate more bytes than are actually going to come (as the true packet finishes). This will also cause a timeout in the receiver as it waits for the rest of the bytes to come.

• Third, the false length may be less than the actual number of bytes remaining in the incoming packet. In this case, the receiver will progress all the way to the (false) FCS, where, most of the time, the error will be detected.

It is possible to envision scenarios where one HGU on a network gets a false start and potentially never recovers because it keeps seeing data from other units on the network, if the data is just right. The way to ensure that all units on a network eventually get restored to their WSOF state is to pause at least a full character timeout at the end of every packet.

3.3.9 Data ThroughputIn many applications, there is a large number of units on a network, and the host PC is performing real-time polling of these units to gather status information and make decisions. It is important when designing such systems to consider the maximum data throughput that may be achieved.

A single status poll command (SendStatusCRC – see page 142) requires 8 bytes for the command and 11 bytes for the response. At 9600 baud, this limits the polling rate to 52.6 polls per second, assuming no communications delays and no response delays. In practice, it will be difficult to achieve this rate because of slight processing delays in the unit and in the application program. A very efficient application program can achieve a poll rate up to approximately 48 polls per second at 9600 baud.



Downloading datalogs requires 8 bytes for the command and 26 bytes for the response. This implies a maximum transfer rate of about 29 per second at 9600 baud, although again processing delays may reduce this slightly.

User data can be uploaded and downloaded in two ways. Transferring an entire bank of user data, 4096 bytes, using the SendDataBank command, requires about 4.1 seconds. If user records are transferred one at a time using the HereIsUserRecord and SendUserRecord commands, in addition to the communication time, there is a database search time that must be considered as the unit searches its database using a linear search. The communications time for the HereIsUserRecord command is about 35 milliseconds, which implies a rate of 28 records per second if the database is empty. However, this drops to about 5 per second if there are 8000 records in the database.

On average, each user record adds roughly 25 microseconds to the search time on the Model F units, and about 37 microseconds on Model E units. All commands which require database searching will experience this delay. This includes HereIsUserRecord, SendUserRecord, RemoveUserRecord, and VerifyOnInternalData. However, SendLastUserRecord does not experience this delay since the data returned to the host is copied from the results buffer, not from the user database. (See Section 4.4 on page 56 for information on the results buffer.)

When a modem is used, additional delays can be expected due to the modem’s buffering of the data. It is typical to see an additional 100 to 200 milliseconds added to the response time when communicating through a modem.

The Ethernet adaptor introduces approximately 50 to 80 milliseconds of delay, limiting the status poll rate to around 10 to 15 polls per second.

3.4 Communication in High-Level Languages

3.4.1 Binary DataCommunication with a HGU requires some experience with low-level binary data. Many high-level languages interfere with the direct usage of low-level binary data and can make attempting to create an application program a very frustrating experience. For example, in C, if a file is opened in “text” mode, the operating system will typically translate CR/LF combinations (hex 0DH/0AH) into single LF characters when writing, and expand LF to CR/LF on reading. Sometimes the character 1AH is interpreted to mean “end of file” and will terminate file-based input when read. Needless to say, things like this will ruin the data stream to or from the HGU.

In addition, it is very common when saving data to databases to convert binary data to a text representation of that data. For example, setup data and user records are often expanded to text representations of their data in hexadecimal. This is perfectly fine, as long as the conversion back is done before sending the data back to the unit. All data



from the HGU is in a raw binary format, and all data to the HGU must also be in a raw binary format.

Many high-level languages provide support for manipulation of binary data in a raw format, but do not always go out of their way to make it obvious that they do. It is strongly recommended that developers learn the techniques for manipulating binary data appropriate for whatever their chosen development platform is.

3.4.2 Structure Alignment, Byte Ordering, and PackingMany HGU data structures contain multi-byte entities such as integers and arrays. It is very important to understand the exact arrangement of the bytes within these larger entities and make sure that whatever construction is used to represent them in high-level languages can be translated to the format the HGU is expecting.

All HGU data structures should be thought of as simply an array of bytes, each of which has a particular meaning. To access the HGU data structures from high-level languages, three fundamental approaches can be taken.

• First, the high-level language can access the bytes directly, using a pointer and offset.

• Second, a translator layer can be written which copies the HGU data into structures written in the high-level language, and back from high-level structures to the HGU data. This avoids all issues with structure member alignment, packing byte ordering, and structure member ordering, but it takes a great deal of development time to get the translator functions written. This is the approach taken in the RSI DLL.

• Third, high-level language structures can be written which exactly copy the byte and member ordering of the HGU data structures. This is easiest in a language like C, where structure members have a uniquely defined order, and where most compilers provide ways to control exactly how structure members are aligned. However, even in C, the official language definition allows structure member sizes to be different than the member type size, so this approach can be risky.

All integer fields in HGU data structures are low byte first, also called “little endian.” Any 32-bit “long integers” are also low byte first. There are no floating point data objects in the HGU.

3.4.3 Bit-Level ManiuplationsIn addition to being in a raw binary form, the HGU data contains many bit fields. This allows space within the HGU memory to be used more efficiently. For example up to eight TRUE/FALSE type variables can be packed into a single byte, whereas many high-level languages would put such a variable into an entire byte, or even into a four-byte integer type. An example of this type of packing is the response to the



SendSetupData command. The three bytes which make up the HereIsSetupData response contain twenty four TRUE/FALSE fields.

To access the individual bits within a bit field, the language used must support bit-level manipulation, sometimes called “logical” operations. Most languages provide support for all necessary bit manipulation operations (bitwise AND/OR/NOT, shift left/right). However, this topic is often omitted from training courses in high-level development languages. It is beyond the scope of this manual to explain how to do this, but it is strongly recommended that developers who may need such operations consult the appropriate documentation for the development platform they have chosen.

3.5 Controlling a Data Converter (DC-101/102)

3.5.1 IntroductionA data converter is a device which converts RS-232 signals to RS-422/RS-485 signals. It consists of one circuit for converting RS-232 signals to RS-422/485 signals, and another for doing to opposite, converting RS-422/485 to RS-232. The RS-232 end of the device is connected to a host RS-232 port, which is typically a PC serial port. The RS-422/485 end is connected to a network of HGUs.

Recognition Systems provides a data converter called the DC-102. An older version of this unit was the DC-101. These two products are virtually identical functionally, and no distinction between them will be made in this manual. In this section, the RS-422/485 side of the data converter will be called the “network” side.

3.5.2 Network Side Transmitter ControlThe RS-232 side of the data converter is always “on,” meaning that the data converter is always driving the RS-232 transmit line. However, on the network side, the transmit channel drivers can be turned off. This is because an RS-485 network (two wires) has one bi-directional channel, so stations on the network must disconnect their transmit drivers when they are not transmitting.

The network side’s transmit output is controlled by the RTS line on the RS-232 port. When RTS is in the MARK state (negative voltage) the network-side transmitter is enabled. When RTS is in the SPACE state, the transmitter is disabled.

3.5.3 RS-422 NetworkFor a network wired for RS-422 (the four-wire version) using a data converter is quite simple. Simply set the RTS line to the right level and leave it there.



3.5.4 RS-485 NetworkOn an RS-485 link, there is only one pair of wires, so there is only one channel, and it must be shared between the two directions of communication. This is another reason why the Master/Slave distinction is important.

When the Master wants to send something, it enables its output driver and sends the data. When it is done, it turns off its output driver so the target Slave can transmit its response. When the Slave is done responding, it must turn off its output driver so the Master can use the channel to send the next command. This need to constantly be aware of the state of the output driver makes the software drivers for communication over an RS-485 link somewhat more difficult to successfully design.

This is also why the pre-frame and post-frame padding characters are used. The pre-frame padding character provides a convenient way of ensuring there is a delay between the moment the transmitter is turned on and the moment the first bit of the SOF character gets sent. The post-frame padding character is used because UARTs typically issue an interrupt when the holding register is empty, not when the last bit of the last character is sent. By adding the post-frame padding character, the transmit driver can ensure that the last byte of the packet is sent before the transmit driver is turned off.

3.5.5 Notes for Windows Users

3.5.5.1 Windows and RS-485Since all direct hardware interactions are handled by the Windows operating system, there is no way to know the exact moment at which the last character is leaving the UART. This is because there is a huge latency between the time a transmitter becomes empty and the time an application program gets notified of this fact. This means that the PC cannot know the correct time to turn off the network-side transmit driver, so RS-485 communications cannot be directly implemented in a Windows program.

To handle this situation, RSI provides a special data converter, the DC-103, which monitors the communications and manages the RS-485 drivers correctly. This problem does not occur with DOS-mode programs if the system is programmed to allow direct writes to hardware.

3.5.5.2 Windows NT and DOS ProgramsThe Windows NT serial port virtual device driver does not properly report the status of the UART. This can cause problems establishing the correct moment to turn off the data converter network side transmit drivers. It is recommended that in a Windows NT environment, the RS-422 link be used rather than RS-485, or that a DC-103 be used.



3.6 Programming your ModemAlthough using a modem solves the problem of the limit imposed on where the HGU can be located, it introduces some complexities into the software that is communicating with the HGU. The software must first communicate with the modem and get it to establish a connection to the HGU modem. This can often be a difficult and frustrating process. It is beyond the scope of the manual to provide a comprehensive discussion of how to program modems, but some useful suggestions can be provided.

3.6.0.1 RetryExpect communication errors when communicating over a modem link. Design your software to retry commands several times when an error is encountered, rather than terminating the link at the first error. Even the best modems optimally configured will encounter noise on the telephone lines which can result in communication errors. Anticipating these errors in the application program design can greatly improve the overall stability of modem communication.

3.6.0.2 Select the Right Baud RateExtensive testing in RSI labs has shown that in the majority of cases, the best initialization string to use is simply ATZ or AT&F, which reset the modem to factory defaults. Provided the baud rate from the PC to the modem is correct (which will be defined in a moment) most modems work quite well with no further configuration.

The correct baud rate to choose depends on the model of HGU at the other end of the phone line. Model F units communicate with their modems at 9600 baud, and Model E units do so at 2400 baud. Matching this baud rate at the PC generally leads to the best performance.

It will actually impair overall performance to communicate with the PC modem at a higher baud rate than the HGU is using to communicate with its modem. This is because the difference in baud rates requires the modems to buffer data and engage in handshaking, which can introduce delays in the overall data flow. More than any other factor, selecting the correct baud rate at the PC will help improve the reliability of the modem connection.

3.6.0.3 Other SuggestionsIf trouble is experienced after simply using the factory default settings for the modem, the following suggestions may help.

Although the modem in the Model F HGU supports data compression, it is recommended that the PC modem not use this mode. Data compression can introduce significant intercharacter delays which the HGU is not expecting. Similarly, other high-level modem features such as auto-retrain can cause communications to stop for extended periods of time and should be disabled. Although these features may seem to



be helping by adding additional speed and reliability, they actually end up causing more trouble in some circumstances.

Disabling all these features of the modem may seem to reduce the reliability of the link, but the command protocol to the HGU has sufficient data integrity checking in CRC mode that virtually all errors will be detected. The application program can then resend the command until an acknowledgement from the HGU is received.

Recognition Systems has noticed through customer feedback, and has confirmed in our labs, that some modern, high-speed modems have problems working at lower baud rates like 2400 baud. This problem seems to be isolated to certain specific manufacturers. It is recommended that if frequent data errors are observed when attempting to communicate with a HGU, especially at 2400 baud, that the first course of action be to change to a different brand modem.

3.7 Setting Up an Ethernet ConnectionThe easiest way to work with a TCP/IP connection on Windows machines is to use the DLL provided by RSI. If it is not desired to use the DLL, the next easiest way to establish the TCP connection is by using the Windows Sockets API. It is beyond the scope of this manual to explain how to do this, but some example code can be found in the Windows DLL. On Unix machines, the Berkeley Sockets API is commonly used. Developers on other platforms should refer to the documentation for those machines for instructions on how to establish a TCP connection.

3.7.0.1 TroubleshootingDiagnosing a non-functioning Ethernet or TCP/IP link can be frustrating and difficult, and generally requires specialized training in network setup. It is strongly recommended that a trained network technician or engineer be consulted when attempting to install a HGU on an Ethernet network.

In general, the simplest way to begin is to have a host machine connected only to the HGU, either via a hub or via a direct connect Ethernet cable. This eliminates any possible problems with other machines that may be on the network. Once the host can ping the HGU, a TCP connection should be easy to establish. After establishing the TCP connection with the unit which contains the Ethernet adaptor, it should be easy to communicate with other units through the RS-422 connection, or other units at different IP addresses.

3.7.0.2 TCP PortThe Ethernet adaptor has been programmed to use TCP port 3001.This is not adjustable.



3.7.0.3 Gateways and Subnet MasksThe Ethernet adaptor in the HGU should work in most LAN and WAN configurations. The address of a gateway can be entered, and a menu is available by special order which allows a subnet mask to be programmed.

Once a host can establish a TCP link with the HGU’s Ethernet adaptor using the simple configuration described above, it should be possible to establish a TCP link in any LAN or WAN. If the link is working when only the host PC and the HGU are connected through an isolated hub, but not when connected to the LAN or WAN, contact the network administrator for guidance on what may be going wrong. Due to the wide range of possible network configurations, Recognition Systems will be unable to provide support in troubleshooting TCP/IP connections in LAN and WAN environments.

3.7.0.4 Notes Regarding DHCPPlease note that the Ethernet adaptor does not support DHCP at this time, and RSI does not plan to support it in the future. The HGU should therefore be assigned a static address in the network’s address scheme.

DHCP is most useful when IP addresses are frequently allocated and released from workstations that utilize the addresses for short periods of time. Since the HGU is on continuously in most installations, it will always be consuming the IP address that the server allocates to it. In addition, while it may be true that in some applications, communication with the HGU is infrequent, the communication is initiated by the host program, not by the HGU, so the HGU must always be ready to receive data. It will never initiate communication, but only respond. So if it were to release its IP address, it would have no way of knowing when it should ask for another one. DHCP is therefore of limited value in an HGU installation.

3.8 Troubleshooting a Communication LinkAlthough it is not possible to provide a comprehensive troubleshooting flowchart due to the wide variety of communication configurations and possible problems, some general advice can be given.

• When first attempting to establish communications with a unit, it is very helpful to have a PC program which is known to work. Recognition Systems provides a number of test and demo programs which can be used for this purpose, such as WinHand and MODEM.

• Avoid trying to set up a complete network of units until communication with a single unit has been established.

• Make sure the address and baud rate of the HGU is set to match the what the PC is doing.

• Make sure the HGU is set to Remote mode.



• If an RS-422/485 data converter is being used, make sure it is wired correctly and power is applied to it.

• Check that the PC program is set to use the same serial port that the cable to the HGU is plugged in to, and that no other application is using the port. Often, under Windows 95, 98, and NT, a single DOS box using a com port can block other DOS boxes from using all com ports.

• It may help to have an RS-232 test box attached to the PC’s serial port. This can give a visual indication that data is being emitted by the PC’s serial port.

• When using a modem, be sure the phone line is plugged in to the correct jack on the modem. It should be in the “Line” jack, not the “Phone” jack. Be sure the modem is powered on. You should hear a dial tone when it goes off-hook.

• When using an Ethernet adaptor, be sure the PC and HGU are plugged in to the network correctly. Either a hub or a special point-to-point network cable must be used; you cannot connect the HGU directly to the PC’s Ethernet port with normal cables.

• When the Ethernet connection is properly working, you should be able to ping the HGU’s Ethernet adaptor. Until this works, something is wrong with the network connection. However, ping does not test the TCP connection, so there may still be problems. Some network software can intercept TCP connection attempts and redirect them in unexpected ways; see your system administrator if you find you can ping the HGU but not open a TCP connection.

• Take advantage of the troubleshooting modes built in to some HGU models. See Section 4.16 on page 74 for more information.

• In particularly difficult cases, it may be helpful to add RS-232 or RS-422/485 monitors onto the serial lines. There are also Ethernet snoopers which can monitor communications on the Ethernet connection.

• Some testing configurations are shown in the following figures. The monitoring device may be an oscilloscope, logic analyzer, or a PC running a terminal program which can show binary data. It needs at least two channels in order to monitor communication in both directions. Single-channel devices can be used, but only one direction can be monitored at a time.

3.8.1 Configuring a Unit for Serial CommunicationsWhen trying to develop a new PC application using a HGU, much time can be wasted troubleshooting serial communications if the unit itself is not properly configured. Since there are quite a few options that affect serial communications, it is worth explaining here how to configure a unit’s serial communication parameters.

3.8.1.1 Model E HandPunch UnitsThe command menu is entered on HandPunch units by entering 0 before an enrolled ID, or simply entering 0# if no users are enrolled. At the “Enter Password” prompt, enter the password for the menu to which you wish to gain access. The factory default passwords are simply 1,2,3,4,5. The serial configuration menu is in command set number 2.



Scroll through the menus by pressing the * key until the “Set Serial” menu appears. Press the # key and the unit will display the baud rate for channel 0, which is the RS-422/485 communication channel. The factory default baud rate code is 2, which corresponds to 9600 baud. Other codes may be selected if the host communication is at a different rate. The baud rate codes are listed in Table 15 on page 177. To change the baud rate, enter the code number for it and press #. To leave the baud rate alone, simply press # without entering a code.

After entering the channel 0 baud rate, the unit will advance to the channel 1 baud rate, which is for the RS-232 output port. This code number has the same meaning as the other channel.

After the baud rates are displayed, the unit will show its address and prompt for a new one. To accept the current address, press #. HandPunch units are always in remote mode, so there is no menu for selecting Master/Remote/Standalone.

It is possible to set a HandPunch unit to Master or Standalone by sending it the appropriate setup data from a host computer. This practice is discouraged, but some communication problems can be caused by setting a unit to Master or Standalone inadvertently.

Do not set the unit to address 170 (AAH, the broadcast address) or 255 (FFH, the network master address). Do not set two units on the same network to the same address.

3.8.1.2 Model E HandKey UnitsOn HandKey units, press the # key while the “ID VERIFIED” message is displayed after a hand verification, or simply press the # key at the “Ready” prompt if no users are enrolled. At the “Enter Password” prompt, enter the password for the menu you wish to gain access to. The factory default passwords are simply 1,2,3,4,5. The serial configuration menus are all in command set number 2.

The first thing that needs to be set for host communications is the “Reader Mode,” which should be set to Remote. Press # for Yes when the “Reader Mode” menu appears, then press * to scroll through the options until “Remote” appears, then press # for Yes. The unit will then prompt for an address, then press * to scroll through the options until “Remote” appears, then press # for Yes. The unit will then prompt for an address.

The factory default address for HandKey units is 0. If desired, a different address may be entered. To accept the current address, simply press #. The unit will now return to the “Reader Mode” menu.



Press * to scroll through the menus until “Set Serial” appears. Press # for Yes. The baud rates may be changed as described above in the HandPunch section. The HandKey units do not have their address set in the same menu as the baud rates are set.

Setting a unit to Master mode will change its address to 255 (FFH) and will cause it to behave as a master. It will not be possible to communicate with the unit from a host PC if it is a master. If a unit is in Master mode and it is changed to Remote mode, address 255 will be displayed as the unit’s address, and the address must be changed to something other than 255.

Do not set the unit to address 170 (AAH, the broadcast address) or 255 (FFH, the network master address). Do not set two units on the same network to the same address.

3.8.1.3 Model F UnitsThe command menus are entered by pressing Enter and Clear either simultaneously or quickly in sequence. All the serial communications configuration is in menu 2, so at the “ENTER PASSWORD” prompt, enter the password for menu 2. The factory default password for this menu is “2”. The menu items which affect serial communication are Set Address, Set Reader Mode, and Set Serial. Not all these menu items are present on all models.

To set the address, go to the Set Address menu. Enter the new address at the “New” prompt and press Enter. Do not set the unit to address 170 (AAH, the broadcast address) or 255 (FFH, the network master address). Do not set two units on the same network to the same address.

To set the baud rate or serial channel for host communications, go to the Set Serial menu. If the RS-422/485 channel is present, the unit will ask if you want to configure this channel. Pressing Yes (#) will show the current baud rate. Select the baud rate desired by pressing No (*) until the correct baud rate appears. Pressing Yes will select the baud rate currently on the display.

Next, the unit will ask if you want to configure the RS-232 port. Pressing Yes will show the RS-232 port’s baud rate. This works the same as the RS-485 baud rate selector. When the baud rate is selected, the unit will ask if you want to use the RS-232 port for printer or host communications (except the HP-2000, which always has host communications on the RS-232 port). Pressing 1 will select host communication. Pressing 0 will select printer output. The factory default is printer output.

To set the reader mode on HandKey units, scroll through the menus to the “Set Reader Mode” menu. Press # for Yes. The unit will cycle between Master and Remote until one is selected by pressing #. Model F units do not have a Standalone mode. For stand alone operation, set the unit to Remote mode. Units are shipped configured for Remote mode. HandPunch units are always in Remote mode.



It is possible to set a HandPunch unit to Master or Standalone by sending it the appropriate setup data from a host computer. This practice is discouraged, but some communication problems can be caused by setting a unit to Master or Standalone inadvertently.

When a unit is changed from Master mode to Remote mode, it will prompt for a new address. Units are assigned address 255 when they are set to master mode, so this must be changed when they are taken out of master mode.



Blank page.



4.0 Hand Geometry Unit Inner Workings

4.1 IntroductionThe purpose of this section is to provide some detailed information on what the HGU is doing when IDs are entered and verification happens. This information can be helpful when trying to understand how the function key menus work, when the score of verifications is valid, and why certain types of datalogs are recorded. The information here is intended to be background information which should be understood before attempting to design a system with a HGU. This section is not a programming reference; reference material which will be helpful during actual software development work is given mainly in Section 5.0 on page 79. This section also does not cover the basics of how to operate the unit; refer to the Installation and Operation Manual for the specific models for that information.

4.2 EnrollmentEnrollment is the process of acquiring a template to be used as a baseline reference for verifying a user. If initiated from the HGU keypad, an ID must be provided for the enrollee, and when the enrollment is complete, a record will be created in the user database with that ID. If initiated remotely, from a host PC, there is no ID provided, and no user record is created when the enrollment is complete. The enrollment template is available to the host PC to do with whatever is necessary. It may be used to create a new user record in the HGU, or it may simply be stored in a database on the PC.To acquire the enrollment template, the HGU takes three hand readings and averages them together. The templates from the three readings must be close together in order for the enrollment to accept them. “Close” means that the maximum score between them must be less than 60% of the system reject threshold. If the three readings are too different, the user is asked to place his hand several more times until they match, or until the HGU gives up and aborts the enrollment.Whether initiated locally or remotely, the result of the enrollment is stored in a template buffer in the HGU which may be accessed by the host PC (see the SendTemplate command).

4.3 What Happens When an ID is Entered for VerificationAfter users are enrolled, the HGU is waiting for someone to walk up to it and enter an ID. There are two fundamental ways an ID may be entered to an HGU: from the keypad or via a card reader (see the section on card readers for more details). An HGU follows the same series of events upon receiving an ID, regardless of how it was received. However, remote verifications do not follow this sequence of events. See the command description for the VerifyOnExternalData command for details on how remote enrollments proceed.



The complete sequence of events following an ID entry is rather complicated, and is best diagrammed with a flowchart, but at its simplest level, the receipt of an ID initiates a hand verification. The user will be prompted to place his/her hand, and if the template from that image matches the template in the user database (or the template received from the PC in the case of a remote verification) a transaction will be put in the transactions buffer. Other actions, such as the lock output turning on, may happen, depending on the model and configuration of the particular HGU.

Before the hand verification happens, a number of decisions are made based on the ID entered. These decisions are explained in Section 4.5 on page 57. The results of the verification are available to the host PC via several commands. See Section 4.4 for further details, or refer to the descriptions of the specific commands in Section 5.0 on page 79.

Those units which support function key menus may have a menu activated when an ID is entered. This is the “Explicit Punch” menu. Other models have a hard-coded explicit option which may be enabled by setting the “Accounting Mode” field in the setup data.

4.4 Results Buffer and Template BufferThere are two storage areas which hold information from any access attempt. The data in these buffers can be retrieved by host commands as described below.

4.4.0.1 Results BufferThe results buffer holds the ID and score of the last hand reading. This is what is returned with response type ‘5’, HereAreResults. The unit returns this data in response to command type ‘C’, SendResults. See page 154 for more details. If the last ID entered was not in memory (the NIM flag is set in the status data), it is also stored here. In the NIM case, the score will be undefined.

4.4.0.2 Template BufferThe template buffer holds the averaged template and score of the last hand reading. This is what is returned with response type ‘7’, HereIsTemplateVector. The unit returns this data in response to command type ‘K’, SendTemplate. See page 170 for more details.

This is where the template that results from any enrollment or verification is stored. For enrollments, this template is the average of the several hand readings that occur in the enrollment process. For verifications, the template that is stored here may not be the exact template that was derived from the hand image because the unit will average the image template with the reference template if there is a match (see Section 4.8 on page 63 for more on template averaging). Still, any time the unit is able to generate a template from the object in the image area and attempts to generate a score against a reference template, the result is stored in this buffer. If an object is in the field of view



of the unit but cannot be recognized as a hand, or if no object is put in the unit before it times out, no template is generated and the template buffer is not changed. See Section 4.6 on page 59 for more details. If the reference template and image template do not match within the threshold in effect at the time of the comparison, the image template is stored here and the reference template is not updated with the average.

Note that the template returned in response to the SendLastUserRecord command (‘@’) is not the contents of the template buffer, but rather the template taken directly from the last hand reading image, prior to performing the average against the reference template. This unaveraged template should not normally be retrieved or stored in host PC databases.

4.5 Validation of the ID NumberThe purpose of this section is to describe how the units decide whether to proceed with a hand verification once the ID has been entered. The same decisions are made whether the ID is entered from the keypad or by a card reader.

First, the HGU must search the user database for a record with a matching ID. If none is found, the HGU double beeps, sets the NIM flag in the status data, and returns to waiting for an ID. If the ID is found, the time restrictions for that individual are checked. If this user is not allowed to punch or gain access at the current time, the HGU displays a message on the LCD and initiates the TZVIOL event.

There are several types of time restrictions, and not all models use all of them. First, there is a global restrictions override flag which can be set by the command menus in T&A units (HandPunch). Setting this flag allows everyone to punch at any time. Second, there is the time zone in the user record. This is checked only if the global restrictions override flag is not set. When a user enters his ID, the unit’s clock must indicate that the current time is in the time zone that is programmed for that user or access will be denied, a TZVIOL event will be generated, and a datalog format 42 will be recorded.

HandPunch-4000 units add additional time restriction features, time intervals and amnesty punches, which are explained more fully in Section 4.15 on page 68. For the purposes of this section, we will simply describe where in the process these items are checked. Time intervals take precedence over time zones and are checked before time zones, right after the global restrictions override flag. If any time interval for a user is current, the verification can proceed. If none are, then the time zone is checked. Amnesty punches are checked after all other time restrictions have failed to grant access.

The ID entered, whether valid or not, and whether in memory or not, is stored in the results buffer and is available through the SendResults command.



4.5.1 Time ZonesThe time zone stored in the user record is an index into a time zone table. This table contains 60 time zone entries, numbered 1 to 60. Time zone 0 is reserved to mean “always” and time zone 61 is reserved to mean “never.” Putting other values into the time zone field of a user record will result in the unit behaving unpredictably.

A time zone consists of four time intervals and four day-of-the-week (DOW) masks. The exact layout of a time zone entry is shown in Table 29 on page 194, and the format of the DOW mask is shown on page 184. A time interval consists of a start time and a stop time. Start and stop times are specified in 6 minute (1/10 hour) increments starting with midnight, which is zero.

A time zone becomes current when three things are true. First, the units’s clock must indicate that the current time is greater than or equal to the start time of at least one of the time zone’s time intervals. Second, the current time must be less than the stop time of that span. Third, the current day of the week must match one of the days set in the DOW mask for that time interval.

For example, a start time of 0 and stop time of 1 means from midnight to 00:05:59. A start time of 216 represents a time of 21.6 hours past midnight, or 21:36, or 9:36 PM. The highest meaningful value a start time can have is 239, which is 11:54:00 PM. In order for a time interval with this start time to work, the stop time must be 240 or greater. Such a time interval will be current from 11:54:00 PM to 11:59:59 PM. This means that in order to establish a time zone which spans midnight, two time intervals must be used, one for the PM portion and another for the AM portion.

If the start time of a time interval is greater than or equal to the stop time, regardless of the actual values, the time interval can never be current.

4.5.2 HolidaysHolidays are days on which no one is normally allowed to gain access or punch in. Only those who are in a time zone which has at least one time interval whose DOW mask has the holiday bit set will have their ID’s validated on a holiday. The holiday table is sent to the unit along with the time zone table using the HereAreTimeZones command (see page 105). Each month is assigned a 32-bit mask, and the bits in this mask correspond to the days of the month. The format of the holiday table is shown in page 194.

4.5.3 HP-4000 Time IntervalsThe HandPunch 4000 unit introduces a different method for time restrictions. This is different from the time intervals in the time zone table in two ways. First, instead of having a global table with an index stored in the user records, the HP-4000 time intervals are stored directly in each user record. This allows the potential of each user having different time restrictions rather than limiting the system to a total of 60



different time restriction schedules. Second, the time intervals allow validation to be controlled down to the minute, rather than in 6-minute increments like time zones.There is a section in this chapter devoted exclusively to the HP-4000 features. Please refer to Section 4.15.3 on page 69 for a full description of how HP-4000 Time Intervals work.

4.6 Hand VerificationOnce the ID number has been verified, hand verification begins. Alternatively, hand verification can be initiated remotely, by sending a command from the host PC. The same series of steps is taken either way, and the results will be either a successful verification or a failure. Note that by the time verification starts, the ID has already been placed in the results buffer (see Section 4.5 on page 57) and it is not changed, regardless of the outcome of the verification.

4.6.1 Successful VerificationThe results of a successful hand verification are the template derived from the hand image and the score this template has against the reference template (either from the user database or the host PC). The results will go into the results buffer and the template buffer, described above. The template is placed in the template buffer. The score is placed in the results buffer and the template buffer.

A successful verification will result in either the door lock output being activated, which is described further in Section 4.7 on page 61, or a data stream being emitted from the card reader outputs. Additionally, for local verifications (initiated by keypad or card reader ID entry, rather than by the host VerifyOnExternalData command) a datalog format 7 will be recorded with the ID that was entered. Remote verifications do not generate a datalog.

4.6.2 Failed VerificationA hand verification attempt can fail for a variety of reasons. Most of these failures produce an entry in the transactions log, and some of them can be used to trigger the auxiliary outputs. In addition, there is a set of bits which the host PC can read which indicate the status of a verification.

4.6.2.1 Obstructed Image AreaIf there is an obstruction in the image area at the beginning of the verification process, the HGU first assumes the user’s hand is in, and displays “Remove hand” on the LCD. If the hand (or obstruction) is not removed within a certain time, the verification fails, but no datalog or event is generated. The template buffer is not changed in this case and will contain whatever data was there before the verification started.



4.6.2.2 Inability to Read HandIf no hand is placed into the HGU before a certain time, the verification is aborted. The unit reverts back to waiting for an ID to be entered, and no datalog or event is generated.If something is placed into the HGU, but the HGU cannot recognize it as a hand or is unable to generate a template from it, the user is rejected. This is handled the same as if the unit reads a hand but the hand fails to match the enrollment template. See the next section for details.

In either case, the template buffer is not changed when the unit is unable to read a hand or recognize the object in the field of view as a hand.

4.6.2.3 Template Does Not MatchIf a template can be generated from the hand image, but it does not match the enrollment template well enough to generate a score below the appropriate threshold, one of several courses of action will be taken, as will be described in the next paragraph. The score that is used as the threshold will be the threshold set in the user record if it is not zero, or else the global threshold set in the setup data. Note that for remote verifications (host-initiated), there is no test against any threshold, but rather the template and score are simply put into the template buffer and results buffer as described in Section 4.6.1 on page 59.

When the template from a hand image fails to match the enrollment template, the unit will take a course of action based on a variety of things. First, if the score was less than twice the threshold in effect when the hand is read (either the user’s or the global, selected as described above) then the user will be asked to retry up to three times. If the score is more than twice the threshold or this is past the third attempt, the user will be rejected.

How a rejection is handled depends on how many consecutive times an ID has been rejected. There is a programmable count which selects whether this ID will be locked out or allowed to try again. (This is the “Number of Tries” field in the basic setup data. See Table 14 on page 173.) If the number of consecutive rejects is less than the maximum number allowed, the TRY AGAIN event will be generated, the “TRY AGAIN” message will appear on the LCD, the unit will beep twice, and a datalog format 3 will be recorded. If the number of consecutive rejects has reached the maximum number allowed, the last ID entered is locked out. This is described in the next paragraph.The TRY AGAIN event can be used to trigger auxiliary outputs, as described in Section 4.11 on page 64.

4.6.2.4 ID LockoutWhen the number of consecutive rejects reaches the maximum programmed in the “Number of Tries” field of the setup data, the unit will display “ID REFUSED”, make a warning sound, generate the ID REFUSED event, and record a datalog format 6.



(The ID REFUSED events can be used to trigger auxiliary outputs, as described in Section 4.11 on page 64.) This ID will not be accepted anymore until a successful verification occurs.

Note that the each consecutive reject counts toward the maximum, even if they are not the same ID. The ID that is locked out, however, will be only the one that was used on the last reject when the count reaches the maximum. After an ID is locked out, the count is reset. The count is also reset after any successful verification. However, sending the setup data does not immediately re-initialize the remaining retry count.

Currently, all models allow up to seven IDs to be locked out at a time. If an eighth ID number needs to be locked out, the unit will generate the ID REFUSED event and display the same text and make the same noise as if the ID were locked out, but the ID will not actually be locked out and it may be entered again. The size of the list of locked out IDs may change in the future.

All locked out IDs are unlocked when a successful verification happens.

4.7 Door ControlsOnce access has been granted and the identity of the user has been verified, most access control systems and some T&A systems will allow a door to be opened. The HGU supports full door control logic. This section describes the door controls and shows the state machine for the door controller. Note that the door controls are disabled when the unit is put into card reader emulation mode, which is done either by a command menu (on HandKey models) or by programming the “Output Mode” field in the setup data. Refer to the operating manuals for details on how to use the command menu, and refer to the OutputControl command description on page 121 for the allowable values for the Output Mode field.

When the identity of the user is verified, the HGU will activate its lock output. The duration of time the output is active is programmed by the “Lock Time” field in the setup data. If the door opens during this time, which is detected by the door switch input, then a door timer starts. The duration of the door timer is programmed by the “Shunt Time” field in the setup data. The door must close before the door timer expires or a door alarm will result.

The state machine for the door controller is shown in Figure 4 on page 62. Note that the lock output is activated when the OPEN state is entered. Datalogs are issued when certain events occur, as shown in the figure. The Unlock event which causes the transition to the OPEN state is the same Unlock event that can be used to activate the auxiliary outputs on Model F units.

The states are IDLE, OPEN, WAIT FOR CLOSE, and ALARM. The events above the lines cause transitions between states. The lock output is activated when the UNLOCK



state is entered. Note that the transition out of the ALARM state is unconditional. The timeout for the OPEN to IDLE transition is the lock time in the setup data, and the timeout for the WAIT FOR CLOSE to ALARM state is the shunt time.

Figure 4: State Transition Diagram for the Door Controller



4.8 Templates and ScoresA template is a nine-byte string that contains the biometric data for a given hand image. The nine bytes do not correspond to any particular features on the hand, and there is no way to reconstruct a hand image from a template. The template can be thought of as an optimally “compressed” representation of the measurements of the features of the hand that the hand geometry unit makes.

When two templates are compared, a score results. A perfect match, meaning all nine bytes are exactly equal, gives a score of zero. Higher scores indicate greater mismatch between the templates. Note that a perfect match is extremely unlikely. “Correct” scores (meaning the hand presented is in fact the same hand that was enrolled) range from 10 to 100 over 98% of the time.

Normally, there is no need to write code to compare templates, since the HGU provides scores for all verifications. All that is necessary is to decide whether the score is within the acceptable threshold. Setting a high threshold allows fewer false rejects to occur, but increases the chance of a false accept. Setting a low threshold reduces the probability of a false accept, but does so at the expense of the false reject probability. The HGU has been designed so that the optimal balance between the probability of a false accept and a false accept is reached at a threshold of 100. Most systems work best when the threshold is set from 75 to 125.

In order to accomodate possible long-term changes in people’s hand geometry, the HGU will average each hand reading into a user’s reference template. This takes place each time a score comparison results in a successful match. Note that the averaging algorithm is proprietary time-domain filter and is not simply half the sum of the image and reference templates. Do not attempt to perform template averaging in a host PC program. Always retrieve the updated template from the HGU after a successful hand reading if the PC is to store templates or manage the distribution of templates across a network.

4.9 Transactions LogAll transactions are stored in a circular buffer called the transactions log or datalog buffer. Different models have different datalog buffer capacities. Each datalog consists of a time stamp, an address indicating which reader recorded the datalog (useful in Master/Slave mode), a format number indicating what event caused the datalog, and ten bytes of data, not all of which necessarily have meaning in all formats.

Datalogs are retrieved from the HGU to a host PC using the SendDatalog (‘M’) command (see page 129) and the SendPreviousDatalog (‘m’) command (see page 137).

Since the datalog buffer is finite, in HandPunch units, a warning will appear on the LCD when the buffer starts to get full. When 80% capacity is reached, “MEMORY



LOW” will appear on the second line of the LCD instead of the time. When the last datalog is recorded, “MEMORY FULL” will appear and the unit will stop doing anything which may generate a datalog. This is to protect the punches which are stored in the unit. To remove these warnings, retrieve the datalogs from the unit.

HandKey units do not have the memory low and memory full warnings. Since the datalog buffer is a circular buffer, when it gets full, new datalogs will overwrite the oldest datalogs.

4.10 Setup DataAs described in Section 2.3.13.2 on page 20, the Hand Geometry Units contain one or two 128-byte blocks of setup data. The full layout of the data in the setup data areas is also shown in Section 5.6 on page 173. Note that some fields in the Basic Setup Data overlap in function with similar fields in the Extended Setup Data. This was necessary to allow Model F units to be backwards compatible with software meant for Model E units. Each time the host PC sends either the Basic or Extended data, the other data area is reconciled with the incoming data in the HGU.

4.11 Events Controlling OutputsThe hand geometry units can be programmed to activate their outputs when certain events happen. These events are listed in Table 3 on page 65. Note that not all events are supported on all models.



The events which are supported on both models have “E+F” in the “Models” column.Outputs are programmed to activate when certain events happen by setting flags in the setup data areas. See the descriptions of the HereIsSetup command on page 114 and HereIsExtendedSetup command on page 112, and the descriptions of the Basic Setup Data command on page 173 and the Extended Setup Data command on page 185 for more details.

4.12 Controlling a Bell – HandPunch Units OnlyHandPunch units may be used to activate a bell at pre-programmed times. The bell schedule contains up to 100 activation times. The auxiliary output (Aux Out 0 on those units with multiple auxiliary outputs) is used for this. The HereIsBellSchedule command is used to load the bell schedule into the unit. See the HereIsBellSchedule command and data structure on page 107 for details on the bell schedule data format.

Table 3: Auxiliary Output Events

Event Models Description Model E Flag

TAMPER E+F The tamper switch is activated TTZVIOL F only A user is attempting to gain access or

punch outside the authorized timenone

IDREF E+F An ID is locked out IDURESS E+F The duress code is entered at the keypad

(see Section 7.5 on page 255)Duress

AUXIN1 E+F Aux Input 1 is activated AAUXIN2 F only Aux Input 2 is activated noneDOOR F only Either the “door forced open” or “door

open too long” condition is activeD

TRYAGAIN F only Score is out of range, user must re-enter ID

none

F1KEY F only The F1 key is pressed noneF2KEY F only The F2 key is pressed nonePOWER F only The unit’s external power is lost and it is

running on battery powernone

UNLOCK F only A hand was verified, access was granted noneAUXKPD F only An ID was received from the auxiliary

keypadnone



4.13 Function Key MenusModel F units support custom menus, sometimes called “decision menus,” for the collection or display of data. Although this feature is most useful for Time and Attendance applications, HandKey units support the full functionality of the function key menus as well. The menus are defined by a script in a text file that can be created with any standard text editor. This script is then run through the function key compiler, a program called FKPARSE, which produces a binary data image. That binary data is then loaded into the unit using the HereIsDecisionMenuData command (see page 109). The internal format of this binary data is not documented, and no mechanism for creating it other than using FKPARSE is supported.

The decision menu script language and the operation of FKPARSE are explained in the Function Key Compiler Manual. This section describes how the data is collected, when the menus are activated, and how to retrieve the data from the datalog buffer.

4.13.1 Transactions LogData collected by function key menus is saved in the datalog buffer, just like other transactions. Each piece of data gets a single datalog of format 7, the same as the ID Verified transaction. The collected data goes in the Data2 field of the datalog.

4.13.2 Retrieving Decision Menu DataFunction key menu data is retrieved using the SendNextDatalog command, just like any other item in the transactions log.

A common question is how to tell when data collection has stopped when retrieving datalogs from the unit. The first datalog will be the ID verified transaction, then datalogs with format 7 will follow, but it is not always known how many will follow or when the sequence terminates. The HGU does not automatically mark the end of the data collection sequence in order to reduce overhead in those applications which have a simple, fixed menu structure. If it is necessary to mark the end of data collection so that the host PC can know when to terminate, it is best to add into the menu definition a collect object of type TA with a unique TA code. This code will mark the end of the menu execution and signal the host PC that data collection has stopped.

4.13.3 ID First, ID Last, Data QueueMenus which are activated by pressing a function key can take one of two basic courses. One course, called “ID last,” is to run and collect all their data before asking for an ID and verifying the hand. The other course, “ID first,” is first to get an ID, validate it, then start running the menu, and finally perform the hand verification. Which way the menu operates is specified in the menu definition script and is up to the menu designer.



Either way, the data is collected into a temporary buffer and not committed to the datalog buffer until the entire process is complete. The datalogs which correspond to the menu data collection will always follow the datalog that corresponds to the verification of the user’s identity, regardless of whether the menu is ID first or ID last. The time stamp of the data collection datalogs will be the time at which the individual data items were committed to the datalog buffer. They may not match the time stamp of the hand verification, and they may not match each other.

4.13.4 Explicit PunchThe explicit punch menu, if present, is activated every time a user punches. This menu does not depend on a function key being pressed, but rather is triggered simply by a punch. This is useful if there is a menu which must be entered every time users punch, rather than relying on them to press a function key.

The explicit punch menu will execute after an ID is entered if the ID is valid (i.e. passes any applicable time restrictions; see Section 4.5), before the hand is verified. However, data gathered during the explicit punch menu is not committed to the datalog buffer unless the hand verification is successful.

4.14 Other Special Modes

4.14.1 Explicit PunchHandPunch units support an explicit punch mode, also called “T&A mode” that may be turned on by a command menu. This mode will show a prompt asking the user to select In, Out, or Back. This data is saved in the TA code part of the data2 field of the datalog generated when the hand is verified.

Turning this on from the command menu will set the “Accounting Mode” field in the basic setup data to have the value 1. A host PC can also turn on this mode by setting bit 0 of this field.

4.14.2 Department CodeOn HandPunch units, if the # key is pressed before an ID is entered, the unit will prompt the user for a department code before proceeding with hand verification. This department code will be saved in the data2 part of the datalog generated when the hand is verified.

This mode can also be activated by setting bit 1 of the Accounting Mode field in the basic setup data. It cannot be turned on from the command menu. Note that activating the T&A mode described in Section 4.14.1 above will set the Accounting Mode field to 1, which will clear bit 1 and turn off the department code feature if it was turned on.



4.14.3 Command ModeCommand mode is the mode which gives access to the command menus. Refer to the operating manuals for the various models for information on what the menus do and how to enter them. For the purposes of this document, there are just a few important menus to pay special attention to for serial port setup. All these menus are in menu level 2. The baud rate is set in the “Set Serial” menu. The address is set in the “Set Address” menu. On HandKey units, the reader mode (Master/Remote/Stand-alone) is set in the “Set Operating Mode” menu. If an Ethernet board is installed, it is necessary to enter the unit’s IP address, and possibly gateway and subnet mask information, which is under the “Set Serial” menu.

4.15 HP-4000 Only CommandsThe HandPunch 4000 adds a number of features not found in the other models. Some of these have been briefly mentioned previously, but this section will describe them all in detail. In addition to new features, the format of the user database record has changed. Some new commands have been added to support the new features and new user records

4.15.1 MessagesThe messaging feature provides the ability to display a message or series of messages to a user when he punches. Messages are sent to the reader by the host PC one at a time, but all messages for a user will be displayed when the user punches. When all messages for a user have been read, a datalog is entered in the transactions log. At that time, the programmer may choose to delete that user's messages so they are not displayed again.

4.15.1.1 The Message PoolMessages are stored in a region of memory called the message pool. The exact amount of memory assigned to the message pool depends on the memory option purchased: It is either 5 banks or 32 banks. Each message occupies 37 bytes in the message pool, so each bank (4096 bytes) can hold 110 messages.

4.15.1.2 Sending MessagesTo place a message for a user into the message pool, the AddUserMessage command is used. The ID of the user for whom the message is directed, and the text of the message, are sent with this command. The user does not need to be enrolled in the user database at the time the command is sent. Messages are displayed only after a valid punch, which includes a correct hand verification. This ensures both the privacy of the message and confidence that the intended user was the one who got the message.More than one message may be sent for a user. Provided a simple rule is followed (Section 4.15.1.6 on page 69), the messages will be displayed in the order they are sent.



4.15.1.3 Removing Messages for a UserTo remove all messages for a user, the RemoveUserMessages command is sent. There is no way to selectively remove particular messages.

4.15.1.4 Clearing the Entire Message PoolThe entire message pool is cleared by sending the ClearUserMessages command.

4.15.1.5 How to Know When a User Has Read All Pending MessagesAlthough there's no way to be sure a user actually read what was displayed, it is possible to know that all pending messages for a user have at least been displayed (HP-4000 units only). When the user hits the Enter key while the last pending message for the user is being displayed, a data log with format number 21 will be generated (see page 209.) If a message display times out, no datalog is generated.

4.15.1.6 Order of DisplaySince messages are not marked with a sequence number, it is not possible in general to guarantee the order of their display.

The Remove User Messages command creates holes in the message pool, and new messages are added into the first available location. Since messages are displayed in the order they are found in the message pool, starting from the beginning, it is possible that messages added after a remove operation may be displayed before messages that were added earlier.

If it is critical that newly added messages for a user be displayed in a precise sequence, and it cannot be ensured that no holes have been created since the last message was uploaded for that user, then it is necessary for the system sending the messages to save them as they are sent. When it is desired to add a new message to the user's list of pending messages, send the RemoveUsers command, then send all the messages for that user again.

4.15.2 User NameThis feature allows a user's name to be displayed during the "Place Hand" phase of punching. If a name is entered in the user's database record (see the description of the Extended User Record user record on page 193 for details) that name will be displayed on line 2 of the LCD, underneath the "Place Hand" prompt.

4.15.3 Time IntervalsAs mentioned in Section 4.5.3 on page 58 the HP-4000 has a new way of restricting punching to certain times. Here, time intervals will be explained more fully.



4.15.3.1 Values in a Time IntervalThe following data fields make up a time interval. The actual packing format is given on page 196.

• A start minute. This is the minute of the day at which the interval begins.• A stop minute. This is the minute of the day at which the interval ends.• A day-of-the-week (DOW) field. This contains 7 bits, one for each day.• A bit indicating whether holiday access is granted.

4.15.3.2 Calculating Start and Stop MinutesThe start and stop minutes are 12 bits each. They are calculated by taking the hour, multiplying by 60, and adding the minute. There are 60 x 24 = 1440 minutes in a day. For example, minute 0 is 12:00 a.m. and minute 1439 is 11:59 p.m.

Further examples:

• 6:00 a.m. is minute number 6 x 60 + 0 = 360• 8:30 a.m. is minute number 8 x 60 + 30 = 510• 12:00 noon is minute number 12 x 60 + 0 = 720• 5:45 p.m. is minute number 17 x 60 + 45 = 1065

4.15.3.3 Active and Inactive Time Intervals – Current and Non-Current Time IntervalsA time interval is called "active" when it participates in deciding whether to allow the user to punch. See Section 2.4.2 for a full discussion of this. A time interval is inactive only if its start minute and stop minute are both zero; it is active otherwise.

A time interval is called "current" when the actual time is within the limits specified by the time interval, and it is "non-current" otherwise.

4.15.3.4 Stop TimeA time interval begins at the first second of its start minute and ends at the first second of its stop minute. That means, for example, that a time interval starting at 8:00 and ending at 17:00 will allow users to punch starting at 8:00:00 a.m., up to 4:59:59 p.m., but not at 7:59:59 a.m. nor at 5:00:00 p.m. This also means that a time interval whose start time equals its stop time will never be current.

4.15.3.5 Midnight CrossingIf a time interval's start minute is greater than its stop minute, this is interpreted to mean that the time interval spans midnight, and the portion of the time interval after midnight is taken to refer to the next day. Note that this is different than the time intervals in the time zone table.



For example:

• Monday 22:00 - 23:00 is a normal, non-midnight crossing time interval. It begins at 22:00 and ends at 23:00.

• Monday 22:00 - 02:00 is a midnight-crossing time interval. It begins at 22:00 Monday night and ends at 2:00 Tuesday morning.

• Monday 02:00 - 01:00 is another midnight-crossing time interval. It begins at 2:00 a.m. Monday morning, extends all the way around to Monday night, then continues into Tuesday morning until 1:00 a.m.

Actually, what the midnight crossing condition does is more complicated than this because it is possible to specify several days in a time interval's DOW field, and this has to be handled properly.

For example, Monday Tuesday 22:00 - 02:00 is interpreted as follows:

• Monday 22:00 - 23:59• Tuesday 0:00 - 1:59• Tuesday 22:00 - 23:59• Wednesday 0:00 - 1:59

4.15.3.6 Packing Time IntervalsTime intervals are stored in the user record in a packed format which is shown on page 196. There are three packed time intervals per user record.

4.15.4 Amnesty PunchesAs described previously, the HP-4000 allows supervisors to grant amnesty punches to users. The count of available amnesty punches is stored in the user record and decremented each time an amnesty punch is used. Punching in during normally authorized times does not affect the amnesty punch count. This can also be set from the host PC using the HereIsExtendedUserRecord command.

4.15.5 Reconciliation of Time Restriction ControlsThis was discussed in Section 4.5 for non-HP-4000 units, and some discussion of the HP-4000 additional features was made. However, the HP-4000 has enough new behavior that it is worth restating how it works in more detail.

In a HP-4000, there are four items which play a role in determining whether a user can punch at a given time: The global restrictions flag, the user's time intervals, the user's time zone, and the user's amnesty punch count. Not all of these items need to be used in a given implementation.



When the HP-4000 needs to decide whether to allow a user to punch, this is the sequence of checks it does. This sequence was carefully designed to allow HP-4000 units to work on systems which have only Model E software capability without compromising any of the new features of the HP-4000.

If the global restrictions flag is set (this is set by the command menu) everyone gets to punch at any time and nothing else is considered. If the global restrictions flags is not set, the HP-4000 checks to see if there are any active time intervals specified in this user's record. (An active time interval was defined in Section 4.15.3.) If there is at least one active time interval, the decision about whether the user can punch is controlled by the time intervals; the time zone field in the BUR is ignored.

If there are no active time intervals, the time zone field in the BUR is checked. If it is current, the user is allowed to punch.

Finally, if the above decisions have not allowed the user to punch, the user's amnesty punch count is checked. If it is not zero, the user is allowed to punch, and it is decremented.

4.15.6 Restricting User Access to Function KeysUsers may be restricted from using particular function keys. This is useful if privileged operations are accessed by certain keys and access to these keys is to be limited to supervisors, for example. The flags controlling which keys, if any, are restricted for a user are located in the Extended User Record. See page 193 for the exact location and bit assignments of the function key mask field in the user record.

4.15.7 Contents of the Extended User Record

4.15.7.1 TerminologyThe 16-byte user data in Model E readers, and in the other Model F products, is referred to as the "Basic User Record" (BUR). The additional data in the HP-4000 user records is referred to collectively as the "Extended User Data" (XUD).

The user-specific data fields for the decision menu system are referred to as the UDF.A HandPunch 4000 user record consists of a basic user record followed by extended user data, and is called an "Extended User Record" (XUR).

4.15.7.2 Extended User Data FieldsA full description of the XUD structure, with lengths and offsets of each member, is provided in page 193. This is just a quick list so we can be familiar with what the XUD contains.



• Three Packed Time Intervals (PTI)• Function Key Masks• User Name• User Data Field• Amnesty Punch Count

The total size of the XUD is 61 bytes, which makes an XUR a total of 77 bytes long. Each user database bank (4096 bytes) can hold 53 XUR's with 15 unused bytes at the end of the bank.

4.15.8 Managing the Extended User DatabaseThe HandPunch 4000 user database is organized and controlled basically the same as the other products' databases. However, special commands must be used because the user record is different. Furthermore, commands are provided to access only parts of the user record.

4.15.8.1 Adding UsersUser records may be added to the HP-4000 database using the HereIsExtendedUserRecord command. This command operates exactly as the HereIsUserRecord command documented in the previous Software Manual, except that it sends the 77-byte XUR rather than the 16-byte BUR.

This command, like the Model E command, will create a new record if the given ID is not already in the database, or else will update the data in an existing record. See Section 4.15.9 for an important discussion of what happens when the HereIsUserRecord command is sent to a HP-4000.

4.15.8.2 Deleting UsersUser records are removed from the HP-4000 database using the RemoveUserRecord command. This is the same command given in the previous Software Manual. No new command for removing user records from a HP-4000 is needed.

4.15.8.3 Setting Only the XUD Portion of an Extended User RecordIt is possible to set only the XUD portion of an XUR. This ability is provided if it turns out to be more convenient, from a programming standpoint, in mixed-model systems, to first run a body of code which uploads all BURs to all hand readers, then send the XUD portions only to those addresses known to have HP-4000 units.

The command which does this is called SetExtendedUserData. A record with the ID given in this command must already exist in the database; this command cannot create a new record in the database.



4.15.8.4 Setting Only the User Data FieldSince the UDF may change frequently and independently of the rest of a user record, a separate command is provided to access the UDF portion of an XUR. The command is called SetUserData field. A record with the ID given in this command must already exist in the database; this command cannot create a new record in the database.

4.15.8.5 Retrieving a User RecordAnalogous to the Model E command SendUserRecord is the HP-4000 command SendExtendedUserRecord. This command sends the complete XUR for the given ID.

4.15.9 Compatibility with Model E User Record CommandsThere are three commands which operate on the databases of Model E units and non-HP-4000 Model F units. The HP-4000 has been designed to behave reasonably when sent these commands.

4.15.9.1 HereIsUserRecordA user record will be created with the given BUR values (ID, template, authority, timezone) whose XUD area contains all zeros. This will disable all HP-4000 features for this user. If so desired, the XUD portion may be changed by sending the SetExtendedUserData and SetUserData commands.

4.15.9.2 SendUserRecordThe record returned from the Hand Punch 4000 in response to this command will have the values from the BUR portion of the record with the given ID. If the given ID does not exist, the HP-4000 will behave exactly as a Model E unit.

4.15.9.3 RemoveUserRecordThis command works exactly the same on the HP-4000 as on any other product.

4.16 Special Troubleshooting Modes

4.16.1 The Status DisplayThe status display is activated from the “Status Display” menu in command menu level 1. The details of the status display differ for the different models.

Both models display what is called the “poll character.” This is a single character which indicates the status of the unit’s host communications receive function. When the last packet was received properly, the poll character is an underscore. If an error occurs while receiving a packet, the poll character is a single digit that indicates the nature of the error. Table 4 on page 75 shows the meanings of the poll characters. The poll character is displayed once, then becomes a space. Since it is possible to send commands to the unit at a rate higher than the rate at which the LCD is updated, the poll character may not show every single error that happens, and it may flicker. If it is



desired to see the poll character for every communication packet, a delay must be inserted before each command to give the LCD time to update. The LCD is updated twice a second.

4.16.1.1 Model EThe Model E status display shows the poll character in the first position of line two on the LCD, then the status of the four inputs in the order Tamper, Door Switch, Aux In, Request to Exit. For the input status display, an ‘O’ means the input is open, or high, and a ‘C’ means the input is closed, or low (the input is at zero volts).

Next is the score of the last hand reading. Then four hexadecimal numbers are shown which correspond to which time zones are current. The LSB of the first number is for time zone 0 and will always be 0. Bit 1 of the first number is for time zone 1; the MSB of the first number is for time zone 7. The next byte’s LSB is for time zone 8, and its MSB is time zone 16, and so on. The MSB of the last byte corresponds to time zone 31. When a bit is 1, the corresponding time zone is current. See Figure 5 for a picture of the status display.

Figure 5: Model E Status Display

Table 4: Poll Character Meanings

Poll Character Meaning

underscore The last packet was received with no errors1 Timeout waiting for start of packet2 Timeout waiting for type field of packet3 Timeout waiting for length field of packet4 Timeout waiting for data field of packet5 Timeout waiting for CRC6 Invalid CRC received7 Timeout waiting for checksum, or invalid checksum8 Packet length exceeds receive buffer size (4096 bytes)



4.16.1.2 Model FThe Model F status display shows the poll character in the first position of line two on the LCD, then the status of all five inputs in the order Tamper, Door Switch, Aux In 1, Request To Exit, Aux In 2. As in the Model E units, ‘O’ means the input is open/high, and ‘C’ means the input is closed/low. Next is the status of the outputs. These are shown in the order Lock, Aux Out 0, Aux Out 1, Aux Out 2. An ‘H’ means the output is high and an ‘L’ means the output is low. Note that outputs are normally high, or off, and are low when they are activated or turned on. Finally, the score of the last hand reading is displayed. See Figure 6 for a picture of the Model F status display.

Figure 6: Model F Status Display

4.16.2 New Features for Model F

4.16.2.1 The Troubleshooting DisplayPressing the “*/NO” key ten times will start the troubleshooting display. This shows some useful information about the unit. This information is explained more fully in the operations manuals, but it is worth mentioning here that it exists. Also, the modem debug mode and display message code modes are activated from the troubleshooting display.

4.16.2.2 Modem Debug ModeWhen the status display is activated, the troubleshooting display will include an option for enabling the modem debug mode. This option appears after the time zone display. In this mode, the unit will show information about the status of the modem connection on the LCD. The first thing it will show is “Ring” when the modem’s ring indicator is activated. Then “Answering” will appear briefly as the unit is sending the modem the command to answer. (Note the modem is not set to auto-answer.) Then it will show “Waiting” with a countdown. The countdown is the number of seconds remaining for a CONNECT to be established before the unit gives up and resets the modem.

When the two modems have established a connection and the HGU modem sends the CONNECT message, the LCD will show “Connected” and the last countdown value. The modem will stay off-hook until carrier detect is lost. The HGU monitors the CD



line, and when it goes inactive, the HGU will display “Disconnected” and hang up the modem by resetting it and pulsing the DTR line.

This mode is currently available only in the F series models.

4.16.2.3 Display Message Code Output ModeThis mode is useful when working on translating HGU display information into a new language. It is activated by entering the Set Language menu with the status display active and toggling Msg Debug mode when prompted. This mode will send the internal message number out the RS-232 printer port every time a message is displayed.

4.17 Real-Time ClockThe Hand Geometry Unit is frequently used in applications which require the accurate recording of the time at which a verification happens. The units keep time by means of an on-board real-time clock (RTC). The RTC runs from a precision quartz crystal time reference and is accurate to within ±20 parts per million (ppm), or 0.002%. The 20 ppm drift is equivalent to about 1.7 seconds per day, 12.1 seconds per week, or 51.8 seconds per 30-day month. The specification that Recognition Systems gives for the clock accuracy is 1 minute per month. This specification is over the entire operating temperature range of the unit. If a unit is kept in a temperature-controlled environment, such as a typical indoor office, much better accuracy can usually be realized.

The RTC is connected to the same lithium battery backup circuit as the unit’s main memory. This allows the RTC to operate with the same accuracy when the power is removed, for as long as the lithium battery charge is maintained.

Since over long periods of time this drift can add up to an unacceptably high amount of time, it is recommended that system designers plan on implementing a scheduled update of their units’ clocks by sending the HereIsTime command. Of course, the host system which sends this command must itself have an accurate clock. This can be ensured by periodically synchronizing with a time standard such as that broadcast by the National Institute for Standards and Technology (NIST), which is available on the internet.

Occasionally, a unit will show a much larger deviation than 1 minute per month. This usually indicates a defective unit, and Recognition Systems should be contacted for service if this is a problem. However, by resynchronizing the unit’s clock moderately frequently, perhaps once a day or once a week, deviations even several times the specified amount of 1 minute per month will have no impact in most applications.



Blank page.



5.0 Commands, Responses and Data Structures

5.1 IntroductionIn this chapter all the commands, responses, and data types will be described in detail. To help keep the commands organized, they are arranged into groups according to their function. The next section describes each of these functional groups and lists the commands each contains. Next, there are some tables listing the commands, responses, and data structures, showing their type numbers, and providing a page number reference to the detailed descriptions. The last three sections are devoted to a full description of each command, response, and data structure that the HGU uses.

5.2 Functional Groupings of CommandsThis section presents the groups of command functions. The commands in each group are listed, and the purpose of each group is explained. Detailed descriptions of the commands are given in the next section.

5.2.1 Status FunctionsThis group contains functions which simply return information about the status of a HGU to a host system. They do not initiate any action in the HGU.

• SendStatusChecksum• SendStatusCRC• SendReaderInfo• SendOEMCode• SendTimeAndDate• SendCardData• SendKeypadData

5.2.2 EnrollmentThis group, which contains only one command, is for initiating a remote enrollment. This is typically done is systems which are managed primarily by the host computer.

• EnrollUser• HereIsSmartCardRecord



5.2.3 Hand VerificationThis group contains the commands which are used to initiate a remote verification. This is typically done in systems which are set up to have the host computer receive user ID numbers, rather than having users directly enter their ID numbers into the HGU.

• VerifyOnExternalData• VerifyOnInternalData

5.2.4 ResultsThe commands in this group are used to retrieve results of hand verifications and enrollments. Different combinations of ID, template, and score are returned by each of the commands.

These commands access temporary storage areas in the HGU for their results. These storage areas may contain data that is valid or not, depending on the progress of an attempt at a hand reading. For a full discussion of this, refer elsewhere.

• SendLastUserRecord• SendResults• SendTemplate

5.2.5 User Database ManagementThe commands in this group allow the host computer to manage the HGU user database. The basic database operations are provided. Note that the Add command also serves as an Update.

• HereIsUserRecord• SendUserRecord• RemoveUserRecord• ClearUserDatabase

5.2.6 User Database BackupIt is possible to backup and restore the user database using the database management commands, but it is very slow due to the overhead of sending a command and getting a response for every user record. A much faster way is to use the commands in this group, which transfer an entire 4096-byte block of data from the HGU’s user database. The disadvantage of this technique is that the programming is a bit more complicated. A full discussion of how to use these commands is provided in Section 6.11 on page 230.

• HereIsDataBank• SendDataBank



5.2.7 Transactions Log ManagementThese are the commands for fetching data from the HGU transaction log.

• SendDatalog• SendPreviousDatalog

5.2.8 ConfigurationThis group contains all the commands which send configuration information to the HGU. Configuration information includes such items as the date and time, the door control output pulse times, command mode passwords, time zones, etc. Each of these is documented fully in the next section.

• HereIsTime• SendSetup• HereIsSetup• SendExtendedSetup• HereIsExtendedSetup• HereAreTimeZones• HereIsBellScheduleTable

5.2.9 Hardware ControlThese commands cause something to happen to the HGU hardware. This includes turning outputs on or off, sending text to the printer or the LCD, and turning the Red/Green LEDs on or off.

• OutputControl• PrinterPassThrough• HereIsDisplayMessage• DisplayCodedMessage• LED Control

5.2.10 MaintenanceThe commands in this group are for doing a forced re-calibration and retrieving the results.

• Calibrate• SendCalibrationData



5.2.11 Ancillary CommandsThe commands in this group are needed only to support other commands. They do not represent any new operations that the HGU does, but merely pieces of an overall series of commands that must be sent to accomplish a task.

• HereIsBankNumber• NextMessageIsTimeZones• NextMessageIsBellScheduleTable• UpdateNVRAM• EnterIdleMode• EnterIdleMode2• Beep• LEDControl• EmitKeypadData• Resume• Abort

5.2.12 Function Key MenusThere is only one command in this group. It loads the function key menu table into the HGU.

• HereIsDecisionMenuData

5.2.13 HP-4000 OnlyTo support the new features of the HP-4000, there are several commands which are unique to it.

• HereIsExtendedUserRecord• SendExtendedUserRecord• SetExtednedUserData• SetUserData• AddUserMessage• RemoveUserMessages• ClearUserMessages

5.2.14 Special Commands and Undocumented CommandsThere are a number of commands which have been added for special projects and undocumented commands which are used for internal testing and development at RSI. These commands are listed in Table 5 beginning on page 84 for the sake of completeness and to aid in troubleshooting if a packet with such a command should happen to be accidentally sent from a PC application. They are not considered part of the standard command set and are not documented. Some of them will destroy data in



the HGU. Do not send these commands to a unit under any circumstances. No further information is available on these commands.

5.3 Command and Response Tables

5.3.1 CommandsTable 5 beginning on page 84 lists the commands grouped by function. The table shows the hex and ASCII type value for each command, which models support which commands, and the hex and ASCII value of the response type for each command. The last column indicates the page number on which the commands detailed description is given.

Models which support a command have a bullet in their column (•). Note that many commands have restrictions on how they work or which models they work on which are not indicated in this table. Refer to the detailed description of each command for full details.

Often, when troubleshooting communication problems and examining binary dumps of communications monitoring equipment, it is helpful to be able to identify a command based just on its number. Table 6 on page 87 shows all the commands arranged by their command number.

Table 7 on page 89 shows all commands sorted by name.

The following notes apply to all three Command Tables:

1. The SendTimeAndDate command was implemented on 4/14/97. Units with firmware compiled prior to that date will not respond to this command. All Model F units have firmware compiled after that date.

2. The SendTimeZones command was implemented on 6/29/00. Units with firmware compiled prior to that date will not respond to this command.

3. HandKey units do not support a bell schedule.



Table 5: Hand Geometry Unit Commands Grouped by Function

Command Models Supporting this Command Response

Type Type

Hex

AS

CII

Leng

th

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Hex

AS

CII

Leng

th

Pag

e

Status FunctionsSendStatusCRC 44 D 0 • • • • • 30 0 3 page 142SendStatusChecksum 3B ; 0 • • • • • 30 0 3 page 141SendReaderInfo 73 s 0 • • • 53 S 102 page 138SendOEMCode 6F o 0 • • • 4F O 2 page 136SendTimeAndDate 61 a 0 1 1 • • • 61 a 6 page 144SendCardData 67 g 0 • • • • • 34 4 varies page 127SendKeypadData 68 h 1 • • • • • 62 b varies page 133

EnrollmentEnrollUser 49 I 2 • • • • • 30 0 3 page 102HereIsSmartCardRecord 69 i 16 • • • 30 0 3 page 115

Hand VerificationVerifyOnExternalData 4A J 11 • • • • • 30 0 3 page 150VerifyOnInternalData 51 Q 5 • • • • • 30 0 3 page 151

ResultsSendLastUserRecord 40 @ 0 • • • • • 32 2 16 page 135SendResults 43 C 0 • • • • • 35 5 7 page 139SendTemplate 4B K 0 • • • • • 37 7 11 page 143

User Database Management

HereIsUserRecord 37 7 16 • • • • • 30 0 3 page 117SendUserRecord 38 8 5 • • • • • 32 2 16 page 146RemoveUserRecord 3F ? 5 • • • • • 30 0 3 page 124ClearUserDatabase 3E > 0 • • • • • 30 0 3 page 98

User Database BackupHereIsDataBank 47 G 4096 • • • • • 30 0 3 page 108SendDataBank 48 H 2 • • • • • 36 6 4096 page 128

Transactions Log Management

SendDatalog 4D M 0 • • • • • 38 8 18 page 129SendPreviousDatalog 6D m 0 • • • • • 38 8 18 page 137

ConfigurationHereIsTime 41 A 6 • • • • • 30 0 3 page 116SendSetup 4E N 0 • • • • • 39 9 128 page 140HereIsSetup 3D = 128 • • • • • 30 0 3 page 114SendExtendedSetup 2C , 0 • • • 41 A 128 page 130



Configuration (continued)SendTimeZones 24 $ 0 3 3 3 3 3 24 $ 768 page 145HereIsExtendedSetup 2B + 128 • • • 30 0 3 page 112HereAreTimeZones 53 S 768 • • • • • 30 0 3 page 105HereIsBellScheduleTable 58 X 300 2 • 2 • • 30 0 3 page 107

Hardware ControlOutputControl 4F O 1 • • • • • 30 0 3 page 121PrinterPassThrough 70 p * • • • • • 30 0 3 page 122HereIsDisplayMessage 50 P 37 • • • • • 30 0 3 page 110DisplayCodedMessage 56 V 2 • • • • • 30 0 3 page 100

MaintenanceCalibrate 3A : 0 • • • • • 30 0 3 page 97SendCalibrationData 3C < 0 • • • • • 33 3 6 page 126

Ancillary CommandsHereIsBankNumber 46 F 2 • • • • • 30 0 3 page 106NextMessageIsTimeZones 52 R 0 • • • • • 30 0 3 page 120NextMessageIsBellScheduleTable 57 W 0 2 • 2 • • 30 0 3 page 119

UpdateNVRAM 4C L 0 • • • • • 30 0 3 page 149Resume 31 1 0 • • • • • 30 0 3 page 125EnterIdlemode 45 E 0 • • • • • 30 0 3 page 103EnterIdleMode2(added 6/5/00) 65 e 0 • • • • • 30 0 3 page 104

Beep (added 6/5/00) 62 b 2 • • • • • 30 0 3 page 96LEDControl (added 6/5/00) 23 # 1 • • • • • 30 0 3 page 118EmitKeypadTestData 42 B 5 • • • • • 30 0 3 page 101Abort 32 2 0 • • • • • 30 0 3 page 94SendInternalErrorLog 5C \ 0 • • • 5C \ 51 page 132

Function Key MenusHereIsDecisionMenuData 64 d 4096 • • • 30 0 3 page 109

HP-4000 OnlyHereIsExtendedUserRecord 78 x 77 • 30 0 3 page 113SendExtendedUserRecord 74 t 5 • 31 1 77 page 131SetExtendedUserData 75 u 61 • 30/58 0/X 3 page 147SetUserData 66 f 24 • 30/58 0/X 3 page 148AddUserMessage 76 v 37 • 30/58 0/X 3 page 95RemoveUserMessages 77 w 5 • 30 0 3 page 123

Table 5: Hand Geometry Unit Commands Grouped by Function (Continued)


Type Type

Hex

AS

CII

Leng

th

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Hex

AS

CII

Leng

th

Pag

e



HP-4000 Only (continued)ClearUserMessages 79 y 0 • 30 0 3 page 99

Special CommandsTake Pictures 34 4 30 0 3SendSpecialStatus 39 9 (31) (1)CalculateTemplate 36 6 7 7 11

Undocumented Commands

DAQ 35 5Special Command 33 3TB Results 63 cFill Memory With Test Pattern 54 TValidate Test Pattern 55 UProtected Subcommands 5A Z

Table 5: Hand Geometry Unit Commands Grouped by Function (Continued)


Type Type

Hex

AS

CII

Leng

th

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Hex

AS

CII

Leng

th

Pag

e



Table 6: Hand Geometry Unit Commands Sorted by Command NumberCommand Models Response

Type Type

Hex

AS

CII

Leng

th

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Hex

AS

CII

Leng

th

Pag

e

LEDControl (added 6/5/00) 23 # 1 • • • • • 30 0 3 page 118SendTimeZones 24 $ 0 3 3 3 3 3 24 $ 768 page 145HereIsExtendedSetup 2B + 128 • • • 30 0 3 page 112SendExtendedSetup 2C , 0 • • • 41 A 128 page 130Resume 31 1 0 • • • • • 30 0 3 page 125Abort 32 2 0 • • • • • 30 0 3 page 94Special Command 33 3Take Pictures 34 4 30 0 3DAQ 35 5CalculateTemplate 36 6 7 7 11HereIsUserRecord 37 7 16 • • • • • 30 0 3 page 117SendUserRecord 38 8 5 • • • • • 32 2 16 page 146SendSpecialStatus 39 9 (31) (1)Calibrate 3A : 0 • • • • • 30 0 3 page 97SendStatusChecksum 3B ; 0 • • • • • 30 0 3 page 141SendCalibrationData 3C < 0 • • • • • 33 3 6 page 126HereIsSetup 3D = 128 • • • • • 30 0 3 page 114ClearUserDatabase 3E > 0 • • • • • 30 0 3 page 98RemoveUserRecord 3F ? 5 • • • • • 30 0 3 page 124SendLastUserRecord 40 @ 0 • • • • • 32 2 16 page 135HereIsTime 41 A 6 • • • • • 30 0 3 page 116EmitKeypadTestData 42 B 5 • • • • • 30 0 3 page 101SendResults 43 C 0 • • • • • 35 5 7 page 139SendStatusCRC 44 D 0 • • • • • 30 0 3 page 142EnterIdleMode 45 E 0 • • • • • 30 0 3 page 103HereIsBankNumber 46 F 2 • • • • • 30 0 3 page 106HereIsDataBank 47 G 4096 • • • • • 30 0 3 page 108SendDataBank 48 H 2 • • • • • 36 6 4096 page 128EnrollUser 49 I 2 • • • • • 30 0 3 page 102VerifyOnExternalData 4A J 11 • • • • • 30 0 3 page 150SendTemplate 4B K 0 • • • • • 37 7 11 page 143UpdateNVRAM 4C L 0 • • • • • 30 0 3 page 149SendDatalog 4D M 0 • • • • • 38 8 18 page 129SendSetup 4E N 0 • • • • • 39 9 128 page 140OutputControl 4F O 1 • • • • • 30 0 3 page 121HereIsDisplayMessage 50 P 37 • • • • • 30 0 3 page 110VerifyOnInternalData 51 Q 5 • • • • • 30 0 3 page 151NextMessageIsTimeZones 52 R 0 • • • • • 30 0 3 page 120HereAreTimeZones 53 S 768 • • • • • 30 0 3 page 105Fill Memory With Test Pattern 54 TValidate Test Pattern 55 UDisplayCodedMessage 56 V 2 • • • • • 30 0 3 page 100NextMessageIsBellScheduleTable 57 W 0 2 • 2 • • 30 0 3 page 119HereIsBellScheduleTable 58 X 300 2 • 2 • • 30 0 3 page 107Protected Subcommands 5A ZSendInternalErrorLog 5C \ 0 • • • 5C \ 51



SendTimeAndDate 61 a 0 1 1 • • • 61 a 6 page 144Beep (added 6/5/00) 62 b 2 • • • • • 30 0 3 page 96TB Results 63 cHereIsDecisionMenuData 64 d 4096 • • • 30 0 3 page 109EnterIdleMode2 (added 6/5/00) 65 e 0 • • • • • 30 0 3 page 104SetUserData 66 f 24 • 30/58 0/X 3 page 148SendCardData 67 g 0 • • • • • 34 4 varies page 127SendKeypadData 68 h 1 • • • • • 62 b varies page 133HereIsSmartCardRecord 69 i 16 • • • 30 0 3 page 115SendPreviousDatalog 6D m 0 • • • • • 38 8 18 page 137SendOEMCode 6F o 0 • • • 4F O 2 page 136PrinterPassThrough 70 p * • • • • • 30 0 3 page 122SendReaderInfo 73 s 0 • • • 53 S 102 page 138SendExtendedUserRecord 74 t 5 • 31 1 77 page 131SetExtendedUserData 75 u 61 • 30/58 0/X 3 page 147AddUserMessage 76 v 37 • 30/58 0/X 3 page 95RemoveUserMessages 77 w 5 • 30 0 3 page 123HereIsExtendedUserRecord 78 x 77 • 30 0 3 page 113ClearUserMessages 79 y 0 • 30 0 3 page 99

Table 6: Hand Geometry Unit Commands Sorted by Command NumberCommand Models Response

Type Type

Hex

AS

CII

Leng

th

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Hex

AS

CII

Leng

th

Pag

e



Table 7: Hand Geometry Unit Commands Sorted AlphabeticallyCommand Models Response

Type Type

Hex

AS

CII

Len

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Hex

AS

CII

Len

Pag

e

Abort 32 2 0 • • • • • 30 0 3 page 94AddUserMessage 76 v 37 • 30/58 0/X 3 page 95Beep (added 6/5/00) 62 b 2 • • • • • 30 0 3 page 96CalculateTemplate 36 6 7 7 11Calibrate 3A : 0 • • • • • 30 0 3 page 97ClearUserDatabase 3E > 0 • • • • • 30 0 3 page 98ClearUserMessages 79 y 0 • 30 0 3 page 99DAQ 35 5DisplayCodedMessage 56 V 2 • • • • • 30 0 3 page 100EmitKeypadTestData 42 B 5 • • • • • 30 0 3 page 101EnrollUser 49 I 2 • • • • • 30 0 3 page 102EnterIdleMode 45 E 0 • • • • • 30 0 3 page 103EnterIdleMode2 (added 6/5/00) 65 e 0 • • • • • 30 0 3 page 104Fill Memory With Test Pattern 54 THereAreTimeZones 53 S 768 • • • • • 30 0 3 page 105HereIsBankNumber 46 F 2 • • • • • 30 0 3 page 106HereIsBellScheduleTable 58 X 300 2 • 2 • • 30 0 3 page 107HereIsDataBank 47 G 4096 • • • • • 30 0 3 page 108HereIsDecisionMenuData 64 d 4096 • • • 30 0 3 page 109HereIsDisplayMessage 50 P 37 • • • • • 30 0 3 page 110HereIsExtendedSetup 2B + 128 • • • 30 0 3 page 112HereIsExtendedUserRecord 78 x 77 • 30 0 3 page 113HereIsSetup 3D = 128 • • • • • 30 0 3 page 114HereIsSmartCardRecord 69 i 16 • • • 30 0 3 page 115HereIsTime 41 A 6 • • • • • 30 0 3 page 116HereIsUserRecord 37 7 16 • • • • • 30 0 3 page 117LEDControl (added 6/5/00) 23 # 1 • • • • • 30 0 3 page 118NextMessageIsBellScheduleTable 57 W 0 2 • 2 • • 30 0 3 page 119NextMessageIsTimeZones 52 R 0 • • • • • 30 0 3 page 120OutputControl 4F O 1 • • • • • 30 0 3 page 121PrinterPassThrough 70 p * • • • • • 30 0 3 page 122Protected Subcommands 5A ZRemoveUserMessages 77 w 5 • 30 0 3 page 123RemoveUserRecord 3F ? 5 • • • • • 30 0 3 page 124Resume 31 1 0 • • • • • 30 0 3 page 125SendCalibrationData 3C < 0 • • • • • 33 3 6 page 126SendCardData 67 g 0 • • • • • 34 4 varies page 127SendDataBank 48 H 2 • • • • • 36 6 4096 page 128SendDatalog 4D M 0 • • • • • 38 8 18 page 129SendExtendedSetup 2C , 0 • • • 41 A 128 page 130SendExtendedUserRecord 74 t 5 • 31 1 77 page 131SendInternalErrorLog 5C \ 0 • • • 5C \ 51 page 132SendKeypadData 68 h 1 • • • • • 62 b varies page 133SendLastUserRecord 40 @ 0 • • • • • 32 2 16 page 135SendOEMCode 6F o 0 • • • 4F O 2 page 136SendPreviousDatalog 6D m 0 • • • • • 38 8 18 page 137



SendReaderInfo 73 s 0 • • • 53 S 102 page 138SendResults 43 C 0 • • • • • 35 5 7 page 139SendSetup 4E N 0 • • • • • 39 9 128 page 140SendSpecialStatus 39 9 (31) (1)SendStatusChecksum 3B ; 0 • • • • • 30 0 3 page 141SendStatusCRC 44 D 0 • • • • • 30 0 3 page 142SendTemplate 4B K 0 • • • • • 37 7 11 page 143SendTimeAndDate 61 a 0 1 1 • • • 61 a 6 page 144SendTimeZones 24 $ 0 3 3 3 3 3 24 $ 768 page 145SendUserRecord 38 8 5 • • • • • 32 2 16 page 146SetExtendedUserData 75 u 61 • 30/58 0/X 3 page 147SetUserData 66 f 24 • 30/58 0/X 3 page 148Special Command 33 3Take Pictures 34 4 30 0 3TB Results 63 cUpdateNVRAM 4C L 0 • • • • • 30 0 3 page 149Validate Test Pattern 55 UVerifyOnExternalData 4A J 11 • • • • • 30 0 3 page 150VerifyOnInternalData 51 Q 5 • • • • • 30 0 3 page 151

Table 7: Hand Geometry Unit Commands Sorted AlphabeticallyCommand Models Response

Type Type

Hex

AS

CII

Len

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Hex

AS

CII

Len

Pag

e



5.3.2 ResponsesResponses are packets sent from an HGU to the host system. The packet format for a response is identical to that for a command. Responses are sent only in response to commands from the host system. Table 8 on page 91 summarizes the responses which may be sent by a HGU, along with which models support the commands which cause these responses to be sent. These commands have a bullet in their column (•). Note that more than one command may cause a particular response to be sent. For example, many commands respond with HereIsStatus.

The following applies to the Response Table.

1. Not all model E units support the command which returns this response. The SendTime command was added into the Model E firmware on 4/14/97.

2. Not all units support the command which returns this response. The SendTimeZones command was added into the firmware on 6/29/00.

Table 8: Hand Geometry Unit Responses

Response Type

Models Which May Send This Response

Hex

AS

CII

E-H

K

E-H

P

F-H

K

F-H

P

HP

4K

Pag

e

Common ResponsesHereIsStatus 30 0 • • • • • page 168HereIsUserRecord 32 2 • • • • • page 171HereIsCalibrationData 33 3 • • • • • page 156HereIsCardData 34 4 • • • • • page 157HereAreResults 35 5 • • • • • page 154HereIsDataBank 36 6 • • • • • page 158HereIsTemplateVector 37 7 • • • • • page 170HereIsNextDatalog 38 8 • • • • • page 163HereIsSetupData 39 9 • • • • • page 167HereIsExtendedSetup 41 A • • • page 159HereIsMyTime 61 a 1 1 • • • page 162HereIsKeypadData 62 b • • • • • page 161HereIsOEMCode 4f O • • • page 164HereIsReaderInfo 53 S • • • page 165HereAreTimeZones 24 $ 2 2 2 2 2 page 155

HP-4000 OnlyUnableToCompleteCommand 58 X • page 172HereIsExtendedUserRecord 31 1 • page 160



Blank page.



5.4 CommandsThis section provides a detailed description of each command. Commands are listed in alphabetical order.

The data shown with each command is the data exactly as the HGU expects to receive it. The Windows DLL provides a set of structures which are designed to allow easier access to the bit fields in the HGU data structures from high-level languages such as Visual Basic. These structures can only be used with the DLL functions that are designed to use them, and they do not represent the data in the format the HGU actually expects to receive it.

Please note that the Windows DLL provides functions which do not correspond directly to a single HGU command, but rather represent a set of commands grouped together to accomplish a task, or to perform data translation to high-level structures. Please refer to the DLL manual for descriptions of these functions.

Each command is presented in a small table in the general format shown below, one command per page. The first line shows the Command Name, the ASCII character for the command type, and the hex value of the command type. The rest of the paragraph provides a detailed description of the command.

Command Name ASCII: A Hex: FF

Function Group The name of the group to which the function belongs

Description A brief description of what the command does

Data Data that must go with the command

Response The name of the response to be expected from the HGU

DLL Function The function name in the DLL

Portability Which models support the command (indicated by a •) – shown in table format

NotesMost commands require some explanation beyond what is given in the “Description.” That explanation is provided here.

EHK•

EHP•

FHK•

FHP•

HP4K•



AbortCommand ASCII: 2 Hex: 32

Function Group Ancillary commands

Description Abort a host command

Data None

Response HereIsStatus

DLL Function rsiAbortCommand

Portability

NotesThis command will cause the HGU to abort the following hand reading commands: VerifyOnExternalData, VerifyOnInternalData, and EnrollUser.

In addition, this command has the following side effects:

• In SysStat1, the following bits are cleared:

VERIFY_RDYRSLTS_RDYFAILED_CMDCMD_BUSY

• The template buffer reported by SendLastUserRecord is cleared to zeros, and the template buffer reported by SendTemplate is cleared to zeros.

• The LCD reverts to the ready prompt.

EHK•

EHP•

FHK•

FHP•

HP4K•



AddUserMessage ASCII: v Hex: 76

Function Group HP-4000 Only

Description Add a message for a user

Data


DLL Function rsiAddUserMessage

Portability

NotesThe ID need not be enrolled in the user database in order for the message to be stored. If a message is added with an ID that is not enrolled, it will remain in the message pool, and the first time that ID is used, the messages for it will be displayed.

Field Bytes Offset DescriptionID 5 0 Which user this message is forMessage 32 5 Message text, either zero-terminated or exactly 32

bytes longTotal 2

EHK

EHP FHK FHP HP4K•



Beep ASCII: b Hex: 62

Function Group Ancillary Commands

Description The unit will beep

Data


DLL Function rsiBeep

Portability

NotesThis command is available only on units with firmware compiled after 6/5/00.

The allowable range of values for the length is 1-7. The range for the number of beeps is 1-15. These limits are enforced by forcing the upper bits to zero, so values outside these ranges will be folded back into them. Sending a length or number of 0 (or any value which results in zero after the upper bits are masked) will result in no beep.

The actual duration of the beep will be approximately 20 msec for each unit of length. There is a 20 msec pause between beeps, regardless of the value of length.

Field Bytes Offset DescriptionLength 1 0 Length of beepNumber 1 1 Number of beepsTotal 2

EHK•

EHP•

FHK•

FHP•

HP4K•



Calibrate ASCII: : Hex: 3A

Function Group Maintenance

Description The HGU will re-calculate the optimal exposure and row/column offsets.

Data None


DLL Function rsiCalibrate

Portability

NotesThe response to this command is sent prior to the command actually executing.

Execute this command only under very well controlled circumstances where it can be certain that the platen is clear. If the platen is obstructed, the exposure time determined by this command will be erroneously high. Ideally, the person at the host system who initiates the command should have the HGU in view when the command is executed to be sure the platen area is clear. For this reason, it is not recommended that this command be used in most host applications.

The results of the calibration operation may be obtained with the SendCalibrationData command.

EHK•

EHP•

FHK•

FHP•

HP4K•



ClearUserDatabase ASCII: > Hex: 3E

Function Group User database management

Description The user database is cleared. All user records are deleted.

Data None


DLL Function rsiClearUserDataBase

Portability

NotesUse this command before restoring the user database.

The entire database is filled with empty records before the HGU response is sent, so the response time may be slower than most of the other commands. Expect as much as five seconds.

EHK•

EHP•

FHK•

FHP•

HP4K•



ClearUserMessages ASCII: y Hex: 79


Description The message pool is cleared

Data None


DLL Function rsiClearUserMessages

Portability

NotesThis command clears all messages for all user IDs. To clear all messages for a specific user ID, use the RemoveUserMessages command (ADD CROSSREFERENCE LINK).

EHK EHP FHK FHP HP4K•



DisplayCodedMessage ASCII: V Hex: 56

Function Group Hardware Control

Description Displays a message from a predetermined list for a time

Data


DLL Function rsiDisplayCodedMessage

Portability

NotesThis command displays one of three messages, based on the value in the message field.

Field Bytes Offset DescriptionMessage 1 0 Which message to displayTime 1 1 Display time in 500 msec intervalsTotal 2

EHK•

EHP•

FHK•

FHP•

HP4K•

Message Display0 ACCESS GRANTED1 ACCESS DENIED

WRONG TIME/PLACE2 ACCESS DENIED

HAND NOT CLEARED



EmitKeypadTestData ASCII: B Hex: 42


Description The given ID will be emitted from the unit’s card reader output

Data


DLL Function None

Portability

NotesThis command is not available on all units. No unit with firmware compiled prior to 2/8/00 has this command. Model E HandKey units after this date will have it. Model F units compiled after 6/6/00 will have this command.

The given ID number is sent through the format and card data conversion process exactly as if it were typed at the main keypad. The resulting data is sent out the card reader output port.

Field Bytes Offset DescriptionID 5 0 ID number to convert and emitTotal 5

EHK•

EHP•

FHK•

FHP•

HP4K•



EnrollUser ASCII: I Hex: 49

Function Group Enrollment

Description The HGU begins a host-initiated enrollment.

Data


DLL Function rsiEnrollUser

Portability

NotesThis command causes the HGU to execute an enrollment and report the status of the enrollment through a set of bits in the SysStat1 byte of the status response. This enrollment will proceed exactly as an enrollment initiated from the keypad menu, except that a keypad-initiated enrollment does not set the status bits in SysStat1. The full details of the enrollment process are explained in Section 4.2 on page 55.

The data in this command selects one of two possible prompts which will appear on the second line of the LCD, below “PLACE HAND”. If the data is 0, RIGHT will be displayed. This is what should be sent for most HGUs. If the data is 1, LEFT will be displayed. This should only be sent for left-handed HGUs.

Immediately upon receiving this command, the HGU sets the CMD_BUSY bit in the SysStat1 byte and sends the response. After a short delay (100-200 ms) the HGU will begin the enrollment. The host system should continue checking the bits in SysStat1, using the SendStatus command, to determine when the enrollment is over. If the enrollment fails, the FAILED_CMD bit is set. If the enrollment is successful, the RSLTS_RDY bit is set.

If the enrollment was successful, there will be a template generated and stored in the HGU’s template buffer. The contents of this buffer may be accessed using the SendTemplate command. The value in the score field of the HereIsTemplate response following an enrollment is undefined and should be ignored.

If the enrollment failed, the contents of the template buffer are undefined and sending the SendTemplate command will not get any useful data from the HGU.

The Prompt field determines what is displayed on the second line of the LCD during the enrollment. If the data is set to 0, “RIGHT” is displayed. If the data is set to 1, “LEFT” is displayed. Any other value will cause the second line to be blank.

Field Bytes Offset DescriptionPrompt 2 0 See notesTotal 2

EHK•

EHP•

FHK•

FHP•

HP4K•



EnterIdleMode ASCII: E Hex: 45


Description Places the HGU in idle mode. All processing is suspended, except host communications.

Data None


DLL Function rsiEnterIdleMode

Portability

NotesThis command is used mainly during the block-mode user database backup and restore operations. Idle mode is exited when the HGU receives the Resume command or either of the SendStatus commands.

On units with firmware compiled after 6/5/00, there is an alternative idle mode which is not exited when the SendStatus commands are received. See the EnterIdleMode2 command for details.

Different models may behave slightly differently when they are in idle mode. Sometimes the unit may beep when keys are hit but not take any other action until after idle mode is left. Similarly, presenting a card to the HGU may cause it to beep, but no hand verification will follow while in idle mode.

All of the following will continue to work normally in idle mode.

Door controlsDatalog printingTime and date updatingModem answering

EHK•

EHP•

FHK•

FHP•

HP4K•



EnterIdleMode2 ASCII: e Hex: 65


Description Places the HGU in idle mode. All processing is suspended, except host communications. Not terminated by SendStatus

Data None


DLL Function rsiEnterIdleMode2

Portability

NotesThis command behaves exactly like EnterIdleMode, except that it prevents Idle mode from being terminated when the SendStatus commands are recieved. To resume normal mode after receiving this command, a unit must receive the Resume command. This command may be used to block keypad entry during remote-initiated verifications and enrollments.

This command is only available on units with firmware compiled after 6/5/00.

EHK•

EHP•

FHK•

FHP•

HP4K•



HereAreTimeZones ASCII: S Hex: 53

Function Group Configuration

Description Send a time zone table to the HGU

Data


DLL Function rsiHereAreTimeZones

Portability

NotesThe holiday table is an array of twelve month entries, each 4 bytes long. The format of a holiday entry is shown on page 194. The time zone table is an array of 60 time zone entries, each one 20 bytes long. The exact format of a time zone entry is shown on page 195.

On all E series units, it is necessary to send the NextMessageIsTimeZones command prior to sending this command. On F series units, the NextMessageIsTimeZones command is allowed, but not required. When in doubt, send the NextMessageIsTimeZones command.

Field Bytes Offset DescriptionHolidays 48 0 Holiday table. See page 194 for detailsTime Zones 720 48 Time Zone Table. See page 195 for detailsTotal 768

EHK•

EHP•

FHK•

FHP•

HP4K•



HereIsBankNumber ASCII: F Hex: 46


Description Prepares HGU to receive a bank of user database data.

Data

Response HereIsStatus (some versions do not respond to invalid data, see notes below)

DLL Function rsiHereIsBankNumber

Portability

NotesThis command is part of the block-mode user database restore operation. The proper technique for this operation is explained in Section 6.11.3 on page 233.

On E series units, the HereIsDataBank command must be sent not more than 5 seconds after sending this command. F series units do not have this time restriction.

The allowable range of bank numbers depends on the memory capacity of the specific HGU. See the appendix for a table, by model, of allowable ranges of bank numbers.

Different models will behave differently if the bank number given is out of range. E series units with firmware compiled prior to 5/19/97 will accept the invalid bank and write the data from the HereIsDataBank command into an undefined area of system RAM. E series units with firmware compiled after 5/19/97 will fail to respond to this command if an invalid bank number is received, and a subsequent HereIsDataBank command will be ignored. F series units will respond to this command in all cases, but the HereIsDataBank command will be ignored if the bank number is out of range. It is strongly recommended that this command be used only when it is certain that the bank number is within the range of the unit’s memory capacity.

Field Bytes Offset DescriptionBank Number 2 0 Bank number of next data bankTotal 2

EHK•

EHP•

FHK•

FHP•

HP4K•



HereIsBellScheduleTable ASCII: X Hex: 58


Description Send a bell schedule to the HGU

Data


DLL Function rsiHereIsBellScheduleTable

Portability

NotesThis command has more than 255 bytes of data and requires the high bit in the Type field of the command packet be set.

On all E series units, it is necessary to send the NextMessageIsBellSchedule command not more than 5 seconds before sending this command. On F series units, the NextMessageIsBellSchedule command is allowed but not required, and there is no time restriction on it. When in doubt, send the NextMessageIsBellSchedule command.

This command is responded to, but ignored, on all HandKey units. Note also that the HandPunch unit must not be operating in card reader emulation mode in order for bell schedules to have any effect. See Section 4.12 on page 65 for more information.

Field Bytes Offset DescriptionID 300 0 Array of 100 bell schedule entries. See page

page 182 for details.Total 300

EHK EHP•

FHK FHP•

HP4K•



HereIsDataBank ASCII: G Hex: 47

Function Group User database backup

Description Loads a bank of user database data into the HGU from the host system.

Data


DLL Function rsiHereIsDataBank

Portability

NotesThis command has more than 255 bytes of data and requires that the high bit of the Type field in the command packet be set.

This command is part of the block-mode user database restore operation. An example of the correct way to implement this is provided in Section 6.11.3 on page 233.

This command must be preceded with the HereIsBankNumber command. See the Appendix for a table of allowable bank numbers for each model and memory option, and see the notes on the HereIsBankNumber command for details about how the different models behave when the bank number is out of range.

Field Bytes Offset DescriptionData 4096 0 User dataTotal 4096

EHK•

EHP•

FHK•

FHP•

HP4K•



HereIsDecisionMenuData ASCII: d Hex: 64

Function Group Function key menu

Description Loads the menu data into the HGU.

Data


DLL Function rsiHereIsFkeyData

Portability

NotesThe data sent with this command must always be the output of the Function Key Compiler program. The only exception is that it is acceptable to send a block of all 0FFH to clear the menu data and inactivate all function keys.

Field Bytes Offset DescriptionData 4096 0 Menu dataTotal 4096

EHK EHP FHK•

FHP•

HP4K•



HereIsDisplayMessage ASCII: P Hex: 50

Function Group Hardware control

Description A message is displayed on the LCD

Data


DLL Function rsiHereIsDisplayMessage

Portability

NotesThere are two forms of this command, distinguished by the value of the first byte of the data. Both forms will not display if the LCD is currently busy, which means it is displaying anything other than the idle state prompt (“Ready” or “Enter ID”). See Table 47 on page 249 for the LCD character set.

Display Message – Form 1

This form is used for unconditionally displaying text for a certain amount of time. The 37 bytes of the data sent are as follows. A time of 0 will result in the message being displayed indefinitely.

Display Message – Form 2

This form causes the HGU to display the given text if the ID number of this message matches the last ID number entered at the HGU. The text is displayed until the * or # key is pressed or a card is read.

Field Bytes Offset DescriptionData 37 0 Two variant forms. See notes below.Total 37

EHK•

EHP•

FHK•

FHP•

HP4K•

Field Bytes Offset DescriptionHeader 1 0 Must be FFH. This is how Form1 is distinguished from

Form2.Time 1 1 Number of ½ second intervals the message will be dis-

played. Unused 3 2 Not used. Data in these bytes is ignored by the HGU.Text 32 5 Text to display. See Table 47 on page 249 for the LCD

character set.

Field Bytes Offset DescriptionID 5 0 ID for matching.Text 32 5 Text to display if ID matches. See the appendix for a

table of the LCD character set. See Table 47 on page 249 for the LCD character set.



To be considered “entered” for the purposes of this command, an ID must be entered either by keypad or by card, not by the VerifyOnInternalData command. Furthermore, the ID entry must have resulted in at least an attempt at a hand reading, whether successful or not. ID numbers which are not enrolled, are outside their authorized access time, are locked out, or which otherwise failed to cause an attempt at a hand reading are not considered as “entered” for purposes of this command.



HereIsExtendedSetup ASCII: + Hex: 2B


Description Sends extended setup data to an F series unit.

Data


DLL Function rsiHereIsExtSetupData

Portability

NotesA description of the proper technique for updating setup information is provided in Section 6.3 on page 218. It is very important that the correct sequence be followed. The current setup be should be retrieved from the HGU using the SendExtendedSetup command, then the necessary fields modified, then the new extended setup data sent with this command. Do not modify any undocumented fields in the extended setup data area, as they may be used for new features in the future.

This command, and the items controlled by it, are only supported on the F series products. E series units will not respond to this command.

The layout and content of the extended setup data is discussed in detail beginning on page 185.

Field Bytes Offset DescriptionData 128 0 Extended setup data. See page 185 for details.Total 4096

EHK EHP FHK•

FHP•

HP4K•



HereIsExtendedUserRecord ASCII: x Hex: 78

Function Group HP-4000 only

Description Add or replace an Extended User Record in an HP-4000 unit

Data


DLL Function rsiHereIsExtUserRecord

Portability

NotesThis command works very much like the HereIsUserRecord command, but applies to an entire extended user record. If the ID is already enrolled in the user database, the data supplied with this command replaces the data in the HGU user database. If the ID is not enrolled, a new record is created with the given ID and data.

Field Bytes Offset DescriptionID 5 0 User IDTemplate 9 5 Hand geometry template – do not alterAuthority 1 14 Authority and reject override thresholdTimezone 1 15 Time zonePTI 12 16 Packed time intervalsFKMASKS 2 28 Function key use masksName 16 30 User name for displayData 24 46 Custom user dataAmnesty 1 70 Amnesty punch countRESERVED 6 71 Reserved – do not alterTotal 77




HereIsSetup ASCII: = Hex: 3D


Description Send basic setup data to the HGU

Data


DLL Function rsiHereIsSetup

Portability

NotesA description of the proper technique for updating setup information is provided in Section 6.3 on page 218. It is very important that the correct sequence be followed. The current setup be should be retrieved from the HGU using the SendSetupData command, then the necessary fields modified, then the new setup data sent with this command. Do not modify any undocumented fields in the setup data area, as they may be used for new features in the future.

E series units save the data received by this command in a system RAM area. The new setup data takes effect immediately, but is not actually transferred to NV-RAM, so it will be lost if the unit is powered down. It is therefore important to follow this command with the UpdateNVRAM command so the data is permanently saved.

F series units automatically transfer the received data to NV-RAM before responding to this command, so the UpdateNVRAM command is not needed. Saving the data to NV-RAM is a slow process, so the HGU may take up to 1 second to respond to this command.

Field Bytes Offset DescriptionData 128 0 Basic Setup Data. See page 173 for details.Total 77

EHK•

EHP•

FHK•

FHP•

HP4K•



HereIsSmartCardRecord ASCII: i Hex: 69

Function Group Enrollment

Description send User Record to initialize Smart Card

Data


DLL Function rsiHereIsSmartCardRecord

Portability

NotesIf the hand reader is equipped with a smart card reader, this command causes the user record sent as part of the command to be written to the smart card. The operator is prompted by the hand reader to place and remove a card as necessary.

It is recommended that the reader be placed in the second idle mode prior to issuing this command, and taken out of idle mode (via Resume) only after the operation is complete or has timed out. Except for polling, no other commands should be issued to the hand reader until this one has finished or timed out.

While this command is in progress, the CMD_BUSY bit is asserted in status reports. If the command is successful, then the RSLTS_RDY bit is set in the status; and if the command times out, the FAILED_CMD bit is set. If the hand reader is not equipped with a smart card reader, the command finishes immediately and no data is written.

Field Bytes Offset DescriptionID 5 0 User IDTemplate 9 5 Hand geometry template. Do not alter.Authority 1 14 Authority and reject overrideTimezone 1 15 Index into time zone tableTotal Length 16

EHK EHP FHK•

FHP•

HP4K•



HereIsTime ASCII: A Hex: 41


Description Sends the time and date from the host system to the HGU

Data


DLL Function rsiHereIsTime

Portability

NotesUnits with firmware compiled after 9/4/97 will truncate the year received to keep it within the range 0 – 99. Earlier units will not do this. See the section on Y2K compliance for a full discussion of the implications of this.

Field Bytes Offset DescriptionSeconds 1 0 Seconds, 0-59Minutes 1 1 Minutes, 0-59Hours 1 2 Hours, 0-23Day 1 3 Day, 1-31Month 1 4 Month, 1-12Year 1 5 YearTotal Length 6

EHK•

EHP•

FHK•

FHP•

HP4K•



HereIsUserRecord ASCII: 7 Hex: 37


Description Adds or updates a basic user record

Data


DLL Function rsiHereIsUserRecord

Portability

NotesThis command is used to add or update a basic user record. This is equivalent to what was previously referred to as simply a “user record.”

If the ID is already enrolled in the user database, the data supplied with this command replaces the data in the HGU user database. If the ID is not enrolled, a new record is created with the given ID and data.

On HP-4000 units, this command will affect only the BUR portion of the user record for updates. For adds, the XUR portion will be initialized to all zeros.


EHK•

EHP•

FHK•

FHP•

HP4K•



LEDControl ASCII: # Hex: 23


Description Activates the Red/Green LED, if present

Data


DLL Function None

Portability

NotesThis command activates the Red/Green LED which is present on the top panel of all Model F units and many Model E units. On units which do not have the LED installed, this command will have no effect and will return the normal response. There is no way to determine through software if the LED is physically present.

The control code should be ASCII ‘R’/Hex 52 to turn the LED red and ASCII ‘G’/Hex 47 to turn the LED green. All other values will turn the LED off. The LED will remain lit until anything is written to the display, or until a control code other than ASCII ‘R’/Hex 52 or ASCII ‘G’/Hex 47 is sent. In order to preserve compatibility with future enhancements, use control code value Hex FF to turn the LED off.

Field Bytes Offset Description

Control Code 1 0Specifies color – Red (ASCII ‘R’/Hex 52) or Green (ASCII ‘G’/Hex 47)

Total Length 1

EHK•

EHP•

FHK•

FHP•

HP4K•



NextMessageIsBellScheduleTable ASCII: W Hex: 57


Description Prepares the HGU to receive a bell schedule table

Data None


DLL Function rsiNextMessageIsBellScheduleTable

Portability

NotesOn E series units, it is necessary to send this command prior to sending the HereIsBellSchedule command. F series units do not require this command, but will accept it.

HandKey units may respond to this command, but it will have no effect. HandKey units do not support bell schedules.

EHK•

EHP•

FHK•

FHP•

HP4K•



NextMessageIsTimeZones ASCII: R Hex: 52


Description Prepares the HGU to receive a time zone table

Data None


DLL Function rsiNextMessageIsTimeZones

Portability

NotesThis command is required only on E series units before sending the HereAreTimeZones command. F series units do not require this command, but will accept it.

EHK•

EHP•

FHK•

FHP•

HP4K•



OutputControl ASCII: O Hex: 4F

Function Group Hardware Control

Description Activate or deactivate an output

Data


DLL Function rsiOutputControl

Portability

NotesNote that the HK-CR and HP-2000 will respond to this command, but no action will be taken.

The following state values are supported on all models

1 Timed unlock using the unlock timer setting (from the basic setup data)2 Unlock is indefinite3 Re-lock4 Turn the Auxiliary output on. (On F series units, this refers to AuxOut0).5 Turn the Auxiliary output off. (On F series units, this refers to AuxOut0).6 Disable the lock output for hand-initiated unlocks. This is re-enabled by sending this

command again with the state set to 1, 2, or 3.

The following state values are supported only on F series products.

7 Turn AuxOut1 on indefinitely8 Turn AuxOut1 off9 Turn AuxOut2 on indefinitely10 Turn AuxOut2 off11 Turn AuxOut0 on, timed12 Turn AuxOut1 on, timed13 Turn AuxOut2 on, timed

Other state values will have no effect.

Field Bytes Offset DescriptionState 1 0 See notes below.Total Length 1

EHK•

EHP•

FHK•

FHP•

HP4K•



PrinterPassThrough ASCII: p Hex: 70

Function Group Hardware control

Description The data supplied with the command is sent directly out the printer port

Data Data to be sent to printer. Can be variable length, but is limited. See notes.


DLL Function rsiPrinterPassThrough

Portability

NotesThis command was implemented on 12/5/95. Units with firmware compiled prior to this date do not support this command and will not respond to it.

The data is passed through to the RS-232 port directly. It is up to the device attached to the RS-232 port to know how to handle the data. The HGU does not alter or interpret the data.

The length of data sent with this command is variable. On Model F units, up to 4096 bytes may be sent. On Model E units, up to 256 bytes may be sent. Do not exceed this length.

The HGU will send as many bytes to the printer as are in the received packet. Note that the value in the length field of the command packet must match the number of bytes actually sent.

The text received goes into a printer port output buffer. If this buffer is full, the command will wait for adequate space to become available. This may take several seconds, depending on the baud rate the port is configured for and the length of the text sent. The response to this command is sent after all the received text has been put into the printer port output buffer.

In order to prevent the various tasks in the HGU which use the port from interfering with each other, the printer port is locked with a semaphore. This command waits for the port to become free before attempting to use it. If the printer does not become free within 2 seconds of the receipt of this command, the command is aborted and no response is sent to the host. This scenario is extremely unlikely.

Note that on those models which support RS-232 host communication, this command will have no effect if the unit is configured to use the RS-232 port for host communication.

EHK•

EHP•

FHK•

FHP•

HP4K•



RemoveUserMessages ASCII: w Hex: 77


Description All messages for a given user are removed.

Data


DLL Function rsiRemoveUserMessage (note the missing ‘s’)

Portability

NotesMessages for other users remain as they were. This command may create holes in the message pool which, under certain circumstances, may cause messages to appear out of sequence. See Section 4.15.1 on page 68 for a full explanation of this.

If there are no messages in the message pool with the given ID, the HGU responds normally and takes no further action.

Field Bytes Offset DescriptionID 5 0 User ID for whom messages are removedTotal Length 5




RemoveUserRecord ASCII: ? Hex: 3F


Description The user record with the given ID is removed from the user database.

Data


DLL Function rsiRemoveUserRecord

Portability

NotesThis command will remove the user record with the given ID from the user database. If no record matching the given ID exists, the HGU will respond to this command normally and take no further action.

On HP-4000 units, this command will remove the entire Extended User Record. There is no other command on the HP-4000 for removing a user record.

Field Bytes Offset DescriptionID 5 0 User ID to remove from databaseTotal Length 5

EHK•

EHP•

FHK•

FHP•

HP4K•



Resume ASCII: 1 Hex: 31


Description Take the HGU out of idle mode.

Data None


DLL Function rsiResume

Portability

NotesIf the HGU is in idle mode (as a result of sending the EnterIdleMode command) this command will take it out of idle mode. If the HGU is not in idle mode, the HGU responds normally and no further action is taken.

This command will also cause the unit to reset the display to the “Ready” or “Enter ID” prompt and the date/time display.

Regarding the two idle modes, there is no way to ask a reader which of the two idle modes is currently in effect, or whether it is currently in or out of idle mode. At powerup (regardless of DIP-switch settings) the reader is not in idle mode.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendCalibrationData ASCII: < Hex: 3C

Function Group Maintenance

Description Causes the HGU to send the results of the latest calibration operation

Data None

Response HereIsCalibrationData

DLL Function rsiSendCalibrationData

Portability

NotesA calibration operation is performed as part of every power-on sequence, regardless of the settings of the DIP switches. A calibration may also be commanded by the host system by sending the Calibrate command. Either way, the results of the calibration are available through this command.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendCardData ASCII: g Hex: 67

Function Group Status Functions

Description Causes HGU to send recent card data

Data None

Response HereIsCardData

DLL Function None

Portability

NotesWith respect to status reporting, this command has the same side effects as the two “poll” commands, viz. the commands SendStatusChecksum and SendStatusCRC, EXCEPT that it does not affect the choice of Checksum versus CRC.

This functionality is implemented in F-Series PROMs made after October 19, 2001, and in E-Series (ID3D) PROMs made after May 23, 2002.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendDataBank ASCII: H Hex: 48

Function Group User database backup

Description A bank of data from the user database is sent from the HGU to the host system

Data

Response HereIsDataBank (Type 6)

DLL Function rsiSendDataBank

Portability

NotesThis command is part of the block-mode user database backup operation. The correct technique for this procedure is explained in Section 6.11 on page 230.

Note that there is a limit on the valid range of bank numbers, depending on the model and memory configuration of the specific HGU receiving the command. See the appendix for a complete table of HGU models and their memory capacity.

Different versions of firmware will respond differently to out-of-range bank numbers. All models with firmware compiled prior to 6/18/98 will send unpredictable data if the bank number is out of range. This data may be indistinguishable from valid user database data, so great care must be taken to know the number of banks in the specific reader that is being backed up and not to request banks outside that limit. Units with firmware compiled after 6/18/98 (this includes all F series models) will respond to out-of-range bank numbers by sending a bank that is guaranteed to begin with 0FFH. Since no valid user record begins with 0FFH, this signals the backup program that the last bank of the user database has been retrieved.

Field Bytes Offset DescriptionBank 2 0 Bank number, LSB firstTotal Length 2

EHK•

EHP•

FHK•

FHP•

HP4K•



SendDatalog ASCII: M Hex: 4D

Function Group Transactions log management

Description The oldest entry in the transactions log is returned to the host system

Data None

Response HereIsDatalog

DLL Function rsiSendDataLog

Portability

NotesDatalogs are returned to the host system on a first-in, first-out basis, meaning that they are retrieved in the order in which they happened.

If there is no response to this command, or if the response contains an error (bad Frame Check Sequence) the SendPreviousDatalog command should be used to make the HGU send the datalog again.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendExtendedSetup ASCII: , Hex: 2C


Description The HGU sends the extended setup data (F series only) to the host system

Data None

Response HereIsExtendedSetupData (41H)

DLL Function rsiSendExtSetup

Portability

NotesThis is the first step in changing the extended setup data. See Section 6.3 on page 218 for the correct technique of changing the extended setup data.

EHK EHP FHK•

FHP•

HP4K•



SendExtendedUserRecord ASCII: t Hex: 74

Function Group HP-4000 only

Description The extended user record with the ID matching the given ID is returned to the host system

Data

Response HereIsExtendedUserRecord

DLL Function rsiSendExtUserRecord

Portability

NotesThis command is supported only on the HP-4000. Other models will not respond to it.

This command behaves exactly like the SendUserRecord (‘8’) command, except that an extended user record is returned. Just as the ‘8’ command, this command returns a record with the ID field containing all zeroes if the requested ID is not enrolled in the user database.

Field Bytes Offset DescriptionID 5 0 User ID requestedTotal Length 5




SendInternalErrorLog ASCII: \ Hex: 5C


Description Returns the contents of the internal error log

Data None

Response HereIsInternalErrorLog

DLL Function not implemented in the DLL

Portability

NotesThis command, and the internal error log, were implemented on 4/20/00, and were only implemented in the Model F units. Units with firmware compiled prior to this date will not respond to this command. This command is for diagnostic purposes. Contact RSI technical support for information on the data returned.

EHK EHP FHK•

FHP•

HP4K•



SendKeypadData ASCII: h Hex: 68

Function Group Status Functions

Description Request raw keystroke data from reader

Data

Response HereIsKeypadData

DLL Function None

Portability

NotesThere is a small buffer for saving raw keystrokes. It holds 14 bytes. If it fills up, any new keystrokes are added to the end, and the oldest saved value is discarded. The buffer may, however, be flushed under certain circumstances, specifically (1) after a certain timeout, and (2) in the course of replying to this command.

The timeout occurs after a period of inactivity following the most recent keystroke. The timeout value is equal to the value used by the HGU for timing out when in normal ID-entry mode, and the operator has stopped typing without completing an ID entry. But for the purpose of this command, the timeout applies regardless of the mode of operation.

There is one byte of data, henceforth called the “arg.” For the following arg values, the indicated actions are taken. Additional arg values may be added at a later date. Unless otherwise indicated, all keystrokes currently in the buffer are sent, and the buffer is flushed.

0 Just send data; no changes to mode.

1 Temporary mode change: disable normal use of ID entry, except when in command mode. After the timeout value mentioned above, this mode setting expires, and the HGU reverts to normal operation. Keystrokes are echoed to the LCD, being replaced by asterisks if model and setup operations are such as to require an ID to be replaced by asterisks. These echoed characters will be taken down after two seconds, or when this mode is exited, whichever happens first. Reply gives any pending characters, and the buffer is flushed.

2 Just change mode as in (1) above, without sending keystrokes or flushing the buffer. This will result in zero bytes in the reply, even if data was pending.

3 Mode change: reenable normal use of ID entry.

4 Just flush buffer; no changes to mode. This will result in zero bytes in the reply, even if data was pending.

The reply to this command, HereIsKeypadData (see page 161), is a variable length message with a length of at least 1.

Field Bytes Offset DescriptionArg 1 0 Control code (see Notes below)Total Length 1

EHK•

EHP•

FHK•

FHP•

HP4K•



This command was added to the F-Series on 8-16-2004, and is available in Versions 216 and higher of the PROM.

This command was added to the E-series on 3-7-2005, and is available in those versions of the many PROMs having a version number of 16 (shown on the LCD by the occurrence of the text “.16” as the rightmost text on the Line-1 Powerup String). The mode changes caused by arg values of 1, 2, or 3 have no effect in the E-Series. Note that there are many differences between the F-Series and the E-Series with respect to the exact keystrokes used for particular operations.



SendLastUserRecord ASCII: @ Hex: 40

Function Group Results

Description Returns the last ID entered and the template of the last hand image taken

Data None

Response HereIsUserRecord

DLL Function rsiSendLastUserRecord

Portability

NotesThe ID returned by this command is the last ID entered by the keypad or card reader which successfully started a hand reading. ID numbers sent by the VerifyOnInternalData command are not considered “entered” for the purposes of this command. ID numbers which are not enrolled, are outside their authorized access times, are locked out, or otherwise fail to cause an attempt at a hand reading are not considered “entered” for the purposes of this command.

The template returned by this command is that of the last image taken, regardless of what caused the image to be taken, and regardless of what score, if any, this template may have generated. This command does not return the template which results from the averaging with the template in the user database. Normally, it is the results of the average that a host PC system will want to retrieve and store in its database, not the template returned from this command. Use the SendTemplate command to retrieve this average template.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendOEMCode ASCII: o Hex: 6F

Function Group Status functions

Description Returns the factory-assigned OEM code

Data None

Response HereIsOEMCode

DLL Function rsiSendOemCode

Portability

NotesThe OEM code is a value assigned by special arrangement with RSI at the factory. It may be queried, but not set.

If no arrangement has been made to assign a specific OEM code, the value returned is 0.

EHK EHP FHK•

FHP•

HP4K•



SendPreviousDatalog ASCII: m Hex: 6D

Function Group Transactions log management

Description Re-sends the last datalog

Data None

Response HereIsDatalog

DLL Function rsiSendPreviousDataLog

Portability

NotesThis command is used when the response to the SendDatalog command has an error or is not received. The last datalog sent is sent again. It is the responsibility of the host system to determine whether this is a duplicate of the last one. For a full description of the correct technique for reliably retrieving datalogs, refer to Section 6.10 on page 226.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendReaderInfo ASCII: s Hex: 73


Description Requests various information on the unit’s configuration and state

Data None

Response HereIsReaderInfo

DLL Function rsiSendReaderInfo

Portability

NotesFor details of the HereIsReaderInfo response, see page 165.

EHK EHP FHK•

FHP•

HP4K•



SendResults ASCII: C Hex: 43


Description Requests results from the last hand reading (see notes)

Data None

Response HereAreResults

DLL Function rsiSendResults

Portability

NotesThe HGU has an internal structure called the “results buffer.” This buffer contains an ID and a score (see the description of the HereAreResults response). The ID and score fields are updated after verification operations, but not enrollment operations.

For verifications initiated at the unit (keypad or card), both the score and ID portions of the results buffer are updated after a successful hand reading is completed. This does not necessarily mean that access was granted, only that a hand was read. If access was granted, the score will be positive. If access is denied, the score will be negative. If the hand reading was unsuccessful (for example, it timed out or a non-hand was inserted into the unit) the results buffer is not changed, and the results from the last successful hand reading will remain.

For verifications initiated by the host system (using the VerifyOnExternalData or VerifyOnInternalData commands) the ID field is never updated, and the score field of the results buffer is updated at the same time the RSLTS_RDY bit is set.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendSetup ASCII: N Hex: 4E


Description Request setup information from the HGU

Data None

Response HereIsSetupData

DLL Function rsiSendSetup

Portability

NotesThis command causes the HGU to return the Basic Setup Data. Use the SendExtendedSetupData command to request the extended setup data from those units which support it.

This command is part of a series of commands which are used to modify the HGU’s setup. Examples of the correct technique for reading, modifying, and writing setup data are provided Section 6.3 on page 218.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendStatusChecksum ASCII: ; Hex: 3B

Function Group Status

Description Get status from HGU, put HGU into checksum FCS mode

Data None


DLL Function not supported

Portability

NotesThis and subsequent commands packets will be validated with a checksum for the Frame Check Sequence field.

See SendStatusCRC and the HereIsStatus response for further details.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendStatusCRC ASCII: D Hex: 44

Function Group Status

Description Get status from HGU, put HGU into CRC FCS mode

Data None


DLL Function rsiSendStatusCRC

Portability

NotesThis and subsequent command packets will be validated with a CRC for the Frame Check Sequence field.

This command will take the unit out of Idle mode (see the EnterIdleMode command). On units with firmware compiled after 6/5/00, the unit will resume normal mode only if the ‘E’ command was used. If the ‘e’ command was used to enter Idle mode, the SendStatus commands will not resume normal mode.

This is the main command used for polling the HGU. The information returned includes the status of the finger pin LEDs, any hand reading operations in process, and the state of the inputs and outputs. There are also bits for indicating when a datalog is ready, when a key has been pressed, and when the HGU has been reset.

Full details of the contents of the response are given in the section on the HereIsStatus response, page 168.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendTemplate ASCII: K Hex: 4B


Description Causes the HGU to return the contents of the template buffer

Data None

Response HereIsTemplate

DLL Function rsiSendTemplate

Portability

NotesSee Section 4.4 on page 56 for a discussion of when the template buffer is updated.

This command also clears the VERIFY_RDY and RSLTS_RDY bits in SysStat1.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendTimeAndDate ASCII: a Hex: 61


Description Causes the HGU to return the time and date from its clock

Data None

Response HereIsTimeAndDate

DLL Function rsiSendTime (note the different name)

Portability See note below.

NotesThis command is supported only on units with firmware compiled after 4/14/97.

The time and date from the HGU are returned. See the section on Y2K compliance for a discussion of some possible issues that may arise.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendTimeZones ASCII: $ Hex: 24


Description Causes the HGU to return the time zone and holiday table

Data None

Response HereAreTimeZones

DLL Function not implemented in the DLL

Portability See note below.

NotesThis command is supported only on units with firmware compiled after 6/28/00.

The data returned is exactly the same as that sent with the HereAreTimeZones command. Normally, a host PC knows the time zone table already, since it typically sends it to a unit, but this command can be used for duplicating an unknown unit or for diagnostic purposes.

EHK•

EHP•

FHK•

FHP•

HP4K•



SendUserRecord ASCII: 8 Hex: 38

Function Group User Database Management

Description The user record for the given ID is returned.

Data

Response HereIsUserRecord

DLL Function rsiSendUserRecord

Portability

NotesIf the given ID is not enrolled in the HGU, the ID field of the response is set to all zeros.

On HP-4000 units, this command returns only the basic user record portion of the user record. Use the SendExtendedUserRecord to retrieve the complete user record.

Field Bytes Offset DescriptionID 5 0 User ID requestedTotal Length 5

EHK•

EHP•

FHK•

FHP•

HP4K•



SetExtendedUserData ASCII: u Hex: 75


Description Set the extended user data portion of a user record

Data

Response HereIsStatus or UnableToCompleteCommand

DLL Function rsiSetExtUserData

Portability

NotesThis command replaces the extended portion of a user record with the given data. The basic portion is not changed. See page 192 for details on the fields in the extended user data.

If the given ID is not enrolled in the HGU, the response is UnableToCompleteCommand.

This command is typically used to add HP-4000 capability to existing code on the host system. It provides a convenient way of breaking the HP-4000 user database functions from the basic user record functions.

Field Bytes Offset DescriptionID 5 0 User ID for whom messages are removedPTI 12 5 Packed time intervalsFKMASKS 2 17 Function key use masksName 16 19 User name for displayUDF 24 35 Custom user dataAmnesty 1 59 Amnesty punch countRESERVED 6 60 Reserved. Do not alter.Total Length 66




SetUserData ASCII: f Hex: 66


Description Set the user data portion of an extended user record

Data

Response HereIsStatus or UnableToCompleteCommand

DLL Function rsiSetUserData

Portability

NotesThis command sets only the user data portion of an extended user record. This is the portion which may be used to display data with an INFO object in the function key menus. The rest of the user record is not changed.

If the update is successful, the response is HereIsStatus. If the given ID is not enrolled in the user database, the response is UnableToCompleteCommand.

Field Bytes Offset DescriptionID 5 0 User ID for whom data is to be setUDF 24 5 Custom user dataTotal Length 29




UpdateNVRAM ASCII: L Hex: 4C


Description The setup data is transferred to NV-RAM

Data None


DLL Function rsiUpdateNVRam

Portability

NotesThis command transfers the setup data sent by the HereIsSetupData command to the HGU’s NV-RAM. If this command is not sent, the setup data will take effect, but it will be lost when the HGU is powered up again.

This command is not required on the F series units; it is implicitly part of the HereIsSetupData command.

EHK•

EHP•

FHK•

FHP•

HP4K•



VerifyOnExternalData ASCII: J Hex: 4A

Function Group Hand Verification

Description Initiates a hand verification against a template supplied by the host system

Data


DLL Function rsiVerifyOnExternalData

Portability

NotesThe reader will display a prompt based on the value of the prompt part of the data supplied. See the EnrollUser command.

After this command has been sent, the host should poll the HGU using one of the SendStatus commands and examine the resulting status bits. While this command is in progress, the CMD_BUSY bit is set. If the verification is successful (that is, a template was derived from the hand image), the RSLTS_RDY bit is set. If the verification times out or a template could not be derived from the image, the FAILED_CMD bit is set.

When the RSLTS_RDY bit is set, the host may request the score and updated template with the SendTemplate command or the SendResults command. However, the score must be less than 2222 for the template to be valid.

If the template supplied with this command is all FFH, the hand reading proceeds normally, but a score of FFFFH is returned. This enables operation without requiring hand verification, just like the “Special Enrollment” feature.

If the template supplied with this command is all FEH, the hand reading proceeds normally, but a score of FFFEH is returned. The template which ends up in the template buffer will be the template derived from the hand reading. This allows an automatic enrollment.

Field Bytes Offset DescriptionPrompt 2 0 See the EnrollUser commandTemplate 9 2 Hand geometry template for verificationTotal Length 11

EHK•

EHP•

FHK•

FHP•

HP4K•



VerifyOnInternalData ASCII: Q Hex: 51

Function Group Hand Verification

Description Initiates a hand verification against the template stored in the user database for the given ID

Data


DLL Function rsiVerifyOnInternalData

Portability

NotesIf the given ID is not enrolled in the user database, the ID_NIM bit is set and no hand verification happens. However, if the ID is in memory, the ID_NIM bit is not cleared. If it was set due to a previous NIM condition (perhaps by a keypad entry) it will remain set. So if it is important to have the state of ID_NIM indicate the presence or absence of the ID sent with this command, clear the ID_NIM bit using the SendResults command before sending this command.

After this command has been sent, the host should poll the HGU using one of the SendStatus commands and examine the resulting status bits. While this command is in progress, the CMD_BUSY bit is set. If the verification is successful (that is, a template was derived from the hand image), the RSLTS_RDY bit is set. If the verification times out or a template could not be derived from the image, the FAILED_CMD bit is set. A more detailed description of how to use this command is given in Section 6.8 on page 225.

This command requires the unit to search through its user database to locate the template for the given ID. This may take a significant amount of time, up to 3/4 second on Model F units with 30000 users enrolled, or about 1 second on Model E units with 30000 users. This will be a delay between the time the command is received and the time hand verification begins. The response to this command is returned immediately, before database searching or hand verification actually begins.

Field Bytes Offset DescriptionID 5 0 ID to use for verificationTotal Length 5

EHK•

EHP•

FHK•

FHP•

HP4K•



Blank page.



5.5 ResponsesResponses are listed here in alphabetical order of their English name. Note that some responses have the same name as some commands. This is merely a coincidence and nothing should be inferred from it.

Each response is listed with a detailed description of the data it contains. Some data, however, is sent by more than one response, or as part of a command. These data items have been given their own names and are described in Section 5.6 on page 173.

The data structures defined in the Windows DLL are based on the data contained in these responses, but are structured differently so that it is easier to access the individual data items from high-level languages such as Visual Basic. The data received directly from the HGU is what is documented here, and the details of the arrangement of the data will differ from the structures defined in the DLL. Please refer to the DLL documentation for information regarding the format of the DLL structures.

Response ASCII: X Hex: FF

Description A description of the response appears here.

Data The data structure which accompanies the response is shown here. Details of the data structures appear in Section 5.6 on page 173.

NotesSome responses require a more detailed description. That description will appear here.



HereAreResults ASCII: 5 Hex: 35H

Description Returns the contents of the results buffer. Response to SendResults command.

Data

NotesThe results buffer is described in more detail in Section 4.4 on page 56, and the various conditions which cause the ID and score to be updated are described in Section 4.5 on page 57 and Section 4.6 on page 59. The main idea is that the ID field contains the last ID entered, from whatever source. The score field contains the score for the last hand verification, regardless of the subsequent behavior of the unit based on that verification.

Field Bytes Offset DescriptionID 5 0 Last ID eneteredScore 2 5 Score for last hand verificationTotal 7



HereAreTimeZones ASCII: $ Hex: 24

Description Returns the contents of the time zone table.

Data

NotesThis is sent in response to the SendTimeZones command. This was implemented on 6/29/00, and units with firmware compiled prior to that date will not send this response. The structure of this response is exactly the same as the HereAreTimeZones command.

Field Bytes Offset DescriptionHolidays 48 0 Holiday table. See page 194 for details.Time Zones 720 48 Time Zone Table. See page 195 for details.Total 768



HereIsCalibrationData ASCII: 3 Hex: 33

Description Returns current calibration information. Response to SendCalibrationData command.

Data

NotesThe row and column alignment offsets are the actual values, not the relative values displayed in the command mode calibration display. The calibration display shows the deviation of the actual values from the factory alignment. The exposure time is the current exposure time in timer tick counts, not the relative number shown on the calibration display. The calibration display shows the current exposure time as a percentage of the value measured at the factory during manufacture. To convert this to milliseconds, divide by 307.2 on Model E units and 460.8 on Model F units. Most customer host systems will not need this information.

Field Bytes Offset DescriptionExposure 2 0 Camera exposure timeRow 2 2 Alignment offsetColumn 2 4 Alignment offsetTotal 6



HereIsCardData ASCII: 4 Hex: 34

Description Returns most recent card data input

Data

NotesThis is sent in response to the SendCardData command. It is a variable length message with a length of at least 4 bytes. The first three bytes are exactly the data that would be given for the many commands that get a status report by way of reply. This is followed by a byte that gives the length in BITS of the data that immediately follows it, which data has at least as many bytes as needed in order to hold the indicated number of bits, which latter are left-justified. If present, these bits give the most recently read card input data that has not yet been requested via this command. If no card data has been read since the last SendCardData command, then the length is zero.

Field Bytes Offset DescriptionSysStat0 1 0 See Table 11 on page 168SysStat1 1 1 See Table 12 on page 169MonStat 1 2 See Table 13 on page 169Length 1 3 Length of data in bitsCard Data varies 4 Data from last card readTotal Length 4 or more



HereIsDataBank ASCII: 6 Hex: 36

Description Returns a bank of user data. Response to SendDataBank command.

Data User data bank, 4096 bytes.

NotesThis response is sent only when the SendDataBank command is received. It is recommended that the procedure outlined in Section 6.11 on page 230 be followed for user database backups.

This response will set the high bit in the Type field.



HereIsExtendedSetupData ASCII: A Hex: 41

Description Returns the extended setup data, if applicable to the model. Response to SendExtendedSetupData command.

Data Extended setup data, 128 bytes. See page 185 for a data table and for detailed descriptions of the fields.

NotesOnly Model F units have the Extended Setup Data and the features that go along with it. Model E units will not send this response under any circumstances.

The default ready string depends on the model and on the language. In English, the default for HandKey units is “READY” and for HandPunch units is “ENTER ID”. See Table 47 on page 249 for the LCD character set.



HereIsExtendedUserRecord ASCII: 1 Hex: 31

Description Returns an extended user record. HP-4000 only. Response to SendExtendedUserRecord command.

Data Extended user record, 77 bytes. See page 193 for detailed descriptions of the fields.

NotesThis is returned on HP-4000 units in response to the SendExtendedUserRecord command. Other models will never return this. See page 193 for a full description of the fields in the extended user record.

Field Bytes Offset DescriptionID 5 0 User IDTemplate 9 5 Hand geometry template. Do not alter.Authority 1 14 Authority and reject override thresholdTimezone 1 15 Time zonePTI 12 16 Packed time intervalsFKMASKS 2 28 Function key use masksName 16 30 User name for displayData 24 46 Custom user dataAmnesty 1 70 Amnesty punch countRESERVED 6 71 Reserved. Do not alter.Total 77



HereIsKeypadData ASCII: b Hex: 62

Description Returns a list of recent keystrokes

Data A count byte followed by ASCII values of recent keystrokes in chronological order

NotesThis is the reply to SendKeypadData, and is a variable length message with a length of at least 1. The first byte gives the length in bytes of the data that immediately follows it. This length may be zero. If non-zero, the bytes that follow will give, in chronological order, values representing recent keystrokes.

Any data sent is automatically removed from the buffer. A length of zero, of course, indicates there are no recent keystrokes to send.

The character set includes the numeric characters ‘0’ through ‘9’ in their standard ASCII values of 0x30 through 0x39, respectively. The function keys F1 through F10 give upper case letters ‘A’ through ‘J’ in ASCII values of 0x41 through 0x4A, respectively. Other possible codes are listed below. .

There are many other two key press combinations; these are not noted at this time.

Field Bytes Offset DescriptionLength 1 0 Count of following bytes (can be zero)Values varies 1 Zero or more bytes of keystroke dataTotal 1 or more

Hex Description

0x2A Asterisk (*)

0x23 Pound Sign (#)

0x21 Clear Key

0x40 Enter Key

0x83 Clear and Enter Keys pressed simultaneously



HereIsMyTime ASCII: a Hex: 61

Description Returns the unit’s clock time. Response to SendTime command.

Data Time of unit’s clock, 6 bytes.

NotesFor information on Y2K issues and the contents of the year field, “Y2K Issues” on page 255.

Field Bytes Offset DescriptionSeconds 1 0 Seconds, 0-59Minutes 1 1 Minutes, 0-59Hours 1 2 Hours, 0-23Day 1 3 Day, 1-31Month 1 4 Month, 1-12Year 1 5 YearTotal Length 6



HereIsNextDatalog ASCII: 8 Hex: 38

Description Sent in response to SendNextDatalog and SendPreviousDatalog commands.

Data Datalog, 18 bytes. See page 183 for details.

NotesSee the example in Section 6.10 on page 226.

Field Bytes Offset DescriptionAddress 1 0 Address of unit which generated the datalogTime stamp 6 1 Time stamp of datalog (same as HereIsTime)Format 1 7 Identifies type of datalogData1 5 8 Content varies with typeData2 5 13 Content varies with typeTotal Length 18



HereIsOEMCode ASCII: O Hex: 4F

Description Returns the OEM code assigned to the unit. Response to SendOEMCode command.

Data

NotesThe OEM code is assigned by special arrangement with Recognition Systems. Not all versions of firmware support this command. Those which do not should retrieve the OEM code from the basic setup data.

Field Bytes Offset DescriptionOEM Code 2 0 OEM CodeTotal Length 2



HereIsReaderInfo ASCII: S Hex: 53

Description Returns information about the unit. Response to the SendReaderInfo command.

Data

Notes1. The model number is assigned per Table 9.

Field Bytes Offset DescriptionModel 1 0 Model number. See note 1.Memory 1 1 Memory configuration. See note 2.PromDate 20 2 Text string with PROM date.ModelName 17 22 Displayed on LCD line 2 at startupSN 4 39 Unit’s serial number.SN Prefix 1 43 Serial number prefix. See note 3.UCap 2 44 Maximum user capacityTCap 2 46 Maximum transactions capacityUNum 2 48 Current number of users enrolledTNum 2 50 Current number of transactionsConfig 14 52 Displayed on LCD line 1 at startupME 1 66 Modem/Ethernet adaptor flag. See note 4.AltProm 1 67 Alternate PROM style. See note 5.Reserved 34 68 Reserved. Values are unspecified.Total Length 102

Table 9: Model Identification Number

Model Number Model

0 HP-2000

1 HP-3000

2 HP-4000

3 HK-CR

4 HK-2



2. The memory configuration is assigned per Table 10.

3. The serial number prefix will be either 0, 1, or 2. The vast majority of units shipped have a prefix of 0. Prefix=1 means “E6-” appears on the label, prefix=2 means “E6HP-” appears on the label. These prefixes are labels only and have no functional meaning.

4. The modem/ethernet flag field is 0 when no adaptor is installed, 1 if a modem is installed, and 2 if an Ethernet adaptor is installed.

5. The Alternate PROM Style field is a one-byte field at offset 67, used to indicate an alternate PROM different from the mainstream F-Series PROM.

A value of zero in this field signifies the PROM is a mainstream one. A non-zero value signifies and identifies an alternate-style PROM.

A value of 1 signifies the A-Style PROM, introduced with Version 175 of the F-Series firmware. The A-Style PROM, unlike the mainstream PROM, permits communication via Ethernet even if the model number is 0. This affects, among others, the pseudomodel known as the HP-1000.

The B-Style PROM, signified by a value of 2, was introduced with Version 190. It generates datalog format 52 for NIM condition, and datalog format 53 when an existent User ID is entered for verification. Also, beginning with Version 219, HP models print a specifically formatted “ticket” for printer output, in lieu of the usual format.

The E-Style PROM, signified by a value of 5, was introduced with Version 227. It is like the A-PROM, except it disables upgrading of restrictions on the maximum number of users.

The letter designating the alternate PROM style appears, at powerup, on Line1 of the LCD display, just to the right of the PROM version number. This is also reflected in the “Config” field of the HereIsReaderInfo data.

Table 10: Memory Configurations

Memory Configuration Memory Size

0 128K

1 256K

2 640K



HereIsSetupData ASCII: 9 Hex: 39

Description Returns the basic setup data. Response to the SendSetupData command

Data Setup data, 128 bytes. See page 173 for the fields and descriptions.

NotesNot applicable.



HereIsStatus 0 30H

Description System status. This response is returned from a wide variety of commands.

Data System status, 3 bytes.

NotesThe three bytes returned are each bit fields with the structures shown in the following tables.

.

Field Bytes Offset DescriptionSysStat0 1 0 See Table XXXXXXXXXXX1SysStat1 1 1 See Table XXXXXXXXXXX2MonStat 1 2 See Table XXXXXXXXXXX2Total Length 3

Table 11: SysStat0 Bit Descriptions

Label Bit Mask Description

H_READ 0 01H Set when unit is trying to read a hand. Cleared when all fingers are in proper position on the platen.

LED1 1 02H Set during hand reading. Cleared when the little finger is closed to the guide pin.

LED2 2 04H Set during hand reading. Cleared when the ring finger is closed to the guide pin.

LED3 3 08H Set during hand reading. Cleared when the middle finger is closed to the guide pin.

LED4 4 10H Set during hand reading. Cleared when the index finger is closed to the guide pin.

ANY_KEY 5 20H Set when a key is pressed on the keypad. Cleared when the SendStatus command is received.

AUX_OUT_1 6 40H On Model F units, set to 1 when AuxOut1 is activated (low). Undefined on Model E units.

AUX_OUT_2 7 80H On Model F units, set to 1 when AuxOut2 is activated (low). Undefined on Model E units.



.

Table 12: SysStat1 bits


RES_SYS 0 01H Set when unit is initialized. Cleared when any command other than SendStatus is received.

VERIFY_RDY 1 02H Set when a hand has been read due to PIN entry at the unit. Cleared when the SendResults or SendTemplate command is received.

RSLTS_RDY 2 04H Set when Enroll, VerifyOnExternalData, or VerifyOnInternalData command has completed. Cleared when the SendResults or SendTemplate command is received. Note that this bit is not set on a timeout.

FAILED_CMD 3 08H Set when the Enroll, VerifyOnExternalData, or VerifyOnInternalData command fails to complete. Cleared when the HereIsStatus message is sent from the unit to the host, regardless of which command caused this response to be sent.

DLOG_RDY 4 10H Set whenever the datalog buffer is not empty. Cleared when the datalog buffer empties.

ID_NIM 5 20H Set when an ID entered for verification is not in memory. Cleared when the SendResults command is received. To get the last ID entered, use the SendResults command.

CMD_BUSY 6 40H Set when the Enroll, VerifyOnExternalData, or VerifyOnInternalData command is in progress.

KP_ID 7 80H Set when an ID is entered by the keypad. Cleared when the ID is entered by a card reader. This bit is not changed if the ID is entered by the host PC using the VerifyOnInternalData command.

Table 13: MonStat bits


TAMPER 0 01H Tamper status. 1=tamper, 0=no tamper

AUX_IN_1 1 02H AuxIn1 status. 1=high, 0=low. Only available on Model F units.

DOOR_SW 2 04H Door switch status. 1=high, 0=low

AUX_IN_0 3 08H AuxIn0 status. 1=high, 0=low. Only available on Model F units.

REX 4 10H Request to exit status. 1=high, 0=low.

Not used 5 20H Not used. Value is undefined.

AUX_OUT_0 6 40H AuxOut0 status, or bell output status. 1=high, 0=low.

LOCK 7 80H Lock output status. 1=high, 0=low.



HereIsTemplateVector ASCII: 7 Hex: 37

Description Response to the SendTemplate command.

Data Contents of the template buffer. See Section 4.4 on page 56 for details.

NotesThe template vector is from the most recent successful hand reading, or the enrollment average for enrollments. See Section 4.4 on page 56 for a detailed discussion of how the template buffer is used.

Field Bytes Offset DescriptionScore 2 0 Score of last verificationTemplate 9 2 Hand geometry templateTotal Length 11



HereIsUserRecord ASCII: 2 Hex: 32

Description Sent in response to the SendUserRecord command.

Data Basic user record.

NotesThis is sent in response to the SendUserRecord command on all models. To retrieve the HP-4000 extended user records, use the SendExtendedUserRecord command.




UnableToCompleteCommand ASCII: X Hex: 58

Description Indicates the received command could not be carried out. HP-4000 only.

Data Same as HereIsStatus.

NotesSent when the SetExtendedUserData, SetUserData, and SetUserMessage commands are unable to carry out their operation. See the individual command descriptions for more information.



5.6 Data StructuresThe following data structures occur commonly enough that they are grouped here rather than with a particular command or response. This section also contains the detailed descriptions of each field for those data structures which require such a description.

They are listed here in alphabetical order of their name.

BasicSetupData

Table 14: Basic Setup Data Fields

Field

Byt

es

Offs

et Description

Def

ault

Valu

e

See

Page

Reserved 2 0 Reserved; do NOT alterPassword5 12 2 ASCIIZ password for operating mode 5 “5#” page 175Password4 12 14 ASCIIZ password for operating mode 4 “4#” page 175Password3 12 26 ASCIIZ password for operating mode 3 “3#” page 175Password2 12 38 ASCIIZ password for operating mode 2 “2#” page 175Password1 12 50 ASCIIZ password for operating mode 1 “1#” page 175Threshold 2 62 System reject threshold (30 - 250) Note page 175Aux Flag Clear 1 64 If nonzero, valid access clears AUX 1 page 175Aux Timeout 2 65 Aux out on this long in seconds (0-20,000) 5 page 175Print Flag 1 67 If nonzero, valid access attempts are printed 0 page 175Status Flag 1 68 If nonzero, system status is displayed 0 page 176Aux Flag D 1 69 If nonzero, door alarm activates Aux Out 0 0 page 176Aux Flag A 1 70 If nonzero, aux in 0 activates Aux Out 0 0 page 176Aux Flag I 1 71 If nonzero, invalid access activates Aux Out 0 0 page 176Aux Flag T 1 72 If nonzero, tamper activates Axu Out 0 0 page 176Aux Flag P 1 73 If nonzero, power failure activates Aux Out 0 (F) 0 page 176Lock Time 2 74 Time of activation of lock output 5 page 176Shunt Time 2 76 Time door can remain open during unlock 10 page 176Network Baud Rate 1 78 Sets baud rate for RS-422/485 port 2 page 176Printer Baud Rate 1 79 Sets baud rate for RS-232 port 2 page 176HGU Address 1 80 0H - 0FEH, excluding 0AAH Note 2 page 177Facility Code 2 81 For Wiegand card output 50 page 177Reserved 1 83 Reserved. Do NOT alter.Operating Mode 1 84 0=Stand alone, 1=Master, 2=Remote Note 3 page 177Output Mode 1 85 0=Lock/Door, 1=Card Reader Emulation Note 4 page 178Beeper Flag 1 86 0=Disable beeper, nonzero=enable beeper 1 page 178



Notes1. The system reject threshold is set to 100 on all Model F units. For Model E, HandPunch units’ default is 125 and HandKey units’ default is 100.

2. All HandPunch units have a default address of 1; for all HandKey units, it is 0.

3. All Model F units have a default operating mode of Remote (2); many Model E units have a default operating mode of Stand-Alone (1).

4. HandKey CR units are in card reader emulation mode by default; all other units are in door control mode by default.

5. HandPunch units set the number of tries to 6 by default. HandKey units set it to 3.

ID length 1 87 Maximum ID length for keypad entry (1 - 11) 11 page 178Accounting Mode 1 88 System dependent 0 page 178Unlock Timezone 1 89 Time zone for auto-unlock. Use 61 for never 61 page 178Aux Timezone 1 90 Time zone for AUX activation. Use 61 for never 61 page 178Aux Duress Flag 1 91 If nonzero, duress activates AUX output page 179Duress Character 1 92 ‘0’ to ‘9’ [31H to 39H]. No duress if ‘*’ [2AH] ‘*’ page 179Number of tries 1 93 Number of tries before lockout Note 5 page 179reserved 2 94 Reserved. Do NOT alter.DLS On 4 96 Month, Day, Hour, Minute 0 page 179DLS Off 4 100 Month, Day, Hour, Minute 0 page 17924 Hour Time Flag 1 104 0=24 hour (military) time display, 1=12 hour 0 page 180Option Flags 1 105 Miscellaneous options 0 page 180Reserved 22 106 Reverved. Do NOT alter.Total Length 128

Table 14: Basic Setup Data Fields

Field

Byt

es

Offs

et Description

Def

ault

Valu

e

See

Page



Reserved Offset 0 Size 2These bytes are reserved; do NOT alter these byte fields.

Password Offset 2 Size 60The passwords to control access to command mode can be programmed through these fields. There are five passwords, each controlling access to one of the five command menus. The passwords are ASCII strings up to 10 characters long, and they must be terminated with a zero. The characters in the password must only be the digits 0 through 9, since these are the only codes which the HGU keypad can generate. In addition, they must have the ASCII code for the ‘#’ character (35 decimal, 23H) after the password but before the terminating zero, because the HGU uses the ‘#’ key as the input terminator. Each password is therefore allocated 12 bytes, and the five passwords together occupy 60 bytes.

Threshold Offset 62 Size 2This is the system global threshold for template acceptance. A verification succeeds when two templates are compared and the score is less than or equal to this value. Note that this value is used only if the override threshold in the user record is zero.

Aux Flag Clear Offset 64 Size 1If this flag is set to a non-zero value, a valid access will deactivate the Aux output following an alarm condition. If this flag is set to zero, the Aux output will pulse for the duration programmed by the Aux Timeout field. Note that in Model F units, there are multiple Aux outputs, and this field controls only Aux Out 0. It is recommended that the Extended Setup Data be used to program the auxiliary outputs on Model F units.

Aux Timeout Offset 65 Size 2This specifies the duration, in seconds, of the Aux output on a timed activation. This value is limited to values from 0 to 20,000 when input from the keypad, but may be programmed by the host to have any 16-bit value. Programming a value of 0 will cause the output to remain on indefinitely until it is forced off by the OutputControl command. This value is ignored when the OutputControl command is used to activate the output indefinitely. Note that on Model F units, the time base for all output times may be adjusted.

Print Flag Offset 67 Size 1On HandKey units only, if this flag is non-zero, valid accesses will be logged to the datalog buffer and printed. If this flag is zero, no datalogs will be generated for valid accesses. This flag is ignored on HandPunch models.



Status Flag Offset 68 Size 1If this flag is non-zero, the LCD will display system status on line 2. If this flag is zero, line 2 of the LCD will display the unit’s date and time.

Aux Alarm Flags Offset 69 Size 5There are five flags here which control if certain events activate the Aux0 output. The events are described in detail in Section 4.11 on page 64. The order of the five flags within this field is D (offset 69), A, I, T, P (offset 73). Note that on Model F units, there are additional events which can control the outputs, and there are additional outputs as well. It is recommended that Model F units be programmed through the Extended Setup Data.

Lock Time Offset 74 Size 2This specifies the duration, in seconds of the Lock output on a timed activation. This value is limited to values from 0 to 20,000 when input from the keypad, but may be programmed by the host to have any 16-bit value. Programming a value of 0 will cause the output to remain on indefinitely until it is forced off by the OutputControl command. This value is ignored when the OutputControl command is used to activate the output indefinitely. Note that on Model F units, the time base for all output times may be adjusted.

Shunt Time Offset 76 Size 2This specifies the duration, in seconds, that the door may remain open during an unlock period before a “Door Open Too Long” event is generated. This value is limited to values from 0 to 20,000 when input from the keypad, but may be programmed by the host to have any 16-bit value. Programming a value of 0 will allow the door to remain open forever without generating any alarm. Note that on Model F units, the time base for this may be adjusted.

Network Baud Rate Offset 78 Size 1This specifies the baud rate for the network communications port (RS-422/485). This is an index into the baud rate table. The baud rate tables are slightly different for Model E units and Model F units. Table 15 shows the baud rates for the various indices. Note that although 38400 baud is listed for Model E units, communication at this speed is usually unreliable.

Printer Baud Rate Offset 79 Size 1This specifies the baud rate for the RS-232 communications port. This is an index into the baud rate table shown in Table 15 on page 177. The same caveat regarding Model E units at 38400 baud applies to this port. This byte in the setup data is linked to the actual port itself, regardless of its function (on Model F units, it is possible to assign host communications to the RS-232 port).



HGU Address Offset 80 Size 1This is the network address of the unit. Any value is legal except 0xAA, which is reserved for broadcast messages, and 0xFF, which is reserved for the network master. The unit will not validate the contents of this field, so it is the host’s responsibility to avoid setting a slave to these addresses.

Facility Code Offset 81 Size 2The facility code is used to build card output data streams on many units. This value may be set by the command menu. See the section on card reader outputs for more information on how the facility code is utilized in the standard Wiegand card format.

Reserved Offset 83 Size 1This byte is reserved; do NOT alter this byte field.

Operating Mode Offset 84 Size 1This sets whether the unit acts as a stand-alone, a network slave, or a network master. Refer to the operating manuals for more information on these modes. Table 16 shows the allowable value of this field. Setting this field to other values will have unpredictable results.

Table 15: Baud Rates

Index Model E Model F

0 38400 288001 19200 192002 9600 96003 4800 48004 2400 24005 1200 12006 600 6007 300 300

Table 16: Operating Mode Values

Value Meaning

0 Stand-alone1 Network master2 Network remote (slave)



Output Mode Offset 85 Size 1This controls whether the unit’s outputs act as door controls or card reader outputs. On Model E units, the Lock and Aux/Bell outputs are controlled by this. On Model F units, the Lock and AuxOut0/Bell outputs are controlled by this. Setting this to 0 programs the outputs for Lock and Aux operation; setting this to 1 programs the outputs for card reader emulation. Writing other values into this field will have unpredictable results.

Beeper Flag Offset 86 Size 1Set this to 0 to disable the keypad beeper. Any other value enables the beeper.

ID Length Offset 87 Size 1This sets the maximum ID length for keypad entry. Legal values are 1 to 11. Values from 1 to 10 will cause ID entry to terminate when this many digits have been entered; the user will not have to press the Enter or # key. Setting this to 11 will require the # or Enter key to be hit to terminate the ID. Setting this field to any other values will result in unpredictable behavior when ID’s are entered from the keypad.

Accounting Mode Offset 88 Size 1This field consists of two flags which enable special modes. Bit 0 enables a mode which will ask the user to enter a department code after every valid punch. Bit 1 enables a mode which will show the user a menu of T&A activities and record the user’s selections in the datalog that accompanies the punch. On Model F units, the setting of bit 1 is ignored if an explicit punch menu is programmed with the function key compiler. Bits 2 through 7 are ignored.

Unlock Timezone Offset 89 Size 1Setting this to a time zone number will cause the unit to automatically unlock the door when the time zone becomes current. The door will remain unlocked as long as the time zone is current. Setting this field to 61 (the “never” time zone) will disable this feature.

Aux Timezone Offset 90 Size 1Setting this to a time zone number will cause the unit to automatically activate the Aux output (AuxOut0 on Model F units) when the time zone becomes current. See Unlock Timezone, above, for more comments. Note that on the Model F units, the Extended Setup Data allows the other outputs to be programmed as well.



Aux Duress Flag Offset 91 Size 1Setting this to any non-zero value will cause the Aux output (AuxOut0 on Model F units) to activate when the Duress event is generated. The DURESS event is generated whenever the user enters the duress character (set at offset 92, see next item below) at the keypad. See Section 4.11 on page 64 for more information on setting the auxiliary outputs to activate on events. See Section 7.5 on page 255 for information on the purpose of the duress character.

Duress Character Offset 92 Size 1This is the key which, when pressed, will generate the DURESS event. This must be the ASCII code for one of the digits 0 through 9. Other values will disable the duress feature. The command menu sets this field to ‘*’ (2AH) when duress is disabled. See Section 7.5 on page 255 for information on the purpose of the duress character.

Number of Tries Offset 93 Size 1This field sets the number of times an ID can be rejected and re-entered before it is locked out. This is described in detail in Section 4.6 on page 59.


Daylight Savings Time On Offset 96 Size 4This field consists of a four-byte field specifying the time and date of DLS on and another specifying the time and date of DLS off. Each field gives the month, date, hour, and minute. See Table 17 for the time and date byte locations.

Daylight Savings Time Off Offset 100 Size 4This field consists of a four-byte field specifying the time and date of DLS on and another specifying the time and date of DLS off. Each field gives the month, date, hour, and minute. See Table 17 for the time and date byte locations..

Table 17: Daylight Savings Byte Definition

Byte Definition

1 Month2 Day3 Hour4 Minute



24-Hour Time Flag Offset 104 Size 1Set this to zero for 24-hour time display (military time) or to any nonzero value for 12 hour time display.

Option Flags Offset 105 Size 1This byte has flags for options available on both E-Series and F-Series hand readers. Bit numbering is 0 for LSB of byte through 8 for MSB. Unassigned bits should remain unchanged whenever Basic Setup Data is updated from a host program.


Bits Usage

0 If set, this flag suppresses some actions that normally occur when the REX input pin is activated; specifically, activation of LOCK output is suppressed, as are associated status changes and datalogs. But this bit leaves unchanged the other effects of REX on status and datalogs. When the REX pin is activated, a shunt time period is started, during which no datalog will be generated for “door forced open.”

This option affects F-Series PROMs from Version 169 on, and E6 PROMs made on or after 21 APR 2003.

1-7 Unassigned – Do not change these bits.



BasicUserRecord

The ID field is stored as two packed BCD digits per byte. The first byte contains the first and second digits of the ID; the last byte contains the last two digits of the ID.

The template should not be altered by a host PC program.

The authority byte is split into two fields. The three least significant bits carry the user’s authority level (0-5) which is used as described elsewhere. The five most significant bits carry an override reject threshold. If these bits are set to zero, the system reject threshold is used to determine whether a score for this user is considered an accept or reject. If they are not zero, then the value of these bits multiplied by ten will be the threshold score for this user.

The time zone byte is an index into the time zone table. Time zone 0 means ALWAYS and time zone 61 means NEVER. Values other than these will cause the unit to behave unpredictably.

Table 18: Basic User Record Fields

Field Bytes Offset

ID 5 0Template 9 5Authority 1 14Timezone 1 15Total Length 16

Authority Byte

7 6 5 4 3 2 1 0

Override reject threshold Authority



BellSchedule

NotesA bell schedule table consists of 100 of these structures. The formats of the individual bytes are shown below. The hour and minute refer to the time at which the bell will be activated. See the HereIsBellSchedule command for more details on the use of the bell output.

Table 19: Bell Schedule Structure


First Byte 1 0 Minute in six LSBs, low bits of hour in 2 MSBs.

Second Byte 1 1High bits of hour in 3 LSBs, duration (seconds) in 5 MSBs

Third Byte 1 2 DOW flags. See page 184.Total Length 3

First Byte of Bell Schedule Entry

7 6 5 4 3 2 1 0

LSB of hour Minute

Second Byte of Bell Schedule Entry

7 6 5 4 3 2 1 0

Activation time in seconds MSB of hour



Datalog

NotesThe above table shows the fundamental structure of a datalog. The format numbers and contents of the Data1 and Data2 fields for each format are listed elsewhere. There are several variations on this fundamental structure. A complete list of format numbers and detailed diagrams of the different variations on this structure are given in Section 5.7 on page 199.

Table 20: Datalog Structure


Address 1 0 Address of unit which generated the datalogTime Stamp 6 1 Time stamp of datalog (same as HereIsTime)Format 1 7 Identifies type of datalogData1 5 8 Content varies with typeData2 5 13 Content varies with typeTotal Length 18



DOW Mask

A DOW mask specifies days of the week and holiday privileges in a HP-4000 Packed Time Interval and in a standard time zone. See the discussions on time zones and time intervals elsewhere for more information.

7 6 5 4 3 2 1 0Holiday Saturday Friday Thursday Wednesday Tuesday Monday Sunday



ExtendedSetupData

Notes1. The default ready string depends on the model and on the language. In English, the default for HandKey units is “READY” and for HandPunch units is “ENTER ID”.

2. Only Model F units have the Extended Setup Data and the features that go along with it.

Table 21: Extended Setup Data Fields

Field

Byt

es

Offs

et Description

Def

ault

Valu

e

See

Page

Ready String 14 0 LCD Line 1 prompt Note 1 page 186Serial Mode 1 14 0=host coms on RS-422, 1=RS-232 0 page 186Aux Output 0 Control Flags 2 15 Which events activate Aux Out 0 0 page 186Aux Output 1 Control Flags 2 17 Which events activate Aux Out 1 0 page 187Aux Output 1 Time 2 19 Timer for Aux Out 1 activation 5 page 187Aux Output 1 Clear 1 21 How Aux Out 1 is cleared 1 page 187Aux Output 1 Timezone 1 22 Time zone for Aux Out 1 activation 61 page 187Aux Output 2 Control Flags 2 23 Which events activate Aux Out 2 0 page 187Aux Output 2 Time 2 25 Timer for Aux Out 2 activation 5 page 187Aux Output 2 Clear 1 27 How Aux Out 2 is cleared 1 page 187Aux Output 2 Timezone 1 28 Time zone for Aux Out 2 activation 61 page 187HandPunch IO Datalog Flag 1 29 Nonzero=Log I/O (HP only) 1 page 187Time Scale 1 30 Time base for timers 0 page 188Aux Keypad Control 1 31 Controls auxiliary keypad 0 page 188Language Type 1 32 Language for menus and printer output 0 page 188Date Format 1 33 Date format for date displays 0 page 189Ring Count 1 34 Modem units answer after this many rings 0 page 189Ring Timeout 1 35 Timeout to reset ring counter if no ring 0 page 189Ring Delay 1 36 Pause before waiting for next ring 0 page 190Default FK Masks 2 37 Default Fkey masks at enroll time 0 page 190Card Digits 1 39 Number of right-most digits to retain 0 page 190Language Type 2 1 40 Second language for LCD2/TP2 0 page 190Rule Flags 1 41 Flags for special rules 0 page 191Rule Value 2 42 Expiration value for “IN” 0 page 191Grace Value 2 44 Minutes by which the TZ can be exceeded 0 page 191Reserved 82 46 Reserved. Do NOT alter. 0 n/aTotal Length 128



Ready String Offset 0 Size 14This field holds the ASCII string that will be displayed on the top line of the LCD when the Hand Reader is waiting for an ID to be entered. The string must be zero-terminated if it is less than 14 bytes long. If there is no zero termination, it is assumed that all 14 bytes should be displayed. Note that the LCD has 16 characters per line. Two characters are used for line 1 to display the indicator of whether the unit is in master or remote mode. The ready string is not automatically centered on the LCD; spaces must be used if it is desired to have the ready string centered.

Serial Mode Offset 14 Size 1This field controls whether the unit communicates with the host PC via the RS-232 port or the RS-422 port. Setting it to 0 will put host communications on the RS-422 port. Setting it to 1 puts host communications on the RS-232 port. Other values will result in undefined behavior. When set by the host PC, this setting takes effect the next time the unit is powered up. It takes effect immediately when set by the command menu. Note that not all models support RS-422 communication. On models which do not support RS-422 communication, this field is ignored.

Aux Output 0 Control Flags Offset 15 Size 2This field is a 16-bit value controlling which events will trigger the Auxiliary outputs. The exact format is shown in the following table. Bits 13 through 15 are unused and should be set to zero to preserve compatibility with future enhancements.

Table 22: Auxiliary Output Control Flags

Bit Mask Event

0 0001H TAMPER1 0002H TZVIOL2 0004H IDREF3 0008H DURESS4 0010H AUXIN15 0020H AUXIN26 0040H DOOR7 0080H TRYAGAIN8 0100H F1KEY9 0200H F2KEY10 0400H POWER11 0800H UNLOCK12 1000H AUXKPD13 – not used14 – not used15 – not used



Aux Output 1 Control Flags Offset 17 Size 2See “Aux Output 0 Control Flags” on page 186 for the data field definition.

Aux Output 1 Time Offset 19 Size 2This field control the time, in seconds, that the auxiliary outputs are activated. See the notes regarding Aux Out 0 in the basic setup data section (page 175) for further comments which also apply here.

Aux Output 1 Clear Offset 21 Size 1This field specifies how the auxiliary outputs are cleared. Note that these behave slightly differently than the clear flag for Aux Out 0. These are bitmaps, with bit 0 designated as clearing the output on a hand verification, and the other bits reserved for future enhancements. For Aux Out 0, any nonzero value will cause a hand verification to clear the output, and Aux Out 0 will not be able to participate in any new ways of clearing the outputs.

Aux Output 1 Timezone Offset 22 Size 1Setting this field to a time zone number will cause the unit to automatically activate the Aux output (AuxOut1 or AuxOut2) when the time zone becomes current.

Aux Output 2 Control Flags Offset 23 Size 2See “Aux Output 0 Control Flags” on page 186 for the data field definition.

Aux Output 2 Time Offset 25 Size 2See “Aux Output 1 Time” for the data field definition.

Aux Output 2 Clear Offset 27 Size 1See “Aux Output 1 Clear” for the data field definition.

Aux Output 2 Timezone Offset 28 Size 1See “Aux Output 1 Timezone” for the data field definition.

HandPunch IO Datalog Flag Offset 29 Size 1Setting this field to zero prevents HandPunch units from logging I/O events. Setting this field to 1 will cause I/O events to be logged. This field is ignored on HandKey units, which log all events all the time.



Time Scale Offset 30 Size 1This field sets the time scale of the timers which are set in the setup data areas. The timers affected are the lock output, the auxiliary outputs, and the door switch. This is the number of tenths of a second that the values in the timers represent. If this field is set to 10, then each unit of the timers is 1 second. If this field is set to 1, then each unit of the timers is 1/10 second. Note that setting this to zero will have the same effect as setting it to 10.

Auxiliary Keypad Control Offset 31 Size 1This is a bit field which controls the behavior of the Auxiliary Keypad. This is an optional keypad that can be used to enter ID numbers into the unit from a remote location. There is an application note available from Recognition Systems describing the use of the Auxiliary Keypad. Here, we only document the locations of the bits to program its behavior. Setting bit 0 will cause the lock output to be activated when the Auxiliary Keypad is used; when bit 0 is 0, using the auxiliary keypad merely generates an event which can be used to activate an auxiliary output. Setting bit 1 to 1 will cause time restrictions to be ignored for IDs that are entered from the auxiliary keypad; setting bit 1 to 0 will keep normal time restrictions in force.

Language Type Offset 32 Size 1This field controls the language which the unit uses for command menus and printer output. This field is initialized from the factory-programmed default setting upon a cold boot or a warm boot. The following languages are currently defined. Note that languages are often added by special arrangement with RSI and it is not guaranteed that all text strings have been translated in all languages.

Table 23: Languages

Value Language

0 English1 UK English2 Japanese3 French4 Italian5 Spanish6 German7 Russian8 Indonesian9 Portuguese10 Polish11 Dutch12 Slovak



Date Format Offset 33 Size 1This field controls the format of date display. The values shown in Table 24 are defined. Values other than those shown will cause the unit to use format number 0 (same as number 1). Note that in those formats which show the month as text, that the month will be shown in an abbreviation appropriate for the selected language.

Ring Count Offset 34 Size 1On units with a modem, this field specifies the number of rings after which the unit will answer an incoming phone call. A value of zero will cause the unit to answer immediately on the first ring. The default value is zero. Please note that in most phone systems, the caller hears a ring tone which is different than the actual ring signal at the other phone line. This difference may cause the unit to seem to answer one ring earlier or later than it seems it should. The unit counts rings as they show up on its phone line.This field, and the associated ring timeout and ring delay fields, was implemented on 7/24/00 in PROM revision 71. Only units with firmware compiled after this date will support this feature.

Ring Timeout Offset 35 Size 1On units with a modem and the ring count field set to a non-zero value, the unit will reset its ring counter back to zero if this much time elapses with no ring. In other words, if the ring count is not zero, each incoming ring must arrive within this amount of time, or the unit assumes the incoming call has stopped (or another phone has picked up the line). The unit will reset its ring counter and start looking for the first ring again. This time is specified in tenths of a second. The ring timeout timer starts after the ring delay time has elapsed (see below).

In the United States and most of Europe, the ring cadence is a total of six seconds long, so the sum of this value and the ring delay should be greater than six seconds.The default value for this field is zero, which will cause the unit to use a ten second timeout time. This should work well in most countries.

Table 24: Date Formats

Value Name Example

0 United States Default 05/29/981 United States Default 05/29/982 International Alpha Dash 29-MAY-983 International Numeric Dash 29-05-984 International Numeric Slash 29/05/985 United States Numeric Dash 05-29-986 Year 2000 Compliant 29MAY2000



Ring Delay Offset 36 Size 1On units with a modem and a ring count set to a non-zero value, this field specifies the amount of time the unit will wait after detecting the start of a ring before starting to wait for the next ring. This value must be longer than the time the ring signal is present to prevent the unit from counting the same ring more than once. This time is specified in tenths of a second. The default value for this field is zero, which will cause the unit to use a three second delay time.

In the United Staes and most of Europe, the ring cadence is two seconds on and four seconds off, so a ring delay of at least two seconds should be used or the unit will count more than one ring for each actual ring. In the United Kingdom, the ring cadence is 0.4 seconds on, 0.2 seconds off, 0.4 seconds on, then a gap of 2 seconds. The ring delay value should be lowered to 2 seconds in countries with this type of ring cadence.

Default FKey Masks Offset 37 Size 2This field indicates which function keys are available to all newly enrolled users. Using the default value of 0 (zero) allows all newly enrolled users to use all function keys. However, if desired, this mask allows you to limit new enrollees to have immediate access only to specific function keys.

Card Digits Offset 39 Size 1If zero, then no action. If non-zero, this field gives the number of right most digits to be retained in a User ID when input is from a card.

Language Type 2 Offset 40 Size 1This field gives the second language to use on a top panel equipped with a graphic LCD.



Rule Flags Offset 41 Size 1If this byte is zero, then it causes no special behavior. Several of its bits are assigned special meanings, and if set, have the following effects:

Rule Value Offset 42 Size 2If bit 0 of Rule Flags above is set, gives expiration value for “IN” part of rule; otherwise leave 0.

Grace Value Offset 44 Size 2If using packed time zones for a user (HP 4K only) , number of minutes by which can exceed either end of TZ interval.


Bit Effect if non-zero

4 Enforce TZ for IN only (see below); use Grace Value.

3 Bracket MagStripe output with AUX2 on/off. Some recipients of MagStripe data require a third output line to signal the beginning and end of a MagStripe transmission. AUX2 may be used to provide such a signal if this bit is set.

2 Enables Level 5 menu to change Bit 1 below.

1 Requires FKey press before ID entry.

0 If HP-4000, prevents IN punch if last was IN; prevents OUT punch if last was OUT; here Function Key Program TACODE of odd and less than 50 counts as IN, even and less than 50 as OUT; enables Level 5 menu to set value of Rule Value (see below).

5, 6, 7 Unassigned – Do not change these bits.



ExtendedUserData

NotesThe PTI field is three Packed Time Interval entities. For details on the Packed Time Interval, see page 196.

The FKMASKS field is a bit field specifying whether this user has access to each of the ten function keys. Bit 0 controls access to

Name is the name that is displayed when the user punches. This will appear on line 2 of the LCD while the “Place Hand” prompt is displayed. This field must be a zero-terminated ASCII string. If it is not zero terminated, all 16 characters will be used. See Table 47 on page 249 for the LCD character set.

Data is data which can be displayed by the function key menu system. See the Function Key Compiler Manual for more information on this.

Amnesty is a count of amnesty punches. Amnesty punches allow a supervisor to grant a limited number of overrides past the normal time restrictions.

Table 25: Extended User Data

Field Bytes Offset

PTI 12 0FKMASKS 2 12Name 16 14UDF 24 30Amnesty 1 54RESERVED 6 55Total Length 61



ExtendedUserRecord

See the sections on the Basic User Record (BUR) and Extended User Data (XUD) for more details. An Extended User Record is simply a BUR followed by XUD.The Extended UserRecord has the structure shown in the following table when it is expanded to show all its members.

Table 26: Extended User Record, Gross View

Field Bytes Offset

BUR 16 0XUD 61 16Total Length 77

Table 27: Extended User Record, Detailed View


ID 5 0 User IDTemplate 9 5 Hand geometry template. Do not alter.Authority 1 14 Authority and reject override thresholdTimezone 1 15 Time zonePTI 12 16 Packed time intervalsFKMASKS 2 28 Function key use masksName 16 30 User name for displayData 24 46 Custom user dataAmnesty 1 70 Amnesty punch countRESERVED 6 71 Reserved. Do not alter.Total 77



HolidayTable

The holiday table defines which days are holidays. This is explained in Section 4.5.2 on page 58. Each month is allocated a 4-byte field, and each day of the month is assigned to a bit in this field. The first day of each month corresponds to bit 0 of the first byte in each month’s four-byte field. Bits past the number of days in a month are ignored.

As an example, the following entries from the table show January 1, February 28, and March 16 as holidays.

Table 28: Holiday Table Data Structure

Field Bytes Offset

January 4 0February 4 4March 4 8April 4 12May 4 16June 4 20July 4 24August 4 28September 4 32October 4 36November 4 40December 4 44Total Length 48

Table 29: Holiday Table Entries

Date Data Structure

January 1 01H 00H 00H 00H

February 28 00H 00H 00H 08H

March 16 00H 80H 00H 00H



TimeZone

A time zone is one of the ways access is restricted based on time. How the time zone table works is explained in Section 4.5.1 on page 58. Each time zone contains four time intervals as defined by the start and stop fields. Each start and stop field specifies a clock time in 6 minute (1/10 hour) increments from midnight. For example, a start time of 216 represents a time of 21.6 hours, or 21:36, or 9:36 PM.

If the start time is greater than or equal to the stop time, the time zone will never be current.

The DOW mask specifies the days of the week on which the time interval is valid. See the section on DOW masks on page 184.

The complete global time zone table contains 60 time zone entries with the format shown here.

Table 30: Time Zone Table Entry Structure

Field Bytes Offset

Start 1 1 0Start 2 1 1Start 3 1 2Start 4 1 3Stop 1 1 4Stop 2 1 5Stop 3 1 6Stop 4 1 7DOW 1 1 8DOW 2 1 9DOW 3 1 10DOW 4 1 11Total Length 12



PackedTimeInterval

A Packed Time Interval is used by HP-4000 units as an alternative to time zones. Packed Time Intervals are arranged like this:

Figure 3: Example of Packed Time Intervals

The DOW field indicates day-of-the-week information. Bit 0 is Sunday, Bit 1 is Monday, etc., and Bit 6 is Saturday. Bit 7 controls holiday access.

Some example code for packing and unpacking time intervals is given in Figure 9 on page 237. It is recommended that programmers not fluent with bit manipulation techniques use the packing and unpacking functions provided by RSI, for example, in the DLL.

Note that in Figure 3 the bytes are given in the opposite order from that in which they occur in an actual message. For example, in a message, one of the three packed time intervals might be:

10 32 54 BE

This example gives the data as hexadecimal. The last byte, BE is the DOW mask and should be handled separately. To understand the three bytes of the packed time interval, first reverse them, giving:

54 32 10

“Packed” here means we cram two 12-bit values into three bytes. When thus reversed, the first three nibbles, 543, are one number, and the last three nibbles, 210, are another

Table 31: HP-4000 Packed Time Interval Structure

Field Bytes Offset

BE 3 0DOW 1 3Total Length 4



number. The first number (after reversal) is the END time of the time interval, and the second number (after reversal) is the BEGINNING time of the time interval.

The numbers represent minutes since midnight. Thus the beginning time is 8:48, and the ending time is 22:27.

If beginning and ending numbers are both zero, it means the given packed time interval is not in use, though one or both of the others may be in use. For a particular user, if at least one packed time interval is in use, then the packed time intervals in the extended user record are what is used, and the time zone to which that user is assigned is disregarded. If packed time intervals are used, then the user can gain access if at least one interval includes the current time-of-day and its DOW mask has a bit set for the current day-of-the-week. If none of the three packed time are in use, then the time zone is used in the normal manner.



Blank page.



5.7 Datalog FormatsOn page 183 the data structure for a transactions datalog was shown. In this section we list all the datalog formats and show the information that is entered into the Data1 and Data2 fields for each format. The formats which have special variations on the basic datalog data structure will be described in detail.

5.7.1 TA CodesSome datalog formats split Data2 into two fields. The first field is one byte long and called the “TA Code” (for Time & Attendance code), or just TA. The second field is the remaining four bytes of Data2, and is called “DataB.” Its content varies with the specific format and TA code of the transaction.

The datalog formats which have Data2 split this way are the Supervisor Override format (15) and the Identity Verified format (7). Format 7 uses this form only if a function key menu with Collect objects has been run. The data from the collect objects goes into the DataB portion, and the TA code supplied in the menu definition goes into the TA field.

The Supervisor Override format is described in Section 5.7.4 on page 202.



5.7.2 Time & Attendance ID Verified DatalogsTime and Attendance units may have a slightly different format for the ID verified datalog (type 7). Each datalog has the format shown in Table 32. Note that there is a discrepancy in the way HandKey units report the TA code when in Time & Attendance Mode, as described in the note to the table.

Note: HandKey units on both Model E and Model F, when in Time & Attendance Mode, will have a one-digit TA code with no leading zero, and the department code can be up to nine digits long.

Table 32: Time and Attendance ID Verified Datalog


Address 1 0 Address of unit which generated the datalogTime Stamp 6 1 Time stamp of datalog (same as HereIsTime)Format 1 7 Always 7 (ID Verified)Data1 5 8 Employee ID

Data2 5 13

One of the following (see note)

TA DataB DescriptionFF FFFFFFFF no data expected

00 00000000 no data entered

01 Department in

02 Department back 1

03 Department out

04 Department department


06 Department job




5.7.3 Function Key Data Collection DatalogsOn those models which support data collection through the function key menu system, the data collected goes into the transactions buffer as a series of datalog records with the format set to the ID Verified format number (7). The format of this datalog is shown in Table 33. The datalog record that corresponds to the actual identity verification comes first, then the datalog records corresponding to the collect objects follow. These datalog records have the same format as the ID Verified datalog, except that the TA code field is programmable by the author of the function key menu.

Table 33: Function Key Menu Data Collection Datalog


Address 1 0 Address of unit which generated the datalogTime Stamp 6 1 Time stamp of datalog (same as HereIsTime)Format 1 7 Always 7 (ID Verified)Data1 5 8 Employee IDData2 5 13 TA code and DataB depend on the menu

Total Length 18



5.7.4 Supervisor OverrideTime and Attendance units may emit datalogs for the Supervisor Override operation, format number 15. This operation is initiated from the keypad in menu subsystem 3. Datalogs for Supervisor Override have a more complicated structure than the other datalog types. Supervisor Override datalogs consist of two or three transaction records, depending on the type of override.

There are two types of override, called “Punch” and “Bulk”. (Bulk includes bulk hours and bulk dollars.) Punch overrides can be distinguished from Bulk overrides by the TA code in the first datalog. Punch overrides have TA code FFH in their first datalog record and contain a total of two datalog records per transaction. Bulk overrides have TA code 15H in their first datalog record and contain a total of three datalog records per transaction.

When a supervisor is entering a Bulk override, the HGU prompts for a category, which is included in the DataB field of the first datalog record. Punch overrides have no category.

Table 34, Table 35 on page 203 and Table 36 on page 204 show the structure of each of the Supervisor Override datalogs.

Table 34: Supervisor Override Datalog 1


Address 1 0 Address of unit which generated the datalogTime stamp 6 1 Time stamp of datalog (same as HereIsTime)Format 1 7 Always 15 for Supervisor OverrideData1 5 8 Supervisor ID

Data2 5 13

Total Length 18

One of the following

TA DataB DescriptionFF FFFFFFFF Punch

15 category Bulk





Address 1 0 Address of unit which generated the datalogTime Stamp 6 1 Time stamp of datalog (same as HereIsTime)Format 1 7 Always 15 for Supervisor OverrideData1 5 8 Employee ID (entered at keypad)

Data2 5 13Notes:The department is requested if the department flag is set, otherwise, it is zero.TA code 0 means data was expected but not entered and the HGU timed out.For TA codes 08 and 09, the p is either a 0AH or a 0BH, which indicates a + or -, respectively.For TA code 08, the h’s indicate hours and the m’s indicate minutes.For TA code 09, the $ indicate dollars and the ¢ indicates cents.

Total Length 18




01 Department in


03 Department out

04 Department department


06 Department job


08 phhhhFmm bulk hours

09 p$$$$F¢¢ bulk dollars





Address 1 0 Address of unit which generated the datalogTime Stamp 6 1 Time stamp of datalog (same as HereIsTime)Format 1 7 Always 15 for Supervisor OverrideData1 5 8 Always FFFFFFFFFF

Data2 5 13




04 Department entered at keypad



5.7.5 Datalog Format GenerationThis section lists each datalog format and describes what causes it to be generated. Note that commands from a host system to change setup data, such as reader address or baud rate, do not generate datalogs. Only changes to setup data made from a command menu generate a datalog. HandPunch units have many datalogs excluded by default, since their emphasis is on collecting punch data rather than on maintaining a detailed audit trail.

The following table is a list of all datalog formats which may be generated. Note that not all models generate all datalogs. Each datalog format is explained in the sections below.

Table 37: Datalog Formats

Format Name Data1 Data2 See page0 Transaction Buffer Empty 0 0 page 2061 User Enrolled enrolled ID page 20623 Identity Unknown ID page 2074 Exit Granted ID page 20756 Access Denied ID page 2077 Identity Verified ID see text page 2078 User Removed operator ID removed ID page 2079 Command Mode Entered ID page 20710 Command Mode Exited ID page 20811 System Re-calibrated ID page 2081213 Door Forced Open page 20814 Tamper Activated page 20815 Supervisor Override See Section 5.7.4 page 2081617 Auxiliary Input ON page 20818 Request To Exit Activated page 20819 Auxiliary Output ON page 20920 Baud Rate Changed ID page 20921 Messages Read ID page 20922 Unit Address Changed ID page 20923 Site Code Changed ID page 21024 Time and Date Set ID page 21025 Lock Setup page 21026 Passwords Changed ID page 21027 Reject Threshold Set New threshold page 21028 Aux Out Setup Changed ID page 21129 Printer Setup Changed ID page 211



Datalog Format 0 Transaction Buffer EmptyThis format is returned when the host requests a datalog but the datalog buffer is empty. The entire contents of all fields will contain zeros.

Datalog Format 1 User EnrolledThis indicates that a user was enrolled normally from the command menu. Special enrollments (“no-hand enrolls”) generate format 49. Remote enrollments initiated by a host PC using the Enroll command do not generate any datalog. The data1 field contains the ID of the user that was just enrolled.

Datalog Format 2 NOT USED

30 Extended Datalogs See Table 38 page 21131 Door Open Too Long page 21132 Users Listed ID page 21233 User Database Saved page 21234 User Database Restored page 21235 Amnesty Punch Granted grantee ID grantor ID page 21236 Reject Override Changed changed ID page 21237 Authority Level Changed changed ID page 21238 Operating Mode Changed ID page 21239 Output Mode Changed ID page 21340 ID Length Changed ID page 21341 User Database Cleared ID page 21342 Access Refused, Time Restriction refused ID page 21343 Time Zone Data Changed ID page 21344 User Time Zone Changed changed ID See text page 21345 Duress Alarm ID page 21346 Lock Output ON page 21447 Lock Output OFF page 21448 Aux Output OFF page 21449 Special Enrollment enrolled ID enroller ID page 21450 Aux Unlock via Wiegand Keypad page 21451 Global Restrictions Changed ID See text page 21452 ID Not In Memory ID page 21553 ID In Memory ID page 215

Table 37: Datalog Formats (Continued)

Format Name Data1 Data2 See page



Datalog Format 3 Identity UnknownThis indicates that the hand presented to the unit did not match the template enrolled for the given ID to within the score threshold. This is the same as the TRY_AGAIN event described Section 4.6.2 on page 59. If the ID is locked out, format 6 will be generated instead. The data1 field contains the ID that was entered.

Datalog Format 4 Exit GrantedThe HGU generates this datalog only when request is granted via a request from the special Request To Exit Keypad. Units without this option will not generate this datalog. The data1 field contains the ID of the user requesting the exit. The data2 field may contain accounting code information if the accounting mode is enabled. Note that the Request To Exit keypad is not the same as the Auxiliary Keypad.


Datalog Format 6 Access DeniedThis indicates that a user’s ID was locked out. This is the same as the same as the ID_REFUSED event described in Section 4.6.2 on page 59. The data1 field will contain the ID which is locked out.

Datalog Format 7 Identity VerifiedThis datalog is the one generated by a successful hand verification. The data1 field will contain the ID which was verified. The data2 field may contain additional accounting code information or collected menu data, as described previously in this section.

Datalog Format 8 User RemovedThis indicates a user was removed from the HGU database using the keypad command menus. The data1 field contains the ID of the user which executed the command to perform the removal. The data2 field contains the ID which was removed. User database modifications which are initiated by a host computer do not generate datalogs.

Datalog Format 9 Command Mode EnteredThis indicates that a command menu was entered. The data1 field contains the ID of the user which entered the command menu. Activity which occurs while in command mode may generate more datalogs. When command mode is exited, datalog format 10 is generated.



Datalog Format 10 Command Mode ExitedThis is generated when command mode is exited and the unit returns to normal operation. The data1 field contains the ID of the user which was in command mode.

Datalog Format 11 System RecalibratedIndicates a re-calibration was initiated from the command menu. The data1 field contains the ID of the user which initiated this command. The host command Calibrate does not cause any datalog to be generated.


Datalog Format 13 Door Forced OpenThis indicates the door switch input made a transition from its low state to its high state while the door was not shunted and not unlocked. This is one of the conditions which can generate the DOOR event described in Section 4.11 on page 64. No data accompanies this format.

Datalog Format 14 Tamper ActivatedThis indicates the tamper switch changed to the tamper condition. On Model E units, this means the tamper switch plunger was extended. On Model F units, this is initiated by a tilt switch. This is the same as the TAMPER event described in Section 4.11 on page 64. No data accompanies this format.

Datalog Format 15 Supervisor OverrideThis is generated by data collected from the Supervisor Override menu, described above in Section 5.7.4 on page 202.


Datalog Format 17 Auxiliary Input ONThis is generated when any auxiliary input makes a transition from low to high. When AuxIn1 (the auxiliary input on models which have only one auxiliary input) rises, both data1 and data2 will contain all FF. When AuxIn2 rises, data1 will contain all FF and data 2 will have TA code 1 with dataB all zeros.

Datalog Format 18 Request To Exit ActivatedThis datalog occurs when the Request To Exit input makes a high-to-low transition. This occurs whether the unit is configured as a door controller or for card reader output. No data accompanies this format.



Datalog Format 19 Auxiliary Output ONThis datalog is generated whenever an auxiliary output is turned on, meaning the unit brings the output low. The data that accompanies this datalog depends on the reason for the output turning on. Host-initiated activations of the auxiliary outputs using the OutputControl command generate datalogs which have both data1 and data2 set to all FF. When the auxiliary output is activated because its activation time zone (programmed in the setup data) becomes current, data1 and data2 are set to all FF. When AuxOut1 and AuxOut2 are activated because of an event listed in Table 22 on page 186, the data2 field contains the number of the output which was activated in its TA field, and the bit number listed in Table 22 on page 186 in its dataB field. The data1 field always contains all FF.

To preserve backwards compatibility with existing application software, AuxOut0 activations always generate datalogs with both data1 and data2 containing all FF, no matter why the output was activated.

The off transition (output going high) will generate a datalog format 48 unless the activation is a timed activation.

Datalog Format 20 Baud Rate ChangedThis indicates that the baud rate for one of the serial channels was changed. For units with an Ethernet adaptor installed, this datalog will also be generated when the unit’s IP address is changed. The data1 field will contain the ID of the user which made the change. Note that the baud rate menu was visited, not necessarily that an actual change was made. Changes to setup data caused by commands from a host system do not generate any datalogs.

Datalog Format 21 Messages Read (HP-4000 only)This datalog is issued when all messages for a user have been displayed. The data1 field contains the ID of the user. This is exclusively a HandPunch 4000 feature.

Datalog Format 22 Unit Address ChangedThis indicates a unit’s RS-422 network address was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.



Datalog Format 23 Site Code ChangedThis indicates a unit’s site code (also called “facility code”) was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

Not all units have this datalog format implemented.

Datalog Format 24 Time and Date SetThis indicates a unit’s clock was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to the unit’s clock caused by commands from a host system do not generate any datalogs.

Datalog Format 25 Lock SetupThis indicates a unit’s lock setup was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

Datalog Format 26 Passwords ChangedThis indicates a unit’s command menu passwords were changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

Datalog Format 27 Reject Threshold SetThis indicates a unit’s system global reject threshold or number of tries was changed from the keypad command menu. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

This format is unusual in that the data1 field does not contain the ID of the user which made the change, but rather contains the new reject threshold in binary format. The first byte of data1 contains the low-order byte of the new threshold, and the second bytes of data1 contains the high-order byte. The contents of remaining three bytes of data1 is undefined, but most on models they will contain the fields form the basic setup data area which follow the reject threshold.



Datalog Format 28 Aux Out Setup ChangedThis indicates a unit’s auxiliary output setup was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

Datalog Format 29 Printer Setup ChangedThis indicates a unit’s printer setup was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

Datalog Format 30 Extended DatalogsThis format number is used for a variety of functions, depending on the TA code and DataB field. Table 38 on page 211 lists the TA codes and their meanings. Note that Model E units do not generate this datalog format. For more information on the reset datalog, refer to Section 7.3.4 on page 251.

Datalog Format 31 Door Open Too LongThis indicates the door was left open too long after being unlocked. This is one of the conditions which can generate the DOOR event described in Section 4.11 on page 64. No data accompanies this format.

Table 38: Extended datalog codes

TA DataB Data1 Meaning

1 1 id Language changed by command menu1 2 id Date format changed by command menu2 1 FF Line power lost, running on battery2 2 FF Line power restored3 1 FF Clock’s hour incremented due to daylight savings

time adjustment3 2 FF Clock’s hour decremented due to daylight savings

time adjustment4 1 FF Wrong-length FKey program received and ignored99 varies FF Unit was reset. DataB contains information on the

cause of the reset



Datalog Format 32 Users ListedThis is generated when the “List Users” command menu begins listing the users. This occurs whether the users were listed to the printer or viewed on the LCD. The data1 field contains the ID of the user which listed the users.

Datalog Format 33 User Database SavedThis datalog is no longer in use. Very old Hand Readers with floppy drives would emit this datalog when the database was saved to disk.

Datalog Format 34 User Database RestoredThis datalog is no longer in use. Very old Hand Readers with floppy drives would emit this datalog when the database was restored from disk.

Datalog Format 35 Amnesty Punch Granted (HandPunch 4000 only)This indicates amnesty punches were granted to a user from the command menu. This is exclusively a HP4000 feature. Data2 is the ID of the grantor, data1 is the ID of the grantee. The number of amnesty punches granted is not recorded. Changes made to user records by commands from a host computer do not generate datalogs.

Datalog Format 36 Reject Override ChangedThis indicates the reject override threshold for a user was changed from the command menu. Data1 contains the ID of the user which was changed. This indicates only that the menu was visited, not that the value necessarily changed. The user which did the change is not recorded in this format but can be inferred from the most recent datalog showing command mode was entered. Changes made to user records by commands from a host computer do not generate datalogs.

Datalog Format 37 Authority Level ChangedThis indicates the authority level for a user was changed from the command menu. Data1 contains the ID of the user which was changed. This indicates only that the menu was visited, not that the value necessarily changed. The user which did the change is not recorded in this format but can be inferred from the most recent datalog showing command mode was entered. Changes made to user records by commands from a host computer do not generate datalogs.

Datalog Format 38 Operating Mode ChangedThis indicates a unit’s operating mode (Master/Remote/Standalone) was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. Unlike many setup-related datalogs, this indicates that a change did in fact occur, rather than merely showing the menu was visited. Changes to setup data caused by commands from a host system do not generate any datalogs.



Datalog Format 39 Output Mode ChangedThis indicates a unit’s output mode (Lock and Aux or Card Reader Emulation) was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

Datalog Format 40 ID Length ChangedThis indicates a unit’s ID length was changed from the keypad command menu. The data1 field contains the ID of the user which made the change. This indicates only that the menu was visited, not that a change necessarily occurred. Changes to setup data caused by commands from a host system do not generate any datalogs.

Datalog Format 41 User Database ClearedThis indicates a unit’s user database was cleared from the keypad command menu. The data1 field contains the ID of the user which erased the database. Changes to the user database made by commands from a host computer do not generate datalogs.

Datalog Format 42 Access Refused – Time RestrictionThis indicates a user attempted to gain access or punch outside the authorized time. This is equivalent to the TZVIOL event described in Section 4.11 on page 64. The data1 field contains the ID of the user attempting to gain access.

Datalog Format 43 Time Zone Data ChangedThis indicates the time zone table or holiday table was edited or cleared from the command menu. The data1 field contains the ID of the user which made the edits. Changes to the time zone table caused by commands from a host computer do not generate datalogs.

Datalog Format 44 User Time Zone ChangedThis indicates that a user’s time zone was changed from the keypad command menu. The data1 field contains the ID of the user which was changed. Some models will put the ID of the user which made the change in the data2 field. Changes to user records made by commands from a host computer do not generate datalogs.

Datalog Format 45 Duress AlarmThis indicates the duress key was pressed, if the unit has the duress feature enabled. This is the same as the DURESS event described in Section 4.11 on page 64. The ID of the user which pressed the duress key is recorded in the data1 field. See Section 7.5 on page 255 for information on the purpose of the duress character.



Datalog Format 46 Lock Output ONThis indicates that the lock output was activated (brought low) by either the host command OutputControl or by the auto-unlock timezone becoming current. Changes in the state of the lock output that are caused by hand verifications do not generate this datalog. No data accompanies this datalog.

Datalog Format 47 Lock Output OFFThis indicates the lock output was turned off (brought high) by either the host command OutputControl or by the auto-unlock timezone becoming non-current. Changes in the state of the lock output that are caused by hand verifications do not generate this datalog. No data accompanies this datalog.

Datalog Format 48 Aux Output OFFThis indicates that one of the auxiliary outputs was turned off (brought high) by either the host command OutputControl or by the activation timezone becoming non-current. Changes in the state of the auxiliary outputs that are caused by hand verifications (via the Auxiliary Keypad option) do not generate this datalog. Unlike the datalog format which indicates auxiliary output activation (19), no data accompanies this datalog.

Datalog Format 49 Special EnrollmentThis indicates a special enrollment was completed. The data1 field contains the ID of the user that was enrolled. The data2 field contains the ID of the user who entered the command menu to perform the special enrollment. Changes to the user database which are in response to commands from a host computer system do not generate datalogs.

Datalog Format 50 Aux Unlock via Wiegand KeypadThis indicates that an attempt was made to use the Auxiliary Keypad, also called the Wiegand Keypad, to unlock the door. Exactly how this is handled varies depending on the model. It does not necessarily indicate any output was activated or that the AUXKPD event actually occurred. It indicates that a valid ID was received from the Auxiliary Keypad, and whatever actions the operator has programmed will be taken. See Section 7.4 on page 254 and refer to application note on the Auxiliary Keypad for more information.

Datalog Format 51 Global Restrictions ChangedThis indicates the global user time restrictions flag was changed from the keypad command menu. The data1 field contains the ID number of the user who made the change. The data2 field contains all zeros except the last byte, which will contain 0 if restrictions were turned off and 1 if restrictions were turned on.



Datalog Format 52 ID Not In MemoryThis reports that the indicated ID has been typed in but is not enrolled in the reader.

This code is reserved, beginning with F-Series Version 190, but is not actually enabled on most models at the present time. At some future date it may be made more widely available, although there is no plan to do this at any time soon.

Datalog Format 53 ID In MemoryThis reports that the indicated ID has been typed in and is indeed enrolled, although the attempt to use it may yet fail for some other reason, such as time zone restrictions or failure to supply a correct password.

This code is reserved, beginning with F-Series Version 190, but is not actually enabled on most models at the present time. At some future date it may be made more widely available, although there is no plan to do this at any time soon.



Blank page.



6.0 Examples of Standard Operation

6.1 IntroductionThis section shows sequences of commands and responses to accomplish common tasks. In addition, some helpful programming tips are given to guide the programmer. This section relies heavily on information provided in previous section, and it is recommended that the reader have a good understanding of that material before beginning to read this section.

Some examples in this section are given in the form of pseudo-code, a shorthand programming-style description of certain operations. The notation for this code is borrowed heavily from the C programming language. Since not all readers may be familiar with C, the symbols used in the pseudo-code examples in this manual are given in Table 39.

Table 39: Pseudo-code Symbols Used in this Section

Symbol Operation

// Comment. All text following this symbol until the end of the line is a comment.

/* ... */ Comment. All text between these symbols is a comment. Statement block delimiters, like BEGIN and END in Pascal. Also

start and end of a function body.= Assignment== Comparison for equality& Bitwise AND| Bitwise OR~ Bitwise NOT<< Shift left. The expression x << 5 means the variable x is shifted left

5 bits.>> Shift right. Similar to <<.AND, OR, NOT

Logical AND, OR, NOT. Used in conditional expressions to test for truth values. Not the same as bitwise operations.

int f (void)void g (int)

Function f accepts no arguments and returns an int. Function g takes a single argument of type int and returns nothing.

[ ] Array indexing. All arrays are zero-offset.int, long, unsigned, BYTE

int is 16 bits, signed, and also indicates truth values, where nonzero means true and zero means false. BYTE is an unsigned 8-bit type, and long is 32 bits.



6.2 Checking StatusTo check status, send the SendStatusCRC or SendStatusChecksum commands. Since this operation is usually the first thing a new development project tries to do, it is useful to see the exact data bytes that should be send to the unit to make it respond. If difficulty is experienced during the early phase of custom software development, it may be helpful to hard-code the following strings into a program and see that the unit responds. Note that the FF’s before and after the data are for RS-485 line driver turn-around time and may be omitted.

The response from the unit to these commands will, of course, vary with the actual status of the unit, but should have the following general format.

6.3 Unit SetupA common set of questions confronting new systems is how to setup a new unit, what kind of information is necessary to configure a unit, and how this information gets into the unit. Much of this is answered in the operating manuals for the various products, and it is not the intent of this section to replace a thorough reading and understanding of those manuals. However, setting up a unit using host PC commands is a little different than setting it up using the command menus. Data is arranged differently and grouped in ways not evident from the menus. Also, there are many configuration parameters available through host commands which simply cannot be set from the menus, especially on HandPunch units.

This is not meant to be a comprehensive list of all features which could conceivably be configured, but rather a guide to the more common configurations and what to bear in mind when installing units.

Table 40: Detailed Example of SendStatus Command

FCS Mode Address Bytes

CRC 0 FF 0A 00 44 00 08 C1 FFCRC 1 FF 0A 01 44 00 38 F6 FFChecksum 0 FF 0A 00 3B 00 C5 FFChecksum 1 FF 0A 01 3B 00 C4 FF

Table 41: Example of Response to SendStatus Command

FCS Mode Bytes

CRC FF 0A FF 30 03 00 82 1E 88 4D FFChecksum FF 0A FF 30 03 00 82 1E 2E FF



6.3.1 Setup DataA large number of features are controlled by the setup data. The exact fields and their locations in the setup data areas were described beginning on page 173. Here, we will present some of the most common features that are used and which values in the setup area go with them.

First, it is important to understand the way the setup data is held in the units and what the right way to change fields in it is. This is described in the reference section on the particular commands that read and write the setup data, but it is worth explaining again here.

There are two blocks of setup data. The basic setup data is available on all units; the extended setup data is available only on Model F units. Each of these blocks of setup data is 128 bytes long and is accessed as a unit. This means that all 128 bytes are written or read at the same time. To modify a single field, the entire 128 bytes must be read from the unit, then the PC modifies the fields it needs to modify, then all 128 bytes are written back to the unit.

The setup data is of course held in the unit’s static RAM so that its values can be easily accessed by the CPU. However, a copy is kept in EEPROM so that its values may be retained through a board power failure. As mentioned previously, it is necessary on some models, after sending setup data to the unit, to send it an additional command to transfer the received setup data to EEPROM. Without this command, the updated setup data will be in static RAM and will take effect, but it will be lost the next time the unit loses power.

Since the setup data can be retrieved from the unit by a host command, it is not necessary that a host system keep a copy of it. However, it may be desirable in planning system backup strategy to make the host system the owner of the true copy of the setup data. In this case, it will not be necessary to perform the read/modify/write cycle described above every time a setup data field changes. The host system simply accesses the true copy (stored in a disk file), modifies it, and sends the updated setup data to the unit.

Now we will explain some of the setup data items most commonly changed.

6.3.1.1 Command Menu PasswordsAccess to command menus is restricted by passwords. These passwords also select which menu will be accessed. It is an important part of any installation to manage the command menu passwords properly. The default passwords are simply “1,” “2,” etc. and are rather obvious. These defaults were chosen to be simple and easy to remember.

It is strongly recommended that all units have their passwords set to something which provides real security before going into a working installation.



Note that the password strings must be numeric and must be terminated by a “#” (ASCII 35). The HGU keypad can only enter numeric data, and the # symbol is necessary for keypad entry termination.

6.3.1.2 CommunicationsThe baud rate and reader address are set in the setup data. In addition, on Model F units, the communications port for host communications can be set in the extended setup data. The baud rate and address take effect immediately on most models. Changing the host communications port on some firmware versions may not take effect until the unit is power cycled.

6.3.1.3 Door ControlsFor units which control doors, there are several parameters which may need to be adjusted. First, of course, is the output mode, which must be set to lock mode rather than card reader emulation mode. This is because the door control outputs are shared with the card reader outputs since these two options are mutually exclusive in the vast majority of systems.

Next, the lock time and door time (also called “shunt time”) can be set. The lock time is the amount of time the lock output remains active after a hand verification. The door time is the amount of time a door can remain open after a verification before an alarm is issued.

If the unit is controlling a public door, such as the front door to a business, it may be desirable to have the unit automatically open an relock the door at the beginning and end of the business day. In this case, a time zone defining the business hours should be created and loaded into the time zone table (see below), and then the unlock timezone should be set to this time zone.

6.3.1.4 Auxiliary OutputsMany installations require signals into panels for alarm conditions, rather than having a host PC poll the units for alarms. The auxiliary outputs can be configured to activate on many different events, as shown in Section 4.11 on page 64. Part of the setup of a system may include deciding which events will activate which outputs. The basic setup data contains four fields which control the Aux output (Aux Out 0 on Model F units), and the extended setup data contains additional fields for all outputs.

It may also be necessary to change the activation time of the auxiliary outputs. Each auxiliary output has its own timer. In addition, the auxiliary outputs may be programmed to activate and deactivate at certain times specified by a time zone, just like the lock output.



6.3.2 Time ZonesFundamental to most access control and time and attendance systems is the idea that users can only gain access or punch at restricted times. These restrictions are established by the system administrators or supervisors based on work schedules, need to gain access, etc. Time zones are the way these schedules are programmed into the unit. Each different scheduling pattern is given a time zone, and each user is assigned to a particular time zone. Built-in time zones are “Never” and “Always,” but nearly all the time other time zones must be created.

Section 4.5.1 on page 58 provides a detailed description of time zones and the related idea on the HandPunch 4000 of a time interval. Note that the entire time zone table is loaded into the unit at once, and it is not possible to set individual time zones. Also, there is no way to retrieve the time zone table from the unit. The host system is therefore the owner of the time zone data, and this fact has an impact on planning for data backup.

An important fact to bear in mind when planning system data backup is that time zones can be changed from the command menus on HandKey models, and these changes will not be available to the host system since there is no command to retrieve the time zone table. The fact that the time zone menu was accessed can be determined from the transactions log, but the exact changes that were made will not be available.

6.3.3 ClockUnits ship from the factory with their clocks set correctly in the Pacific time zone. For deployment in other time zones, it will be necessary to reset the clock. This is done with the HereIsTime command, described on page 116.

6.4 Adding UsersUsers are added to the HGU database by the AddUser command. (HP-4000 units have different commands to add extended user data, but the principles of operation are the same as the other models.) Users may also be added from the command menus. An important decision to be made as part of the system implementation is the policy regarding who has authority to enroll users and how this will be done. There are a few options for this, depending on the system architecture. Here are the main questions to be asked with some examples of how they are answered in typical configurations. Bear in mind that many of these decisions are system architectural and policy decisions and have little to do with the actual functioning of the hand geometry unit. Here we are trying to show how the HGU can be used in a variety of different system architectures.

6.4.1 Where Will IDs Be First Entered Into the System?When it comes time to enroll a new user, the user is assigned an ID or PIN – perhaps from a pre-printed card, perhaps randomly. This ID needs to get into the hand geometry units and into the host PC system if there is one.



For stand-alone systems with no host PC, of course, users are simply enrolled at the single unit. For networked master/slave configurations with no host PC, users are enrolled at the master unit and their IDs and templates are distributed to the slaves. Enrollments at slaves are not distributed through the network.

Systems with host PCs may have ID numbers entered first at the host system, which then initiates an enrollment at a particular unit using the EnrollUser command. The user’s template is generated at that unit and retrieved by the host PC, which then distributes this template to other units on the network.

However, it is possible to initiate an enrollment from the command menus without using the host software. The system administrators need to have a policy regarding what to do with these enrollments. They can be honored and entered into the host database or the host can detect them and delete them.

6.4.2 When and Where Will the Enrollment Happen?In all the scenarios described above, the enrollment happened as soon as the ID was entered into the system, whether the ID entry happens at the HGU or at the host PC. It is possible, however, to design a host PC system which allows entry of a set of ID numbers without initiating an enrollment. When the enrollment is detected at a later time by retrieving datalogs, the template can be fetched from the unit, saved in the host database, and distributed as necessary.

Of course, for the enrollment to be complete, there must be a hand template, and that requires the user to go to a unit and physically present the hand for enrollment. Which units are designated as enrollment units is another decision to make. There can be a single unit on the desk of the system administrator which is designated as the enrollment unit, or any unit on the network can be used for enrollment. From the standpoint of the HGU, this decision makes little difference, but the design of host PC applications may have to accommodate the possibility of restricting enrollments to a particular set of units.

6.4.3 To Which Units Will Users Be Distributed?In large installations, not all users may be enrolled in all units. It is common, for example, only to enroll employees which have offices in a particular building in the units for that building, but not in units for a different building on the same plant site. A host PC software system may be required to allow this selective distribution of enrollments across a subset of the entire network.

6.4.4 How Will Templates Be Updated?The hand geometry template may change slowly over time, and it is recommended that host PC software work to keep templates up to date. This is done by retrieving the template from a user’s database record and sending it to all other units where the user is enrolled, which will overwrite the template in those units. There are a few strategies



for this. The simplest is not to do it at all, which does work reasonably well in many cases, but if a user’s hand changes over time, that user may encounter problems when attempting to use an infrequently-used unit since the template in that unit may be different.

Another method is to distribute the most recent verification template to all units where the user is enrolled. This is relatively simple, since the most recent verification can be determined by examining the datalogs. If this is done consistently, all units in the network have an up-to-date version of each user’s template and the chance of a false reject because of an old template is reduced.

Many systems consist of large numbers of single units with modems. In these cases, template management becomes a more complex problem because the verifications are not available in real-time so it is difficult to know which unit was last used. Furthermore, distributing the updated templates requires dialing every modem in the system, which can be costly. A detailed discussion of how to handle this case is beyond the scope of this manual, but it is possible to sort the transactions data, build a queue of template updates, and coordinate this queue with the routine dial-ups that must occur for data downloading. Recognition Systems can provide guidance on this if necessary.

6.5 Removing UsersRemoving users is somewhat easier than adding them, but there are some complexities. The RemoveUser command deletes a user record from the unit’s database, and that user will no longer be able to use the system. The problem is being sure that the user has been removed from all units where the user ever enrolled or where the user’s template was ever added by the host system. The easiest way to do this is simply send the RemoveUser command to all units under the control of the host. If the user is not enrolled at some units which receive the command, they will simply ignore it.

In systems which have many isolated sites accessible only via modem, the host system must carefully manage which users are enrolled where and be sure to dial up and delete users when needed.

6.6 Changing User DataAll hand geometry units contain some user data beyond just the ID and hand template. The authority level, time zone, and score threshold exist in the user records of all units, and the HP-4000 has additional data fields. Since the entire user record is accessed as a unit (even on the HP-4000, the basic user record is a single unit, and the user data fields are all accessed as a unit) it is not possible to change individual fields in the user records. Therefore, a host system must either keep a copy of all the data in all user records or retrieve records as needed for modification. Keeping a copy is the safest



policy since it provides a backup of the HGU database. When a field needs to be changed, it is changed in the local copy, then the entire record is sent to the HGU. Modified data is sent to the HGU using the AddUser command. This command will update the data fields of a record if the ID is already enrolled.

6.7 Remote EnrollmentAs described in Section 6.4 on page 221, some system designs have enrollment initiated by the host PC, rather than by the HGU command menu. Elsewhere in this manual the commands needed for remote enrollment were described, but here a high-level description of the process is given.

Remote enrollment begins by sending the EnrollUser command (see page 102). This command will begin the enrollment process at the HGU. The response to this command will come almost immediately, before the enrollment begins, and this merely confirms that the unit has received the command, not that the enrollment is complete. After sending the EnrollUser command, the host PC must monitor the progress of the enrollment by sending one of the SendStatus commands (44H or 3BH). There are three bits in the SysStat1 field of the response which indicate the progress of the enrollment. The CMD_BUSY bit will be set immediately upon receipt of the Enroll command and remain set until the enrollment is complete. It indicates only that the enrollment is in progress, but says nothing about the result of the operation.

The enrollment will either succeed or fail. The unit indicates success by setting the RSLTS_RDY bit. This means that the enrollment produced a valid template which is ready to be fetched by the SendTemplate command. The unit indicates failure by setting the FAILED_CMD bit. This can be caused by a variety of things, but it indicates that no template was generated, and whatever is returned by SendTemplate will not be a valid template for the user’s hand.

Note that the unit clears the RSLTS_RDY bit only when the it receives the SendResults or SendTemplate command. This bit is set by several commands other than the Enroll command, so care must be taken to ensure that this bit is not set from a previous operation at the beginning of the enrollment. One way to do this is simply to be sure that every operation which results in this bit being set clears it before allowing the rest of the application program to continue. Another strategy is to send the SendTemplate command (discarding the response) before initiating a remote enrollment to ensure the RSLTS_RDY bit is clear.

The FAILED_CMD bit does not behave this way; it is cleared whenever the HereIsStatus message is sent to the host. The problem here is that many commands return this response, so care must be taken when watching for the end of an enrollment not to inadvertently clear this bit by sending commands and not checking the responses during the enrollment monitoring. This can happen, for example, in a



multitasking system where one task runs all the time, polling the unit to check for datalogs, then another is created to handle an enrollment.

Note that the EnrollUser command does not create a record in the user database. It simply creates a template based on the readings of the hand. The application program can retrieve this template, and, if desired, use the AddUserRecord command.

6.8 Remote VerificationTwo more fundamental architectural questions to be answered when designing a host PC application are whether hand verifications will be initiated by the host PC application or by the hand geometry units and whether templates will be stored in the host PC database only, or also in the hand geometry unit database. These two questions are actually related in some ways.

If the decision is made that the PC will control the initiation of hand verifications, the next decision is whether templates will reside in the HGU or in the PC. Either method will work, and the HGU has commands to initiate a verification against an externally provided template as well as a template in its user database, specified by user ID. For verification against a template provided by the host PC the VerifyOnExternalData command is used. For verification against a template stored in the HGU user database, the VerifyOnInternalData command is used. Either way, the steps the host PC goes through to initiate and monitor the process is the same, and is very similar to the EnrollUser process described in Section 6.4 on page 221.

First the appropriate Verify command is sent from the host to the HGU. The host then must monitor the RSLTS_RDY and FAILED_CMD bits in the response to SendStatus. The same conditions for indicating when the command has completed apply as in the case of the remote enroll, and so do the notes about the behavior of those bits. The template that resulted from the hand reading can be retrieved using the SendTemplate command. The only difference is that the score resulting from the template comparison will also be available using the SendResults command, whereas no score is available in the enrollment process.

6.9 Turning an Output On or OffNormally, the outputs of the unit are controlled by the unit directly, based on the setup information programmed by the host PC. However, the outputs can be controlled directly by the host using the OutputControl command. The lock output can be turned on either momentarily or indefinitely. The auxiliary outputs can be turned on indefinitely. This command can also turn off any output. See page 121 for the full details of the OutputControl command.



6.10 Retrieving TransactionsThis is a particularly important issue in HandPunch units, since their primary purpose is to collect punch data. An application program must know when a unit has datalogs, and it must be able to reliably retrieve all of them, even in the case of a communication error. Additionally, Model F units which have function key menus programmed into them must be able to distinguish menu-related punches from in/out type punches.

6.10.1 The Basic Methods of Retrieving TransactionsThere are two ways to determine that a unit has punches in it. The first is to check the DLOG_RDY bit in the SysStat1 field of the HereIsStatus response. This bit is set when a datalog is recorded and cleared when the last datalog is retrieved from a unit. Note that if a unit is powered off, this bit will be cleared when power is restored, even if datalogs are present. It will be set again when the next datalog is recorded.

The second way to determine that a unit has datalogs is to send the SendNextDatalog command and check the format field. If the transactions buffer is not empty, the format field will be nonzero; if it is empty, the format will be zero.

So one method for retrieving transactions is to poll the unit using the SendStatus command, checking the DLOG_RDY bit each time. When it is set, continue sending SendNextDatalog until the format field is zero. Alternatively, the application can send SendNextDatalog continuously, checking the format field for nonzero. Either method will work.

6.10.2 Handling Communication Errors Without Losing DatalogsApplications which must ensure reliable datalog transfer must handle communication errors properly. This is what the SendPreviousDatalog command is for. Before explaining how to use this command, it will help to understand the problem that communication errors create.

Each time the HGU receives the SendNextDatalog command, it advances its pointer into the datalog buffer, and that datalog is effectively gone. Unfortunately, if a communication error occurs while downloading transactions, the PC application cannot tell whether the HGU received the command properly or not. All it knows is the HGU failed to respond, so the error could be in the command or in the response, and there is no way to know whether the pointer was advanced or not.

The solution is to send SendPreviousDatalog after a communication error is detected in the SendNextDatalog loop. The result of SendPreviousDatalog is compared with the last transaction returned from SendNextDatalog. If they are the same, the unit did not receive the command associated with the communication error. If they are different, the unit did receive the command, but the response was in error, and the unit is resending the datalog. An example may help clarify this.



Suppose the unit is ready to send datalog number 5, after already successfully sending datalog number 4. The PC sends SendNextDatalog, but the command never arrives because of a communication error. The unit remains ready to send datalog number 5. The PC detects the lack of response from the unit and sends SendPreviousDatalog. The unit will return datalog number 4, which is the last one the PC correctly received. The PC now knows the unit did not receive the command, so it is safe to send SendNextDatalog again. If the unit receives this re-send properly, it will return datalog number 5, which the PC can now write to its own transaction file.

On the other hand, if the unit did receive the SendNextDatalog command and return datalog number 5, but the response got an error, the unit will have advanced its pointer and now be ready to send datalog number 6. The PC will detect the error, and again it will send SendPreviousDatalog. This time the unit will return datalog number 5, which is not the last datalog the PC received. The PC now knows that the unit did receive the command correctly, and the PC has datalog number 5, which should now be written to the PC’s transaction file. The PC now resumes sending SendNextDatalog, which will now be number 6.

Note that a communication error includes a complete failure to receive any response from the HGU, as well as CRC errors, short response errors, etc. Anything other than a perfectly received response should be considered a communication error, and it should always be assumed that the HGU received the command and advanced its pointer.

This process, along with some special cases not mentioned above, is represented in a pseudo-code function below.



6.10.3 Handling Menu-Initiated PunchesModel F units, and the HandPunch Plus, have customizable menus which can be associated with function keys. These menus can be used to collect information from the user along with a punch (perhaps a job code, for example). This information will appear in the datalog buffer. The menus can also be used on the HandPunch 4000 to show information to the user (available vacation hours, for example). Each of these two features presents a slight problem to the PC application which must collect and interpret the datalogs in the unit.

Please see Section 6.14 on page 241 for additional information on this subject.

6.10.3.1 When Does Data Collection Terminate?Information collected from the user will appear in datalogs following the actual verification punch. These datalogs will all have format number 7, which is the same as the Identity Verified datalog. The question is how to distinguish the data collection datalogs from the actual verification punch datalog and how to know when data collection has terminated. The verification punch will always have FFH in all five bytes of the data2 field, so it is easy to identify. The data collection punches will have

Figure 4: Pseudo-code for Downloading Transactions.

// Returns number downloaded, or negative error code.// The functions SendNextDatalog and SendPreviousDatalog communicate// with the hand reader. They set comError if, after retrying, they // are unable to successfully communicate with the unit.

int DownloadTransactions (void)

DATALOG datalog, lastDatalog;int n = 0;

LOOP:datalog = SendNextDatalog();if (comError)

datalog = SendPreviousDatalog();if (comError)

return -1;if ((n>0) AND (datalog==lastDatalog))

goto LOOP;if (datalog.format == 0)

return n;SaveDatalog (datalog);lastDatalog = datalog;n = n + 1;goto LOOP;



whatever TA code is assigned by the menu designer in the TA code field of data2, and the remaining four bytes will contain the user input data.

The most reliable way to terminate data collection is to insert a special collect object of type TA at the end of each data collection menu, and assign its TA code a value that is not used by the other collect objects. This will insert a place-holder datalog in the transaction buffer which marks the end of the data collection. This has the disadvantage of using up an additional datalog, but it will work in all cases.

Alternative solutions that have been devised are to make all the menus the same length, or to check for a change in the ID field in the datalog stream. These will work, but may not be suitable for all systems, and are not as reliable as the method described above.

6.10.3.2 Identifying HP-4000 Custom Data Viewing Versus Actual PunchingThe second question which arises about interpreting transaction data when using function key menus pertains only to the HP-4000. These units allow the display of custom data for users, but the unit must first verify the user’s identity, and this verification generates a datalog. The problem is how to distinguish the datalogs that are used to gain access to the custom data from those that represent legitimate punches. There are several ways to do this. The easiest way uses a feature which was added to the HGU firmware on 4/18/2000, in PROM revision 60.

6.10.3.3 Firmware Dated After 4/18/2000 – PROM Revision 60This version introduced the TA Code override feature in the menu system. This allows the TA code in the hand verification datalog, which always appears first in the data collection sequence. It can also completely suppress the datalog that is associated with the actual hand punch to gain access to the menus and only keep datalogs associated with the menu system. This feature is described fully in the Function Key Compiler Manual, revisions dated after 4/18/00.

6.10.3.4 Firmware Dates Prior to 4/18/2000 – PROM Revisions 59 and EarlierTwo less elegant solutions exist for older firmware.

First, an explicit punch menu can be installed which contains only a collect object of type TA and a unique TA code. The PC application which downloads transactions can search for this TA code and disregard all other datalogs.

Another way to handle the info datalogs is to put collect objects of type TA before each info-displaying menu. Assign them a unique TA code. This will mark the beginning of an info display, and the PC application can know to discard datalogs which have this marker.



6.11 User Database Backup and RestoreTo backup a unit’s user database, it is recommended that the block transfer commands (HereIsDataBank, SendDataBank) be used. These commands transfer an entire 4K block of user data, greatly reducing the overhead of sending commands. However, properly implementing a database backup and restore requires some care.

6.11.1 Idle ModeBefore transferring user database data into or out of a unit, it is a good idea to put the unit into Idle mode. This blocks all keypad entry and hand verifications, which may change the user database data if a template is updated due to a hand reading. In addition this allows the unit to devote all its processor resources to communications, which can speed up the transfer. When the entire transfer is complete, the host can take the unit out of idle mode by sending the Resume command. The unit should be put into Idle mode prior to transferring the first bank and should remain in idle mode until the transfer of the last bank is complete.

6.11.2 BackupFor backup, the host will be retrieving data banks from the unit. This requires that the host know when to stop asking for more data. There are several ways to do this. The simplest way, although the least efficient, is simply to use a hard-coded limit based on the memory configuration of the unit. All banks in the unit’s memory are transferred without regard to how many users are actually enrolled. This only requires a knowledge of exactly how the unit is configured, and table Table 42 on page 230 shows the number of user banks available for all the memory options which can exist.

Table 42: Number of User Banks for All Models

Model and Memory Option User Banks

HP2K-A 2HP3K-A 2HP3K-B 38HP3K-C 127HP4K-B 10HP4K-C 66E-SA 1E-SB 13E-LA 38E-LB 109



Note that the HP2K is only available with the A memory option, and the HP4K is only available with the B and C options. Model E units have the same user capacity for a given memory option whether they are HandKey or HandPunch units. For Model E units, the letters S and L refer to the physical memory installed, either 128K or 512K, and the letters A and B refer to the PROM installed. See Table 1 on page 15 for more information on memory options.

A more sophisticated way to do the transfer, which will work with absolute certainty only on units whose firmware was compiled after 8/10/98 for Model F and 6/18/98 for Model E units, is to check the first byte of each bank that comes back from the unit. When a bank is returned with the first byte containing 0FFH, the transfer is complete. Since no valid user ID number contains 0FFH in its first byte (this is in fact used to mark an empty record), this provides a reliable indication that the last bank has been received. Units with firmware compiled before this date will return random data if the bank number is out of range, so there is no way to be sure the transfer has terminated.

Another step which can be taken to detect the end of the transfer is to scan backwards from the end of each bank, looking for a user record which begins with 0FFH. This method can be used on all units. However, there are still two caveats. First, HandPunch 4000 units have a different user record size, so the ID numbers are not located at the same offsets within the database bank as on other models. Second, in the unlikely event that the entire database is completely full, the last record of the last bank will not actually contain 0FFH, but rather it will hold the last user record. In this case, there is no way to detect the end of the database unless the unit’s firmware supports the feature of returning 0FFH when an out-of-range bank number is requested by the host.

An example program in pseudo-code showing all these features is shown in Figure 5.



This shows all the techniques for termination that were discussed in the text. Setting the argument “limit” to a non-zero value will enable hard-limiting to a fixed bank number, although this function will terminate earlier if it detects an appropriate stopping condition. The test of the first byte against 0FFH is always a legitimate stopping condition, although it is not strong enough to catch all cases. Searching backwards from the last record looking for ID numbers whose first byte is FF will catch most database ends, except when the database is completely full.

Figure 5: Pseudo-Code for User Database Backup

// Returns number of banks transferred// The functions EnterIdleMode, SendDataBank, and Resume communicate// with the hand reader. They set comError if, after retrying, // they are unable to communicate with the unit.

int BackupUserDatabase (int limit)

USER_BANK data;int bank = 0;int RecordSize;int UsersPerBank;int n;

EnterIdleMode();if (comError)

return bank;

if (ModelIsHP4000)RecordSize = 77;

elseRecordSize = 16;

UsersPerBank = 4096 / RecordSize;

LOOP:data = SendDataBank (bank);if (comError)

return bank;if (data[0]==0xFF)

return bank;for (n=0; n<UsersPerBank; n=n+1)

int offset = RecordSize * (UsersPerBank-n-1);if (data[offset] == 0xFF)

return bank;WriteDataToFile (data);bank = bank+1;if (limit > 0)

if (bank < limit)goto LOOP;

Resume();return bank;



6.11.3 RestoreRestoring a user database is considerably simpler than backing it up because the termination point is already known. However, the proper sequence of commands must be sent in the right way. For each bank, the host must first send the HereIsBankNumber command. Then send the actual data with the HereIsDataBank command. Repeat this process for each data bank.

Note that Model E units require that the HereIsDataBank command be sent within 5 seconds of sending the HereIsBankNumber command. the unit will not respond to the HereIsDataBank command unless it is preceded by HereIsBankNumber, and the data will not be stored in the user database. The unit will not respond to other commands if they are sent within 5 seconds of sending the HereIsBankNumber command. Only the HereIsDataBank command will be processed during this time. This restriction applies to Model E units only; the F series units can receive the HereIsDataBank command at any time and will use the last bank number set by HereIsBankNumber.

Although the programming of the restore operation is fairly simple, there are two rules which must be observed.

• Do not attempt to restore a database from a HP-4000 to any other model, and do not attempt to restore databases from other models into a HP-4000. The user record size of the HP-4000 is different than the other models, and mixing the database formats will cause the units to behave unpredictably.

• Do not attempt to restore data into a bank beyond the physical capacity of the destination unit. Most units will not respond to the HereIsBankNumber command if the bank number received is beyond the limit of their physical memory, but some older units may not work correctly in this situation.

• Pseudo-code showing the recommended technique for database restore is shown in Figure 6 on page 234.



This shows the technique for restoring user data to a unit. Note that the termination can be based on a hard limit or on the end of the data file. Also note that although the technique for restoring data does not depend on the model, HP4000 records are not compatible with records from other models.

6.12 Complete Backup of an Entire UnitTo backup a unit completely, or to copy the contents of one unit to another, the user database and the setup data must be retrieved and saved to a file. The procedure for backing up and restoring the user database was described in Section 6.11 on page 230. To retrieve the setup data, use the SendSetup command and, if applicable (Model F units), the SendExtendedSetup command. Restoration of the setup data is done using the HereIsSetup and HereIsExtendedSetup command. In addition, the UpdateNVRam command may be required; see the detailed descriptions of the commands for more information on this.

Figure 6: Pseudo-Code for Database Restore

Returns number of banks transferredThe functions EnterIdleMode, HereIsBankNumber, HereIsDataBank, and Resume communicate with the hand reader. They set comError if,after retrying, they are unable to communicate with the unit.

BackupUserDatabase (int limit)

USER_BANK data;int bank = 0;

EnterIdleMode();if (comError)

return bank;

P:HereIsBankNumber (bank);if (comError)

return bank;

data = ReadDataFromFile();if (EndOfFile)

return bank;

HereIsDataBank (data);if (comError)

return bank;

bank = bank+1;if (limit > 0)

if (bank < limit)goto LOOP;

Resume();return bank;



If the datalogs from the unit are important, they should be retrieved. There is no facility for adding datalogs to a unit, although this is not normally required in restoring data from a backup.

HandPunch 4000 units also contain a message pool. There is no mechanism for backing up the message pool from the unit. If this is required, the host computer system must maintain a copy of the data in each unit, and the messages can be restored from this copy.

6.13 Examples of Packing and Unpacking Binary Data Fields

6.13.1 High Bit in Type FieldThe high bit in the type field of a command or response packet is set if the data in that packet exceeds 255 bytes. This bit is set and tested as shown in Figure 7.

It is not necessary to clear the high bit of the type, but it may make it easier to check the type value against the expected value from the command/response tables.

Figure 7: Setting and Testing the High Bit in the Type Field

void SendCommand (...)

/* send 0A, address */

if (length > 255)type = type | 0x80;

/* continue sending type, length low byte, length high byte, etc. */

void GetResponse (...)

/* receive 0A, address, type, length low byte */

if (type & 0x80)GetLengthHighByte();

type = type & (~0x80);

/* continue receiving data, etc. */



6.13.2 User Record Authority FieldThe authority field in the basic user record actually holds two pieces of data. The three least significant bits hold the authority level, and the five most significant bits hold the override reject threshold. Figure 8 on page 236 shows how to extract and set these values. Note that the reject threshold stored in this field is the actual threshold desired divided by ten.

SetAuthority shows how to generate the authority byte from the two data items it contains. The function f is some function which processes a user record and needs to extract the authority level and reject override data.

Figure 8: Extracting and Setting the Authority Byte Fields

BYTE SetAuthority (int auth, int rej)

// Given auth and rej, calculate the authority byte for the user record// Note that rej contains a score, and so will be divided by 10

return ((rej/10)<<5) & (auth&0x07);

void f (void)

int authority;

/* doing some stuff, got a value into authority from a user record */

AuthorityLevel = authority & 0x07;// lower 3 bits are authorityRejectOverride = (authority >> 3) * 10;

/* continue processing as needed */



6.13.3 HP-4000 Time IntervalsThe time intervals in a HandPunch 4000 consist of three pairs of 12-bit start and stop times. Each pair of 12-bit values is packed into 3 bytes, so a single time interval occupies 3 bytes. Packing and unpacking a single time interval is shown in Figure 9 on page 237. The Extended User Record contains three of these packed time intervals.

The (unsigned long) in front of a variable casts it to type unsigned long, assumed here to be a 32-bit type. This is so the shifts do not cause the result to be zero. Note that this is not necessarily the most efficient way to do this, but illustrates a simple technique that is easily ported to other languages.

Figure 9: Packing and Unpacking HandPunch 4000 Time Intervals

unsigned start, stop;unsigned char dow;unsigned long pti;

void func (void)

/* start, stop, and dow are initialized somehow, and we wantto generate the packed time interval */

pti = ((unsigned long) dow << 24) | ((unsigned long) (stop & 0xFFF) << 12) | (start & 0xFFF);

/* pti now contains the packed time interval which can be put intoa HP4000 user record */

void gunc (void)

/* pti is initialized somehow, and we want to unpack it */start = pti & 0xFFF;stop = (pti >> 12) & 0xFFF;dow = pti >> 24;



6.13.4 DOW Masks for Time Zones and Time IntervalsThe DOW mask contains seven bits specifying days of the week and one bit for holiday access. There are many ways to set the individual bits based on a known set of days, since there are many ways to represent a set of known days. One possible technique is shown in Figure 10 on page 238, where each day is assigned a number, 0 being for Sunday, 1 for Monday, and so on until 6 is assigned to Saturday. That example also shows a function for testing whether a particular day is set in the DOW mask.

Figure 10: Setting and Testing Bits in the DOW Mask

BYTE SetDOW (BYTE dow, int day)

return dow | (1 << day);

int TestDOW (BYTE dow, int day)

if (dow & (1<<day) == 0)return 0;

elsereturn 1;



6.13.5 Holiday TableProbably the easiest way to represent the Holiday table in C is as an array of unsigned longs, or in Pascal, a long int. Each element in the array corresponds to a month, and each bit is a day within the month. Functions for setting and testing values in such a holiday table are shown in Figure 11.

Production-quality software would include range checking on the array index, and could also include testing for valid days depending on the month. The HGU will ignore holiday table bits which do not exist for the particular month, e.g. February 31st.

Figure 11: Setting and Testing Bits in the Holiday Table

typedef unsigned long HOLIDAY_TABLE[12];

void SetHoliday (HOLIDAY_TABLE ht, int month, int day)

unsigned long mask = 1 << (day-1);ht[month] = ht[month] | mask;

int TestHoliday (HOLIDAY_TABLE ht, int month, int day)

unsigned long mask = 1 << (day-1);if (ht[month] & mask == 0)

return 0;else

return 1;



6.13.6 Bell ScheduleThe bell schedule is a feature that is supported only in HandPunch units. It allows activation of the auxiliary output based times loaded into the bell schedule table. Each entry in the bell schedule table consists of an activation time, a duration, and a DOW mask identical to the DOW mask in the time zone table and the HP4000 packed time intervals. An example of how to build a bell schedule table entry is given in Figure 12. Note that it is not normally necessary to unpack a bell schedule entry since there is no command to retrieve a bell schedule from the HandPunch unit, and the data can be stored in the PC application in a different, unpacked format.

Figure 12: Creating a Bell Schedule Entry

typedef BYTE BELL_SCHEDULE_ENTRY[3];BELL_SCHEDULE_ENTRY bell[100];

SetBellScheduleEntry (int num, int min, int hour, int dur, BYTE dow)

hour = hour & 0x1F; // limit hour to 5 bitsmin = min & 0x3F; // limit minute to 6 bitsdur = dur & 0x1F; // limit duration to 5 bits

bell[num][0] = ((hour & 0x03) << 6) | min;bell[num][1] = (dur << 5) | (hour >> 2);bell[num][2] = dow;



6.14 Function Key Menus

6.14.1 IntroductionThe Model F units all support user-programmable menus defining what the function keys do. These menus can be used for data collection, tailoring the datalog data to particular needs, or, in the case of the HP-4000, for displaying custom data to the end user of the unit.

The function key menu code is binary data that is interpreted by the HGU. This binary data is created from a text script by the program FKPARSE. The usage of this program and the description of the script language is given in the Function Key Compiler Manual. We will limit our discussion of the function key menu system to a few key points about communication and programming.

6.14.2 Reverting to “Cleared” StateThe binary image of “cleared” function key menus, meaning all function keys have no operation to them, must be created by FKPARSE by loading an empty script into it. The function key table is not cleared by sending all zeros or FFH to the unit. Sending data other than the output of FKPARSE will likely cause the unit to behave unpredictably.

6.14.3 Marking the Beginning and End of Data CollectionEach time a function key menu is activated, a hand verification is necessary. This hand verification will appear in the transactions datalog as an ID Verified datalog (type 7). The datalogs that correspond to collected data will follow the datalog from hand verification, whether the function key is defined to be ID first or ID last. If it is necessary to mark the end of the data collection sequence, it is suggested that a Collect object of type TA be used with a TA code that is unique and can indicate the end of data collection.

If the user presses the Clear key during data collection, only the collected datalogs will be discarded. The hand verification will still appear.

6.14.4 Modification to Hand Verification DatalogOn firmware dated 4/10/2000 and later, an additional feature is present in the function key menu system which allows the menu designer to modify the way the hand verification datalog is generated. One possible modification is to specify an alternate TA code. This makes it easier for the host system to distinguish datalogs associated with function keys from datalogs associated with normal punches.



The other modification is that the menu designer may specify that no datalog is to be generated from the hand verification associated with activating a menu. This will result in only true hand verifications appearing in the transactions buffer, or datalogs associated with the actual collect objects in the menu system.

Refer to the Function Key Compiler Manual for more information on this.

6.15 HP-4000 OnlyImplementing most of the HP-4000 features is fairly straightforward and does not require specific examples. Still, there may be some questions about some of the new features and how they are meant to be used, as well as some issues about how the Model E commands act on an HP-4000. Some of these issues were covered previously in Section 4.15 on page 68. Here we provide a comprehensive list of new HP-4000 features and give information specifically centered around programming using the host commands.

6.15.1 Messages

6.15.1.1 AddingMessages are added to the message pool with the AddUserMessage command. As explained in Section 4.15.1 on page 68, deleting messages can create holes in the message pool, and the procedure described in that section should be followed if it is necessary to keep messages displayed in a particular sequence.

6.15.1.2 RemovingMessages are removed from the message pool with the RemoveUserMessage command.

6.15.1.3 Clearing AllThe entire message pool can be cleared at once, for all users, with the ClearUserMessages command.

6.15.2 User Database Management

6.15.2.1 Adding UsersUsers are added to the HP-4000 database using either the HereIsUserRecord or HereIsExtendedUserRecord commands. Using the HereIsUserRecord command will create a new user record if the ID is not found in the database. This new record will have the fields in the BUR portion as specified in the command, and the remaining fields will be filled with zeros. The XUD portion can be filled in with the HereIsExtendedUserData command. Using the HereIsExtendedUserRecord command allows the entire extended user record to be specified in one command.



6.15.2.2 Removing UsersUsers are removed from the HP-4000 user database using the RemoveUser command. The entire user database can be cleared with the ClearUserDatabase command. These commands behave no differently on HP-4000 units than on other models.

6.15.2.3 Sending Only the Extended User Data to an Existing User RecordIf it is desired to load only the HP-4000 specific part of the user record, called the Extended User Data or XUD, the HereIsExtendedUserData command may be used.

6.15.2.4 Sending Only the Data for Function Key Menu DisplayThe HP-4000 user record contains a 24-byte user-defined field (UDF) which is used to display data on the function key menus. How the data is displayed is described in the Function Key Compiler Manual. Here we are only concerned with how the data gets sent from the host PC to the HGU.

There are two ways to set the UDF data. One way is to use the HereIsExtendedUserRecord (‘x’) command. This requires that all the other fields in the user record be sent along with the UDF data, which means that either the records must be stored in a database on the host PC and retrieved from the database before the ‘x’ command can be sent, or else the SendExtendedUserRecord command has to be used to retrieve all the other fields.

The other way to set this data is to use the SetUserData (‘f’) command. This command allows the UDF portion of the record to be set independently of the rest of the record. This can make the programming job much easier since the other fields in the user record do not need to be known in order to set the UDF data.

6.15.2.5 Retrieving a User RecordThe BUR portion of the HP-4000 user record is returned when the SendUserRecord (‘8’) command is received at the HGU. In order to retrieve the full extended user record, the host system must send the SendExtendedUserRecord (‘t’) command.



Blank page.



7.0 Miscellaneous Reference

7.1 Connector Pinouts

7.1.1 Model E Terminal StripsThe pinouts of the Model E series of Hand Geometry units are shown in Table 43. For pinouts of the modem and Ethernet connectors, see the section below.

Table 43: Connector Pinouts for Model E Terminal Strips

Pin HandKey Function HandPunch Function

1 + Power + Power2 Ground Ground3 RS-232 Rx RS-232 Rx4 Gnd Gnd5 RS-232 Tx RS-232 Tx6 RS-422 Rx-

RS-485 RT-RS-422 Rx-RS-485 RT-

7 RS-422 Rx+RS-485 RT+

RS-422 Rx+RS-485 RT+

8 RS-422 Tx- RS-422 Tx-9 RS-422 Tx+ RS-422 Tx+10 Aux Output

Card Output D0 or DATAAux OutputBell Output

11 Gnd Gnd12 Lock Output

Card Output D1 or CLKLock Output

13 Door Switch Input Not Used14 Gnd Gnd15 Aux Input Not Used16 Gnd Gnd17 Rex Switch Input Rex Switch Input18 +5V power to card reader +5V power to card reader19 Card Input D0 or DATA Card Input D0 or DATA20 Not used Not used21 Card Input D1 or CLK Card Input D1 or CLK22 Gnd Gnd



Typical configurations are shown. Some special products have variations on these pinouts. For card reader inputs and outputs, D0/D1 are for Wiegand formats, CLK and DATA are for Magstripe formats.

7.1.2 Model F Terminal StripsTable 44 on page 247 shows the connector pinouts for HandPunch 3000, HandPunch 4000, HandKey-II, and HandKey-CR. The HandPunch 2000 has no external terminal strips. For pinouts of the serial, modem, Ethernet, and power connectors, see Section 7.1.3 on page 248.

Note: HandPunch units have power applied through a barrel connector. HandPunch units have RS-422 and RS-485 network connections through an RJ-11 jack. See Section 7.1.3 on page 248 for more information.



Table 44: Model F Connector Pinouts

Pin HP3K HP4K HK2 HKCR

1 Note 1 Note 1 + Power + Power2 Note 1 Note 1 - Power - Power3 Note 2 Note 2 RT- RT-4 Note 2 Note 2 RT+ RT+5 Note 2 Note 2 TX- TX-6 Note 2 Note 2 TX+ TX+7 Rex Switch Rex Switch Rex Switch8 GND GND GND9 Door

SwitchDoor Switch

Door Switch

10 GND GND GND11 Aux In 1 Aux In 1 Aux In 112 GND GND GND13 Aux In 2 Aux In 2 Aux In 214 GND GND GND15 +5V Out +5V Out +5V Out +5V Out16 D0/DATA

InD0/DATA In

D0/DATA In D0/DATA In

17 D1/CLK In D1/CLK In D1/CLK In D1/CLK In18 GND GND GND GND19 Lock

D1/CLK Out

LockD1/CLK Out

LockD1/CLK Out

LockD1/CLK Out

20 GND GND GND GND21 AuxOut0/

BellD0/DATA Out

AuxOut0/BellD0/DATA Out

AuxOut0D0/DATA Out

AuxOut0D0/DATA Out

22 GND GND GND GND23 AuxOut1 AuxOut1 AuxOut1 AuxOut124 GND GND GND GND25 AuxOut2 AuxOut2 AuxOut2 AuxOut226 GND GND GND GND



7.1.3 Model F Additional Connectors

7.1.3.1 RJ-45 RS-232 ConnectorThe Model F units have an RJ-45 connector located at the right side of the board, when viewed from the read of the unit. This connector is labeled as J4 on the board.The pins on this connector are numbered from 1 to 8, starting from the right. Note that most of the RS-232 signals are not currently supported by the firmware and are included only for possible future expansion. Currently, only TX and RX are used. TX refers to data out of the unit; RX refers to data into the unit.

7.1.3.2 RJ-11 RS-422/RS-485Some Model F units have an RJ-45 connector for RS-422/485 communications, rather than having these signals present on a terminal strip connector. This connector is located slightly left of the center of the main board, as viewed from behind the unit. This connector is labeled J3 on the board.

The pins of this connector are numbered 1 to 4, starting from the left. Data coming out of the unit is TX, and data going into the unit is RX.

7.1.3.3 RJ-45 Ethernet ConnectorThe connector on the optional Ethernet board is a standard EIA-568B RJ-45 connector.

Table 45: Model F RJ-45 RS-232 Connector Pinout

Pin Function

1 RI (not currently supported)2 CD (not currently supported)3 DTR (not currently supported)4 GND5 RX (data into unit)6 TX (data out of unit)7 CTS (not currently supported)8 RTS (not currently supported)

Table 46: Model F RJ-11 RS-422/485 Connector Pinout

Pin Function RS-422 Function RS-485

1 RX+ RT+2 RX- RT-3 TX- not used4 TX+ not used



7.1.3.4 Power ConnectorThe power connector is the barrel connector located at the left side of the board. The center pin is +power, and the outside pin is GND.

7.2 LCD Character MapIn general, a host computer system does not need to know about the LCD character set. The HGU displays messages independently of the host PC. However, there are some situations where the host is loading text strings into the HGU for display. These are the HereIsDisplayMessage command, loading into user messages into a HandPunch 4000, and setting the ready string in the extended setup data.

With minor exceptions, for character values from 32 to 127, the LCD follows the ASCII character set. Values from 128 to 255 generally display Japanese katakana symbols and some Greek letters and foreign currency symbols. Values from 0 to 31 are reserved for control codes to the LCD and should not be used. A solid block may be displayed using character 255.

The character map for the LCD is shown in Table 47. Control codes, Katakana characters, and codes which display characters that cannot be shown in the fonts available for this manual are not shown.

Codes are in hex. The number at the left shows the upper four bits and the number at the top shows the lower four bits. Codes less than 20H are reserved for control codes to the LCD controller module. Do not send codes less than 20H to the unit. Code 20H will make a space. Code FFH will make a solid block. Other codes which are blank in the table will display characters which cannot be drawn in fonts available for this manual. In addition, codes A0H through D0H will show Japanese Katakana characters. Contact Recognition Systems if it is necessary to obtain information on character codes not shown here.

0 1 2 3 4 5 6 7 8 9 A B C D E F

2x ! " # $ % & ' ( ) * + , - . /

3x 0 1 2 3 4 5 6 7 8 9 : ; < = > ?

4x @ A B C D E F G H I J K L M N O

5x P Q R S T U V W X Y Z [ ¥ ] ^ _

6x ‘ a b c d e f g h i j k l m n o

7x p q r s t u v w x y z | → ←

Ex α ä β ε µ σ ρ √ -1 ¢ ñ ö

Fx θ ∞ Ω ü Σ π x ÷

Table 47: LCD Character Codes



7.3 Behavior on Reset

7.3.1 Types of ResetThere are three types of reset that a unit can be set to perform. They are referred to as a “cold boot,” “warm boot,” and “normal boot.” In a normal boot, no data or setup is altered from how it was when power was last turned off, provided the lithium battery is sufficiently charged to keep the backup circuit working. In a warm boot, the setup data is restored to its factory default values, but the user database and transactions buffer are not altered. In a cold boot, all internal databases are cleared, including the user database and transaction log, and the setup data is restored to the factory default values.

The way that a particular unit is configured to do a cold, warm, or normal boot depends on the model. For Model F units, the DIP switches at the left of the main board control the boot mode. Setting both SW4 and SW5 ON will cause a cold boot. Setting SW4 OFF will cause a normal boot, regardless of the setting of SW5. Setting only SW4 ON and SW5 OFF will cause a warm boot.

On Model E units, setting SW4 ON and holding the tamper switch in will cause a cold boot. Setting SW4 on and not holding the tamper switch will cause a warm boot. Setting SW4 off will cause a normal boot regardless of the position of the tamper switch.

7.3.2 Data Displayed on Reset

7.3.2.1 Model F UnitsModel F units will indicate whether they are booted cold or warm by showing “COLD BOOT” or “WARM BOOT” on the first line of the LCD immediately after the top panel version number is displayed. The second line shows the reason for the cold boot, which is usually “DIP SWITCH SET.” For a normal boot, nothing is displayed at this point. Following the boot type display, Model F units will show the model type (HP2, HP3, HP4, HK2, HKC) followed by the memory option (A, B, or C) and the PROM version (after the dot). In addition, on those units which have been programmed with custom configuration data, an identifier number for this configuration will appear after the PROM version. On the second line, the card format identifier string or custom line 2 string will appear. After a short time, the “READY” or “ENTER ID” (or custom ready message) will appear and the unit is ready to use.

7.3.2.2 Model E UnitsModel E units will not indicate whether they are booted cold, warm, or normal. They will display the PROM ID and card format.



7.3.3 Additional Reset Display DataPressing a key on the keypad during the initial power-up displays (the PROM version and card format string) will cause the most units to display their PROM build date and their serial number. This information may be requested by Recognition Systems customer support, and can help identify what features a unit supports.

7.3.4 Reset DatalogModel F units with firmware compiled on or after 4/26/99 will genererate a special datalog on reset. This will be of format number 30 (see page 211) with TA code 99. The exact contents of the datalog varies with the specific firmware revision. This is not necessarily the first datalog generated at power-up; some versions of firmware may also detect the state of the door controls and auxiliary inputs and issues datalogs associated with these inputs prior to recording the reset datalog.

7.3.4.1 Firmware Dates 4/26/99 to 4/19/00The last byte (byte 4 of 4) of the DataB field indicates the status of the DIP switches that control the boot mode. The least-significant half of this byte will be a 1 if DIP SW5 is OFF, or a 0 if it is ON. The most-significant half of this byte will be a 1 if DIP SW4 is OFF, or a 0 if it is ON. Therefore, for a DIP-switch initiated cold boot (both switches ON), this byte will contain 00, and for a normal boot (both switches OFF), it will contain 11.

The least significant byte’s most significant bit (bit 7) is used to indicate that a boot was caused by a special software-initiated reset command. This is an internal undocumented command used in manufacturing the unit. This bit should not be set in the field.

The next most significant byte (the second from the last, byte 3 of 4) contains two flags which indicate other information about the boot sequence. If the least significant bit (bit 0) is set, the transfer of setup data from the EEPROM failed, or the contents of the EEPROM did not match the contents of the SRAM copy. This will force the unit to do a cold boot, regardless of the settings of the DIP switches. Bit 1 of this byte indicates the integrity of the internal calibration data area of the EEPROM. If this bit is set, the calibration data is damaged. This event is rare, but it does happen in the field and generally indicates the board was hit with an electrostatic discharge. This will cause the unit to revert to a factory test mode, and the unit will need to be returned to Recognition Systems for service.

This data is summarized in Table 48 on page 252.



r

7.3.4.2 Firmware Dates 4/20/00 and LaterOn 4/20/00, the power-up sequence in the Model F units was completely revised to help reduce the impact of those rare ESD events which cause the contents of EEPROM to be damaged. The unit keeps integrity checks on both the SRAM copy and the EEPROM data, and if one is determined to be corrupt, it is recovered from the other. This is referred to as the “Data Integrity” firmware revision, and it generates a new set of data in the reset datalog. This data is summarized in the table below. Refer to Section 7.3.5 on page 253 for a summary of the operation of the data integrity mechanism.

Table 48: Reset Datalog Data for Model F Firmware Before 4/20/00

Field Location

DIP SW4 Most-significant half of byte 4/4 = 1 if switch is OFF.

DIP SW5 Least-significant half of byte 4/4 = 1 if switch is OFF.

EEPROM failed Bit 0 of byte 3/4 is 1 if failureCal data invalid Bit 1 of byte 3/4 is 1 if invalidSoftware Reset Bit 7 of byte 4/4 is set (not seen in field)

Table 49: Reset Datalog Data for Model F Firmware Dated 4/20/00 and Late

Byte Contents

1 of 4 Force state. This is set if any errors or warnings are detected.0 = Nothing forced. Booting proceeds normally, controlled by DIP swtich settings.1 = Cold boot forced. Will set mode field bit 1.2 = Warm boot forced. Will set mode field bit 0.3 = Reboot forced. This is set when the unit detects a condition which requires an internally-initiated reboot to happen for proper recovery.

2 of 4 Boot mode. This is what determines the actual mode the unit will boot in, based on the setting of the DIP switches and the force field.Bit 0 = warm bootBit 1 = cold bootNote that a cold boot implies that the warm boot steps also occur, regardless of the setting of the warm boot bit.

3 of 4 Error number. This will be displayed on the LCD at reset if not zero.Note that the display shows the values in decimal. Refer to ??? for a list of errors and warnings.

4 of 4 Boot status. This contains the same data as the previous firmware versions, as shown in Table 48.



7.3.5 Data Integrity CheckingThe data integrity mechanism is complex and a full understanding of its operation is not required. However, a quick summary may be helpful in understanding the more common types of errors and warnings that may appear.

The basic aim of the data integrity checking is to validate the integrity of the EEPROM data and its SRAM copy and verify that they match byte-for-byte. Any deviation from this state generates a warning or error. Depending on the nature of the problem, it may be possible to recover the data. Some severe problems will require that the unit be cold booted, and others may require the unit to be returned to Recognition Systems for service. Some of the error codes that are likely to be seen in the field are shown below. The unit may generate other error codes, but these generally will indicate a serious hardware failure. If any error or warning code other than those in the table below appear, contact RSI technical support. Do not enter anything on the keypad until receiving instructions from RSI. It may be possible to recover user data and transactions even if an error is present..

7.3.6 Model ErrorsIn extremely rare cases, a unit may show a display like “Model Error 120”. The model error display is an internal check on the range of the values that indicate the model a unit is, how much memory it has, and how much memory is assigned to the various databases in the unit. In most cases, these errors are caught during development and manufacturing and simply cannot occur in the field. If a model error does show up, chances are that the main board has suffered catastrophic damage and the display is bogus. For example, a PROM not correctly seated in the socket can cause the CPU to execute random instructions and fail intermittently, and this display can come up.

Table 50: Most Common Data Integrity Warnings

Code Meaning Likely cause Action taken

48 SRAM is good, EEPROM is bad

ESD damage to EEPROM

SRAM overwrites EEPROM, unit reboots

64 EEPROM is good, SRAM is bad

Lithium battery dead or changed

EEPROM overwrites SRAM, unit reboots

112 Both EEPROM and SRAM are bad, but cal data is good.

Firmware update on pre-data integrity unit. This is normal.

EEPROM overwrites SRAM, unit reboots.

17,18,19 Unit was reset in the middle of a data transfer, but all data is OK

Unknown. None. This is harmless and is for information only.



One situation which can occur in the field which does not indicate a gross board failure is when a HP-4000 is run with the 128K memory option. This option is not supported on the HP-4000. The three-digit code in this case should end in 03. The first digit may vary.

For the sake of completeness, the model error codes are listed below. Since this is an internal error checking mechanism only, these codes and their meanings may change at any time without notice. The model error display should have the words “MODEL ERROR” on the first line of the LCD, followed by a three-digit number. On the next line should be a short text description of the error. Anything different from this most likely indicates that the main board is damaged and the model error display is bogus. That includes the model error display not being on the first line of the LCD, values appearing which are not in the table below, and anything other than exactly three digits of code number.

7.4 Auxiliary KeypadThere is an application note on the Auxiliary Keypad which is the definitive reference for it. Here we merely summarize some important pieces of information.

The Auxiliary Keypad will generate the AUXKPD event if the ID entered is valid. Note that a “valid” ID means that the ID is enrolled and whatever time restrictions are in effect allow this user to use the system at the current time. See Section 4.5 on page 57 for more information. If the ID is not valid, the keypad input is ignored. The unit can be programmed to ignore time restrictions for ID numbers received from the Auxiliary Keypad.

Table 51: Model Errors

Digit Position Value Meaning

First 0-4 Obsolete, no meaning, but should be in this range

Second0 128K memory detected1 256K memory detected2 640K memory detected

Third

0 Memory and model detection was successful1 Model number is invalid2 Memory option detected is not valid3 Memory configuration not supported in this model4 No memory allocated to datalogs5 No memory allocated to users



If the lockup flag is set, the AUXKPD event will not be generated, but this datalog will still be recorded. (The lockup flag is set by the OutputControl command. See page page 121.) The Auxiliary Keypad is not supported on the HandPunch 2000 and HandKey CR models. Please refer to the application note on the Auxiliary Keypad for more information.

7.5 Duress CodesA duress code is a code that users can enter to notify an access control system that they are attempting to gain access under duress rather than of their own free will. This event will typically notify a security guard who can handle the situation appropriately. The Hand Geomtry Units support the use of a single-digit duress code which can be entered as the first digit before an ID. When the duress code is detected, the unit will generate a DURESS event, which can activate auxiliary outputs and will generate a datalog format 45.

The ID that is entered following the duress code does not need to valid, or even enrolled, in order for the duress code to have its effect. Entering the duress code by itself with no following digits will also work. ID numbers entered from the Auxiliary Keypad can also generate the DURESS event. Card reader input will generate the DURESS event if the duress code is the first digit of the ID received from the card.

The DURESS event is generated only after the # or Enter key is pressed. If the keypad duress code needs to work with card reader input, instruct users to enter the duress code and press the # or Enter key, then swipe their card. The HGU will not generate the DURESS event unless the duress code is the first digit of a keypad entry which is terminated by the # or Enter key.

7.6 Y2K IssuesFortunately, the year 2000 transition has come and gone with little worthy of note, and hand geometry units had no Y2K-related failures. However, a few points are worth noting since not all units behave exactly the same way now that the year has changed to 2000.

The HereIsTime command was changed on 9/4/97 to force the year value to wrap year values of 100 or more back around to zero. Units with firmware earlier than this may either do this or not, depending on the version of hardware components that is installed. Application programs should generall use the number 00, rather than 100, to indicate 2000. Applications should also consider time stamps with years equal to 100 to be indicating 2000. Some units older than 9/4/97 may attempt to display a three-digit year in a two-digit field on the LCD, and may show 100 as 10. This can be prevented by ensuring that the year is never a three-digit value.

For more information on Y2K issues, contact Recognition Systems.



Blank page.



8.0 GlossaryAmnesty Punch – A punch made by a supervisorial person for a user that allows the user to override a user limit programmed within the Hand Geometry Units.

Data Communications Equipment (DCE) – DCE devices send output data onto the RX line and DTE devices receive data on the RX line. Typically, computers are DTE and modems are DCE. See Data Terminal Equipment.

DCE – See Data Communications Equipment.

Data Terminal Equipment (DTE) – DTE devices output data onto the TX line and DCE devices receive data input on the TX line. Typically, computers are DTE and modems are DCE. See Data Communications Equipment.

DTE – See Data Terminal Equipment.

False Accept – a hand read that was verified and accepted under someone else’s template. See Threshold.

False Reject – a hand read that was rejected when compared to the correct enrollment template. See Threshold.

Function Key – Extra keys found on certain Hand Geometry Units that can be programmed to perform specific commands.

Handshaking – the ability of stations on a link to signal each other about their state of readiness to send or receive characters.

Holidays – days on which no one is normally allowed to gain access or punch in.

Identity Verification – validating the hand being shown matches the hand that has been enrolled for a given ID number. See Identification. All hand verifications must begin with an ID number that provides identity information.

Identification – attempting to determine, without any additional information, whose hand is being shown. See Identity Verification.

Score – A number that reflects how accurately a hand was read by a Hand Geometry Unit.

T&A – See Time and Attendance.

Time and Attendance – Hand Geometry Units that report employee attendance by tracking the time at which the employee punches in and out.



Time Interval – an identified start/stop period of time in which punching in is restricted.

Time Zone – a table internal to the HGU consisting of four time intervals and four day-of-the-week masks. See Time Interval.

Template – contains the most statistically significant information which distinguishes a hand from all other hands.

Threshold – a score value that is used to determine if a hand read is accepted or rejected. See False Accept and False Reject.

Transaction Log – A data file made up of a listing of all events that have occurred at a Hand Geometry Unit.

Verification – See Identity Verification.



9.0 Appendices

9.1 CRC Generator ProgramThe following C functions create and use a CRC lookup table. The output of this program is text for a statically initialized array that you may include in your program. The test cases verify that the lookup function works.

#include <stdio.h>

static unsigned table[256];

void PrintTable(void);void BuildXMODEM(void);unsigned XMODEMcrc(unsigned char byt, unsigned crc);unsigned crc_buf(unsigned char *buf, unsigned length, unsigned crc);

void main(void)

unsigned crc;

printf("/* XMODEM crc table */\n");BuildXMODEM(); /* Do this only once. No need to do this at all if the

array is statically initialized. */PrintTable();

crc = 0;/* It is important to initizlize the CRC! */crc = XMODEMcrc('M', crc);if (crc != 0x9969)

printf("Test case 1 failed. crc = %04X.\n", crc);

crc = 0;crc = XMODEMcrc('T', crc);if (crc != 0x1A71)

printf("Test case 2 failed. crc = %04X.\n", crc);

crc = 0; crc = XMODEMcrc('T', crc); crc = XMODEMcrc('H', crc); crc = XMODEMcrc('E', crc); if (crc != 0x1E0A) printf("Test case 3 failed. crc = %04X.\n", crc);

crc = 0;crc = crc_buf("1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ", 36, crc);crc = crc_buf("abcdefghijklmnopqrstuvwxyz!@#$%^&*()", 36, crc);if (crc != 0xA18A)printf("Test case 4 failed. crc = %04X.\n", crc);

void PrintTable(void)/* Print the table for including in a C program. */

int i;



printf("unsigned table[256] = \n\n");for (i=0; i < 256; I++)

if ((i % 8) == 0)putchar('\t');

printf("0x%04X, ", table[i]);if (((i+1) % 8) == 0)

putchar('\n');printf(";\n\n");

void BuildXMODEM(void)/* Initialize the table at run-time */

int i;unsigned char z;

for (i=0; i < 256; I++)

z = i ^ (i >> 4);table[i] = z ^ ((unsigned)z << 5) ^ ((unsigned)z << 12);

unsigned XMODEMcrc(unsigned char byt, unsigned crc)/* Update the CRC with a new byte */

crc = (crc << 8) ^ table[byt ^ (crc >> 8)];return crc;

unsigned crc_buf(unsigned char *buf, unsigned length, unsigned crc) /* Calculate the crc of a buffer full of characters */

while (length--)

crc = XMODEMcrc(*buf, crc);buf++;

return crc;



9.2 PC Serial Port PinoutsFor convenience, the RS-232 serial port pinouts for the 25-pin and 9-pin connectors are shown in Table 52.

9.3 RS-232 Electrical SpecificationA complete specification of RS-232 is beyond the scope of this manual. The data in Table 53 is an excerpt from the RS-232 standard which may be useful for troubleshooting and development work. Refer to the EIA standard for more information. The HGU uses RS-232 line drivers which conform to this standard.

The term “Mark” is often used to refer to the negative voltage, ‘1’ condition, while “Space” refers to positive voltage or ‘0’.

9.4 RS-422/RS-485 Electrical SpecificationA complete specification of RS-422 is beyond the scope of this manual. The data in Table 54 on page 262 is an excerpt from the specification which may be helpful for troubleshooting and development work. Refer to the RS-422 standard for more information. All models of HGU use RS-422/485 line drivers which meet or exceed this standard.

Table 52: RS-232 Port Pinouts

Function 25-Pin 9-Pin

CD 8 1RX (DCE to DTE) 3 2TX (DTE to DCE) 2 3DTR 20 4GND 7 5DSR 6 6RTS 4 7CTS 5 8RI 22 9

Table 53: Some Important RS-232 Electrical Specifications

Parameter Specification

Driver Output Voltage -5V to -15V for 1, +5V to +15V for 0Receiver Input Voltage -3V to -15V for 1, +3V to +15V for 0Data Rate Up to 20Kbps, for 3K<RL<7K and CL<2500pF.



Note that the allowable common mode voltage range is not very large. A common souce of damage to units is having two units with very different ground potentials connected through the RS-422 lines. This large common mode voltage can damage the RS-422 drivers. While the RS-422 drivers are designed to handle common mode noise, they are not intended to be an electrical isolation. It is strongly recommended that systems be designed to prevent large differences in the ground potentials of units.

9.5 Hand Reader DIP Switch Settings for RS-422/RS-485 ConnectionFor Model E and Model F units, set SW3 OFF for RS-422 communications and ON for RS-482 communications. The termination resistors are switched into the circuit by putting SW1 and SW2 ON. This is recommended for long cable lengths (in excess of 4000 feet) and should only be done at the two units which are at the physical ends of the cable.

Table 54: Some Important RS-422/485 Electrical Specifications

Parameter Specification

Output voltage 2V min at 50 ohms, 1.5V min at 27 ohms. 5V maxData rate The HGU is software-limited to 19200 bps for reliable

communications. This is not a limit of the RS-422 specification.

Cable length 4000 feet.Cable type Wide variety is acceptable. Preferably AWG22-28,

twisted pair.Stub length 6”. Preferably, zero. The best thing is to make the stub

connection at the HGU terminal stripsNumber of drops 32. Some units have 1/4 load drivers and can support

more drops. Contact RSI for more details if necessary.Termination resistance Depends on cable. For AWG28 twisted pair, typically 120

ohms.Common mode voltage -7V to +12V relative to local ground



9.6 Card Reader InterfaceThe Hand Geometry Units support card reader input and output in a wide variety of standard and custom formats, as described briefly in Section 2.3.11 on page 20. Here, the electrical timing specifications for the Wiegand and MagStripe formats will be described. In addition, the data format for the two “standard” formats that units are shipped with is given.

9.6.1 Wiegand

9.6.1.1 DescriptionAlthough the actual Wiegand card technology is used less frequently now than in the past, the data interface is widely used by a variety of card technologies, including proximity, bar code, and even some magnetic stripe systems. A Wiegand data interface consists of two signals and a ground line. The two signals are labeled ‘0’ and ‘1’. A pulse on the ‘0’ line indicates a 0 in the bit stream, and a pulse on the ‘1’ line indicates a 1 in the bit stream. The signals are normally high, and a data pulse brings the line low momentarily.

9.6.1.2 Input TimingThe HGU will respond to a falling edge on an input line within 2 µs and needs the lines to remain stable for about 2 µs after this. Often, the Wiegand data stream is generated artificially, rather than by a direct swipe of an actual Wiegand card. Most systems generate pulses much wider than these timing rates, so the HGU should have not trouble receiving a Wiegand data stream from the vast majority of devices currently on the market.

The HGU considers the incoming card data stream to be terminated when 300 ms elapses without another incoming bit being received. The HGU does not require and does not accept any sort of Card Present input.

9.6.1.3 Output TimingThe precise timing of the HGU outputs varies with the exact model and firmware revision, but typically the design objectives are 100 µs wide pulses that are spaced 1 ms apart (measured leading edge to leading edge). No units have shorter pulse spacings or pulse widths which differ by more than 5% from this. However, some units have pulse spacings which may be as long as 1.2 ms.

9.6.1.4 Data FormatUnits which are shipped with the “default” Wiegand card format are configured to accept and emit a 26-bit Wiegand data stream. The first bit is parity, the next 8 are the site code, followed by a 16-bit ID number, then another parity bit. This is referred to by Recognition Systems as “Wiegand 8-26,” and units may show this on the LCD at startup. The parity bits are not checked in the default Wiegand card format.



9.6.2 MagstripeA MagStripe data interface consists of two signals and a ground line. The two signals are labeled Clock and Data. Both signals are normally high. Low-going pulses on the Clock line indicate that the data line should be sampled.

9.6.2.1 Input Timing and LevelsTypically, the HGU card reader input is connected to the output of an actual magnetic stripe card reader (as opposed to a simulated source of magstripe data such as the HGU outputs). Both motor-swiped and manually swiped magnetic stripe cards will have data rates which vary with the speed of the swipe. Typical data rates range from 200 µs per bit to 20 ms per bit for cards swiped by a human hand. Clock pulse times are typically one third to one half the clock period. The HGU can easily accept signals in this range of speeds.The HGU samples the data on the falling edge of the input Clock signal. Typically, the HGU can acquire the data signal within 1-2 µs after the Clock line goes low and requires the data line to remain stable for another 1-2 µs. Since even the fastest swipes give clock pulses at least fifty times this long, it is very unlikely any swiped card reader will exceed the HGU speed limitations. (The ABA Track 2 standard specifies a recording density of 75 bits per inch, so in order to exceed the input timing capabilities of the HGU, the card would have to move nearly 400 miles per hour!)

The HGU considers the incoming card data stream to be terminated when 300 ms elapses without another incoming bit being received.

The HGU does not require and does not accept any sort of Card Present indication.

9.6.2.2 Output Timing and LevelsThe precise timing of the output of the HGU will vary with model and the exact date of shipment, but the timings shown in Table 55 cover most models. These times were selected to be similar to a typical, comfortable, human card swipe and most systems should be able to handle them.

Table 55: HGU MagStripe Output Timing Values

Parameter Symbol Time

Clock Period TCLK 750-850 µs

Clock Low Time TLO 250-450 µs

Clock High Time THI 400-550 µs

Data Setup to Clock Edge TDSU 200-250 µs

Data Hold from Clock Edge TDHD 200-250 µs



HGU Mag Stripe Output Timing Diagram

Although most magstripe receiver systems use the falling edge of the Clock signal to sample the data, the shapes of the timing pulses from the HGU is designed to allow a receiver to use either the rising or falling edge of the Clock pulse to sample the data with equal setup and hold times. Any transitions on the data signal will happen in the middle of the Clock high time.

9.6.2.3 Data FormatThe HGU uses the usual ABA-Track 2 MagStripe format conventions. These are specified in ANSI X4.16, later adopted as ISO 7811. Please refer to those specifications for details on the encoding of MagStripe data.

The ID number starts when the start sentinel character (hex B) is detected and ends when the end sentinel character (hex F) is detected. The HGU expects and checks all character parity bits and the terminal LRC on input and will correctly supply them on output. Fields terminated by the field separator character will be ignored. If the FS character is used, the last field terminated by the end sentinel will be the one taken as the ID number. As in all other cases, ID numbers can be no longer than 10 digits.

When outputting an ID, the HGU will not use the field separator character, only the start and end sentinels. The ID will contain the same number of digits that were received or entered at the keypad.



9.6.3 Hand Punch 4000 Integrated Bar Code SensorThe HandPunch 4000 has a built-in infrared bar code sensor. The HP-4000 bar code decoder can read standard Code 3 of 9 and Interleaved 2 of 5 encodings. Please refer to the standards for these formats for all information on encoding, bar widths, and optical properties. The standards are available from AIM USA, 634 Alpha Drive, Pittsburgh, PA, 15238. In addition, ANSI X3.182, “Bar Code Print Quality Guildeline” contains very useful information on printing bar codes and testing their optical quality. It is strongly suggested that customers who will be printing their own bar code cards obtain and adhere to the standards.

The requirements for the HP-4000 system will be described here.

9.6.3.1 Symbologies and the ID NumberThe HP-4000, like all Hand Geometry Units, supports an ID number up to ten digits long. If a bar code symbol contains more than ten digits, the first ten are used and the remaining digits are ignored. There is an exception for ID numbers which contain exactly eighteen digits: These will be interpreted according to the Kronos badge format, which contains a seven-digit ID with particular leading and trailing digits. All eighteen-character bar code symbols in any symbology will be assumed to be of this type. Customers who need an eighteen-digit symbol interpreted differently should contact Recognition Systems to discuss developing customized decoder software.

Each symbol must contain a minimum of four characters. For Code 3/9 symbols, this includes the start and stop characters, so a minimum of two digits of ID can be used.

9.6.3.2 Basic Symbol GeometryThe symbol must be located no more than 0.2” from the edge of the card and must be at least 0.3” high. The quiet zones described in the AIM standards must be adhered to. The minimum width for a bar or a space is 6 mils. The Wide-to-Narrow ratio must be at least 2.0, but no more than 4.0. Typically, the best results are realized with W/N ratios from 2.2 to 3.0. Any element more than four times wider than any adjacent element is interpreted by the HP-4000 as indicating the end of the data stream.

9.6.3.3 Uniformity of WidthsThere will always be some tolerance of the widths of the bars and spaces since no printing system is absolutely perfect. However, when the narrow elements get too wide, or the wide elements get too narrow, it becomes impossible to decide which is which. The ANSI specifications for I 2/5 and Code 3/9 both define a similar procedure for classifying wide and narrow elements which can be briefly described as follows. The total width of all elements in a character is calculated, then divided by the number of elements ni a character. This gives an estimate of the so-called X-dimension, which is basically the average narrow width. Elements more than 1.5 times this wide are classified as wides; those less than 1.5 times this wide are classified as narrows. The HP-4000 decoder follows this basic procedure. Therefore, no narrow element can be



more than 1.5 times the width of the character’s X-dimension, and no wide element can be less.

For reliable scans with the HP-4000, this restriction must be followed.A common source of trouble with this specification is due to ink bleeding. This causes the bars to be wider than the spaces as the ink which defines the bars bleeds into the areas that are supposed to be spaces.

9.6.3.4 Optical CharacteristicsAny bar code scanner must be able to tell the bars apart from the spaces. Bars are defined as regions where little light is reflected; spaces are regions where relatively more light is reflected. The difference between the bars and spaces is the contrast. This is usually expressed numerically as the “Print Contrast Signal” or PCS value. PCS is the difference between the bar and space reflectivity, expressed as a percentage of the space reflectivity. The HP-4000 requires a PCS value of at least 0.3 for reliable reads.

Note that printing which appears to the human eye to have high contrast may appear very poor to the bar code scanner, and vice-versa. This may be due to the fact that the bar code scanner operates with infrared light, which is invisible to the human eye. It may also be due to the fact that often bar code cards are printed with an ink which is very black, but also very shiny. This shininess actually reduces the contrast.

9.6.3.5 DefectsDefects are blemishes in the printing. For example, a spot of ink appearing inside a space is a defect. Obviously, this kind of thing can make it totally impossible to read a bar code, depending on how big the defect is and exactly where it is located. The HP-4000 cannot tolerate any kind of defect within the symbol location defined above.

9.6.3.6 Symbol GradeThe ANSI specification provides an elaborate scheme for grading bar code symbols. Obtaining the grade for a symbol requires specialized equipment and the HP-4000 cannot provide the symbol grade itself. Recognition Systems has the equipment necessary to determine a symbol grade will provide the grade for a set of card samples on request. The HP-4000 will scan virtually all cards with a grade of “C” or better. However, a lower grade does not mean a card cannot be scanned, and some cards with a grade of “F” are quite readable. However, for best performance and reliability, RSI encourages customers who are printing their own bar code cards to attempt to attain a symbol grade of at least “C” for use with the HP-4000.



9.6.3.7 Specifications Summary

Table 56: HP-4000 Integrated Bar Code Reader Specifications

Characteristic Value

Resolution 6 milsWavelength 890 nmPCS value > 0.3Scan speed 150 to 2000 mm/secW/N ratio 2.2 to 3.0 recommended, must be 2.0 to 4.0Symbol Grade ANSI grade “C” or better recommended



10.0 IndexAAmnesty Punch, 71Ancillary Commands

Abort, 94Beep, 96EmitKeypadTestData, 101EnterIdleMode, 103EnterIdleMode2, 104HereIsBankNumber, 106LEDControl, 118NextMessageIsBellScheduleTable, 119NextMessageIsTimeZones, 120Resume, 125SendInternalErrorLog, 132UpdateNVRAM, 149

Auxiliary Keypad, 254

CCommand

AbortCommand, 94AddUserMessage, 95Beep, 96Calibrate, 97ClearUserDatabase, 98ClearUserMessages, 99DisplayCodedMessage, 100EmitKeypadTestData, 101EnrollUser, 102EnterIdleMode, 103EnterIdleMode2, 104HereAreTimeZones, 105HereIsBankNumber, 106HereIsBellScheduleTable, 107HereIsDataBank, 108HereIsDecisionMenuData, 109HereIsDisplayMessage, 110HereIsExtendedSetup, 112HereIsExtendedUserRecord, 113HereIsSetup, 114HereIsSmartCardRecord, 115HereIsTime, 116HereIsUserRecord, 117LEDControl, 118

NextMessageIsBellScheduleTable, 119NextMessageIsTimeZones, 120OutputControl, 121PrinterPassThrough, 122RemoveUserMessages, 123RemoveUserRecord, 124Resume, 125SendCalibrationData, 126SendDataBank, 128SendDatalog, 129SendExtendedSetup, 130SendExtendedUserRecord, 131SendInternalErrorLog, 132SendKeypadData, 133SendLastUserRecord, 135SendOEMCode, 136SendPreviousDatalog, 137SendReaderInfo, 138SendResults, 139SendSetup, 140SendStatusChecksum, 141SendStatusCRC, 142SendTemplate, 143SendTimeAndDate, 144SendTimeZones, 145SendUserRecord, 146SetExtendedUserData, 147SetUserData, 148UpdateNVRAM, 149VerifyOnExternalData, 150VerifyOnInternalData, 151

CommandsAncillary, 82Configuration, 81Enrollment, 79Function Key, 82Hardware Control, 81HP-4000 ONLY, 82Maintenance, 81Results, 80SendCardData 127Special, 82Status Functions, 79



Transaction Log Management, 81Undocumented, 82User Database Backup, 80User Database Management, 80

Commands, 93Commands, Hand Verification, 80Communication

Ethernet, 30Modem, 29RS-232, 27RS422/RS-485, 28

Communication Protocol, 36Configuration Commands

HereAreTimeZones, 105HereIsBellScheduleTable, 107HereIsExtendedSetup, 112HereIsSetup, 114HereIsTime, 116SendExtendedSetup, 130SendSetup, 140SendTimeZones, 145

Connector PinoutsModel E, 245Model F, 246

Connector Pinouts, 245Controlling Outputs, 64CRC Generator Program, 259

DData Communications Equipment, 27Data Structure

BasicSetupData, 173BasicUserRecord, 181BellSchedule, 182Datalog, 183DOW Mask, 184ExtendedSetup

DataAux Output 1 Timezone, 187DataAux Output 2 Timezone, 187

ExtendedSetupDataAux Output 1 Clear, 187Aux Output 1 Control Flags, 187Aux Output 1 Time, 187Aux Output 2 Clear, 187Aux Output 2 Control Flags, 187

Aux Output 2 Time, 187Aux Output Control Flags, 186Auxiliary Keypad Control, 188Card Digits, 190Date Format, 189Default FKey Masks, 190Grace Value, 191HandPunch IO Datalog Flag, 187Language Type 2, 190Language, 188Ready String, 186Ring Count, 189Ring Delay, 190Ring Timeout, 189Rule Flags, 191Rule Value, 191Serial Mode, 186Time Scale, 188

ExtendedSetupData, 185ExtendedUserData, 192ExtendedUserRecord, 193HolidayTable, 194PackedTimeInterval, 196TimeZone, 195

Data StructuresBasicSetupData

24-Hour Time Flag, 180Accounting Mode, 178Aux Alarm Flags, 176Aux Duress Flag, 179Aux Flag Clear, 175Aux Timeout, 175Aux Timezone, 178Beeper Flag, 178Daylight Savings Time Off, 179Daylight Savings Time On, 179Duress Character, 179Facility Code, 177HGU Address, 177ID Length, 178Lock Time, 176Network Baud Rate, 176Number of Tries, 179Operating Mode, 177Option Flags, 180



Output Mode, 178Password, 175Print Flag, 175Printer Baud Rate, 176Shunt Time, 176Status Flag, 176Threshold, 175Unlock Timezone, 178

Data Terminal Equipment, 27Datalog Formats

Function Key Data Collection Datalogs, 201

GenerationAccess Denied, 207Access Refused - Time Restriction, 213Amnesty Punch Granted, 212Authority Level Changed, 212Aux Out Setup Changed, 211Aux Output Off, 214Aux Unlock via Wiegand Keypad, 214Auxiliary Input On, 208Auxiliary Output On, 209Baud Rate Changed, 209Command Mode Entered, 207Command Mode Exited, 208Door Forced Open, 208Door Open Too Long, 211Duress Alarm, 213Exit Granted, 207Extended Datalogs, 211Global Restrictions Changed, 214ID In Memory, 215ID Length Changed, 213ID Not In Memory, 215Identity Unknown, 207Identity Verified, 207Lock Output Off, 214Lock Output On, 214Lock Setup, 210Messages Read, 209Operating Mode Changed, 212Passwords Changed, 210Printer Setup Changed, 211Reject Override Changed, 212Reject Threshold Set, 210

Request to Exit Activated, 208Site Code Changed, 210Special Enrollment, 214Supervisor Override, 208System Recalibrated, 208Tamper Activated, 208Time and Date Set, 210Time Zone Data Changed, 213Transaction Buffer Empty, 206Unit Address Changed, 209User Database Cleared, 213User Database Restored, 212User Database Saved, 212User Enrolled, 206User Removed, 207User Time Zone Changed, 213Users Listed, 212

Generation, 205GenerationOutput Mode Changed, 213Supervisor Override, 202TA Codes, 199Time and Attendance ID Verified Datalogs,

200Datalog Formats, 199DCE, 27DLL Manual, 10Documents

DLL Manual, 10Function Key Compiler Manual, 10Product Manuals, 11

Door Control, 61DTE, 27Duress Code, 255

EEnrollment Commands

EnrollUser, 102HereIsSmartCardRecord 115

Enrollment, 55Errors

Model, 253



FFalse Accept, 17False Reject, 17Function Key Compiler Manual, 10Function Key Menu Commands

HereIsDecisionMenuData, 109Function Key Menu, 66

GGrounding

Earth Ground, 33Floating Power Supplies, 32

Grounding, 31

HHand Geometry Unit

Applications, 25Card Reader Interface

Bar Code, 266Magstripe, 264Wiegand, 263

Card Reader Interface, 20, 263Command Mode, 17Command Protocol, 24Communication

Ethernet, 23Modem, 23RS-232, 22RS-422/RS-485, 23TCP/IP, 23

Communication, 22Description, 13DIP Switch Settings, 262Door Control, 19Events and States, 19Function Keys, 19ID Entry, 18Inputs, 20Memory, 20Operating Mode, 17Outputs, 20Power Management, 21System Configuration, 21Time Restrictions, 19Transaction Log, 18

User Database, 18Verification, 18

Hand Geometry Unit, 13Hand Verification

Failed, 59Successful, 59

Hand Verification CommandsVerifyOnExternalData, 150VerifyOnInternalData, 151

Hand Verification, 59Hardware Control Commands

DisplayCodedMessage, 100HereIsDisplayMessage, 110OutputControl, 121PrinterPassThrough, 122

Holidays, 58HP-4000 Commands

AddUserMessage, 95ClearUserMessages, 99HereIsExtendedUserRecord, 113RemoveUserMessages, 123SendExtendedUserRecord, 131SetExtendedUserData, 147SetUserData, 148

IIdentification, 16Identity Verification, 16

LLCD Character Map, 249

MMaintenance Commands

Calibrate, 97SendCalibrationData, 126

Model Errors, 253

PPC Serial Port Pinouts, 261Product Manuals, 11Pseudo-code, 217



RReal Time Clock, 77Receiver State Machine, 40Reset Behavior, 250Responses

HereAreResults, 154HereAreTimeZones, 155HereIsCalibrationData, 156HereIsCardData 157HereIsDataBank, 158HereIsExtendedSetupData, 159HereIsExtendedUserRecord, 160HereIsKeypadData, 161HereIsMyTime, 162HereIsNextDatalog, 163HereIsOEMCode, 164HereIsReaderInfo, 165HereIsSetupData, 167HereIsStatus, 168HereIsTemplateVector, 170HereIsUserRecord, 171UnableToCompleteCommand, 172

Results Buffer, 56Results Commands

SendLastUserRecord, 135SendResults, 139SendTemplate, 143

RS-232 Electrical Specification, 261RS-422/RS-485 Electrical Specification, 261

SScore, 63Shielding - See Grounding 31Standard Operation

Adding Users, 221Changing User Data, 223Checking Status, 218Complete Unit Backup, 234Function Key Menus, 241HP-4000 Only, 242Remote Enrollment, 224Remote Verification, 225Removing Users, 223Retrieving Transactions, 226Turning Outputs On or Off, 225

Unit SetupClock, 221Time Zones, 221

Unit Setup Data, 219Unit Setup, 218User Database Backup and Restore, 230

Standard Operation, 217Status Commands

SendStatusChecksum, 141SendStatusCRC, 142

Status Functions CommandsSendCardData 127SendKeypadData 133SendOEMCode, 136SendReaderInfo, 138SendTimeAndDate, 144

TTemplate

Score, 63Template Buffer, 56Template, 16, 63Threshold Level

False Accept, 17False Reject, 17

Threshold Level, 17Time Intervals, 58, 69Time Zones, 58Transaction Log, 63Transactions Log Management Commands

SendDatalog, 129SendPreviousDatalog, 137

Troubleshooting Modes, 74

UUser Background, 9User Database Backup Commands

HereIsDataBank, 108SendDataBank, 128

User Database ManagementSendUserRecord, 146

User Database Management CommandsClearUserDatabase, 98HereIsUserRecord, 117RemoveUserRecord, 124



YY2K Issues, 255
