Hand Geometry Unit Technical Manual

ATR Systems, Inc. Tel 215.443.8720 Fax 215.443.8709 info@HandPunch.com 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 users 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 RESERVED Document 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.

Hand Geometry Unit Technical Manual Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Scope of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 User Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Organization of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Other Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 DLL Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Function Key Compiler Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Operations Manual for Specific Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Notational Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 How Commands and Responses are Named . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Introduction to Hand Geometry Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Descriptions of Hand Geometry Unit Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 HandPunch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 HandPunch Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 HandKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 HP-2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HP-3000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HP-4000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HK-II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HK-CR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Introduction to Hand Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Verification Versus Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Basics of HGU Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Threshold Levels: False Accept and False Reject Considerations . . . . . . . . . 17 Basic Concepts of HGU Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Operating Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Command Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 ID Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Transactions Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Time Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Events and States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Door Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Card Reader Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Other Outputs and Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 System RAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 NV-RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Revision 2.7

Page 1

Hand Geometry Unit Technical Manual System Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Operation Without a Host Computer System . . . . . . . . . . . . . . . . . . . . . . 22 HGU Does Host-Initiated Verifications . . . . . . . . . . . . . . . . . . . . . . . . . . 22 HGU Just Returns Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Host Polls for ID Entry but Makes the Access Decision . . . . . . . . . . . . . 22 Introduction to HGU Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Physical Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Networks: RS-422 and RS-485. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Ethernet and TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Overview of the Command Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Typical Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Access Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Time and Attendance Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Communicating with an HGU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Physical Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Notes on Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Networks: RS-422 and RS-485. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Masters and Slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 HGU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Connection to an HGU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Regarding Ethernet Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 HGU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Connection to an HGU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Grounding and Shielding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Preliminary Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Regarding Ground Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Regarding Model F Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Systems with Floating Power Supplies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Earth Ground All Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Carry a Ground Line to Each Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Grounding with Grounded Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Choice of Cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Character Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Handshaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Page 2

Revision 2.7

Hand Geometry Unit Technical Manual Start of Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Frame Check Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Pre-Frame and Post-Frame Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Character Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Packet Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Packet Start Timeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Receiver State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 False Starts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Data Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Communication in High-Level Languages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Structure Alignment, Byte Ordering, and Packing . . . . . . . . . . . . . . . . . . . . . 44 Bit-Level Maniuplations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Controlling a Data Converter (DC-101/102) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Network Side Transmitter Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 RS-422 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 RS-485 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Notes for Windows Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Windows and RS-485 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Windows NT and DOS Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Programming your Modem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Select the Right Baud Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Other Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Setting Up an Ethernet Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Gateways and Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Notes Regarding DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Troubleshooting a Communication Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Configuring a Unit for Serial Communications . . . . . . . . . . . . . . . . . . . . . . . 50 Model E HandPunch Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Model E HandKey Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Model F Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Revision 2.7

Page 3

Hand Geometry Unit Technical Manual Hand Geometry Unit Inner Workings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 What Happens When an ID is Entered for Verification . . . . . . . . . . . . . . . . . . . . 55 Results Buffer and Template Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Results Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Template Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Validation of the ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Time Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Holidays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 HP-4000 Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Hand Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Successful Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Failed Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Obstructed Image Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Inability to Read Hand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Template Does Not Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 ID Lockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Door Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Templates and Scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Transactions Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Setup Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Events Controlling Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Controlling a Bell HandPunch Units Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Function Key Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Transactions Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Retrieving Decision Menu Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 ID First, ID Last, Data Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Explicit Punch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Other Special Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Explicit Punch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Department Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Command Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 HP-4000 Only Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 The Message Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Sending Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Removing Messages for a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Clearing the Entire Message Pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 How to Know When a User Has Read All Pending Messages. . . . . . . . . 69 Order of Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 User Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Page 4

Revision 2.7

Hand Geometry Unit Technical Manual Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Values in a Time Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Calculating Start and Stop Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Active and Inactive Time Intervals Current and Non-Current Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Stop Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Midnight Crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Packing Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Amnesty Punches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Reconciliation of Time Restriction Controls . . . . . . . . . . . . . . . . . . . . . . . . . 71 Restricting User Access to Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Contents of the Extended User Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Extended User Data Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Managing the Extended User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Deleting Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Setting Only the XUD Portion of an Extended User Record . . . . . . . . . . 73 Setting Only the User Data Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Retrieving a User Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Compatibility with Model E User Record Commands . . . . . . . . . . . . . . . . . . 74 HereIsUserRecord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 SendUserRecord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 RemoveUserRecord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Special Troubleshooting Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 The Status Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Model E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Model F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 New Features for Model F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 The Troubleshooting Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Modem Debug Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Display Message Code Output Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Real-Time Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Commands, Responses and Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Functional Groupings of Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Status Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Hand Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 User Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 User Database Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Transactions Log Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Revision 2.7

Page 5

Hand Geometry Unit Technical Manual Hardware Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Ancillary Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Function Key Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 HP-4000 Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Special Commands and Undocumented Commands . . . . . . . . . . . . . . . . . . . 82 Command and Response Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Datalog Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 TA Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Time & Attendance ID Verified Datalogs . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Function Key Data Collection Datalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Supervisor Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Datalog Format Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Examples of Standard Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Checking Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Unit Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Setup Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Command Menu Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Door Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Auxiliary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Time Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Where Will IDs Be First Entered Into the System? . . . . . . . . . . . . . . . . . . . 221 When and Where Will the Enrollment Happen? . . . . . . . . . . . . . . . . . . . . . 222 To Which Units Will Users Be Distributed? . . . . . . . . . . . . . . . . . . . . . . . . 222 How Will Templates Be Updated? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Removing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Changing User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Remote Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Remote Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Turning an Output On or Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Retrieving Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 The Basic Methods of Retrieving Transactions . . . . . . . . . . . . . . . . . . . . . . 226 Handling Communication Errors Without Losing Datalogs . . . . . . . . . . . . 226

Page 6

Revision 2.7

Hand Geometry Unit Technical Manual Handling Menu-Initiated Punches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 When Does Data Collection Terminate? . . . . . . . . . . . . . . . . . . . . . . . . 228 Identifying HP-4000 Custom Data Viewing Versus Actual Punching. . 229 Firmware Dated After 4/18/2000 PROM Revision 60 . . . . . . . . . . . . 229 Firmware Dates Prior to 4/18/2000 PROM Revisions 59 and Earlier. 229 User Database Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Idle Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Complete Backup of an Entire Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Examples of Packing and Unpacking Binary Data Fields . . . . . . . . . . . . . . . . . 235 High Bit in Type Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 User Record Authority Field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 HP-4000 Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 DOW Masks for Time Zones and Time Intervals . . . . . . . . . . . . . . . . . . . . 238 Holiday Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Bell Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Function Key Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Reverting to Cleared State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Marking the Beginning and End of Data Collection . . . . . . . . . . . . . . . . . . 241 Modification to Hand Verification Datalog . . . . . . . . . . . . . . . . . . . . . . . . . 241 HP-4000 Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Adding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Removing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Clearing All. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 User Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Removing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Sending Only the Extended User Data to an Existing User Record . . . . 243 Sending Only the Data for Function Key Menu Display . . . . . . . . . . . . 243 Retrieving a User Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Miscellaneous Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Connector Pinouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Model E Terminal Strips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Model F Terminal Strips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Model F Additional Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 RJ-45 RS-232 Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 RJ-11 RS-422/RS-485 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 RJ-45 Ethernet Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Power Connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 LCD Character Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Behavior on Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Revision 2.7

Page 7

Hand Geometry Unit Technical Manual Types of Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Data Displayed on Reset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Model F Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Model E Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Additional Reset Display Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Reset Datalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Firmware Dates 4/26/99 to 4/19/00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Firmware Dates 4/20/00 and Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Data Integrity Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Model Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Auxiliary Keypad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Duress Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Y2K Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 CRC Generator Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 PC Serial Port Pinouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 RS-232 Electrical Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 RS-422/RS-485 Electrical Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Hand Reader DIP Switch Settings for RS-422/RS-485 Connection . . . . . . . . . 262 Card Reader Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Wiegand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Input Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Output Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Magstripe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Input Timing and Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Output Timing and Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Hand Punch 4000 Integrated Bar Code Sensor . . . . . . . . . . . . . . . . . . . . . . 266 Symbologies and the ID Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Basic Symbol Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Uniformity of Widths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Optical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Defects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Symbol Grade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Specifications Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Page 8

Revision 2.7

Hand Geometry Unit Technical Manual

1.0
1.1

Introduction
Scope of this Manual
This 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 Background
It 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 ones 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 Manual

This 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

Hand Geometry Unit Technical Manual 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/RS485 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
1.4.1

Other Related Documents

DLL Manual
Recognition 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 Manual

If 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

Hand Geometry Unit Technical Manual

1.4.3

Operations Manual for Specific Products

This 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 Conventions
Numbers 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 Named

Commands 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

Hand Geometry Unit Technical Manual

Blank page.

Page 12

Revision 2.7

Hand Geometry Unit Technical Manual

2.0

Introduction to Hand Geometry Units

This 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 Models

The 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

HandPunch
This 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 Plus
This 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

HandKey
This 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.

Revision 2.7

Page 13

Hand Geometry Unit Technical Manual

2.1.4

HP-2000
The 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-3000
The 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-4000
The 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 users names can be shown when they punch as well. Data can be stored in a users 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-II
The 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-CR
The 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.

Page 14

Revision 2.7

Hand Geometry Unit Technical Manual

Table 1: Feature Summary Matrix

Feature User Capacity HP SA-256 SB-3,328 LA-9,728 LB-27,904 3,185 1 1 Yes Yes Yes No None n/a n/a No No HP-Plus SA-256 SB-3,328 LA-9,728 LB-27,904 3,185 1 1 Yes Yes Yes No 4 n/a n/a No No HP-2000 512 HP-3000 A-512 B-9,728 C-32,512 5,120 2 3 Yes Yes Yes No 2 No No No Optional HP-4000 B-530 C-3,498 HK SA-256 SB-3,328 LA-9,728 LB-27,904 3,185 1 1 Yes Yes No No None n/a n/a No No HK-II A-512 B-9,728 C-32,512 5,120 2 3 Yes Yes No No 2 No No No Optional CR A-512 B-9,728 C-32,512 5,120 0 2 (limited) No No No No 2 No No No Optional

Transaction Capacity Aux Inputs Aux Outputs Door Controls Time Restrictions Bell Schedule Messages Function Keys Validation Strings User Data Fields User Messages RS-232 Host Coms

5,120 0 0 No No Yes No 2 No No No Required

7,680 2 3 Yes Yes Yes Yes 10 Yes Yes Yes Optional

Revision 2.7

Page 15

Hand Geometry Unit Technical Manual

2.2
2.2.1

Introduction to Hand Geometry

Templates
All 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 LEDs, 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 Identification

Like 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 HGUs 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 Use

Before 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 persons 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.

Page 16

Revision 2.7

Hand Geometry Unit Technical Manual 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 Considerations

The 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 elses 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 Operations

In 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 Mode
The 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 Mode
In 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 communicationsrelated aspects of the HGU.

Revision 2.7

Page 17

Hand Geometry Unit Technical Manual 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 Database
As 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 users time zone, and another byte which holds both the users 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 Entry
To 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

Verification
Verification 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 Log
Every HGU maintains a record of all transactions that occur. These are sometimes referred to as datalogs. These will be fully explained in following sections.

Page 18

Revision 2.7

Hand Geometry Unit Technical Manual

2.3.7

Time Restrictions
One 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 zones 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 Keys
The 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 States

A 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 HGUs behavior.

2.3.10

Door Controls
Frequently, 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.

Revision 2.7

Page 19

Hand Geometry Unit Technical Manual 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 Interface

Often, 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 Inputs

Depending 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
2.3.13.1

Memory
System RAM The 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 RAMs power to a lithium battery when main board power is lost. NV-RAM In 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 128byte 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.

2.3.13.2

Page 20

Revision 2.7

Hand Geometry Unit Technical Manual 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 Management
Hand 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 Configurations
Although 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.

Revision 2.7

Page 21

Hand Geometry Unit Technical Manual 2.3.15.1 Operation Without a Host Computer System Some 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. HGU Does Host-Initiated Verifications Some 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. HGU Just Returns Templates Other 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. Host Polls for ID Entry but Makes the Access Decision Finally, 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.3.15.2

2.3.15.3

2.3.15.4

2.4
2.4.1

Introduction to HGU Communications

Physical Connection
Four 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-232 This is the simplest physical connection between a host PC and a HGU. The PCs RS232 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.

Page 22

Revision 2.7

Hand Geometry Unit Technical Manual 2.4.1.2 Networks: RS-422 and RS-485 This 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 Modem Hand 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 HGUs through a modem link. This is mainly because the modems in the HGUs are answer-only, so there is no way to initiate a connection from a HGU. Ethernet and TCP/IP Hand 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.

2.4.1.4

Revision 2.7

Page 23

Hand Geometry Unit Technical Manual 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 Protocol

Regardless 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.

Page 24

Revision 2.7

Hand Geometry Unit Technical Manual

2.5
2.5.1

Typical Applications
Access Control Systems
One 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 Systems

In Time and Attendance systems, the two main objectives, aside from verifying peoples 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.

Revision 2.7

Page 25

Hand Geometry Unit Technical Manual 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.

Page 26

Revision 2.7

Hand Geometry Unit Technical Manual

3.0

Communicating with an HGU

This 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 HGUs through high-level languages. The last three sections describe details specific to establishing RS-422, modem, and Ethernet connections to HGUs.

3.1
3.1.1

Physical Connection
RS-232
Historically, 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 PCs TX line is connected to the HGUs RX line, and the PCs RX line is connected to the HGUs TX line. When the HGUs 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 Cables Please 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

Revision 2.7

Page 27

Hand Geometry Unit Technical Manual 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
3.1.2.1

Networks: RS-422 and RS-485

Masters and Slaves One 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 Topology The 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 Masters TX output is connected to the RX input of every slave. The slaves have all their TX outputs connected together, and to the Masters RX input. In other words, one channel is used for Master-to-Slave communication, and the other is used for Slave-to-Master communications.

Page 28

Revision 2.7

Hand Geometry Unit Technical Manual

3.1.3
3.1.3.1

Modem
HGU Configuration Hand 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 HGU The 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 well 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 HGUs TX lines, and their RX lines to the modem HGUs 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.

Revision 2.7

Page 29

Hand Geometry Unit Technical Manual

3.1.4
3.1.4.1

Ethernet
Regarding Ethernet Terminology Strictly 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. HGU Configuration As 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 units baud rate, either from the command menu or with the host setup data commands, will cause that units communication to stop working.

3.1.4.2

3.1.4.3

Connection to an HGU Like 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.

Page 30

Revision 2.7

Hand Geometry Unit Technical Manual

3.2

Grounding and Shielding

This is an extremely importantand often overlookedaspect 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

Introduction
Grounding 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
3.2.2.1

Preliminary Notes
Regarding Ground Connections Many 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

Revision 2.7

Page 31

Hand Geometry Unit Technical Manual 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 Supplies In 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 Supplies

A 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 HGUs 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

Page 32

Revision 2.7

Hand Geometry Unit Technical Manual 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 Units The first method of establishing a ground reference is to connect each units 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 loopslarge-area loops which provide a good coupling to external magnetic fieldswhich 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 daisychained 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 RS485 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 units GND is used for a particular shield, as long as the path is broken from unit to unit.

Revision 2.7

Page 33

Hand Geometry Unit Technical Manual 3.2.3.2 Carry a Ground Line to Each Unit The 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 buildings 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 largecurrent 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 units 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.

Page 34

Revision 2.7

Hand Geometry Unit Technical Manual

3.2.4

Grounding with Grounded Power Supplies

A 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 Cable
In general, best results will be realized with low-resistance, low-capacitance, lowinductance, 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 RXare 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.

Revision 2.7

Page 35

Hand Geometry Unit Technical Manual

3.3
3.3.1

Communication Protocol
Character Format
Regardless of the physical link, characters are always constructed as follows. 1 start bit 8 data bits No parity 1 stop bit

3.3.2

Handshaking
This 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 Rate
The 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 Format
In 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.

Page 36

Revision 2.7

Hand Geometry Unit Technical Manual Table 2: Communication Packet Format Field Start of Frame Address Type Length Data Frame Check Sequence 3.3.4.1 Description 0AH indicates the start of a packet the address to which the packet is being sent the command or response type the number of bytes in the data field the data being sent may be 0 bytes CRC or checksum

Start of Frame Every communication packet begins with the byte 0AH. Address Following 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.2

3.3.4.3

Type Every 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.

Revision 2.7

Page 37

Hand Geometry Unit Technical Manual 3.3.4.4 Length This 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 twobyte 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 Data This 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. Frame Check Sequence The 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 CRC The 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 Checksum The 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,

3.3.4.6

Page 38

Revision 2.7

Hand Geometry Unit Technical Manual 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 Padding

In 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
3.3.6.1

Timeouts
Character Timeout Once 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 Timeout There 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.

Revision 2.7

Page 39

Hand Geometry Unit Technical Manual 3.3.6.3 Packet Start Timeout The 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 Machine

In 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.

Page 40

Revision 2.7

Hand Geometry Unit Technical Manual

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.

Revision 2.7

Page 41

Hand Geometry Unit Technical Manual

3.3.8

False Starts
Since 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 Throughput
In 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.

Page 42

Revision 2.7

Hand Geometry Unit Technical Manual 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 modems 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
3.4.1

Communication in High-Level Languages

Binary Data
Communication 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

Revision 2.7

Page 43

Hand Geometry Unit Technical Manual 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 Packing

Many 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 highlevel 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 Maniuplations
In 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 fourbyte integer type. An example of this type of packing is the response to the

Page 44

Revision 2.7

Hand Geometry Unit Technical Manual 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 bitlevel 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
3.5.1

Controlling a Data Converter (DC-101/102)

Introduction
A 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 Control

The 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 sides 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 Network
For 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.

Revision 2.7

Page 45

Hand Geometry Unit Technical Manual

3.5.4

RS-485 Network
On 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 preframe 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
3.5.5.1

Notes for Windows Users

Windows and RS-485 Since 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 Programs The 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.

Page 46

Revision 2.7

Hand Geometry Unit Technical Manual

3.6

Programming your Modem

Although 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

Retry Expect 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. Select the Right Baud Rate Extensive 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.2

3.6.0.3

Other Suggestions If 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

Revision 2.7

Page 47

Hand Geometry Unit Technical Manual 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 Connection

The 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

Troubleshooting Diagnosing 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 Port The Ethernet adaptor has been programmed to use TCP port 3001.This is not adjustable.

Page 48

Revision 2.7

Hand Geometry Unit Technical Manual 3.7.0.3 Gateways and Subnet Masks The 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 HGUs 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 DHCP Please 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 networks 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 Link

Although 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.

Revision 2.7

Page 49

Hand Geometry Unit Technical Manual 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 PCs serial port. This can give a visual indication that data is being emitted by the PCs 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 PCs Ethernet port with normal cables. When the Ethernet connection is properly working, you should be able to ping the HGUs 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 Communications

When 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 units serial communication parameters.

3.8.1.1

Model E HandPunch Units The 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.

Page 50

Revision 2.7

Hand Geometry Unit Technical Manual 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 RS422/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 Units On 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.

Revision 2.7

Page 51

Hand Geometry Unit Technical Manual 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 units 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 Units The 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 ports 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.

Page 52

Revision 2.7

Hand Geometry Unit Technical Manual 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.

Revision 2.7

Page 53

Hand Geometry Unit Technical Manual

Blank page.

Page 54

Revision 2.7

Hand Geometry Unit Technical Manual

4.0
4.1

Hand Geometry Unit Inner Workings

Introduction
The 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

Enrollment
Enrollment 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 Verification

After 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.

Revision 2.7

Page 55

Hand Geometry Unit Technical Manual 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 Buffer

There 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 Buffer The 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. Template Buffer The 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

4.4.0.2

Page 56

Revision 2.7

Hand Geometry Unit Technical Manual 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 Number

The 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 units 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.

Revision 2.7

Page 57

Hand Geometry Unit Technical Manual

4.5.1

Time Zones
The 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 unitss clock must indicate that the current time is greater than or equal to the start time of at least one of the time zones 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

Holidays
Holidays 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 IDs 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 Intervals

The 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

Page 58

Revision 2.7

Hand Geometry Unit Technical Manual 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 Verification
Once 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 Verification
The 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 Verification
A 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 Area If there is an obstruction in the image area at the beginning of the verification process, the HGU first assumes the users 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.

Revision 2.7

Page 59

Hand Geometry Unit Technical Manual 4.6.2.2 Inability to Read Hand If 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 Match If 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 users 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 Lockout When 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.

Page 60

Revision 2.7

Hand Geometry Unit Technical Manual (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 Controls
Once 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

Revision 2.7

Page 61

Hand Geometry Unit Technical Manual 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

Page 62

Revision 2.7

Hand Geometry Unit Technical Manual

4.8

Templates and Scores

A 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 peoples hand geometry, the HGU will average each hand reading into a users 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 Log
All 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

Revision 2.7

Page 63

Hand Geometry Unit Technical Manual 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 Data
As 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 Outputs

The 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.

Page 64

Revision 2.7

Hand Geometry Unit Technical Manual Table 3: Auxiliary Output Events Event TAMPER TZVIOL IDREF DURESS AUXIN1 AUXIN2 DOOR TRYAGAIN F1KEY F2KEY POWER UNLOCK AUXKPD Models E+F F only E+F E+F E+F F only F only F only F only F only F only F only F only Description The tamper switch is activated A user is attempting to gain access or punch outside the authorized time An ID is locked out The duress code is entered at the keypad (see Section 7.5 on page 255) Aux Input 1 is activated Aux Input 2 is activated Either the door forced open or door open too long condition is active Score is out of range, user must re-enter ID The F1 key is pressed The F2 key is pressed The units external power is lost and it is running on battery power A hand was verified, access was granted An ID was received from the auxiliary keypad Model E Flag T none I Duress A none D none none none none none none

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 Only

HandPunch 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.

Revision 2.7

Page 65

Hand Geometry Unit Technical Manual

4.13

Function Key Menus

Model 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 Log
Data 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 Data

Function 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 Queue

Menus 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.

Page 66

Revision 2.7

Hand Geometry Unit Technical Manual 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 users 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 Punch
The 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
4.14.1

Other Special Modes

Explicit Punch
HandPunch 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 Code
On 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.

Revision 2.7

Page 67

Hand Geometry Unit Technical Manual

4.14.3

Command Mode
Command 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 units IP address, and possibly gateway and subnet mask information, which is under the Set Serial menu.

4.15

HP-4000 Only Commands

The 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

Messages
The 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 Pool Messages 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. Sending Messages To 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.2

Page 68

Revision 2.7

Hand Geometry Unit Technical Manual 4.15.1.3 Removing Messages for a User To remove all messages for a user, the RemoveUserMessages command is sent. There is no way to selectively remove particular messages. Clearing the Entire Message Pool The entire message pool is cleared by sending the ClearUserMessages command. How to Know When a User Has Read All Pending Messages Although 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. Order of Display Since 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.1.4

4.15.1.5

4.15.1.6

4.15.2

User Name
This 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 Intervals
As 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.

Revision 2.7

Page 69

Hand Geometry Unit Technical Manual 4.15.3.1 Values in a Time Interval The following data fields make up a time interval. The actual packing format is given on page 196. 4.15.3.2 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.

Calculating Start and Stop Minutes The 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 Intervals A 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 Time A 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. Midnight Crossing If 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.

4.15.3.5

Page 70

Revision 2.7

Hand Geometry Unit Technical Manual 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: 4.15.3.6 Monday 22:00 - 23:59 Tuesday 0:00 - 1:59 Tuesday 22:00 - 23:59 Wednesday 0:00 - 1:59

Packing Time Intervals Time 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 Punches
As 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 Controls

This 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.

Revision 2.7

Page 71

Hand Geometry Unit Technical Manual 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 Keys

Users 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
4.15.7.1

Contents of the Extended User Record

Terminology The 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 Fields A 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.

Page 72

Revision 2.7

Hand Geometry Unit Technical Manual 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 Database

The 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 Users User 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 Users User 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. Setting Only the XUD Portion of an Extended User Record It 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.3

Revision 2.7

Page 73

Hand Geometry Unit Technical Manual 4.15.8.4 Setting Only the User Data Field Since 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. Retrieving a User Record Analogous to the Model E command SendUserRecord is the HP-4000 command SendExtendedUserRecord. This command sends the complete XUR for the given ID.

4.15.8.5

4.15.9

Compatibility with Model E User Record Commands

There are three commands which operate on the databases of Model E units and nonHP-4000 Model F units. The HP-4000 has been designed to behave reasonably when sent these commands.

4.15.9.1

HereIsUserRecord A 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. SendUserRecord The 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. RemoveUserRecord This command works exactly the same on the HP-4000 as on any other product.

4.15.9.2

4.15.9.3

4.16
4.16.1

Special Troubleshooting Modes

The Status Display
The 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 units 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

Page 74

Revision 2.7

Hand Geometry Unit Technical Manual 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. Table 4: Poll Character Meanings Poll Character underscore 1 2 3 4 5 6 7 8 4.16.1.1 Meaning The last packet was received with no errors Timeout waiting for start of packet Timeout waiting for type field of packet Timeout waiting for length field of packet Timeout waiting for data field of packet Timeout waiting for CRC Invalid CRC received Timeout waiting for checksum, or invalid checksum Packet length exceeds receive buffer size (4096 bytes)

Model E The 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 bytes 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

Revision 2.7

Page 75

Hand Geometry Unit Technical Manual 4.16.1.2 Model F The 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
4.16.2.1

New Features for Model F

The Troubleshooting Display Pressing 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. Modem Debug Mode When 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 modems 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

4.16.2.2

Page 76

Revision 2.7

Hand Geometry Unit Technical Manual 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 Mode This 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 Clock
The 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 units 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 units 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.

Revision 2.7

Page 77

Hand Geometry Unit Technical Manual

Blank page.

Page 78

Revision 2.7

Hand Geometry Unit Technical Manual

5.0
5.1

Commands, Responses and Data Structures

Introduction
In 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 Commands

This 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 Functions
This 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

Enrollment
This 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

Revision 2.7

Page 79

Hand Geometry Unit Technical Manual

5.2.3

Hand Verification
This 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

Results
The 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 Management

The 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 Backup

It 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 HGUs 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

Page 80

Revision 2.7

Hand Geometry Unit Technical Manual

5.2.7

Transactions Log Management

These are the commands for fetching data from the HGU transaction log. SendDatalog SendPreviousDatalog

5.2.8

Configuration
This 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 Control
These 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

Maintenance
The commands in this group are for doing a forced re-calibration and retrieving the results. Calibrate SendCalibrationData

Revision 2.7

Page 81

Hand Geometry Unit Technical Manual

5.2.11

Ancillary Commands
The 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 Menus

There is only one command in this group. It loads the function key menu table into the HGU. HereIsDecisionMenuData

5.2.13

HP-4000 Only
To 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 Commands

There 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

Page 82

Revision 2.7

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

5.3
5.3.1

Command and Response Tables

Commands
Table 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.

Revision 2.7

Page 83

Hand Geometry Unit Technical Manual Table 5: Hand Geometry Unit Commands Grouped by Function
Command Type Length ASCII HP4K E-HK E-HP F-HK F-HP Hex Hex Models Supporting this Command Response Type Length ASCII Page
page 142 page 141 page 138 page 136 page 144 page 127 page 133 page 102 page 115 page 150 page 151 page 135 page 139 page 143 page 117 page 146 page 124 page 98 page 108 page 128 page 129 page 137 page 116 page 140 page 114 page 130

Status Functions
SendStatusCRC SendStatusChecksum SendReaderInfo SendOEMCode SendTimeAndDate SendCardData SendKeypadData 44 3B 73 6F 61 67 68 D ; s o a g h 0 0 0 0 0 0 1 30 30 53 4F 61 34 62 0 0 S O a 4 b 3 3 102 2 6 varies varies

Enrollment
EnrollUser HereIsSmartCardRecord 49 69 I i 2 16

30 30

0 0

3 3

Hand Verification
VerifyOnExternalData VerifyOnInternalData 4A 51 J Q 11 5 30 30 0 0 3 3

Results
SendLastUserRecord SendResults SendTemplate 40 43 4B @ C K 0 0 0 32 35 37 2 5 7 16 7 11

User Database Management

HereIsUserRecord SendUserRecord RemoveUserRecord ClearUserDatabase 37 38 3F 3E 7 8 ? > 16 5 5 0 30 32 30 30 0 2 0 0 3 16 3 3

User Database Backup

HereIsDataBank SendDataBank 47 48 G H 4096 2 30 36 0 6 3 4096

Transactions Log Management

SendDatalog SendPreviousDatalog 4D 6D M m 0 0 38 38 8 8 18 18

Configuration
HereIsTime SendSetup HereIsSetup SendExtendedSetup 41 4E 3D 2C A N = , 6 0 128 0 30 39 30 41 0 9 0 A 3 128 3 128

Page 84

Revision 2.7

Hand Geometry Unit Technical Manual Table 5: Hand Geometry Unit Commands Grouped by Function (Continued)
Command Type Length ASCII HP4K E-HK E-HP F-HK F-HP Hex Hex Models Supporting this Command Response Type Length ASCII Page
page 145 page 112 page 105 page 107 page 121 page 122 page 110 page 100 page 97 page 126 page 106 page 120 page 119 page 149 page 125 page 103 page 104 page 96 page 118 page 101 page 94 page 132 page 109 page 113 page 131 page 147 page 148 page 95 page 123

Configuration (continued)
SendTimeZones HereIsExtendedSetup HereAreTimeZones HereIsBellScheduleTable 24 2B 53 58 $ + S X 0 128 768 300 3 2 3 3 2 3 3 24 30 30 30 $ 0 0 0 768 3 3 3

Hardware Control
OutputControl PrinterPassThrough HereIsDisplayMessage DisplayCodedMessage 4F 70 50 56 O p P V 1 * 37 2 30 30 30 30 0 0 0 0 3 3 3 3

Maintenance
Calibrate SendCalibrationData 3A 3C : < 0 0 30 33 0 3 3 6

Ancillary Commands
HereIsBankNumber NextMessageIsTimeZones NextMessageIsBellSchedule Table UpdateNVRAM Resume EnterIdlemode EnterIdleMode2 (added 6/5/00) Beep (added 6/5/00) LEDControl (added 6/5/00) EmitKeypadTestData Abort SendInternalErrorLog 46 52 57 4C 31 45 65 62 23 42 32 5C F R W L 1 E e b # B 2 \ 2 0 0 0 0 0 0 2 1 5 0 0 2 2 30 30 30 30 30 30 30 30 30 30 30 5C 0 0 0 0 0 0 0 0 0 0 0 \ 3 3 3 3 3 3 3 3 3 3 3 51

Function Key Menus

HereIsDecisionMenuData 64 d 4096 30 0 3

HP-4000 Only
HereIsExtendedUserRecord SendExtendedUserRecord SetExtendedUserData SetUserData AddUserMessage RemoveUserMessages 78 74 75 66 76 77 x t u f v w 77 5 61 24 37 5 30 31 30/58 30/58 30/58 30 0 1 0/X 0/X 0/X 0 3 77 3 3 3 3

Revision 2.7

Page 85

Hand Geometry Unit Technical Manual Table 5: Hand Geometry Unit Commands Grouped by Function (Continued)
Command Type Length ASCII HP4K E-HK E-HP F-HK F-HP Hex Hex Models Supporting this Command Response Type Length ASCII Page
page 99

HP-4000 Only (continued)

ClearUserMessages 79 y 0 30 0 3

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

Undocumented Commands
DAQ Special Command TB Results Fill Memory With Test Pattern Validate Test Pattern Protected Subcommands 35 33 63 54 55 5A 5 3 c T U Z

Page 86

Revision 2.7

Hand Geometry Unit Technical Manual Table 6: Hand Geometry Unit Commands Sorted by Command Number
Command Type Length ASCII HP4K E-HK E-HP F-HK F-HP Hex Hex Models Response Type Length ASCII Page page 118 page 145 page 112 page 130 page 125 page 94 page 117 page 146 page 97 page 141 page 126 page 114 page 98 page 124 page 135 page 116 page 101 page 139 page 142 page 103 page 106 page 108 page 128 page 102 page 150 page 143 page 149 page 129 page 140 page 121 page 110 page 151 page 120 page 105 page 100 page 119 page 107

LEDControl (added 6/5/00) SendTimeZones HereIsExtendedSetup SendExtendedSetup Resume Abort Special Command Take Pictures DAQ CalculateTemplate HereIsUserRecord SendUserRecord SendSpecialStatus Calibrate SendStatusChecksum SendCalibrationData HereIsSetup ClearUserDatabase RemoveUserRecord SendLastUserRecord HereIsTime EmitKeypadTestData SendResults SendStatusCRC EnterIdleMode HereIsBankNumber HereIsDataBank SendDataBank EnrollUser VerifyOnExternalData SendTemplate UpdateNVRAM SendDatalog SendSetup OutputControl HereIsDisplayMessage VerifyOnInternalData NextMessageIsTimeZones HereAreTimeZones Fill Memory With Test Pattern Validate Test Pattern DisplayCodedMessage NextMessageIsBellScheduleTable HereIsBellScheduleTable Protected Subcommands SendInternalErrorLog

23 24 2B 2C 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 5A 5C

# $ + , 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Z \

1 0 128 0 0 0

30 24 30 41 30 30 30 7

0 $ 0 A 0 0 0 7 0 2 (1) 0 0 3 0 0 0 2 0 0 5 0 0 0 0 6 0 0 7 0 8 9 0 0 0 0 0

3 768 3 128 3 3 3 11 3 16 3 3 6 3 3 3 16 3 3 7 3 3 3 3 4096 3 3 11 3 18 128 3 3 3 3 3

16 5 0 0 0 128 0 5 0 6 5 0 0 0 2 4096 2 2 11 0 0 0 0 1 37 5 0 768

30 32 (31) 30 30 33 30 30 30 32 30 30 35 30 30 30 30 36 30 30 37 30 38 39 30 30 30 30 30

2 0 300 0

2 2

2 2

30 30 30 5C

0 0 0 \

3 3 3 51

Revision 2.7

Page 87

Hand Geometry Unit Technical Manual Table 6: Hand Geometry Unit Commands Sorted by Command Number
Command Type Length ASCII HP4K E-HK E-HP F-HK F-HP Hex Hex Models Response Type Length ASCII Page page 144 page 96 page 109 page 104 page 148 page 127 page 133 page 115 page 137 page 136 page 122 page 138 page 131 page 147 page 95 page 123 page 113 page 99

SendTimeAndDate Beep (added 6/5/00) TB Results HereIsDecisionMenuData EnterIdleMode2 (added 6/5/00) SetUserData SendCardData SendKeypadData HereIsSmartCardRecord SendPreviousDatalog SendOEMCode PrinterPassThrough SendReaderInfo SendExtendedUserRecord SetExtendedUserData AddUserMessage RemoveUserMessages HereIsExtendedUserRecord ClearUserMessages

61 62 63 64 65 66 67 68 69 6D 6F 70 73 74 75 76 77 78 79

a b c d e f g h i m o p s t u v w x y

0 2 4096 0 24 0 1 16 0 0 * 0 5 61 37 5 77 0

61 30 30 30 30/58 34 62 30 38 4F 30 53 31 30/58 30/58 30 30 30

a 0 0 0 0/X 4 b 0 8 O 0 S 1 0/X 0/X 0 0 0

6 3 3 3 3 varies varies 3 18 2 3 102 77 3 3 3 3 3

Page 88

Revision 2.7

Hand Geometry Unit Technical Manual Table 7: Hand Geometry Unit Commands Sorted Alphabetically
Command Type ASCII HP4K E-HK E-HP F-HK F-HP Hex Hex Len Models Response Type ASCII Page page 94 page 95 page 96 page 97 page 98 page 99 page 100 page 101 page 102 page 103 page 104 page 105 page 106 page 107 page 108 page 109 page 110 page 112 page 113 page 114 page 115 page 116 page 117 page 118 page 119 page 120 page 121 page 122 page 123 page 124 page 125 page 126 page 127 page 128 page 129 page 130 page 131 page 132 page 133 page 135 page 136 page 137 Len 3 3 3 11 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 6 varies 4096 18 128 77 51 varies 16 2 18

Abort AddUserMessage Beep (added 6/5/00) CalculateTemplate Calibrate ClearUserDatabase ClearUserMessages DAQ DisplayCodedMessage EmitKeypadTestData EnrollUser EnterIdleMode EnterIdleMode2 (added 6/5/00) Fill Memory With Test Pattern HereAreTimeZones HereIsBankNumber HereIsBellScheduleTable HereIsDataBank HereIsDecisionMenuData HereIsDisplayMessage HereIsExtendedSetup HereIsExtendedUserRecord HereIsSetup HereIsSmartCardRecord HereIsTime HereIsUserRecord LEDControl (added 6/5/00) NextMessageIsBellScheduleTable NextMessageIsTimeZones OutputControl PrinterPassThrough Protected Subcommands RemoveUserMessages RemoveUserRecord Resume SendCalibrationData SendCardData SendDataBank SendDatalog SendExtendedSetup SendExtendedUserRecord SendInternalErrorLog SendKeypadData SendLastUserRecord SendOEMCode SendPreviousDatalog

32 76 62 36 3A 3E 79 35 56 42 49 45 65 54 53 46 58 47 64 50 2B 78 3D 69 41 37 23 57 52 4F 70 5A 77 3F 31 3C 67 48 4D 2C 74 5C 68 40 6F 6D

2 v b 6 : > y 5 V B I E e T S F X G d P + x = i A 7 # W R O p Z w ? 1 < g H M , t \ h @ o m

0 37 2 0 0 0 2 5 2 0 0 768 2 300 4096 4096 37 128 77 128 16 6 16 1 0 0 1 * 5 5 0 0 0 2 0 0 5 0 1 0 0 0

30 30/58 30 7 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 33 34 36 38 41 31 5C 62 32 4F 38

0 0/X 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 4 6 8 A 1 \ b 2 O 8

Revision 2.7

Page 89

Hand Geometry Unit Technical Manual Table 7: Hand Geometry Unit Commands Sorted Alphabetically
Command Type ASCII HP4K E-HK E-HP F-HK F-HP Hex Hex Len Models Response Type ASCII Page page 138 page 139 page 140 page 141 page 142 page 143 page 144 page 145 page 146 page 147 page 148 page 149 page 150 page 151 Len 102 7 128 3 3 11 6 768 16 3 3 3 3 3 3

SendReaderInfo SendResults SendSetup SendSpecialStatus SendStatusChecksum SendStatusCRC SendTemplate SendTimeAndDate SendTimeZones SendUserRecord SetExtendedUserData SetUserData Special Command Take Pictures TB Results UpdateNVRAM Validate Test Pattern VerifyOnExternalData VerifyOnInternalData

73 43 4E 39 3B 44 4B 61 24 38 75 66 33 34 63 4C 55 4A 51

s C N 9 ; D K a $ 8 u f 3 4 c L U J Q

0 0 0 0 0 0 0 0 5 61 24 1 3 1 3

53 35 39 (31) 30 30 37 61 24 32 30/58 30/58 30

S 5 9 (1) 0 0 7 a $ 2 0/X 0/X 0 0 0 0

0 11 5

30 30 30

Page 90

Revision 2.7

Hand Geometry Unit Technical Manual

5.3.2

Responses
Responses 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 ASCII Hex Models Which May Send This Response HP4K E-HK E-HP Page
page 168 page 171 page 156 page 157 page 154 page 158 page 170 page 163 page 167 page 159 page 162 page 161 page 164 page 165 page 155 page 172 page 160

F-HK
2

Common Responses
HereIsStatus HereIsUserRecord HereIsCalibrationData HereIsCardData HereAreResults HereIsDataBank HereIsTemplateVector HereIsNextDatalog HereIsSetupData HereIsExtendedSetup HereIsMyTime HereIsKeypadData HereIsOEMCode HereIsReaderInfo HereAreTimeZones 30 32 33 34 35 36 37 38 39 41 61 62 4f 53 24 0 2 3 4 5 6 7 8 9 A a b O S $ 1 1 2 2

HP-4000 Only
UnableToCompleteCommand HereIsExtendedUserRecord 58 31 X 1

Revision 2.7

F-HP

Page 91

Hand Geometry Unit Technical Manual

Blank page.

Page 92

Revision 2.7

Hand Geometry Unit Technical Manual

5.4

Commands
This 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
Function Group Description Data Response DLL Function Portability

ASCII: A

Hex: FF

The name of the group to which the function belongs A brief description of what the command does Data that must go with the command The name of the response to be expected from the HGU The function name in the DLL Which models support the command (indicated by a ) shown in table format EHK EHP FHK FHP HP4K

Notes
Most commands require some explanation beyond what is given in the Description. That explanation is provided here.

Revision 2.7

Page 93

Hand Geometry Unit Technical Manual AbortCommand

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary commands Abort a host command None HereIsStatus rsiAbortCommand

ASCII: 2

Hex: 32

Notes
This 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_RDY RSLTS_RDY FAILED_CMD CMD_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.

Page 94

Revision 2.7

Hand Geometry Unit Technical Manual AddUserMessage

Function Group Description Data
Field ID Message Total Bytes 5 32 2 HereIsStatus rsiAddUserMessage Offset 0 5 Description Which user this message is for Message text, either zero-terminated or exactly 32 bytes long HP-4000 Only Add a message for a user

ASCII: v

Hex: 76

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
The 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.

Revision 2.7

Page 95

Hand Geometry Unit Technical Manual Beep

Function Group Description Data
Field Length Number Total Bytes 1 1 2 HereIsStatus rsiBeep Offset 0 1 Description Length of beep Number of beeps Ancillary Commands The unit will beep

ASCII: b

Hex: 62

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Page 96

Revision 2.7

Hand Geometry Unit Technical Manual Calibrate

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Maintenance The HGU will re-calculate the optimal exposure and row/column offsets. None HereIsStatus rsiCalibrate

ASCII: :

Hex: 3A

Notes
The 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.

Revision 2.7

Page 97

Hand Geometry Unit Technical Manual ClearUserDatabase

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K User database management The user database is cleared. All user records are deleted. None HereIsStatus rsiClearUserDataBase

ASCII: >

Hex: 3E

Notes
Use 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.

Page 98

Revision 2.7

Hand Geometry Unit Technical Manual ClearUserMessages

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K HP-4000 Only The message pool is cleared None HereIsStatus rsiClearUserMessages

ASCII: y

Hex: 79

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

Revision 2.7

Page 99

Hand Geometry Unit Technical Manual DisplayCodedMessage

Function Group Description Data
Field Message Time Total Bytes 1 1 2 HereIsStatus rsiDisplayCodedMessage Offset 0 1 Description Which message to display Display time in 500 msec intervals Hardware Control Displays a message from a predetermined list for a time

ASCII: V

Hex: 56

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This command displays one of three messages, based on the value in the message field. Message 0 1 2 Display ACCESS GRANTED ACCESS DENIED WRONG TIME/PLACE ACCESS DENIED HAND NOT CLEARED

Page 100

Revision 2.7

Hand Geometry Unit Technical Manual EmitKeypadTestData

Function Group Description Data
Field ID Total Bytes 5 5 HereIsStatus None Offset 0 Description ID number to convert and emit Ancillary Commands The given ID will be emitted from the units card reader output

ASCII: B

Hex: 42

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Revision 2.7

Page 101

Hand Geometry Unit Technical Manual EnrollUser

Function Group Description Data
Field Prompt Total Bytes 2 2 HereIsStatus rsiEnrollUser Offset 0 Description See notes Enrollment The HGU begins a host-initiated enrollment.

ASCII: I

Hex: 49

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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 keypadinitiated 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 HGUs 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.

Page 102

Revision 2.7

Hand Geometry Unit Technical Manual EnterIdleMode

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary commands Places the HGU in idle mode. All processing is suspended, except host communications. None HereIsStatus rsiEnterIdleMode

ASCII: E

Hex: 45

Notes
This 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 controls Datalog printing Time and date updating Modem answering

Revision 2.7

Page 103

Hand Geometry Unit Technical Manual EnterIdleMode2

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary commands Places the HGU in idle mode. All processing is suspended, except host communications. Not terminated by SendStatus None HereIsStatus rsiEnterIdleMode2

ASCII: e

Hex: 65

Notes
This 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.

Page 104

Revision 2.7

Hand Geometry Unit Technical Manual HereAreTimeZones

Function Group Description Data
Field Holidays Time Zones Total Bytes 48 720 768 HereIsStatus rsiHereAreTimeZones Offset 0 48 Description Holiday table. See page 194 for details Time Zone Table. See page 195 for details Configuration Send a time zone table to the HGU

ASCII: S

Hex: 53

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
The 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.

Revision 2.7

Page 105

Hand Geometry Unit Technical Manual HereIsBankNumber

Function Group Description Data
Field Bank Number Total Bytes 2 2 HereIsStatus (some versions do not respond to invalid data, see notes below) rsiHereIsBankNumber Offset 0 Description Bank number of next data bank Ancillary Commands Prepares HGU to receive a bank of user database data.

ASCII: F

Hex: 46

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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 units memory capacity.

Page 106

Revision 2.7

Hand Geometry Unit Technical Manual HereIsBellScheduleTable

Function Group Description Data
Field ID Total Bytes 300 300 HereIsStatus rsiHereIsBellScheduleTable Offset 0 Description Array of 100 bell schedule entries. See page page 182 for details. Configuration Send a bell schedule to the HGU

ASCII: X

Hex: 58

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Revision 2.7

Page 107

Hand Geometry Unit Technical Manual HereIsDataBank

Function Group Description Data
Field Data Total Bytes 4096 4096 HereIsStatus rsiHereIsDataBank Offset 0 Description User data User database backup Loads a bank of user database data into the HGU from the host system.

ASCII: G

Hex: 47

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Page 108

Revision 2.7

Hand Geometry Unit Technical Manual HereIsDecisionMenuData

Function Group Description Data
Field Data Total Bytes 4096 4096 HereIsStatus rsiHereIsFkeyData Offset 0 Description Menu data Function key menu Loads the menu data into the HGU.

ASCII: d

Hex: 64

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
The 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.

Revision 2.7

Page 109

Hand Geometry Unit Technical Manual HereIsDisplayMessage

Function Group Description Data
Field Data Total Bytes 37 37 HereIsStatus rsiHereIsDisplayMessage Offset 0 Description Two variant forms. See notes below. Hardware control A message is displayed on the LCD

ASCII: P

Hex: 50

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
There 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 Field Header Time Unused Text Bytes 1 1 3 32 Offset 0 1 2 5 Description Must be FFH. This is how Form1 is distinguished from Form2. Number of second intervals the message will be displayed. Not used. Data in these bytes is ignored by the HGU. Text to display. See Table 47 on page 249 for the LCD character set.

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 Field ID Text Bytes 5 32 Offset 0 5 Description ID for matching. 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.

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.

Page 110

Revision 2.7

Hand Geometry Unit Technical Manual

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.

Revision 2.7

Page 111

Hand Geometry Unit Technical Manual HereIsExtendedSetup

Function Group Description Data
Field Data Total Bytes 128 4096 HereIsStatus rsiHereIsExtSetupData Offset 0 Description Extended setup data. See page 185 for details. Configuration Sends extended setup data to an F series unit.

ASCII: +

Hex: 2B

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
A 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.

Page 112

Revision 2.7

Hand Geometry Unit Technical Manual HereIsExtendedUserRecord

Function Group Description Data
Field ID Template Authority Timezone PTI FKMASKS Name Data Amnesty RESERVED Total Bytes 5 9 1 1 12 2 16 24 1 6 77 HereIsStatus rsiHereIsExtUserRecord Offset 0 5 14 15 16 28 30 46 70 71 Description User ID Hand geometry template do not alter Authority and reject override threshold Time zone Packed time intervals Function key use masks User name for display Custom user data Amnesty punch count Reserved do not alter HP-4000 only Add or replace an Extended User Record in an HP-4000 unit

ASCII: x

Hex: 78

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Revision 2.7

Page 113

Hand Geometry Unit Technical Manual HereIsSetup

Function Group Description Data
Field Data Total Bytes 128 77 HereIsStatus rsiHereIsSetup Offset 0 Description Basic Setup Data. See page 173 for details. Configuration Send basic setup data to the HGU

ASCII: =

Hex: 3D

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
A 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.

Page 114

Revision 2.7

Hand Geometry Unit Technical Manual HereIsSmartCardRecord

Function Group Description Data
Field ID Template Authority Timezone Total Length Bytes 5 9 1 1 16 HereIsStatus rsiHereIsSmartCardRecord Offset 0 5 14 15 Description User ID Hand geometry template. Do not alter. Authority and reject override Index into time zone table Enrollment send User Record to initialize Smart Card

ASCII: i

Hex: 69

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
If 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.

Revision 2.7

Page 115

Hand Geometry Unit Technical Manual HereIsTime

Function Group Description Data
Field Seconds Minutes Hours Day Month Year Total Length Bytes 1 1 1 1 1 1 6 HereIsStatus rsiHereIsTime Offset 0 1 2 3 4 5 Description Seconds, 0-59 Minutes, 0-59 Hours, 0-23 Day, 1-31 Month, 1-12 Year Configuration Sends the time and date from the host system to the HGU

ASCII: A

Hex: 41

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
Units 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.

Page 116

Revision 2.7

Hand Geometry Unit Technical Manual HereIsUserRecord

Function Group Description Data
Field ID Template Authority Timezone Total Length Bytes 5 9 1 1 16 HereIsStatus rsiHereIsUserRecord Offset 0 5 14 15 Description User ID Hand geometry template. Do not alter. Authority and reject override Index into time zone table User database management Adds or updates a basic user record

ASCII: 7

Hex: 37

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Revision 2.7

Page 117

Hand Geometry Unit Technical Manual LEDControl

Function Group Description Data
Field Control Code Total Length Bytes 1 1 HereIsStatus None Offset 0 Description Specifies color Red (ASCII R/Hex 52) or Green (ASCII G/Hex 47) Ancillary Commands Activates the Red/Green LED, if present

ASCII: #

Hex: 23

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Page 118

Revision 2.7

Hand Geometry Unit Technical Manual NextMessageIsBellScheduleTable

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary commands Prepares the HGU to receive a bell schedule table None HereIsStatus rsiNextMessageIsBellScheduleTable

ASCII: W

Hex: 57

Notes
On 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.

Revision 2.7

Page 119

Hand Geometry Unit Technical Manual NextMessageIsTimeZones

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary commands Prepares the HGU to receive a time zone table None HereIsStatus rsiNextMessageIsTimeZones

ASCII: R

Hex: 52

Notes
This 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.

Page 120

Revision 2.7

Hand Geometry Unit Technical Manual OutputControl

Function Group Description Data
Field State Total Length Bytes 1 1 HereIsStatus rsiOutputControl Offset 0 Description See notes below. Hardware Control Activate or deactivate an output

ASCII: O

Hex: 4F

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
Note 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 2 3 4 5 6 Timed unlock using the unlock timer setting (from the basic setup data) Unlock is indefinite Re-lock Turn the Auxiliary output on. (On F series units, this refers to AuxOut0). Turn the Auxiliary output off. (On F series units, this refers to AuxOut0). 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 8 9 10 11 12 13 Turn AuxOut1 on indefinitely Turn AuxOut1 off Turn AuxOut2 on indefinitely Turn AuxOut2 off Turn AuxOut0 on, timed Turn AuxOut1 on, timed Turn AuxOut2 on, timed

Other state values will have no effect.

Revision 2.7

Page 121

Hand Geometry Unit Technical Manual PrinterPassThrough

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Hardware control The data supplied with the command is sent directly out the printer port Data to be sent to printer. Can be variable length, but is limited. See notes. HereIsStatus rsiPrinterPassThrough

ASCII: p

Hex: 70

Notes
This 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 RS232 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.

Page 122

Revision 2.7

Hand Geometry Unit Technical Manual RemoveUserMessages

Function Group Description Data
Field ID Total Length Bytes 5 5 HereIsStatus rsiRemoveUserMessage (note the missing s) Offset 0 Description User ID for whom messages are removed HP-4000 Only All messages for a given user are removed.

ASCII: w

Hex: 77

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
Messages 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.

Revision 2.7

Page 123

Hand Geometry Unit Technical Manual RemoveUserRecord

Function Group Description Data
Field ID Total Length Bytes 5 5 HereIsStatus rsiRemoveUserRecord Offset 0 Description User ID to remove from database User database management The user record with the given ID is removed from the user database.

ASCII: ?

Hex: 3F

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Page 124

Revision 2.7

Hand Geometry Unit Technical Manual Resume

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary commands Take the HGU out of idle mode. None HereIsStatus rsiResume

ASCII: 1

Hex: 31

Notes
If 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.

Revision 2.7

Page 125

Hand Geometry Unit Technical Manual SendCalibrationData

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Maintenance Causes the HGU to send the results of the latest calibration operation None HereIsCalibrationData rsiSendCalibrationData

ASCII: <

Hex: 3C

Notes
A 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.

Page 126

Revision 2.7

Hand Geometry Unit Technical Manual SendCardData

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Status Functions Causes HGU to send recent card data None HereIsCardData None

ASCII: g

Hex: 67

Notes
With 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 ESeries (ID3D) PROMs made after May 23, 2002.

Revision 2.7

Page 127

Hand Geometry Unit Technical Manual SendDataBank

Function Group Description Data
Field Bank Total Length Bytes 2 2 HereIsDataBank (Type 6) rsiSendDataBank Offset 0 Description Bank number, LSB first User database backup A bank of data from the user database is sent from the HGU to the host system

ASCII: H

Hex: 48

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Page 128

Revision 2.7

Hand Geometry Unit Technical Manual SendDatalog

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Transactions log management The oldest entry in the transactions log is returned to the host system None HereIsDatalog rsiSendDataLog

ASCII: M

Hex: 4D

Notes
Datalogs 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.

Revision 2.7

Page 129

Hand Geometry Unit Technical Manual SendExtendedSetup

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Configuration The HGU sends the extended setup data (F series only) to the host system None HereIsExtendedSetupData (41H) rsiSendExtSetup

ASCII: ,

Hex: 2C

Notes
This 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.

Page 130

Revision 2.7

Hand Geometry Unit Technical Manual SendExtendedUserRecord

Function Group Description Data
Field ID Total Length Bytes 5 5 HereIsExtendedUserRecord rsiSendExtUserRecord Offset 0 Description User ID requested HP-4000 only The extended user record with the ID matching the given ID is returned to the host system

ASCII: t

Hex: 74

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Revision 2.7

Page 131

Hand Geometry Unit Technical Manual SendInternalErrorLog

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary Commands Returns the contents of the internal error log None HereIsInternalErrorLog not implemented in the DLL

ASCII: \

Hex: 5C

Notes
This 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.

Page 132

Revision 2.7

Hand Geometry Unit Technical Manual SendKeypadData

Function Group Description Data
Field Arg Total Length Bytes 1 1 HereIsKeypadData None Offset 0 Description Control code (see Notes below) Status Functions Request raw keystroke data from reader

ASCII: h

Hex: 68

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
There 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 1 Just send data; no changes to mode. 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. 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. Mode change: reenable normal use of ID entry. Just flush buffer; no changes to mode. This will result in zero bytes in the reply, even if data was pending.

3 4

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

Revision 2.7

Page 133

Hand Geometry Unit Technical Manual

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.

Page 134

Revision 2.7

Hand Geometry Unit Technical Manual SendLastUserRecord

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Results Returns the last ID entered and the template of the last hand image taken None HereIsUserRecord rsiSendLastUserRecord

ASCII: @

Hex: 40

Notes
The 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.

Revision 2.7

Page 135

Hand Geometry Unit Technical Manual SendOEMCode

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Status functions Returns the factory-assigned OEM code None HereIsOEMCode rsiSendOemCode

ASCII: o

Hex: 6F

Notes
The 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.

Page 136

Revision 2.7

Hand Geometry Unit Technical Manual SendPreviousDatalog

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Transactions log management Re-sends the last datalog None HereIsDatalog rsiSendPreviousDataLog

ASCII: m

Hex: 6D

Notes
This 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.

Revision 2.7

Page 137

Hand Geometry Unit Technical Manual SendReaderInfo

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Status functions Requests various information on the units configuration and state None HereIsReaderInfo rsiSendReaderInfo

ASCII: s

Hex: 73

Notes
For details of the HereIsReaderInfo response, see page 165.

Page 138

Revision 2.7

Hand Geometry Unit Technical Manual SendResults

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Results Requests results from the last hand reading (see notes) None HereAreResults rsiSendResults

ASCII: C

Hex: 43

Notes
The 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.

Revision 2.7

Page 139

Hand Geometry Unit Technical Manual SendSetup

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Configuration Request setup information from the HGU None HereIsSetupData rsiSendSetup

ASCII: N

Hex: 4E

Notes
This 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 HGUs setup. Examples of the correct technique for reading, modifying, and writing setup data are provided Section 6.3 on page 218.

Page 140

Revision 2.7

Hand Geometry Unit Technical Manual SendStatusChecksum

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Status Get status from HGU, put HGU into checksum FCS mode None HereIsStatus not supported

ASCII: ;

Hex: 3B

Notes
This 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.

Revision 2.7

Page 141

Hand Geometry Unit Technical Manual SendStatusCRC

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Status Get status from HGU, put HGU into CRC FCS mode None HereIsStatus rsiSendStatusCRC

ASCII: D

Hex: 44

Notes
This 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.

Page 142

Revision 2.7

Hand Geometry Unit Technical Manual SendTemplate

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Results Causes the HGU to return the contents of the template buffer None HereIsTemplate rsiSendTemplate

ASCII: K

Hex: 4B

Notes
See 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.

Revision 2.7

Page 143

Hand Geometry Unit Technical Manual SendTimeAndDate

Function Group Description Data Response DLL Function Portability
Status functions Causes the HGU to return the time and date from its clock None HereIsTimeAndDate rsiSendTime (note the different name) See note below. EHK EHP FHK FHP HP4K

ASCII: a

Hex: 61

Notes
This 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.

Page 144

Revision 2.7

Hand Geometry Unit Technical Manual SendTimeZones

Function Group Description Data Response DLL Function Portability
Configuration Causes the HGU to return the time zone and holiday table None HereAreTimeZones not implemented in the DLL See note below. EHK EHP FHK FHP HP4K

ASCII: $

Hex: 24

Notes
This 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.

Revision 2.7

Page 145

Hand Geometry Unit Technical Manual SendUserRecord

Function Group Description Data
Field ID Total Length Bytes 5 5 HereIsUserRecord rsiSendUserRecord Offset 0 Description User ID requested User Database Management The user record for the given ID is returned.

ASCII: 8

Hex: 38

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
If 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.

Page 146

Revision 2.7

Hand Geometry Unit Technical Manual SetExtendedUserData

Function Group Description Data
Field ID PTI FKMASKS Name UDF Amnesty RESERVED Total Length Bytes 5 12 2 16 24 1 6 66 HereIsStatus or UnableToCompleteCommand rsiSetExtUserData Offset 0 5 17 19 35 59 60 Description User ID for whom messages are removed Packed time intervals Function key use masks User name for display Custom user data Amnesty punch count Reserved. Do not alter. HP-4000 Only Set the extended user data portion of a user record

ASCII: u

Hex: 75

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Revision 2.7

Page 147

Hand Geometry Unit Technical Manual SetUserData

Function Group Description Data
Field ID UDF Total Length Bytes 5 24 29 HereIsStatus or UnableToCompleteCommand rsiSetUserData Offset 0 5 Description User ID for whom data is to be set Custom user data HP-4000 Only Set the user data portion of an extended user record

ASCII: f

Hex: 66

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
This 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.

Page 148

Revision 2.7

Hand Geometry Unit Technical Manual UpdateNVRAM

Function Group Description Data Response DLL Function Portability
EHK EHP FHK FHP HP4K Ancillary commands The setup data is transferred to NV-RAM None HereIsStatus rsiUpdateNVRam

ASCII: L

Hex: 4C

Notes
This command transfers the setup data sent by the HereIsSetupData command to the HGUs 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.

Revision 2.7

Page 149

Hand Geometry Unit Technical Manual VerifyOnExternalData

Function Group Description Data
Field Prompt Template Total Length Bytes 2 9 11 HereIsStatus rsiVerifyOnExternalData Offset 0 2 Description See the EnrollUser command Hand geometry template for verification Hand Verification Initiates a hand verification against a template supplied by the host system

ASCII: J

Hex: 4A

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
The 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.

Page 150

Revision 2.7

Hand Geometry Unit Technical Manual VerifyOnInternalData

Function Group Description Data
Field ID Total Length Bytes 5 5 HereIsStatus rsiVerifyOnInternalData Offset 0 Description ID to use for verification Hand Verification Initiates a hand verification against the template stored in the user database for the given ID

ASCII: Q

Hex: 51

Response DLL Function Portability

EHK

EHP

FHK

FHP

HP4K

Notes
If 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.

Revision 2.7

Page 151

Hand Geometry Unit Technical Manual

Blank page.

Page 152

Revision 2.7

Hand Geometry Unit Technical Manual

5.5

Responses
Responses 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
Description Data Notes
Some responses require a more detailed description. That description will appear here.

ASCII: X
A description of the response appears here.

Hex: FF

The data structure which accompanies the response is shown here. Details of the data structures appear in Section 5.6 on page 173.

Revision 2.7

Page 153

Hand Geometry Unit Technical Manual HereAreResults

Description Data
Field ID Score Total Bytes 5 2 7 Offset 0 5 Description Last ID enetered Score for last hand verification

ASCII: 5

Hex: 35H

Returns the contents of the results buffer. Response to SendResults command.

Notes
The 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.

Page 154

Revision 2.7

Hand Geometry Unit Technical Manual HereAreTimeZones

Description Data
Field Holidays Time Zones Total Bytes 48 720 768 Offset 0 48 Description Holiday table. See page 194 for details. Time Zone Table. See page 195 for details.

ASCII: $
Returns the contents of the time zone table.

Hex: 24

Notes
This 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.

Revision 2.7

Page 155

Hand Geometry Unit Technical Manual HereIsCalibrationData

Description Data
Field Exposure Row Column Total Bytes 2 2 2 6 Offset 0 2 4 Description Camera exposure time Alignment offset Alignment offset

ASCII: 3

Hex: 33

Returns current calibration information. Response to SendCalibrationData command.

Notes
The 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.

Page 156

Revision 2.7

Hand Geometry Unit Technical Manual HereIsCardData

Description Data
Field SysStat0 SysStat1 MonStat Length Card Data Total Length Bytes 1 1 1 1 varies 4 or more Offset 0 1 2 3 4 Description See Table 11 on page 168 See Table 12 on page 169 See Table 13 on page 169 Length of data in bits Data from last card read

ASCII: 4
Returns most recent card data input

Hex: 34

Notes
This 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.

Revision 2.7

Page 157

Hand Geometry Unit Technical Manual HereIsDataBank

Description Data Notes
This 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.

ASCII: 6

Hex: 36

Returns a bank of user data. Response to SendDataBank command. User data bank, 4096 bytes.

Page 158

Revision 2.7

Hand Geometry Unit Technical Manual HereIsExtendedSetupData

Description Data

ASCII: A

Hex: 41

Returns the extended setup data, if applicable to the model. Response to SendExtendedSetupData command. Extended setup data, 128 bytes. See page 185 for a data table and for detailed descriptions of the fields.

Notes
Only 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.

Revision 2.7

Page 159

Hand Geometry Unit Technical Manual HereIsExtendedUserRecord

Description Data
Field ID Template Authority Timezone PTI FKMASKS Name Data Amnesty RESERVED Total Bytes 5 9 1 1 12 2 16 24 1 6 77

ASCII: 1

Hex: 31

Returns an extended user record. HP-4000 only. Response to SendExtendedUserRecord command. Extended user record, 77 bytes. See page 193 for detailed descriptions of the fields. Offset 0 5 14 15 16 28 30 46 70 71 Description User ID Hand geometry template. Do not alter. Authority and reject override threshold Time zone Packed time intervals Function key use masks User name for display Custom user data Amnesty punch count Reserved. Do not alter.

Notes
This 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.

Page 160

Revision 2.7

Hand Geometry Unit Technical Manual HereIsKeypadData

Description Data

ASCII: b
Returns a list of recent keystrokes

Hex: 62

A count byte followed by ASCII values of recent keystrokes in chronological order

Field Length Values Total

Bytes 1 varies 1 or more

Offset 0 1

Description Count of following bytes (can be zero) Zero or more bytes of keystroke data

Notes
This 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. . Hex 0x2A 0x23 0x21 0x40 0x83 Asterisk (*) Pound Sign (#) Clear Key Enter Key Clear and Enter Keys pressed simultaneously Description

There are many other two key press combinations; these are not noted at this time.

Revision 2.7

Page 161

Hand Geometry Unit Technical Manual HereIsMyTime

Description Data
Field Seconds Minutes Hours Day Month Year Total Length Bytes 1 1 1 1 1 1 6

ASCII: a

Hex: 61

Returns the units clock time. Response to SendTime command. Time of units clock, 6 bytes. Offset 0 1 2 3 4 5 Description Seconds, 0-59 Minutes, 0-59 Hours, 0-23 Day, 1-31 Month, 1-12 Year

Notes
For information on Y2K issues and the contents of the year field, Y2K Issues on page 255.

Page 162

Revision 2.7

Hand Geometry Unit Technical Manual HereIsNextDatalog

Description Data
Field Address Time stamp Format Data1 Data2 Total Length Bytes 1 6 1 5 5 18

ASCII: 8

Hex: 38

Sent in response to SendNextDatalog and SendPreviousDatalog commands. Datalog, 18 bytes. See page 183 for details. Offset 0 1 7 8 13 Description Address of unit which generated the datalog Time stamp of datalog (same as HereIsTime) Identifies type of datalog Content varies with type Content varies with type

Notes
See the example in Section 6.10 on page 226.

Revision 2.7

Page 163

Hand Geometry Unit Technical Manual HereIsOEMCode

Description Data
Field OEM Code Total Length Bytes 2 2 Offset 0 Description OEM Code

ASCII: O

Hex: 4F

Returns the OEM code assigned to the unit. Response to SendOEMCode command.

Notes
The 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.

Page 164

Revision 2.7

Hand Geometry Unit Technical Manual HereIsReaderInfo

Description Data
Field Model Memory PromDate ModelName SN SN Prefix UCap TCap UNum TNum Config ME AltProm Reserved Total Length Bytes 1 1 20 17 4 1 2 2 2 2 14 1 1 34 102 Offset 0 1 2 22 39 43 44 46 48 50 52 66 67 68 Description Model number. See note 1. Memory configuration. See note 2. Text string with PROM date. Displayed on LCD line 2 at startup Units serial number. Serial number prefix. See note 3. Maximum user capacity Maximum transactions capacity Current number of users enrolled Current number of transactions Displayed on LCD line 1 at startup Modem/Ethernet adaptor flag. See note 4. Alternate PROM style. See note 5. Reserved. Values are unspecified.

ASCII: S
Returns information about the unit. Response to the SendReaderInfo command.

Hex: 53

Notes
1. The model number is assigned per Table 9.

Table 9: Model Identification Number

Model Number 0 1 2 3 4 Model HP-2000 HP-3000 HP-4000 HK-CR HK-2

Revision 2.7

Page 165

Hand Geometry Unit Technical Manual

2. The memory configuration is assigned per Table 10.

Table 10: Memory Configurations

Memory Configuration 0 1 2 Memory Size 128K 256K 640K

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.

Page 166

Revision 2.7

Hand Geometry Unit Technical Manual HereIsSetupData

Description Data Notes
Not applicable.

ASCII: 9

Hex: 39

Returns the basic setup data. Response to the SendSetupData command Setup data, 128 bytes. See page 173 for the fields and descriptions.

Revision 2.7

Page 167

Hand Geometry Unit Technical Manual HereIsStatus

Description Data
Field SysStat0 SysStat1 MonStat Total Length Bytes 1 1 1 3

30H

System status. This response is returned from a wide variety of commands. System status, 3 bytes. Offset 0 1 2 Description See Table XXXXXXXXXXX1 See Table XXXXXXXXXXX2 See Table XXXXXXXXXXX2

Notes
The three bytes returned are each bit fields with the structures shown in the following tables.

Table 11: SysStat0 Bit Descriptions

Label H_READ LED1 LED2 LED3 LED4 ANY_KEY AUX_OUT_1 AUX_OUT_2 Bit 0 1 2 3 4 5 6 7 Mask 01H 02H 04H 08H 10H 20H 40H 80H Description Set when unit is trying to read a hand. Cleared when all fingers are in proper position on the platen. Set during hand reading. Cleared when the little finger is closed to the guide pin. Set during hand reading. Cleared when the ring finger is closed to the guide pin. Set during hand reading. Cleared when the middle finger is closed to the guide pin. Set during hand reading. Cleared when the index finger is closed to the guide pin. Set when a key is pressed on the keypad. Cleared when the SendStatus command is received. On Model F units, set to 1 when AuxOut1 is activated (low). Undefined on Model E units. On Model F units, set to 1 when AuxOut2 is activated (low). Undefined on Model E units.

Page 168

Revision 2.7

Hand Geometry Unit Technical Manual Table 12: SysStat1 bits

Label RES_SYS VERIFY_RDY Bit 0 1 Mask 01H 02H Description Set when unit is initialized. Cleared when any command other than SendStatus is received. Set when a hand has been read due to PIN entry at the unit. Cleared when the SendResults or SendTemplate command is received. 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. 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. Set whenever the datalog buffer is not empty. Cleared when the datalog buffer empties. 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. Set when the Enroll, VerifyOnExternalData, or VerifyOnInternalData command is in progress. 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.

RSLTS_RDY

04H

FAILED_CMD

08H

DLOG_RDY ID_NIM

4 5

10H 20H

CMD_BUSY KP_ID

6 7

40H 80H

Table 13: MonStat bits

Label TAMPER AUX_IN_1 DOOR_SW AUX_IN_0 REX Not used AUX_OUT_0 LOCK Bit 0 1 2 3 4 5 6 7 Mask 01H 02H 04H 08H 10H 20H 40H 80H Description Tamper status. 1=tamper, 0=no tamper AuxIn1 status. 1=high, 0=low. Only available on Model F units. Door switch status. 1=high, 0=low AuxIn0 status. 1=high, 0=low. Only available on Model F units. Request to exit status. 1=high, 0=low. Not used. Value is undefined. AuxOut0 status, or bell output status. 1=high, 0=low. Lock output status. 1=high, 0=low.

Revision 2.7

Page 169

Hand Geometry Unit Technical Manual HereIsTemplateVector

Description Data
Field Score Template Total Length Bytes 2 9 11

ASCII: 7
Response to the SendTemplate command.

Hex: 37

Contents of the template buffer. See Section 4.4 on page 56 for details. Offset 0 2 Description Score of last verification Hand geometry template

Notes
The 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.

Page 170

Revision 2.7

Hand Geometry Unit Technical Manual HereIsUserRecord

Description Data
Field ID Template Authority Timezone Total Length Bytes 5 9 1 1 16

ASCII: 2
Sent in response to the SendUserRecord command. Basic user record. Offset 0 5 14 15 Description User ID Hand geometry template. Do not alter. Authority and reject override Index into time zone table

Hex: 32

Notes
This is sent in response to the SendUserRecord command on all models. To retrieve the HP4000 extended user records, use the SendExtendedUserRecord command.

Revision 2.7

Page 171

Hand Geometry Unit Technical Manual UnableToCompleteCommand

Description Data Notes
Sent when the SetExtendedUserData, SetUserData, and SetUserMessage commands are unable to carry out their operation. See the individual command descriptions for more information.

ASCII: X

Hex: 58

Indicates the received command could not be carried out. HP-4000 only. Same as HereIsStatus.

Page 172

Revision 2.7

Hand Geometry Unit Technical Manual

5.6

Data Structures
The 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
Default Value Offset Bytes

Field Reserved Password5 Password4 Password3 Password2 Password1 Threshold Aux Flag Clear Aux Timeout Print Flag Status Flag Aux Flag D Aux Flag A Aux Flag I Aux Flag T Aux Flag P Lock Time Shunt Time Network Baud Rate Printer Baud Rate HGU Address Facility Code Reserved Operating Mode Output Mode Beeper Flag 2

Description Reserved; do NOT alter ASCIIZ password for operating mode 5 ASCIIZ password for operating mode 4 ASCIIZ password for operating mode 3 ASCIIZ password for operating mode 2 ASCIIZ password for operating mode 1 System reject threshold (30 - 250) If nonzero, valid access clears AUX Aux out on this long in seconds (0-20,000) If nonzero, valid access attempts are printed If nonzero, system status is displayed If nonzero, door alarm activates Aux Out 0 If nonzero, aux in 0 activates Aux Out 0 If nonzero, invalid access activates Aux Out 0 If nonzero, tamper activates Axu Out 0 If nonzero, power failure activates Aux Out 0 (F) Time of activation of lock output Time door can remain open during unlock Sets baud rate for RS-422/485 port Sets baud rate for RS-232 port 0H - 0FEH, excluding 0AAH For Wiegand card output Reserved. Do NOT alter. 0=Stand alone, 1=Master, 2=Remote 0=Lock/Door, 1=Card Reader Emulation 0=Disable beeper, nonzero=enable beeper

0 2 14 26 38 50 62 64 65 67 68 69 70 71 72 73 74 76 78 79 80 81 83 84 85 86

12 12 12 12 12 2 1 2 1 1 1 1 1 1 1 2 2 1 1 1 2 1 1 1 1

5# 4# 3# 2# 1# Note 1 5 0 0 0 0 0 0 0 5 10 2 2 Note 2 50 Note 3 Note 4 1

page 175 page 175 page 175 page 175 page 175 page 175 page 175 page 175 page 175 page 176 page 176 page 176 page 176 page 176 page 176 page 176 page 176 page 176 page 176 page 177 page 177 page 177 page 178 page 178

Revision 2.7

Page 173

See Page

Hand Geometry Unit Technical Manual Table 14: Basic Setup Data Fields
Default Value Offset Bytes Field ID length Accounting Mode Unlock Timezone Aux Timezone Aux Duress Flag Duress Character Number of tries reserved DLS On DLS Off 24 Hour Time Flag Option Flags Reserved Total Length 1 1 1 1 1 1 1 2 4 4 1 1 22 128 Description Maximum ID length for keypad entry (1 - 11) System dependent Time zone for auto-unlock. Use 61 for never Time zone for AUX activation. Use 61 for never If nonzero, duress activates AUX output 0 to 9 [31H to 39H]. No duress if * [2AH] Number of tries before lockout Reserved. Do NOT alter. Month, Day, Hour, Minute Month, Day, Hour, Minute 0=24 hour (military) time display, 1=12 hour Miscellaneous options Reverved. Do NOT alter. 0 0 0 0 page 179 page 179 page 180 page 180 * Note 5 See Page page 178 page 178 page 178 page 178 page 179 page 179 page 179

87 88 89 90 91 92 93 94 96 100 104 105 106

11 0 61 61

Notes
1. 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.

Page 174

Revision 2.7

Hand Geometry Unit Technical Manual

Reserved Offset 0 Size 2

These bytes are reserved; do NOT alter these byte fields.

Password Offset 2 Size 60

The 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 2

This 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 1

If 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 2

This 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 1

On 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.

Revision 2.7

Page 175

Hand Geometry Unit Technical Manual

Status Flag Offset 68 Size 1

If 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 units date and time.
Aux Alarm Flags Offset 69 Size 5

There 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 2

This 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 2

This 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 1

This 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 1

This 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).

Page 176

Revision 2.7

Hand Geometry Unit Technical Manual Table 15: Baud Rates

Index Model E Model F

0 1 2 3 4 5 6 7

38400 19200 9600 4800 2400 1200 600 300

28800 19200 9600 4800 2400 1200 600 300

HGU Address

Offset 80

Size 1

This 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 hosts responsibility to avoid setting a slave to these addresses.
Facility Code Offset 81 Size 2

The 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 1

This byte is reserved; do NOT alter this byte field.

Operating Mode Offset 84 Size 1

This 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 16: Operating Mode Values
Value Meaning

0 1 2

Stand-alone Network master Network remote (slave)

Revision 2.7

Page 177

Hand Geometry Unit Technical Manual

Output Mode Offset 85 Size 1

This controls whether the units 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 1

Set this to 0 to disable the keypad beeper. Any other value enables the beeper.
ID Length Offset 87 Size 1

This 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 IDs are entered from the keypad.
Accounting Mode Offset 88 Size 1

This 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 users 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 1

Setting 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 1

Setting 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.

Page 178

Revision 2.7

Hand Geometry Unit Technical Manual

Aux Duress Flag Offset 91 Size 1

Setting 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 1

This 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 1

This 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.
Reserved Offset 94 Size 2

These bytes are reserved; do NOT alter these byte fields.

Daylight Savings Time On Offset 96 Size 4

This 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 4

This 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 2 3 4

Month Day Hour Minute

Revision 2.7

Page 179

Hand Geometry Unit Technical Manual

24-Hour Time Flag Offset 104 Size 1

Set 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 1

This 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 0

Usage 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.

Reserved

Offset 106

Size 22

These bytes are reserved; do NOT alter these byte fields.

Page 180

Revision 2.7

Hand Geometry Unit Technical Manual BasicUserRecord Table 18: Basic User Record Fields
Field ID Template Authority Timezone Total Length Bytes 5 9 1 1 16 Offset 0 5 14 15

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 users 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. Authority Byte 7 6 5 4 3 2 1 Authority 0

Override reject threshold

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.

Revision 2.7

Page 181

Hand Geometry Unit Technical Manual BellSchedule Table 19: Bell Schedule Structure
Field First Byte Second Byte Third Byte Total Length Bytes 1 1 1 3 Offset 0 1 2 Description Minute in six LSBs, low bits of hour in 2 MSBs. High bits of hour in 3 LSBs, duration (seconds) in 5 MSBs DOW flags. See page 184.

Notes
A 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. First Byte of Bell Schedule Entry 7 6 5 4 3 Minute 2 1 0

LSB of hour Second Byte of Bell Schedule Entry 7 6 5 4 3

1 MSB of hour

Activation time in seconds

Page 182

Revision 2.7

Hand Geometry Unit Technical Manual Datalog Table 20: Datalog Structure
Field Address Time Stamp Format Data1 Data2 Total Length Bytes 1 6 1 5 5 18 Offset 0 1 7 8 13 Description Address of unit which generated the datalog Time stamp of datalog (same as HereIsTime) Identifies type of datalog Content varies with type Content varies with type

Notes
The 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.

Revision 2.7

Page 183

Hand Geometry Unit Technical Manual DOW Mask

7
Holiday

6
Saturday

5
Friday

4
Thursday

3
Wednesday

2
Tuesday

1
Monday

0
Sunday

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.

Page 184

Revision 2.7

Hand Geometry Unit Technical Manual ExtendedSetupData Table 21: Extended Setup Data Fields
Default Value 0 0 0 5 1 61 0 5 1 61 1 0 0 0 0 0 0 0 0 0 0 0 0 Offset Bytes Field Ready String Serial Mode Aux Output 0 Control Flags Aux Output 1 Control Flags Aux Output 1 Time Aux Output 1 Clear Aux Output 2 Control Flags Aux Output 2 Time Aux Output 2 Clear HandPunch IO Datalog Flag Time Scale Aux Keypad Control Language Type Date Format Ring Count Ring Timeout Ring Delay Default FK Masks Card Digits Language Type 2 Rule Flags Rule Value Grace Value Reserved Total Length Description LCD Line 1 prompt 0=host coms on RS-422, 1=RS-232 Which events activate Aux Out 0 Which events activate Aux Out 1 Timer for Aux Out 1 activation How Aux Out 1 is cleared Time zone for Aux Out 1 activation Which events activate Aux Out 2 Timer for Aux Out 2 activation How Aux Out 2 is cleared Time zone for Aux Out 2 activation Nonzero=Log I/O (HP only) Time base for timers Controls auxiliary keypad Language for menus and printer output Date format for date displays Timeout to reset ring counter if no ring Pause before waiting for next ring Default Fkey masks at enroll time Number of right-most digits to retain Second language for LCD2/TP2 Flags for special rules Expiration value for IN Reserved. Do NOT alter. See Page page 186 page 186 page 187 page 187 page 187 page 187 page 187 page 187 page 187 page 187 page 187 page 188 page 188 page 188 page 189 page 189 page 189 page 190 page 190 page 190 page 190 page 191 page 191 page 191 n/a

14 1 2 2 2 1

0 14 15 17 19 21 22 23 25 27 28 29 30 31 32 33 34 35 36 37 39 40 41 42 44 46

Note 1 page 186

Aux Output 1 Timezone 1 2 2 1

Aux Output 2 Timezone 1 1 1 1 1 1 1 1 1 2 1 1 1 2 2 82 128

Modem units answer after this many rings 0

Minutes by which the TZ can be exceeded 0

Notes
1. 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.

Revision 2.7

Page 185

Hand Geometry Unit Technical Manual

Ready String Offset 0 Size 14

This 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 zeroterminated 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 1

This 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 2

This 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 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Mask 0001H 0002H 0004H 0008H 0010H 0020H 0040H 0080H 0100H 0200H 0400H 0800H 1000H Event TAMPER TZVIOL IDREF DURESS AUXIN1 AUXIN2 DOOR TRYAGAIN F1KEY F2KEY POWER UNLOCK AUXKPD not used not used not used

Page 186

Revision 2.7

Hand Geometry Unit Technical Manual

Aux Output 1 Control Flags Offset 17 Size 2

See Aux Output 0 Control Flags on page 186 for the data field definition.
Aux Output 1 Time Offset 19 Size 2

This 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 1

This 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 1

Setting 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 2

See Aux Output 0 Control Flags on page 186 for the data field definition.
Aux Output 2 Time Offset 25 Size 2

See Aux Output 1 Time for the data field definition.

Aux Output 2 Clear Offset 27 Size 1

See Aux Output 1 Clear for the data field definition.

Aux Output 2 Timezone Offset 28 Size 1

See Aux Output 1 Timezone for the data field definition.

HandPunch IO Datalog Flag Offset 29 Size 1

Setting 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.

Revision 2.7

Page 187

Hand Geometry Unit Technical Manual

Time Scale Offset 30 Size 1

This 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 1

This 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 1

This 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 1 2 3 4 5 6 7 8 9 10 11 12 Page 188

English UK English Japanese French Italian Spanish German Russian Indonesian Portuguese Polish Dutch Slovak Revision 2.7

Hand Geometry Unit Technical Manual

Date Format Offset 33 Size 1

This 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. Table 24: Date Formats
Value Name Example

0 1 2 3 4 5 6

United States Default United States Default International Alpha Dash International Numeric Dash International Numeric Slash United States Numeric Dash Year 2000 Compliant

05/29/98 05/29/98 29-MAY-98 29-05-98 29/05/98 05-29-98 29MAY2000

Ring Count

Offset 34

Size 1

On 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 1

On 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.

Revision 2.7

Page 189

Hand Geometry Unit Technical Manual

Ring Delay Offset 36 Size 1

On 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 2

This 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 1

If 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 1

This field gives the second language to use on a top panel equipped with a graphic LCD.

Page 190

Revision 2.7

Hand Geometry Unit Technical Manual

Rule Flags Offset 41 Size 1

If 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:

Bit 4 3

Effect if non-zero Enforce TZ for IN only (see below); use Grace Value. 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. Enables Level 5 menu to change Bit 1 below. Requires FKey press before ID entry. 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). Unassigned Do not change these bits.

2 1 0

5, 6, 7

Rule Value

Offset 42

Size 2

If bit 0 of Rule Flags above is set, gives expiration value for IN part of rule; otherwise leave 0.
Grace Value Offset 44 Size 2

If using packed time zones for a user (HP 4K only) , number of minutes by which can exceed either end of TZ interval.
Reserved Offset 36 Size 82

These bytes are reserved; do NOT alter these byte fields.

Revision 2.7

Page 191

Hand Geometry Unit Technical Manual ExtendedUserData Table 25: Extended User Data
Field PTI FKMASKS Name UDF Amnesty RESERVED Total Length Bytes 12 2 16 24 1 6 61 Offset 0 12 14 30 54 55

Notes
The 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.

Page 192

Revision 2.7

Hand Geometry Unit Technical Manual ExtendedUserRecord Table 26: Extended User Record, Gross View
Field BUR XUD Total Length Bytes 16 61 77 Offset 0 16

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 27: Extended User Record, Detailed View
Field ID Template Authority Timezone PTI FKMASKS Name Data Amnesty RESERVED Total Bytes 5 9 1 1 12 2 16 24 1 6 77 Offset 0 5 14 15 16 28 30 46 70 71 Description User ID Hand geometry template. Do not alter. Authority and reject override threshold Time zone Packed time intervals Function key use masks User name for display Custom user data Amnesty punch count Reserved. Do not alter.

Revision 2.7

Page 193

Hand Geometry Unit Technical Manual HolidayTable Table 28: Holiday Table Data Structure
Field January February March April May June July August September October November December Total Length Bytes 4 4 4 4 4 4 4 4 4 4 4 4 48 Offset 0 4 8 12 16 20 24 28 32 36 40 44

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 months 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 29: Holiday Table Entries Date January 1 February 28 March 16 Data Structure 01H 00H 00H 00H 00H 00H 00H 08H 00H 80H 00H 00H

Page 194

Revision 2.7

Hand Geometry Unit Technical Manual TimeZone Table 30: Time Zone Table Entry Structure
Field Start 1 Start 2 Start 3 Start 4 Stop 1 Stop 2 Stop 3 Stop 4 DOW 1 DOW 2 DOW 3 DOW 4 Total Length Bytes 1 1 1 1 1 1 1 1 1 1 1 1 12 Offset 0 1 2 3 4 5 6 7 8 9 10 11

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.

Revision 2.7

Page 195

Hand Geometry Unit Technical Manual PackedTimeInterval Table 31: HP-4000 Packed Time Interval Structure
Field BE DOW Total Length Bytes 3 1 4 Offset 0 3

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

Page 196

Revision 2.7

Hand Geometry Unit Technical Manual 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.

Revision 2.7

Page 197

Hand Geometry Unit Technical Manual

Blank page.

Page 198

Revision 2.7

Hand Geometry Unit Technical Manual

5.7

Datalog Formats
On 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 Codes
Some 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.

Revision 2.7

Page 199

Hand Geometry Unit Technical Manual

5.7.2

Time & Attendance ID Verified Datalogs

Time 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. Table 32: Time and Attendance ID Verified Datalog
Field Address Time Stamp Format Data1 Bytes 1 6 1 5 Offset 0 1 7 8 Description Address of unit which generated the datalog Time stamp of datalog (same as HereIsTime) Always 7 (ID Verified) Employee ID One of the following (see note) TA FF 00 01 02 03 04 05 06 07 Data2 5 13 DataB FFFFFFFF 00000000 Department Department Department Department Department Department Department Description no data expected no data entered in back 1 out department back 2 job back 3

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.

Page 200

Revision 2.7

Hand Geometry Unit Technical Manual

5.7.3

Function Key Data Collection Datalogs

On 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
Field Address Time Stamp Format Data1 Data2 Total Length Bytes 1 6 1 5 5 18 Offset 0 1 7 8 13 Description Address of unit which generated the datalog Time stamp of datalog (same as HereIsTime) Always 7 (ID Verified) Employee ID TA code and DataB depend on the menu

Revision 2.7

Page 201

Hand Geometry Unit Technical Manual

5.7.4

Supervisor Override
Time 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
Field Address Time stamp Format Data1 Bytes 1 6 1 5 Offset 0 1 7 8 Description Address of unit which generated the datalog Time stamp of datalog (same as HereIsTime) Always 15 for Supervisor Override Supervisor ID One of the following TA FF 15 Data2 Total Length 5 18 13 DataB FFFFFFFF category Description Punch Bulk

Page 202

Revision 2.7

Hand Geometry Unit Technical Manual

Table 35: Supervisor Override Datalog 2

Field Address Time Stamp Format Data1 Bytes 1 6 1 5 Offset 0 1 7 8 Description Address of unit which generated the datalog Time stamp of datalog (same as HereIsTime) Always 15 for Supervisor Override Employee ID (entered at keypad) One of the following TA FF 00 01 02 03 04 05 06 07 08 09 Data2 5 13 DataB FFFFFFFF 00000000 Department Department Department Department Department Department Department phhhhFmm p$$$$F Description no data expected no data entered in back 1 out department back 2 job back 3 bulk hours bulk dollars

Notes: 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 hs indicate hours and the ms indicate minutes. For TA code 09, the $ indicate dollars and the indicates cents.

Total Length

18

Revision 2.7

Page 203

Hand Geometry Unit Technical Manual

Table 36: Supervisor Override Datalog 3

Field Address Time Stamp Format Data1 Bytes 1 6 1 5 Offset 0 1 7 8 Description Address of unit which generated the datalog Time stamp of datalog (same as HereIsTime) Always 15 for Supervisor Override Always FFFFFFFFFF One of the following TA FF 00 Data2 5 13 04 DataB FFFFFFFF 00000000 Department Description no data expected no data entered entered at keypad

Page 204

Revision 2.7

Hand Geometry Unit Technical Manual

5.7.5

Datalog Format Generation

This 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 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Name Transaction Buffer Empty User Enrolled Identity Unknown Exit Granted Access Denied Identity Verified User Removed Command Mode Entered Command Mode Exited System Re-calibrated Door Forced Open Tamper Activated Supervisor Override Auxiliary Input ON Request To Exit Activated Auxiliary Output ON Baud Rate Changed Messages Read Unit Address Changed Site Code Changed Time and Date Set Lock Setup Passwords Changed Reject Threshold Set Aux Out Setup Changed Printer Setup Changed Data1 0 enrolled ID ID ID ID ID operator ID ID ID ID Data2 0 See page page 206 page 206 page 207 page 207 page 207 page 207 page 207 page 207 page 208 page 208 page 208 page 208 page 208 page 208 page 208 page 209 page 209 page 209 page 209 page 210 page 210 page 210 page 210 page 210 page 211 page 211

see text removed ID

See Section 5.7.4

ID ID ID ID ID ID New threshold ID ID

Revision 2.7

Page 205

Hand Geometry Unit Technical Manual Table 37: Datalog Formats (Continued)
Format 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 Name Extended Datalogs Door Open Too Long Users Listed User Database Saved User Database Restored Amnesty Punch Granted Reject Override Changed Authority Level Changed Operating Mode Changed Output Mode Changed ID Length Changed User Database Cleared Access Refused, Time Restriction Time Zone Data Changed User Time Zone Changed Duress Alarm Lock Output ON Lock Output OFF Aux Output OFF Special Enrollment Aux Unlock via Wiegand Keypad Global Restrictions Changed ID Not In Memory ID In Memory Data1 See Table 38 ID Data2 See page page 211 page 211 page 212 page 212 page 212 page 212 page 212 page 212 page 212 page 213 page 213 page 213 page 213 page 213 page 213 page 213 page 214 page 214 page 214 page 214 page 214 page 214 page 215 page 215

grantee ID changed ID changed ID ID ID ID ID refused ID ID changed ID ID

grantor ID

See text

enrolled ID ID ID ID

enroller ID See text

Datalog Format 0

Transaction Buffer Empty

This 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 Enrolled

This 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

Page 206

Revision 2.7

Hand Geometry Unit Technical Manual

Datalog Format 3 Identity Unknown

This 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 Granted

The 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 5 NOT USED

Datalog Format 6

Access Denied

This indicates that a users 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 Verified

This 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 Removed

This 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 Entered

This 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.

Revision 2.7

Page 207

Hand Geometry Unit Technical Manual

Datalog Format 10 Command Mode Exited

This 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 Recalibrated

Indicates 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 12 NOT USED

Datalog Format 13

Door Forced Open

This 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 Activated

This 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 Override

This is generated by data collected from the Supervisor Override menu, described above in Section 5.7.4 on page 202.
Datalog Format 16 NOT USED

Datalog Format 17

Auxiliary Input ON

This 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 Activated

This 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.

Page 208

Revision 2.7

Hand Geometry Unit Technical Manual

Datalog Format 19 Auxiliary Output ON

This 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 Changed

This 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 units 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 Changed

This indicates a units 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.

Revision 2.7

Page 209

Hand Geometry Unit Technical Manual

Datalog Format 23 Site Code Changed

This indicates a units 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 Set

This indicates a units 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 units clock caused by commands from a host system do not generate any datalogs.
Datalog Format 25 Lock Setup

This indicates a units 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 Changed

This indicates a units 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 Set

This indicates a units 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.

Page 210

Revision 2.7

Hand Geometry Unit Technical Manual

Datalog Format 28 Aux Out Setup Changed

This indicates a units 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 Changed

This indicates a units 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 Datalogs

This 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. Table 38: Extended datalog codes
TA DataB Data1 Meaning

1 1 2 2 3 3 4 99

1 2 1 2 1 2 1 varies

id id FF FF FF FF FF FF

Language changed by command menu Date format changed by command menu Line power lost, running on battery Line power restored Clocks hour incremented due to daylight savings time adjustment Clocks hour decremented due to daylight savings time adjustment Wrong-length FKey program received and ignored Unit was reset. DataB contains information on the cause of the reset

Datalog Format 31

Door Open Too Long

This 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.

Revision 2.7

Page 211

Hand Geometry Unit Technical Manual

Datalog Format 32 Users Listed

This 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 Saved

This 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 Restored

This 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 Changed

This 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 Changed

This 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 Changed

This indicates a units 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.

Page 212

Revision 2.7

Hand Geometry Unit Technical Manual

Datalog Format 39 Output Mode Changed

This indicates a units 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 Changed

This indicates a units 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 Cleared

This indicates a units 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 Restriction

This 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 Changed

This 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 Changed

This indicates that a users 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 Alarm

This 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.

Revision 2.7

Page 213

Hand Geometry Unit Technical Manual

Datalog Format 46 Lock Output ON

This 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 OFF

This 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 OFF

This 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 Enrollment

This 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 Keypad

This 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 Changed

This 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.

Page 214

Revision 2.7

Hand Geometry Unit Technical Manual

Datalog Format 52 ID Not In Memory

This 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 Memory

This 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.

Revision 2.7

Page 215

Hand Geometry Unit Technical Manual

Blank page.

Page 216

Revision 2.7

Hand Geometry Unit Technical Manual

6.0
6.1

Examples of Standard Operation

Introduction
This 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

// /* ... */ {} = == & | ~ << >> AND, OR, NOT int f (void) void g (int) [] int, long, unsigned, BYTE

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 <<. Logical AND, OR, NOT. Used in conditional expressions to test for truth values. Not the same as bitwise operations. 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 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.

Revision 2.7

Page 217

Hand Geometry Unit Technical Manual

6.2

Checking Status
To 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 FFs before and after the data are for RS-485 line driver turnaround time and may be omitted. Table 40: Detailed Example of SendStatus Command
FCS Mode Address Bytes

CRC CRC Checksum Checksum

0 1 0 1

FF 0A 00 44 00 08 C1 FF FF 0A 01 44 00 38 F6 FF FF 0A 00 3B 00 C5 FF FF 0A 01 3B 00 C4 FF

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. Table 41: Example of Response to SendStatus Command
FCS Mode Bytes

CRC Checksum

FF 0A FF 30 03 00 82 1E 88 4D FF FF 0A FF 30 03 00 82 1E 2E FF

6.3

Unit Setup
A 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.

Page 218

Revision 2.7

Hand Geometry Unit Technical Manual

6.3.1

Setup Data
A 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 units 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 Passwords Access 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.

Revision 2.7

Page 219

Hand Geometry Unit Technical Manual 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 Communications The 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. Door Controls For 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 Outputs Many 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.1.3

Page 220

Revision 2.7

Hand Geometry Unit Technical Manual

6.3.2

Time Zones
Fundamental 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

Clock
Units 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 Users
Users 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.

Revision 2.7

Page 221

Hand Geometry Unit Technical Manual 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 users 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 users 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

Page 222

Revision 2.7

Hand Geometry Unit Technical Manual for this. The simplest is not to do it at all, which does work reasonably well in many cases, but if a users 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 users 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 Users
Removing users is somewhat easier than adding them, but there are some complexities. The RemoveUser command deletes a user record from the units 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 users 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 Data

All 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

Revision 2.7

Page 223

Hand Geometry Unit Technical Manual 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 Enrollment
As 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 highlevel 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 users 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

Page 224

Revision 2.7

Hand Geometry Unit Technical Manual 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 Verification
Two 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 Off

Normally, 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.

Revision 2.7

Page 225

Hand Geometry Unit Technical Manual

6.10

Retrieving Transactions
This 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 Transactions

There 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 Datalogs

Applications 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.

Page 226

Revision 2.7

Hand Geometry Unit Technical Manual 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 PCs 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.

Revision 2.7

Page 227

Hand Geometry Unit Technical Manual

// // // // 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; }

Figure 4: Pseudo-code for Downloading Transactions.

6.10.3

Handling Menu-Initiated Punches

Model 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

Page 228

Revision 2.7

Hand Geometry Unit Technical Manual 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 Punching The 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 users 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. Firmware Dated After 4/18/2000 PROM Revision 60 This 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. Firmware Dates Prior to 4/18/2000 PROM Revisions 59 and Earlier Two 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.10.3.3

6.10.3.4

Revision 2.7

Page 229

Hand Geometry Unit Technical Manual

6.11

User Database Backup and Restore

To backup a units 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 Mode
Before 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

Backup
For 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 units 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 HP3K-A HP3K-B HP3K-C HP4K-B HP4K-C E-SA E-SB E-LA E-LB

2 2 38 127 10 66 1 13 38 109

Page 230

Revision 2.7

Hand Geometry Unit Technical Manual 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 units 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.

Revision 2.7

Page 231

Hand Geometry Unit Technical Manual

// // // // 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; else RecordSize = 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; }

Figure 5: Pseudo-Code for User Database Backup 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.

Page 232

Revision 2.7

Hand Geometry Unit Technical Manual

6.11.3

Restore
Restoring 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.

Revision 2.7

Page 233

Hand Geometry Unit Technical Manual

Returns number of banks transferred The 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;

Figure 6: Pseudo-Code for Database Restore 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 Unit

To 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.

Page 234

Revision 2.7

Hand Geometry Unit Technical Manual 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
6.13.1

Examples of Packing and Unpacking Binary Data Fields

High Bit in Type Field
The 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.
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. */ }

Figure 7: Setting and Testing the High Bit in the Type Field 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.

Revision 2.7

Page 235

Hand Geometry Unit Technical Manual

6.13.2

User Record Authority Field

The 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.
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 authority RejectOverride = (authority >> 3) * 10; /* continue processing as needed */ }

Figure 8: Extracting and Setting the Authority Byte Fields 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.

Page 236

Revision 2.7

Hand Geometry Unit Technical Manual

6.13.3

HP-4000 Time Intervals

The 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.
unsigned start, stop; unsigned char dow; unsigned long pti; void func (void) { /* start, stop, and dow are initialized somehow, and we want to 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 into a 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; }

Figure 9: Packing and Unpacking HandPunch 4000 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.

Revision 2.7

Page 237

Hand Geometry Unit Technical Manual

6.13.4

DOW Masks for Time Zones and Time Intervals

The 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.
BYTE SetDOW (BYTE dow, int day) { return dow | (1 << day); } int TestDOW (BYTE dow, int day) { if (dow & (1<<day) == 0) return 0; else return 1; }

Figure 10: Setting and Testing Bits in the DOW Mask

Page 238

Revision 2.7

Hand Geometry Unit Technical Manual

6.13.5

Holiday Table
Probably 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.
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; }

Figure 11: Setting and Testing Bits in the Holiday Table 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.

Revision 2.7

Page 239

Hand Geometry Unit Technical Manual

6.13.6

Bell Schedule
The 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.
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 bits min = min & 0x3F; // limit minute to 6 bits dur = 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; }

Figure 12: Creating a Bell Schedule Entry

Page 240

Revision 2.7

Hand Geometry Unit Technical Manual

6.14
6.14.1

Function Key Menus

Introduction
The 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 State

The 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 Collection

Each 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 Datalog

On 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.

Revision 2.7

Page 241

Hand Geometry Unit Technical Manual 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 Only
Implementing 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
6.15.1.1

Messages
Adding Messages 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. Removing Messages are removed from the message pool with the RemoveUserMessage command. Clearing All The entire message pool can be cleared at once, for all users, with the ClearUserMessages command.

6.15.1.2

6.15.1.3

6.15.2
6.15.2.1

User Database Management

Adding Users Users 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.

Page 242

Revision 2.7

Hand Geometry Unit Technical Manual 6.15.2.2 Removing Users Users 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. Sending Only the Extended User Data to an Existing User Record If 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. Sending Only the Data for Function Key Menu Display The 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 Record The 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.

6.15.2.3

6.15.2.4

Revision 2.7

Page 243

Hand Geometry Unit Technical Manual

Blank page.

Page 244

Revision 2.7

Hand Geometry Unit Technical Manual

7.0
7.1
7.1.1

Miscellaneous Reference
Connector Pinouts
Model E Terminal Strips
The 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

+ Power Ground RS-232 Rx Gnd RS-232 Tx RS-422 RxRS-485 RTRS-422 Rx+ RS-485 RT+ RS-422 TxRS-422 Tx+ Aux Output Card Output D0 or DATA Gnd Lock Output Card Output D1 or CLK Door Switch Input Gnd Aux Input Gnd Rex Switch Input +5V power to card reader Card Input D0 or DATA Not used Card Input D1 or CLK Gnd

+ Power Ground RS-232 Rx Gnd RS-232 Tx RS-422 RxRS-485 RTRS-422 Rx+ RS-485 RT+ RS-422 TxRS-422 Tx+ Aux Output Bell Output Gnd Lock Output Not Used Gnd Not Used Gnd Rex Switch Input +5V power to card reader Card Input D0 or DATA Not used Card Input D1 or CLK Gnd

Revision 2.7

Page 245

Hand Geometry Unit Technical Manual 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 Strips

Table 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.

Page 246

Revision 2.7

Hand Geometry Unit Technical Manual Table 44: Model F Connector Pinouts
Pin HP3K HP4K HK2 HKCR

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Note 1 Note 1 Note 2 Note 2 Note 2 Note 2 Rex Switch GND Door Switch GND Aux In 1 GND Aux In 2 GND +5V Out D0/DATA In D1/CLK In GND Lock D1/CLK Out GND AuxOut0/ Bell D0/DATA Out GND AuxOut1 GND AuxOut2 GND

Note 1 Note 1 Note 2 Note 2 Note 2 Note 2 Rex Switch GND Door Switch GND Aux In 1 GND Aux In 2 GND +5V Out D0/DATA In D1/CLK In GND Lock D1/CLK Out GND AuxOut0/ Bell D0/DATA Out GND AuxOut1 GND AuxOut2 GND

+ Power - Power RTRT+ TXTX+ Rex Switch GND Door Switch GND Aux In 1 GND Aux In 2 GND +5V Out D0/DATA In D1/CLK In GND Lock D1/CLK Out GND AuxOut0 D0/DATA Out

+ Power - Power RTRT+ TXTX+

+5V Out D0/DATA In D1/CLK In GND Lock D1/CLK Out GND AuxOut0 D0/DATA Out

20 21

22 23 24 25 26

GND AuxOut1 GND AuxOut2 GND

GND AuxOut1 GND AuxOut2 GND

Revision 2.7

Page 247

Hand Geometry Unit Technical Manual

7.1.3
7.1.3.1

Model F Additional Connectors

RJ-45 RS-232 Connector The 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. Table 45: Model F RJ-45 RS-232 Connector Pinout
Pin Function

1 2 3 4 5 6 7 8 7.1.3.2

RI (not currently supported) CD (not currently supported) DTR (not currently supported) GND RX (data into unit) TX (data out of unit) CTS (not currently supported) RTS (not currently supported)

RJ-11 RS-422/RS-485 Some 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. Table 46: Model F RJ-11 RS-422/485 Connector Pinout
Pin Function RS-422 Function RS-485

1 2 3 4 7.1.3.3

RX+ RXTXTX+

RT+ RTnot used not used

RJ-45 Ethernet Connector The connector on the optional Ethernet board is a standard EIA-568B RJ-45 connector.

Page 248

Revision 2.7

Hand Geometry Unit Technical Manual 7.1.3.4 Power Connector The 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 Map

In 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.
0 1 ! 0 @ P p 1 A Q a q 2 " 2 B R b r 3 # 3 C S c s 4 $ 4 D T d t 5 % 5 E U e u 6 & 6 F V f v 7 ' 7 G W g w 8 ( 8 H X h x x 9 ) 9 I Y i y
-1

A * : J Z j z

B + ; K [ k {

C , < L l |

D = M ] m }

E . > N ^ n

F / ? O _ o

2x 3x 4x 5x 6x 7x Ex Fx

Table 47: LCD Character Codes 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.

Revision 2.7

Page 249

Hand Geometry Unit Technical Manual

7.3
7.3.1

Behavior on Reset
Types of Reset
There 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
7.3.2.1

Data Displayed on Reset

Model F Units Model 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. Model E Units Model E units will not indicate whether they are booted cold, warm, or normal. They will display the PROM ID and card format.

7.3.2.2

Page 250

Revision 2.7

Hand Geometry Unit Technical Manual

7.3.3

Additional Reset Display Data

Pressing 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 Datalog
Model 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/00 The 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 bytes 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.

Revision 2.7

Page 251

Hand Geometry Unit Technical Manual Table 48: Reset Datalog Data for Model F Firmware Before 4/20/00
Field Location

DIP SW4 DIP SW5 EEPROM failed Cal data invalid Software Reset 7.3.4.2

Most-significant half of byte 4/4 = 1 if switch is OFF. Least-significant half of byte 4/4 = 1 if switch is OFF. Bit 0 of byte 3/4 is 1 if failure Bit 1 of byte 3/4 is 1 if invalid Bit 7 of byte 4/4 is set (not seen in field)

Firmware Dates 4/20/00 and Later On 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 49: Reset Datalog Data for Model F Firmware Dated 4/20/00 and Later
Byte Contents

1 of 4

2 of 4

3 of 4

4 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. 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 boot Bit 1 = cold boot Note that a cold boot implies that the warm boot steps also occur, regardless of the setting of the warm boot bit. 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. Boot status. This contains the same data as the previous firmware versions, as shown in Table 48.

Page 252

Revision 2.7

Hand Geometry Unit Technical Manual

7.3.5

Data Integrity Checking

The 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.. Table 50: Most Common Data Integrity Warnings
Code Meaning Likely cause Action taken

48 64 112

17,18,19

SRAM is good, EEPROM is bad EEPROM is good, SRAM is bad Both EEPROM and SRAM are bad, but cal data is good. Unit was reset in the middle of a data transfer, but all data is OK

ESD damage to EEPROM Lithium battery dead or changed Firmware update on pre-data integrity unit. This is normal. Unknown.

SRAM overwrites EEPROM, unit reboots EEPROM overwrites SRAM, unit reboots EEPROM overwrites SRAM, unit reboots. None. This is harmless and is for information only.

7.3.6

Model Errors
In 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.

Revision 2.7

Page 253

Hand Geometry Unit Technical Manual 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. Table 51: Model Errors
Digit Position Value Meaning

First Second

Third

0-4 0 1 2 0 1 2 3 4 5

Obsolete, no meaning, but should be in this range 128K memory detected 256K memory detected 640K memory detected Memory and model detection was successful Model number is invalid Memory option detected is not valid Memory configuration not supported in this model No memory allocated to datalogs No memory allocated to users

7.4

Auxiliary Keypad
There 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.

Page 254

Revision 2.7

Hand Geometry Unit Technical Manual 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 Codes
A 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 Issues
Fortunately, 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 threedigit 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.

Revision 2.7

Page 255

Hand Geometry Unit Technical Manual

Blank page.

Page 256

Revision 2.7

Hand Geometry Unit Technical Manual

8.0

Glossary
Amnesty 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 elses 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.

Revision 2.7

Page 257

Hand Geometry Unit Technical Manual 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 dayof-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.

Page 258

Revision 2.7

Hand Geometry Unit Technical Manual

9.0
9.1

Appendices
CRC Generator Program
The 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 = XMODEMcrc('H', crc = XMODEMcrc('E', if (crc != 0x1E0A) printf("Test case 3

crc); crc); crc); 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;

Revision 2.7

Page 259

Hand Geometry Unit Technical Manual

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; }

Page 260

Revision 2.7

Hand Geometry Unit Technical Manual

9.2

PC Serial Port Pinouts

For convenience, the RS-232 serial port pinouts for the 25-pin and 9-pin connectors are shown in Table 52.

Table 52: RS-232 Port Pinouts

Function 25-Pin 9-Pin

CD RX (DCE to DTE) TX (DTE to DCE) DTR GND DSR RTS CTS RI

8 3 2 20 7 6 4 5 22

1 2 3 4 5 6 7 8 9

9.3

RS-232 Electrical Specification

A 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. Table 53: Some Important RS-232 Electrical Specifications
Parameter Specification

Driver Output Voltage Receiver Input Voltage Data Rate

-5V to -15V for 1, +5V to +15V for 0 -3V to -15V for 1, +3V to +15V for 0 Up to 20Kbps, for 3K<RL<7K and CL<2500pF.

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 Specification

A 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.

Revision 2.7

Page 261

Hand Geometry Unit Technical Manual

Table 54: Some Important RS-422/485 Electrical Specifications

Parameter Specification

Output voltage Data rate

2V min at 50 ohms, 1.5V min at 27 ohms. 5V max The HGU is software-limited to 19200 bps for reliable communications. This is not a limit of the RS-422 specification. 4000 feet. Wide variety is acceptable. Preferably AWG22-28, twisted pair. 6. Preferably, zero. The best thing is to make the stub connection at the HGU terminal strips 32. Some units have 1/4 load drivers and can support more drops. Contact RSI for more details if necessary. Depends on cable. For AWG28 twisted pair, typically 120 ohms. -7V to +12V relative to local ground

Cable length Cable type Stub length Number of drops Termination resistance Common mode voltage

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 Connection

For 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.

Page 262

Revision 2.7

Hand Geometry Unit Technical Manual

9.6

Card Reader Interface

The 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
9.6.1.1

Wiegand
Description Although 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. Input Timing The 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.2

9.6.1.3

Output Timing The 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. Data Format Units 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.1.4

Revision 2.7

Page 263

Hand Geometry Unit Technical Manual

9.6.2

Magstripe
A 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 Levels Typically, 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 Levels The 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 Clock Low Time Clock High Time Data Setup to Clock Edge Data Hold from Clock Edge

TCLK TLO THI TDSU TDHD

750-850 s 250-450 s 400-550 s 200-250 s 200-250 s

Page 264

Revision 2.7

Hand Geometry Unit Technical Manual

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 Format The 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.

Revision 2.7

Page 265

Hand Geometry Unit Technical Manual

9.6.3

Hand Punch 4000 Integrated Bar Code Sensor

The 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 Number The 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 Geometry The 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. Uniformity of Widths There 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

9.6.3.3

Page 266

Revision 2.7

Hand Geometry Unit Technical Manual more than 1.5 times the width of the characters 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 Characteristics Any 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 Defects Defects 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 HP4000 cannot tolerate any kind of defect within the symbol location defined above. Symbol Grade The 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.6

Revision 2.7

Page 267

Hand Geometry Unit Technical Manual 9.6.3.7 Specifications Summary Table 56: HP-4000 Integrated Bar Code Reader Specifications
Characteristic Value

Resolution Wavelength PCS value Scan speed W/N ratio Symbol Grade

6 mils 890 nm > 0.3 150 to 2000 mm/sec 2.2 to 3.0 recommended, must be 2.0 to 4.0 ANSI grade C or better recommended

Page 268

Revision 2.7

Hand Geometry Unit Technical Manual

10.0

Index
NextMessageIsBellScheduleTable, 119 NextMessageIsTimeZones, 120 OutputControl, 121 PrinterPassThrough, 122 RemoveUserMessages, 123 RemoveUserRecord, 124 Resume, 125 SendCalibrationData, 126 SendDataBank, 128 SendDatalog, 129 SendExtendedSetup, 130 SendExtendedUserRecord, 131 SendInternalErrorLog, 132 SendKeypadData, 133 SendLastUserRecord, 135 SendOEMCode, 136 SendPreviousDatalog, 137 SendReaderInfo, 138 SendResults, 139 SendSetup, 140 SendStatusChecksum, 141 SendStatusCRC, 142 SendTemplate, 143 SendTimeAndDate, 144 SendTimeZones, 145 SendUserRecord, 146 SetExtendedUserData, 147 SetUserData, 148 UpdateNVRAM, 149 VerifyOnExternalData, 150 VerifyOnInternalData, 151 Commands Ancillary, 82 Configuration, 81 Enrollment, 79 Function Key, 82 Hardware Control, 81 HP-4000 ONLY, 82 Maintenance, 81 Results, 80 SendCardData 127 Special, 82 Status Functions, 79

A Amnesty Punch, 71 Ancillary Commands Abort, 94 Beep, 96 EmitKeypadTestData, 101 EnterIdleMode, 103 EnterIdleMode2, 104 HereIsBankNumber, 106 LEDControl, 118 NextMessageIsBellScheduleTable, 119 NextMessageIsTimeZones, 120 Resume, 125 SendInternalErrorLog, 132 UpdateNVRAM, 149 Auxiliary Keypad, 254 C Command AbortCommand, 94 AddUserMessage, 95 Beep, 96 Calibrate, 97 ClearUserDatabase, 98 ClearUserMessages, 99 DisplayCodedMessage, 100 EmitKeypadTestData, 101 EnrollUser, 102 EnterIdleMode, 103 EnterIdleMode2, 104 HereAreTimeZones, 105 HereIsBankNumber, 106 HereIsBellScheduleTable, 107 HereIsDataBank, 108 HereIsDecisionMenuData, 109 HereIsDisplayMessage, 110 HereIsExtendedSetup, 112 HereIsExtendedUserRecord, 113 HereIsSetup, 114 HereIsSmartCardRecord, 115 HereIsTime, 116 HereIsUserRecord, 117 LEDControl, 118

Revision 2.7

Page 269

Hand Geometry Unit Technical Manual Transaction Log Management, 81 Undocumented, 82 User Database Backup, 80 User Database Management, 80 Commands, 93 Commands, Hand Verification, 80 Communication Ethernet, 30 Modem, 29 RS-232, 27 RS422/RS-485, 28 Communication Protocol, 36 Configuration Commands HereAreTimeZones, 105 HereIsBellScheduleTable, 107 HereIsExtendedSetup, 112 HereIsSetup, 114 HereIsTime, 116 SendExtendedSetup, 130 SendSetup, 140 SendTimeZones, 145 Connector Pinouts Model E, 245 Model F, 246 Connector Pinouts, 245 Controlling Outputs, 64 CRC Generator Program, 259 D Data Communications Equipment, 27 Data Structure BasicSetupData, 173 BasicUserRecord, 181 BellSchedule, 182 Datalog, 183 DOW Mask, 184 ExtendedSetup DataAux Output 1 Timezone, 187 DataAux Output 2 Timezone, 187 ExtendedSetupData Aux Output 1 Clear, 187 Aux Output 1 Control Flags, 187 Aux Output 1 Time, 187 Aux Output 2 Clear, 187 Aux Output 2 Control Flags, 187 Aux Output 2 Time, 187 Aux Output Control Flags, 186 Auxiliary Keypad Control, 188 Card Digits, 190 Date Format, 189 Default FKey Masks, 190 Grace Value, 191 HandPunch IO Datalog Flag, 187 Language Type 2, 190 Language, 188 Ready String, 186 Ring Count, 189 Ring Delay, 190 Ring Timeout, 189 Rule Flags, 191 Rule Value, 191 Serial Mode, 186 Time Scale, 188 ExtendedSetupData, 185 ExtendedUserData, 192 ExtendedUserRecord, 193 HolidayTable, 194 PackedTimeInterval, 196 TimeZone, 195 Data Structures BasicSetupData 24-Hour Time Flag, 180 Accounting Mode, 178 Aux Alarm Flags, 176 Aux Duress Flag, 179 Aux Flag Clear, 175 Aux Timeout, 175 Aux Timezone, 178 Beeper Flag, 178 Daylight Savings Time Off, 179 Daylight Savings Time On, 179 Duress Character, 179 Facility Code, 177 HGU Address, 177 ID Length, 178 Lock Time, 176 Network Baud Rate, 176 Number of Tries, 179 Operating Mode, 177 Option Flags, 180

Page 270

Revision 2.7

Hand Geometry Unit Technical Manual Output Mode, 178 Password, 175 Print Flag, 175 Printer Baud Rate, 176 Shunt Time, 176 Status Flag, 176 Threshold, 175 Unlock Timezone, 178 Data Terminal Equipment, 27 Datalog Formats Function Key Data Collection Datalogs, 201 Generation Access Denied, 207 Access Refused - Time Restriction, 213 Amnesty Punch Granted, 212 Authority Level Changed, 212 Aux Out Setup Changed, 211 Aux Output Off, 214 Aux Unlock via Wiegand Keypad, 214 Auxiliary Input On, 208 Auxiliary Output On, 209 Baud Rate Changed, 209 Command Mode Entered, 207 Command Mode Exited, 208 Door Forced Open, 208 Door Open Too Long, 211 Duress Alarm, 213 Exit Granted, 207 Extended Datalogs, 211 Global Restrictions Changed, 214 ID In Memory, 215 ID Length Changed, 213 ID Not In Memory, 215 Identity Unknown, 207 Identity Verified, 207 Lock Output Off, 214 Lock Output On, 214 Lock Setup, 210 Messages Read, 209 Operating Mode Changed, 212 Passwords Changed, 210 Printer Setup Changed, 211 Reject Override Changed, 212 Reject Threshold Set, 210 Request to Exit Activated, 208 Site Code Changed, 210 Special Enrollment, 214 Supervisor Override, 208 System Recalibrated, 208 Tamper Activated, 208 Time and Date Set, 210 Time Zone Data Changed, 213 Transaction Buffer Empty, 206 Unit Address Changed, 209 User Database Cleared, 213 User Database Restored, 212 User Database Saved, 212 User Enrolled, 206 User Removed, 207 User Time Zone Changed, 213 Users Listed, 212 Generation, 205 GenerationOutput Mode Changed, 213 Supervisor Override, 202 TA Codes, 199 Time and Attendance ID Verified Datalogs, 200 Datalog Formats, 199 DCE, 27 DLL Manual, 10 Documents DLL Manual, 10 Function Key Compiler Manual, 10 Product Manuals, 11 Door Control, 61 DTE, 27 Duress Code, 255 E Enrollment Commands EnrollUser, 102 HereIsSmartCardRecord 115 Enrollment, 55 Errors Model, 253

Revision 2.7

Page 271

Hand Geometry Unit Technical Manual F False Accept, 17 False Reject, 17 Function Key Compiler Manual, 10 Function Key Menu Commands HereIsDecisionMenuData, 109 Function Key Menu, 66 G Grounding Earth Ground, 33 Floating Power Supplies, 32 Grounding, 31 H Hand Geometry Unit Applications, 25 Card Reader Interface Bar Code, 266 Magstripe, 264 Wiegand, 263 Card Reader Interface, 20, 263 Command Mode, 17 Command Protocol, 24 Communication Ethernet, 23 Modem, 23 RS-232, 22 RS-422/RS-485, 23 TCP/IP, 23 Communication, 22 Description, 13 DIP Switch Settings, 262 Door Control, 19 Events and States, 19 Function Keys, 19 ID Entry, 18 Inputs, 20 Memory, 20 Operating Mode, 17 Outputs, 20 Power Management, 21 System Configuration, 21 Time Restrictions, 19 Transaction Log, 18 User Database, 18 Verification, 18 Hand Geometry Unit, 13 Hand Verification Failed, 59 Successful, 59 Hand Verification Commands VerifyOnExternalData, 150 VerifyOnInternalData, 151 Hand Verification, 59 Hardware Control Commands DisplayCodedMessage, 100 HereIsDisplayMessage, 110 OutputControl, 121 PrinterPassThrough, 122 Holidays, 58 HP-4000 Commands AddUserMessage, 95 ClearUserMessages, 99 HereIsExtendedUserRecord, 113 RemoveUserMessages, 123 SendExtendedUserRecord, 131 SetExtendedUserData, 147 SetUserData, 148 I Identification, 16 Identity Verification, 16 L LCD Character Map, 249 M Maintenance Commands Calibrate, 97 SendCalibrationData, 126 Model Errors, 253 P PC Serial Port Pinouts, 261 Product Manuals, 11 Pseudo-code, 217

Page 272

Revision 2.7

Hand Geometry Unit Technical Manual R Real Time Clock, 77 Receiver State Machine, 40 Reset Behavior, 250 Responses HereAreResults, 154 HereAreTimeZones, 155 HereIsCalibrationData, 156 HereIsCardData 157 HereIsDataBank, 158 HereIsExtendedSetupData, 159 HereIsExtendedUserRecord, 160 HereIsKeypadData, 161 HereIsMyTime, 162 HereIsNextDatalog, 163 HereIsOEMCode, 164 HereIsReaderInfo, 165 HereIsSetupData, 167 HereIsStatus, 168 HereIsTemplateVector, 170 HereIsUserRecord, 171 UnableToCompleteCommand, 172 Results Buffer, 56 Results Commands SendLastUserRecord, 135 SendResults, 139 SendTemplate, 143 RS-232 Electrical Specification, 261 RS-422/RS-485 Electrical Specification, 261 S Score, 63 Shielding - See Grounding 31 Standard Operation Adding Users, 221 Changing User Data, 223 Checking Status, 218 Complete Unit Backup, 234 Function Key Menus, 241 HP-4000 Only, 242 Remote Enrollment, 224 Remote Verification, 225 Removing Users, 223 Retrieving Transactions, 226 Turning Outputs On or Off, 225 Unit Setup Clock, 221 Time Zones, 221 Unit Setup Data, 219 Unit Setup, 218 User Database Backup and Restore, 230 Standard Operation, 217 Status Commands SendStatusChecksum, 141 SendStatusCRC, 142 Status Functions Commands SendCardData 127 SendKeypadData 133 SendOEMCode, 136 SendReaderInfo, 138 SendTimeAndDate, 144 T Template Score, 63 Template Buffer, 56 Template, 16, 63 Threshold Level False Accept, 17 False Reject, 17 Threshold Level, 17 Time Intervals, 58, 69 Time Zones, 58 Transaction Log, 63 Transactions Log Management Commands SendDatalog, 129 SendPreviousDatalog, 137 Troubleshooting Modes, 74 U User Background, 9 User Database Backup Commands HereIsDataBank, 108 SendDataBank, 128 User Database Management SendUserRecord, 146 User Database Management Commands ClearUserDatabase, 98 HereIsUserRecord, 117 RemoveUserRecord, 124

Revision 2.7

Page 273

Hand Geometry Unit Technical Manual Y Y2K Issues, 255

Page 274

Revision 2.7