gds printer communications

8/8/2019 GDS Printer Communications

1/83

GDSPrinter:Communication Protocol v1.0.3

(Includes Errata Sheet 1)

Implemented as USB HID Class Device

Document ID: gsa-p0069.001.03

Gaming Standards AssociationGDS Technical Committee

v1.0 Standard Adopted: 2006/03/23

Document Released: 2008/01/22

This version includes changes defined in Errata Sheet 1, which is included in the

package with this document. Errata Sheet 1 describes changes that are

recommended to be made to GDS Printer: Communication Protocol v1.0, which

was released March 23, 2006. These changes have been recommended by the

GDS Technical Committee and will be scheduled for submission to the GSA

membership for approval.

www.gamingstandards.com


2/83

GDSPrinter: Communication Protocol v1.0.3, gsa-p0069.001.03

Released on 2008/01/22, by Gaming Standards Association (GSA).

Patents and Intellectual Property

NOTE: The user's attention is called to the possibility that compliance with this [standard/specification] may require use of an invention covered by patent rights. By publication of this[standard/specification], GSA takes no position with respect to the validity of any such patent rightsor their impact on this [standard/specification]. Similarly, GSA takes no position with respect to theterms or conditions under which such rights may be made available from the holder of any such rights.Contact GSA for further information.

Trademarks and Copyright

Copyright 2005 - 2008 Gaming Standards Association (GSA). All rights reserved. All trademarksused within this document are the property of their respective owners. Gaming Standards Associationand the puzzle-piece GSA logo are registered trademarks and/or trademarks of the Gaming StandardsAssociation.

This document may be copied in part or in full provided that ALL copies retain the copyright and anyother proprietary notices contained on the materials. NO material may be modified, edited or takenout of context such that its use creates a false or misleading statement or impression as to thepositions, statements or actions of GSA.

GSA Contact Information

GSA Gaming Standards AssociationE-mail: [email protected]

WWW: http://www.gamingstandards.com


3/83

GDSPrinter:Communication Protocol v1.0.3 Table of Contents

gsa-p0069.001.03 Released: 2008/01/22 Page i

2005 - 2008 Gaming Standards Association (GSA)

I About This Document........................................................................................... v

I.I GDS (Gaming Device Standards) ....................................................................................... vI.II Acknowledgements ............................................................................................................ v

I.III Related Documents ........................................................................................................... v

I.III.I GSA........................................................................................................................... v

I.III.II USB......................................................................................................................... vi

I.III.III ISO......................................................................................................................... vi

I.III.IV Other References .................................................................................................. vi

I.IV Document Conventions................................................................................................... viiI.V Document Organization ................................................................................................... vii

I.V.I Command and Event Detail Organization .............................................................. viii

1 Introduction .......................................................................................................... 1

1.1 Printer Function Overview ................................................................................................ 11.2 USB Compliance and Benefits ......................................................................................... 11.3 Printers as HID Class Devices ......................................................................................... 2

1.4 Device Firmware Upgrade (DFU) ..................................................................................... 2

2 GDS Peripheral Common Design Characteristics ............................................ 3

2.1 Hardware: Communications ............................................................................................. 3

2.2 Hardware Power-Loss and Non-Reproducible Data Recovery ........................................ 3

2.2.1 Non-Volatile Memory............................................................................................... 3

2.2.2 Power Fail Signaling ............................................................................................... 32.3 Software: USB Classification............................................................................................ 3

2.4 Software: Communications Overview............................................................................... 3

2.4.1 Report Delivery and Priority .................................................................................... 42.4.2 Command................................................................................................................ 4

2.4.3 Event ....................................................................................................................... 4

2.4.4 Event Acknowledgement......................................................................................... 5

2.4.5 Power Up Sequence ............................................................................................... 6

2.4.6 Device and Host Interaction .................................................................................... 6

3 Command Support ............................................................................................... 7

3.1 Command Execution When Enabled/Disabled................................................................. 8

3.2 Report 0x01 ACK.............................................................................................................. 9

3.2.1 Transaction ID Rules............................................................................................... 93.3 Report 0x02 Enable........................................................................................................ 10

3.4 Report 0x03 Disable ....................................................................................................... 103.5 Report 0x04 Self Test..................................................................................................... 113.6 Report 0x05 Request GAT Report ................................................................................. 11

3.7 Report 0x08 Calculate CRC ........................................................................................... 123.8 Report 0xC0 Define Region............................................................................................ 13

3.8.1 Define Region Rules ............................................................................................. 13

3.9 Report 0xC1 Define Template ........................................................................................ 14

Table of Contents
http:///reader/full/page24http:///reader/full/page23http:///reader/full/page23http:///reader/full/page22http:///reader/full/page21http:///reader/full/page21http:///reader/full/page20http:///reader/full/page20http:///reader/full/page19http:///reader/full/page19http:///reader/full/page18http:///reader/full/page17http:///reader/full/page16http:///reader/full/page16http:///reader/full/page15http:///reader/full/page14http:///reader/full/page14http:///reader/full/page14http:///reader/full/page13http:///reader/full/page13http:///reader/full/page13http:///reader/full/page13http:///reader/full/page13http:///reader/full/page13http:///reader/full/page13http:///reader/full/page12http:///reader/full/page12http:///reader/full/page11http:///reader/full/page11http:///reader/full/page11http:///reader/full/page10http:///reader/full/page9http:///reader/full/page9http:///reader/full/page8http:///reader/full/page8http:///reader/full/page8http:///reader/full/page7http:///reader/full/page7http:///reader/full/page7http:///reader/full/page7http:///reader/full/page7


4/83


gsa-p0069.001.03 Released: 2008/01/22 Page ii


3.9.1 Define Template Rules.......................................................................................... 143.10 Report 0xC2 Print Ticket .............................................................................................. 15

3.10.1 Print Ticket Rules ................................................................................................ 163.11 Report 0xC3 Form Feed ............................................................................................... 16

3.12 Report 0xC7 Request Printer Metrics........................................................................... 17

3.13 Report 0xC9 Graphic Transfer Setup ........................................................................... 17

3.13.1 Graphic Transfer Setup Rules............................................................................. 173.14 Report 0xCA File Transfer............................................................................................ 18

4 Event Support..................................................................................................... 20

4.1 Connection/Disconnection of Communications.............................................................. 204.2 Connection/Disconnection of Power............................................................................... 204.3 Report 0x06 Power Status.............................................................................................. 21

4.3.1 Rules for Power Status ......................................................................................... 21

4.4 Report 0x07 GAT Data ................................................................................................... 224.5 Report 0x09 CRC Data................................................................................................... 23

4.5.1 CRC Rules ............................................................................................................ 23

4.6 Report 0x0A Device State .............................................................................................. 244.7 Report 0xC4 Failure Status ............................................................................................ 25

4.7.1 Failure Status Rules ............................................................................................. 254.8 Report 0xC5 Ticket Print Status ..................................................................................... 26

4.8.1 Ticket Print Status Rules ...................................................................................... 264.9 Report 0xC6 Transfer Status .......................................................................................... 28

4.9.1 Status Codes......................................................................................................... 29

4.10 Report 0xC8 Metrics..................................................................................................... 314.11 Report 0xCB Printer Status .......................................................................................... 32

4.11.1 Printer Status Rules ............................................................................................ 32

5 Number Allocation and Report Summary ........................................................ 34

5.1 Usage Number Allocation .............................................................................................. 345.2 Report ID Allocation........................................................................................................ 355.3 Report Summary Table .................................................................................................. 35

6 USB Identification Strings ................................................................................. 39

6.1 idVendor ......................................................................................................................... 396.2 idProduct ........................................................................................................................ 39

6.3 iManufacturer.................................................................................................................. 396.4 iInterface......................................................................................................................... 40

6.4.1 Protocol Level - Major ........................................................................................... 40

6.4.2 Protocol Level - Minor ........................................................................................... 40

6.4.3 Protocol Level - Errata Number............................................................................. 40

6.4.4 Product Name ....................................................................................................... 406.4.5 Firmware Issue...................................................................................................... 40

6.4.6 Build Version......................................................................................................... 41

6.4.7 Manufacturing Date............................................................................................... 416.5 iSerialNumber................................................................................................................. 416.6 Peripheral Class ............................................................................................................. 41
http:///reader/full/page51http:///reader/full/page51http:///reader/full/page51http:///reader/full/page51http:///reader/full/page50http:///reader/full/page50http:///reader/full/page50http:///reader/full/page50http:///reader/full/page50http:///reader/full/page50http:///reader/full/page49http:///reader/full/page49http:///reader/full/page49http:///reader/full/page49http:///reader/full/page45http:///reader/full/page45http:///reader/full/page44http:///reader/full/page44http:///reader/full/page42http:///reader/full/page42http:///reader/full/page41http:///reader/full/page39http:///reader/full/page38http:///reader/full/page36http:///reader/full/page36http:///reader/full/page35http:///reader/full/page35http:///reader/full/page34http:///reader/full/page33http:///reader/full/page33http:///reader/full/page32http:///reader/full/page31http:///reader/full/page31http:///reader/full/page30http:///reader/full/page30http:///reader/full/page30http:///reader/full/page28http:///reader/full/page27http:///reader/full/page27http:///reader/full/page27http:///reader/full/page26http:///reader/full/page26http:///reader/full/page25http:///reader/full/page24


5/83


gsa-p0069.001.03 Released: 2008/01/22 Page iii


7 Metrics Command Data Format ........................................................................ 42

7.1 Metrics Report Data Structure ........................................................................................ 42

7.2 PR: Report Printer Resolution ........................................................................................ 43

7.2.1 Structure................................................................................................................ 43

7.2.2 PR Attribute........................................................................................................... 437.2.3 Example ................................................................................................................ 43

7.3 PS: Report Paper Size ................................................................................................... 43

7.3.1 Structure................................................................................................................ 43

7.3.2 PS Attributes ......................................................................................................... 43

7.3.3 Example ................................................................................................................ 447.4 GM: Report Free Graphic Memory ................................................................................. 44

7.4.1 Structure................................................................................................................ 44

7.4.2 GM Attributes ........................................................................................................ 44

7.4.3 Example ................................................................................................................ 447.5 RCS: Report International Character Support ................................................................ 45

7.5.1 Structure................................................................................................................ 45

7.5.2 Example ................................................................................................................ 457.6 RPT: Report Supported Predefined Templates .............................................................. 45

7.6.1 Structure................................................................................................................ 45

7.6.2 Example ................................................................................................................ 457.7 RBS: Report Barcode Support ....................................................................................... 45

7.7.1 Structure................................................................................................................ 45

7.7.2 Barcode Symbology Indexes ................................................................................ 46

7.7.3 Example ................................................................................................................ 467.8 FS: Fonts Supported ..................................................................................................... 46

7.8.1 Structure................................................................................................................ 46

7.8.2 FS Element ........................................................................................................... 46

7.8.3 FS Attributes ......................................................................................................... 47

7.8.4 Required Font Support.......................................................................................... 477.8.5 Example ................................................................................................................ 48

7.9 CS: Color Support .......................................................................................................... 48

7.9.1 Structure................................................................................................................ 48

7.9.2 CS Element........................................................................................................... 48

7.9.3 CS Attribute........................................................................................................... 48

7.9.4 Example ................................................................................................................ 487.10 GS: Graphic Support .................................................................................................... 49

7.10.1 Structure.............................................................................................................. 49

7.10.2 Example .............................................................................................................. 497.11 LS: Line Support........................................................................................................... 49

7.11.1 Structure.............................................................................................................. 49

7.11.2 Example .............................................................................................................. 497.12 OS: Box Support........................................................................................................... 49

7.12.1 Structure.............................................................................................................. 50

7.12.2 Example .............................................................................................................. 507.13 Example: Data Structure .............................................................................................. 50

Glossary ................................................................................................................ 51
http:///reader/full/page61http:///reader/full/page60http:///reader/full/page60http:///reader/full/page60http:///reader/full/page59http:///reader/full/page59http:///reader/full/page59http:///reader/full/page59http:///reader/full/page59http:///reader/full/page59http:///reader/full/page59http:///reader/full/page58http:///reader/full/page58http:///reader/full/page58http:///reader/full/page58http:///reader/full/page58http:///reader/full/page58http:///reader/full/page57http:///reader/full/page57http:///reader/full/page56http:///reader/full/page56http:///reader/full/page56http:///reader/full/page56http:///reader/full/page56http:///reader/full/page55http:///reader/full/page55http:///reader/full/page55http:///reader/full/page55http:///reader/full/page55http:///reader/full/page55http:///reader/full/page55http:///reader/full/page55http:///reader/full/page54http:///reader/full/page54http:///reader/full/page54http:///reader/full/page54http:///reader/full/page54http:///reader/full/page53http:///reader/full/page53http:///reader/full/page53http:///reader/full/page53http:///reader/full/page53http:///reader/full/page53http:///reader/full/page53http:///reader/full/page52http:///reader/full/page52


6/83


gsa-p0069.001.03 Released: 2008/01/22 Page iv


Appendix A: CRC-32 Checksum Calculation..................................................... 52

A.1 Assembly Example......................................................................................................... 52

A.2 C Language Example..................................................................................................... 60

Appendix B: Printer Report Descriptors ............................................................ 63

Index ...................................................................................................................... 71
http:///reader/full/page81http:///reader/full/page73http:///reader/full/page70http:///reader/full/page62http:///reader/full/page62


7/83

GDSPrinter:Communication Protocol v1.0.3 About This Document

gsa-p0069.001.03 Released: 2008/01/22 Page v


I About This Document

This specification defines the communication protocol of the GSA GDS (Gaming Device Standards)printer.

I.I GDS (Gaming Device Standards)

GSA Gaming Device Standards controls the flow of information between an electronic gamingmachine (EGM) and the array of peripheral devices operating inside it, such as bill validators, cardreaders and ticket printers using Universal Serial Bus (USB) standards protocol. In essence, eachperipheral uses one command set to communicate with its host machine. That information can thenbe relayed to the casino management system through the machine message protocol, such as GSAsG2S (Game-to-System) Message Protocol.

For more details about GSA, visit the Web site: http://www.gamingstandards.com .

I.II Acknowledgements

The Gaming Standards Association would like to express its appreciation to all members of the GDScommittee, past and present, for their significant contribution and dedication to the creation of thisstandard.

I.III Related Documents

I.III.I GSA

Gaming Standards Association documents referenced (http://www.gamingstandards.com ):

Table I.1 Referenced GSA Documents

Ref Title

DCFRS Device Class FRS, version A3, GSA PN [TBD]

BCTS GDS Bar Coded Ticket Format Specification

GAT3 Requirements for the Game Authentication Terminal Program (GAT3)

GDSPDL GDS Page Definition Language
http://www.gamingstandards.com/http://www.gamingstandards.com/


8/83


gsa-p0069.001.03 Released: 2008/01/22 Page vi


I.III.II USB

USB Implementers Forum, Inc., http://www.usb.org, documents referenced:

I.III.III ISO

International Organization for Standardization, http://www.iso.orgdocuments referenced:

I.III.IV Other References

Table I.2 Referenced USB Documents

Ref Title

USB 2.0 Universal Serial Bus Specification, v2.0http://www.usb.org/developers/docs/

DCDHID Device Class Definition for HID, v1.11http://www.usb.org/developers/hidpage/

DFU Device Firmware Upgrade, v1.1http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf.

UnicodeECN USB Engineering Change Notice UNICODE UTF-16LE for StringDescriptorshttp://www.usb.org/developers/docs

Table I.3 Referenced ISO Documents

Reference Title and Source

ISO/IEC 10646 Universal Character Set Encoding Specification

Table I.4 Referenced Miscellaneous Documents

Reference Title and Source

PP0.8 PlusPower Specification v0.8http://www.poweredusb.org/pdf/PoweredUSB_v08g.pdf.

ISO 639 International Organization for Standards, http://www.iso.org,Language Codes.

RFC 2781 UTF-16 Unofficial Specification

Unicode Standard Unicode Standard Version 3.0http://www.unicode.org
http://www.usb.org/developers/devclass_docs/DFU_1.1.pdfhttp://www.unicode.org/http://www.iso.org/http://www.iso.org/http://www.usb.org/developers/docshttp://www.usb.org/


9/83


gsa-p0069.001.03 Released: 2008/01/22 Page vii


I.IV Document Conventions

Plain text indicates specification text.

Blue text indicates an internal link or an external hyperlink to a URL.

Bold (other than in headings) or underlined text is used for emphasis, unless specifically indicatedotherwise.

Italicizedtext (other than in headings) is used for terms being defined, unless specifically indicatedotherwise.

Courier New font is used to indicate code or psuedo code.

I.V Document Organization

Chapter 1 Overview of purpose and benefits of the GDS printerspecification.

Chapter 2 Hardware and software characteristics common to all GDS peripheral devices.Common reports are listed with references to the appropriate detail sections inchapters 3 and 4.

Chapter 3, 4 Command and event details, respectively. Both chapters are similarly organized. SeeCommand and Event Detail Organization below.

Chapter 5 Usage number and report ID allocation for the GDS printer protocol, as well ashigh-level allocation for GDS peripheral device protocols in general. Reportsummary, in tabular format, printer reports and report items, with correspondingdetails such as usage number and/or report ID.

Chapter 6 USB identifier strings, such as vendor codes assigned by USB-IF, as well as otheridentifiers, including product and manufacturer identifiers.

Chapter 7 Printer Metrics Data format. Format of data send in the Metrics report.

Glossary Definitions of terms.

Appendix A CRC-32 checksum calculation, with assembly and C code examples, adapted forcalculation time considerations and for space considerations.

Appendix B Report Descriptors (TBD)
http:///reader/full/page10


10/83


gsa-p0069.001.03 Released: 2008/01/22 Page viii


I.V.I Command and Event Detail Organization

Chapters 3 and 4 are similarly organized as follows:

1. Table listing the reports described in the chapter: report ID, usage number, text label, whetherdata is sent in the report, and page number where details appear.

2. Overview information, if any.

3. Report detail sections. Reports are listed in numerical order by report ID.

a. Description of report.

b. Usage examples or scenarios, if any.

c. Usage rules, if any.

d. Report structure table.

e. Item description table, if applicable. If the only data sent in the report is the report ID,this table is not included.


11/83

GDSPrinter: Chapter 1:Communication Protocol v1.0.3 Introduction

gsa-p0069.001.03 Released: 2008/01/22 Page 1


1 Introduction

This is the specification for a USB printer as defined by the GDS within the GSA. The aim of theGDS is to develop true plug n play peripherals for the gaming environment which are already

common place in the computer industry. Rather than use a derivative of RS232 it was decided to movethe technology forward and adopt the USB standard. This document specifies the high level design ofprinters that will:

be used to derive a specific USB based implementation of the Device Class FunctionalRequirement Specification (see document reference DCFRS).

satisfy the set of common functional requirements as specified in the DCFRS.

satisfy the specific functional requirements for the printer class as specified in the DCFRS.

This document specifies the complete set of functionality for the GDS printer.

1.1 Printer Function OverviewCommands supported by the printer are defined in Chapter 3. Supported events are defined inChapter 4. Common commands and events are identified in Chapter 2.

The printer on power-up must be disabled, run a diagnostic test, and report events as necessary.

The printer stores information about critical ticket fields (for example, Validation and Barcode), evenover power failure intervals, until the acknowledgement of the ticket printing transaction is receivedfrom the host.

The interrupt service period, bInterval, is 100 ms.

1.2 USB Compliance and BenefitsUSB is currently available in three speeds:

low speed: 1.5 Mbits/sec.

full speed: 12 Mbits/sec.

high speed: 480 Mbits/sec.

GDS peripherals must, at a minimum, support full speed and must comply with all USBrequirements.

Only one master exists on the USB bus and that is the host machine. All peripherals must beconnected through hubs (up to 127 allowed but this is likely to be less than 10). There is norequirement for OTG (On-The-Go) extensions to allow peripherals to talk directly to one another.Also, for security reasons, it is undesirable to have a direct peripheral-to-peripheral communicationpath. All communication must be via the host.
http:///reader/full/page7http:///reader/full/page7http:///reader/full/page7


12/83

GDSPrinter: Chapter 1:Communication Protocol v1.0.3 Introduction



1.3 Printers as HID Class Devices

To remove the need for special manufacturer-specific device drivers, the printer is implemented as anHIDHuman Interface Deviceclass device (see document reference DCDHID). This is the sameclass as mice, keyboards and joysticks but is a flexible enough to be used for general input/output data

packets where the data sizes are relatively small and the transfer rates low. HID implements usagepages and usage numbers to allow access to data in an abstracted fashion, regardless of themanufacturer or even the exact location within a report of where the data can be found. For a joystickthere is a usage number for button_1, likewise for a printer there is a usage number for the noteidentifier.

This document assumes hardware and firmware is in place to support a HID class device within USBand so need only concern itself with HID commands and data formats for gaming. Productidentification is also discussed.

1.4 Device Firmware Upgrade (DFU)

GDS devices will use the Device Firmware Upgrade (DFU) standard, version 1.1, as defined by USB-IF, http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf.

The use of the DFU class must not affect the behavior of the HID class.

Upon firmware upgrade the device must clear its internal memory.
http:///reader/full/page8http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf


13/83

GDSPrinter: Chapter 2:Communication Protocol v1.0.3 GDS Peripheral Common Design Characteristics



2 GDS Peripheral Common Design Characteristics

This section describes characteristics shared by all GDS peripheral devices.

2.1 Hardware: Communications

USB 2.0 defines low (1.5Mbits/sec.), full (12Mbits/sec.) and high (480Mbits/sec.) speedcommunications. GSA devices must at a minimum, support full speed and must comply with all USBrequirements.

The USB specification defines a reliable means of communication at both hardware and softwarelevels, including error detection and recovery. See document reference USB 2.0.

2.2 Hardware Power-Loss and Non-Reproducible Data Recovery

2.2.1 Non-Volatile Memory

For critical function devices only (see document reference DCFRS), devices must implement non-volatile memory (NVM).

If battery-backup systems are implemented, the device must implement battery level circuitry to detectwhen the method of storage is no longer reliable.

If non-volatile memory fails, the non-volatile memory (NVM) failure event must be reported. See0xC4 Failure Status event, on page 25.

2.2.2 Power Fail Signaling

Devices must implement power fail detect circuitry and a power reserve capability when NVM isrequired.

2.3 Software: USB Classification

Devices must be classified as HID devices unless otherwise indicated.

2.4 Software: Communications Overview

A set ofstandarddevice requests are defined by USB and HID defines additional class-specificrequestsfor managing reports. All device classes are to implement GET/SET REPORT and GET/SET IDLEHID requests unless otherwise stated.

Under HID, all device communications must be encoded into a reporting structure as defined byDevice Class Definition for Human Interface Devices. See document reference DCDHID.

The host sends a report to the peripheral to issue a command and where a peripheral wishes to notifythe host of an event, it sends a report on the INTERRUPT IN endpoint as specified by the devicesreport descriptor. The report ID indicates the event type and the report data indicates any event data.
http:///reader/full/page35http:///reader/full/page8http:///reader/full/page8http:///reader/full/page7


14/83




2.4.1 Report Delivery and Priority

If the host requires information from the peripheral, it requests a report. The report ID identifies theinformation to retrieve. Reports can be scheduled for delivery at regular intervals if desired. However,note that on power up, devices must handle messages in the following priority:

1. Power status event

2. Failure status event

3. Pending Transaction ID event

4. Any previously stored Transaction ID events that were in addition to the pending TransactionID event

The design that follows, however, focuses on higher level primitives to assist those not familiar withthe USB software layer.

Do not confuse the acknowledgment system defined by the USB protocol layer with the eventacknowledgment system defined below.

The concept of a command, event and event acknowledgment are now defined.

2.4.2 Command

Commands specified in this document are sent from host to device. These commands areimplemented as Set_Report (Feature) requests. See document reference USB 2.0. The following tableidentifies commands currently implemented as common reports (see sections 5.1 and 5.2). Thesecommands are used by multiple device classes. At the time of this writing, the commands areimplemented by the coin acceptor, coin hopper, printer, and note acceptor device classes.

2.4.3 Event

Events specified in this document are sent from device to host.

USB simulates the concept of an interrupt through regular polling intervals issued by the hosts USBdevice driver. The interrupt service period is specified by the device via an endpoint descriptor. Theinterrupt interval chosen is based on the function of a device.

Events can be sent at regular intervals, when the device has something to send or when the host hasrequested that an event be sent.

An application level acknowledgment is required for some events. These events deal with currencyrelated activities or fault activities. The Host must make sure that it has acted on them and not justreceived them before Acknowledging these events to the device.

Table 2.1 Common Commands

Report ID Usage ID Name Data Page

0x01 0x40 ACK No page 9

0x02 0x41 Enable No page 10

0x03 0x42 Disable No page 10

0x04 0x43 Self Test No page 11

0x05 0x44 Request GAT Report No page 11

0x08 0x48 Calculate CRC Yes page 12
http:///reader/full/page22http:///reader/full/page21http:///reader/full/page21http:///reader/full/page20http:///reader/full/page20http:///reader/full/page19http:///reader/full/page45http:///reader/full/page44http:///reader/full/page8


15/83




The protection is needed such that on power loss, these events are not lost but resent when power isrestored and the host can decide if it had serviced the event prior to power loss or must do so now.

Status events need to be reported when a fault occurs and when it is cleared.

The following table identifies events currently implemented as common reports (see sections 5.1 and5.2). These events are used by multiple device classes. At the time of this writing, the events areimplemented by the coin acceptor, coin hopper, printer, and note acceptor device classes.

2.4.4 Event Acknowledgement

For Transaction ID (TID) events only, an event acknowledgment is required.

Critical events sent from a device and the hosts acknowledgment command contain a transaction ID.

Transaction IDs are be one (1) byte in length and initially start at zero (0). Transaction IDs wrap tozero (0) after reaching the upper limit of 255.

The host increments its transaction ID when the transaction ID of the event matches the hosts copy.The host sends a 0x01 ACK command (see page 9) to the device only after it has serviced the event.

A device increments its transaction ID when it receives an ACK from the host indicating thetransaction ID of the pending event.

If transaction numbers do not match, the host may send an ACK indicating the received TID afterhandling this mismatching event; may resynchronize transaction IDs or may take any other action.

If transaction ID events with TID x are received by the host while the host is busy processing an eventwith transaction ID x, the host may choose to ignore these messages as they are duplicates of theevent being processed.

The device resends the event when it receives an ACK with a wrong transaction ID. However, if thedevice has just recovered from power loss and has detected that an event was waitingacknowledgement when power was lost, and has resent the event, the device discards the resent event

as soon as the ACK is received. The host either has indicated that it had already serviced it or did justthen. Regardless the transaction ID is incremented and operation continues.

Transaction ID events can only be sent if there is no pending Transaction ID event. Devices mustqueue any un-sent and pending Transaction ID events.

If an event is unrecognized by the host, the host may ignore the event or take some other action.

If an ACK is not received within one (1) second then the event is resent to the host.

Table 2.2 Common Events

Report ID Usage Event Data Page

N/A USB Defined Connection No page 20

N/A USB Defined Disconnection No page 20

0x06 0x45 Power Status Yes page 21

0x07 0x46 GAT Data Yes page 22

0x09 0x48 CRC Data Yes page 23

0x0A 0x4A Device State Yes page 24
http:///reader/full/page45http:///reader/full/page44http:///reader/full/page19http:///reader/full/page34http:///reader/full/page33http:///reader/full/page32http:///reader/full/page31http:///reader/full/page30http:///reader/full/page30


16/83




2.4.5 Power Up Sequence

Upon power up and after enumeration, the device stays in the Disabled state. During this time thedevice must continuously monitor itself for any failure or fault events. During this time, only the 0x03Disable command (see page 10) is accepted by the device. Any other command will be ignored.

After the device receives its first Disable command from the host, it responds with the 0x0A DeviceState event (see page 24)and then it reports any event messages in the following priority.

1. Power Status events, if external power is missing.

2. Perform self-test and report failure status before generating any other reports. Whileperforming a self-test a device may NAK, at the USB level, any host commands.

3. Any pending credit or pending status events. These are defined as any printer TID that wasalready placed into EndPoint 1 stack for transmission, but was not completely communicatedto the host. A complete communication requires that the host acknowledge the event and alsothat the Transaction ID rules have been met whereby both the host and device TransactionIDs are in sync. These pending events must be transmitted to the host in their order of

occurrence.4. Any previously stored printer TID events that were in addition to the pending TID event

described in the above item #3.

NOTE: A device must be ready to accept the Disable command from host within two (2) secondsafter enumeration.

2.4.6 Device and Host Interaction

The device uses the USB Device Layer ACK and NAK handshake protocols to control the receipt ofcommands from the host. If the device NAKs a command, the host retries the transaction until thedevice responds with an ACK. The host may use any method to determine if a device has NAKed thehost too long.

When the device acknowledges a command packet, the device accepts responsibility to complete thecommand. Commands must be completed within the allocated time-out periods. For the 0x08Calculate CRC (see page 12) and 0x04 Self Test (see page 11) commands the host allows a maximumtime-out of 20 seconds between the receipt of the ACK and the return of requested data on the InputEnd Point. This time-out is five (5) seconds for all other commands that operate during the disabledstate and have an associated response to the host. The 0x03 Disable command (see page 10) is anexception and must respond to the host within three bIntervals (see Printer Function Overview onpage 1).

Care must be taken in the device firmware to ensure that a NAK_OUT is used without STATUS_INbeing included because the host might interpret the ACK of the status packet as receipt of thecommand. The device firmware must also ensure that upon returning to an ACK_OUT state that the

device also includes the STATUS_IN instruction to allow the command from the host to berecognized. To repeat: to stop receipt of commands from the host, the device must perform aNAK_OUT instruction; and to accept commands from the host, the device must perform anACK_OUT_STATUS_IN instruction.

More information is available in section 5.3.2 and section 4.4 of the USB specification (see documentreference USB 2.0).
http:///reader/full/page34http:///reader/full/page20http:///reader/full/page11http:///reader/full/page11http:///reader/full/page8http:///reader/full/page20http:///reader/full/page21http:///reader/full/page22


17/83

GDSPrinter: Chapter 3:Communication Protocol v1.0.3 Command Support



3 Command Support

The following printer commands are supported and are to be implemented as HID Feature reports.

NOTE: The following reports are diagnostic commands: Report 0x04 Self Test, Report 0x05 Request

GAT Report, Report 0x08 Calculate CRC.

Table 3.1 Supported Printer Commands

Report ID Name Data Page

0x01 ACK No page 9

0x02 Enable No page 10

0x03 Disable No page 10

0x04 Self Test No page 11

0x05 Request GAT Report No page 11

0x08 Calculate CRC Yes page 12

0xC0 Define Region Yes page 13

0xC1 Define Template Yes page 14

0xC2 Print Ticket No page 15

0xC3 Form Feed No page 16

0xC7 Request Printer Metrics No page 17

0xC9 Graphic Transfer Setup Yes page 17

0xCA File Transfer Yes page 18
http:///reader/full/page22http:///reader/full/page21http:///reader/full/page21http:///reader/full/page21http:///reader/full/page28http:///reader/full/page27http:///reader/full/page19http:///reader/full/page22http:///reader/full/page21http:///reader/full/page21http:///reader/full/page20http:///reader/full/page20http:///reader/full/page27http:///reader/full/page26http:///reader/full/page25http:///reader/full/page24http:///reader/full/page23


18/83




3.1 Command Execution When Enabled/Disabled

The following table shows the device state a given command can be performed under. No action istaken if a command is sent with the printer in the wrong state.

Table 3.2 Command Execution When Enabled/Disabled

CommandOperation When

Device Enabled

Operation When

Device Disabled

0x02 Enable Yes Yes

0x03 Disable Yes Yes

0x04 Self Test No Yes

0x05 Request GAT Report No Yes

0x08 Calculate CRC No Yes

0xC0 Define Region Yes Yes

0xC1 Define Template Yes Yes

0xC2 Print Ticket Yes No

0xC3 Form Feed Yes Yes

0xC7 Request Printer Metrics Yes Yes

0xC9 Graphic Transfer Setup Yes Yes

0xCA File Transfer Yes Yes


19/83




3.2 Report 0x01 ACK

This is a pseudo-command as it is sent in response to a Transaction ID event from the printer as partof the handshake sequence. This command is used to confirm critical events such as the TID event0xC5 Ticket Print Status.

Ticket Print and Printer Status share the same Transaction ID, and are referred to as printerTransaction ID (or TID) events.

A Transaction ID stamp is used to ensure that every printer TID event is properly handled by the hostand only acknowledged events are removed from the printer queue. If the device does not receive anACK from the host within one (1) second then the event is resent tothe host.

The Transaction ID protocols are only used with TIDs. If power is removed before all of the printerTID events have been completely communicated with the host, they are re-issued by the printer whenpower is restored and enabled. Therefore any un-sent or pending printer TIDs must be buffered inNVM.

3.2.1 Transaction ID Rules

1. Transaction IDs increment through the range 0 to 255.

2. Transaction IDs are only cleared from the printer stack after the host has acknowledged theevent and also the Transaction ID rules have been met whereby both the host and deviceTransaction IDs are in synch.

3. The current Transaction ID must be stored in the device's NVM so as to provide a referencenumber in the event of a power interruption.

4. If the device does not receive an acknowledge from the host within one (1) second aftersending a critical event, the device must retry sending the event every one (1) second until thehost properly acknowledges the event and the Transaction IDs are in sync.

5. While waiting for an ACK, a device must not NAK, at the USB level, a command from thehost.

Table 3.3 0x01 ACK Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x01

Byte 1 - - - - - - - Resync

Byte 2 Transaction ID

Table 3.4 0x01 ACK Field Descriptions

Name Value Description

Resync 0 The device must not re-sync its Transaction ID. This is anacknowledgement.

1 The device MUST re-sync its Transaction ID and resend thepending report.

Transaction ID 0 to 0xFF The confirmed or new Transaction ID. See rules in section 3.2.1.


20/83




3.3 Report 0x02 Enable

The device activates any inputs and/or enables any outputs. If the device has a fault then it must staydisabled and report the fault to the host. If the device has no faults, after enabling itself the devicesends the 0x0A Device State event (see page 24) with the enable bit set.

3.4 Report 0x03 Disable

The device deactivates the 0xC2 Print Ticket capability (see page 15). Functions such as Form Feed,File Transfer and other functions consistent with section 3.1 may be issued while the device isdisabled. The host must send a Disable command before issuing any diagnostic commands (defined

on page 51).When the device is in the enabled state and receives a Disable command, the device must immediatelydisable itself and respond with the 0x0A Device State event (see page 24).

If Disable is received while printing a ticket, the device disables itself and sends the 0x0A Device Stateevent (see page 24) but continues to print the current print job.

Table 3.5 0x02 Enable Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x02

Table 3.6 0x03 Disable Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x03
http:///reader/full/page61http:///reader/full/page18http:///reader/full/page34http:///reader/full/page25http:///reader/full/page34http:///reader/full/page34


21/83




3.5 Report 0x04 Self Test

The device initiates a self-test sequence when instructed by the host. When the host requests a self-test, the device must respond with a 0xC4 Failure Status event (see page 25). The device mustcomplete all tests before sending the Failure Status event to the host. Multiple failures must be

presented in the final single Failure Status event, with the exception of multiple 'Other' failures, whichmust be reported in separate Failure Status events.

3.6 Report 0x05 Request GAT Report

The host sends this command to request diagnostic information from the printer via a 0x07 GATData event (see page 22). The device is not required to monitor itself for fault conditions during theperformance of this command. The command must be in ASCII format for transfer out of the

machine GAT port in XML format. The following characters are not to be used in the GAT data: ''. The printer does not output in XML.

GAT data is manufacturer-specific in terms of length and content. See document reference GAT3.

Table 3.7 0x04 Self Test Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x04

Byte 1 - - - - - - - NVM

Table 3.8 0x04 Self Test Field Descriptions


NVM 0 Perform self-test.

1 Non-volatile Memory (NVM), previously queuedTransaction ID events and Transaction ID sequencenumber, must be cleared before the self-test isperformed.

Table 3.9 0x05 Request GAT Report Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x05
http:///reader/full/page35http:///reader/full/page32http:///reader/full/page7


22/83




3.7 Report 0x08 Calculate CRC

The host can request a 32-bit checksum from the code space within the printers ROM memory,excluding the USB Identification Strings (see page 39). For additional accuracy and security, a 32 bitseed is sent to the device as a parameter of this command. The host may choose any seed value and

compare the result with a look-up table or a similar calculation based on an exact reference copy of thecode to be verified.

A checksum report is returned in the 0x09 CRC Data event (see page 23) with the result.

While calculating the CRC the device is not required to receive any additional commands. The deviceis permitted to NAK_OUT all requests from the host while performing the CRC calculation. Thedevice is also not required to monitor itself for fault conditions during the performance of thiscommand.

See Appendix A for details of the CRC algorithm used.

Table 3.10 0x08 Calculate CRC Structure

Bit 7 6 5 4 3 2 1 0Byte 0 0x08

Byte 1 Seed 0

Byte 2 Seed 1

Byte 3 Seed 2

Byte 4 Seed 3

Table 3.11 0x08 Calculate CRC Field Descriptions


Seed 0 to 255 The starting seed for the CRC-32 calculation. Seed 0is the LSB.
http:///reader/full/page33http:///reader/full/page49


23/83




3.8 Report 0xC0 Define Region

The host issues this command to define printable regions for a ticket that will be printed. Printableregions may be defined to contain text, barcodes or graphic images. Predefined default content may bespecified in this command. Only one printable region may be defined at a time using this report.

Report 0xC1 Define Template (page 14) is used to associate printable regions defined using thisDefine Region command with a specific template. Report 0xC2 Print Ticket (page 15) instructs theprinter to print a content using a specific template.

The format of the data in this command is defined in the DPR command of the GDS Page DefinitionLanguage specification.

If the total Data size exceeds 61 bytes it can be broken into a number of sequential reports. Data up to61 bytes in size may be sent in a single report with the Index set to one (1) and the Size between 0 61. If the Data is longer than this, then the data must be split into sequential packets with all packetshaving a Size of 61 bytes followed by a terminating packet which must have a size of less than 61 bytes.In this way the host knows when all data has been received. If the last data packet fills a 61 byte reportexactly then a null packet must be sent as a terminator. This will have a Size of zero (0). Indexnumbers start at one (1) and increment with each packet sent. The printer can stitch all Data packetstogether in the Index number sequence to reproduce the complete Data report.

The first report will have Index = 1. If more reports are needed to return all the Field Data then theyare indexed 2, 3, 4etc.

The Size byte indicates how many bytes are used within the fixed size report structure as the lastreport may not need all the available space.

Note: Regions that are not predefinedthat is, having identifiers in the range of 100 through 999are not stored across power cycles.

3.8.1 Define Region Rules

1. Only downloadable regions, DPR identifier range 100 to 999, can be defined.2. If a region identifier already exists in the printer, the new region definition will replace the

current region definition.

3. All downloaded regions are not stored across power cycles.

Table 3.12 0xC0 Define Region Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xC0

Byte 1 Index

Byte 2 SizeByte 3 Data 1

Byte 63 Data 61


24/83




3.9 Report 0xC1 Define Template

The host issues this command to define a template for a ticket that will be printed. A templateidentifies the printable regions, defined in the 0xC0 Define Region command (page 13) , to be

included on a ticket. Report 0xC2 Print Ticket (page 15) instructs the printer to print a ticket using atemplate defined with this Define Template command. The Print Ticket command may also specifydynamic content to be printed.

The format of the data in this command is defined in the DPT command of the GDS Page DefinitionLanguage specification.

If the total Data size exceeds 61 bytes it can be broken into a number of sequential reports. Data up to61 bytes in size may be sent in a single report with the Index set to one (1) and the Size between 0 61. If the Data is longer than this, then it must be split into sequential packets with all packets having aSize of 61 bytes followed by a terminating packet which must have a size of less than 61 bytes. In thisway the host knows when all data has been received. If the last data packet fills a 61 byte report exactlythen a null packet must be sent as a terminator. This will have a Size of zero (0). Index numbers start

at one (1) and increment with each packet sent. The printer can stitch all the Data packets together inthe Index number sequence to reproduce the complete Data report.



Note: Templates that are not predefinedthat is, having an identifier in the range of 100 through999 are not stored across power cycles.

3.9.1 Define Template Rules

1. Only downloadable templates, DPT identifier range 100 to 999, can be defined.

2. If a template identifier already exists in the printer, the new template definition will replacethe current template definition.

3. Downloaded templates are not stored across power cycles.

Table 3.13 0xC0 Define Region Field Definitions


Index1 to 255

Indicates a sequence if this command spans multipleUSB packets. This is modeled after the GAT report.

Size0 to 61

Number of bytes of data to follow. The last packetmay contain less that 61 characters.

Data32 to 255

ASCII characters as defined in the DPR commandin the GDS Page Description Languagespecification.


25/83




3.10 Report 0xC2 Print Ticket

The host issues this command to print a ticket using a specified template, with either dynamicallydefined or predefined content. To print a ticket, the printable regions and a template must be defined

using 0xC0 Define Region (page 13) and 0xC1 Define Template (page 14).Dynamically defined regions and templates, assigned identifiers in the range of 100 through 999, arenot stored across power cycles. Predefined regions and templates, assigned identifiers in the range of000 and 099, are stored in and accessible from the printers NVM.

The format of the data in this command is defined in the PT command of the GDS Page DefinitionLanguage specification.

If the total Data size exceeds 61 bytes it can be broken into a number of sequential reports. Data up to61 bytes in size may be sent in a single report with the Index set to one (1) and the Size between 0 61. If the Data is longer than this, then it must be split into sequential packets with all packets having aSize of 61 bytes followed by a terminating packet which must have a size of less than 61 bytes. In thisway the host knows when all data has been received. If the last data packet fills a 61 byte report exactlythen a null packet must be sent as a terminator. This will have a Size of zero (0). Index numbers startat one (1) and increment with each packet sent. The printer can stitch all the Data packets together inthe Index number sequence to reproduce the complete Data report.



Table 3.14 0xC1 Define Template Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xC1

Byte 1 Index

Byte 2 Size

Byte 3 Data 1

Byte 63 Data 61

Table 3.15 0xC1 Define Template Field Descriptions


Index 1 to 255 Packet sequence counter for multi-packet reports.

Size0 to 61

Number of bytes of data to follow. Last packet maycontain less than 61 characters.

Data32 to 255

ASCII characters as defined in the DPT commandin the GDS Page Description Languagespecification.


26/83




3.10.1 Print Ticket Rules

1. If device is in a disabled mode (disabled by host), the device ignores any print ticketcommands received.

2. The printer will ignore the Print Ticket command if any of the following conditions are

present:

Print Head Open

Paper Jam

Paper Empty

Top of Form

3.11 Report 0xC3 Form Feed

The host issues this command to instruct the printer to feed a blank ticket.

Table 3.16 0xC2 Print Ticket Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xC2

Byte 1 Index

Byte 2 Size

Byte 3 Data 1

Byte 63 Data 61

Table 3.17 0xC2 Print Ticket Field Descriptions


Index1 to 255

Packet sequence counter for multi-packet reports.

Size0 to 61

Number of bytes of data to follow. Last packet maycontain less than 61 characters.

Data32 to 255

ASCII characters as defined in the PT command inthe GDS Page Description Language specification.

Table 3.18 0xC3 Form Feed Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xC3


27/83




3.12 Report 0xC7 Request Printer Metrics

The host issues this command to request the printers capabilitiy metrics, such as fonts supported,whether barcode is supported, and the graphic files-to-index mapping. The printer sends the 0xC8Metrics event (page 31) in response.

3.13 Report 0xC9 Graphic Transfer Setup

The host issues this command to indicate the type, size, and identifier of the graphic the host willdownload to the printer in the following 0xCA File Transfer command (page 18). The identifier,Index, is used to identify the graphic as content for a printable region (See the GDS Page Definition

Language specification).

3.13.1 Graphic Transfer Setup Rules

1. If the Index already exists in the printer, the new index will replace the current index andassociate it with the new graphic when it is downloaded using 0xCA File Transfer command(page 18).

2. If the Index being replaced is for a predefined graphic, the Index will be associated with thenew device-specific graphic and the original predefined graphic will be restored when theprinter performs a power cycle reset.

3. To determine the maximum memory size allocated in RAM to hold graphics, the host usesthe 0xC7 Request Printer Metrics command (page 17).

4. The Graphic Transfer Setup command must always precede 0xCA File Transfer command(page 18).

Note: Downloadable device-specific graphics are not predefined and are not stored across power

cycles.

Table 3.19 0xC7 Request Printer Metrics Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xC7

Table 3.20 0xC9 Graphic Transfer Setup Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xC9

Byte 1 Type

Byte 2 Index

Byte 3 File Size (LSB)

Byte 4 File Size (MSB)
http:///reader/full/page28http:///reader/full/page27http:///reader/full/page28http:///reader/full/page28http:///reader/full/page41


28/83




3.14 Report 0xCA File Transfer

The host issues this command to download a graphic file after having issued a 0xC9 Graphic TransferSetup command (page 17) that describes the graphic file type size, and identifier. The printer storesthis file in RAM, associating it with the index specified in the 0xC9 command. The host can then laterissue 0xC0 Define Region commands that specify the graphic as the content for a printable region.

After the graphic file has been downloaded, the printer responds with a 0xC6 Transfer Status event(page 28).

If the total Data size exceeds 60 bytes it can be broken into a number of sequential reports. Data up to60 bytes in size may be sent in a single report with the Index set to one (1) and the Size between 0 60. If the Data is longer than this, then it must be split into sequential packets with all packets having aSize of 60 bytes followed by a terminating packet which must have a size of less than 60 bytes. In thisway the host knows when all data has been received. If the last data packet fills a 60 byte report exactlythen a null packet must be sent as a terminator. This will have a Size of zero (0). Index numbers startat one (1) and increment with each packet sent. The printer can stitch all the Data packets together inthe Index number sequence to reproduce the complete Data report.


The Size byte indicates how many bytes are used within the fixed size report structure as the last

report may not need all the available space.

Table 3.21 0xC9 Graphic Transfer Setup Field Descriptions


Type 0x01 Bitmap graphic file.

0x02 PCX graphic file.

Index

1 to 255

Index into graphic array. After the graphic isdownloaded into the printer, this value can then bereferenced when defining printable regions.1 99: Reserved for predefined graphic.100 255: Downloadable, device-specific graphic.

File Size0 to 65535

Least significant byte and most significant byte,respectively, of the file size.


29/83




Table 3.22 0xCA File Transfer Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xCA

Byte 1 Index (LSB)

Byte 2 Index (MSB)

Byte 3 Size

Byte 4 Data 1

...

Byte 63 Data 60

Table 3.23 0xCA File Transfer Field Descriptions


Index0 to 65535

Least significant byte and most significant byte,respectively. Indicates report sequence whenmultiple reports are required.

Size0 to 60

Number of bytes of data to follow. The lastpacket may contain less than 60 characters.

Data 0 to 255 Graphic file data.


30/83

GDSPrinter: Chapter 4:Communication Protocol v1.0.3 Event Support



4 Event Support

The following printer events are supported. See section 2.4.1 for message priority.

GDS devices are event driven and therefore detection of an error as well as clearance of it must bereported. This guarantees that the host is informed of the state of a given device.

4.1 Connection/Disconnection of CommunicationsThe USB specification handles connection/disconnection of a device. See document reference USB2.0.

4.2 Connection/Disconnection of Power

Devices may require additional power to that supplied by the USB and if so, the standard USBconfiguration descriptor is used to inform the host of this requirement.

On connecting the device USB cable to the host, the host detects the device, although the device maynot be fully operational as in the case when the device requires external power and that power is not

connected.Devices that require external power must report a 0x06 Power Status event (see page 21) per the rulesin section 4.3.1. The host, must be notified whenever a loss or reapplication of external power occurs.In the case where the USB communications section of the device is powered by the USB +5 power,the host will be notified by the device sending a Power Status event with the appropriate status bits set.In the case where the USB communications section of the device is powered by the external power,the host will be notified by virtue of the fact that the device will drop out of the addressing schemewhen the external power is removed and will become re-enumerated and re-addressed when theexternal power is reapplied.

Table 4.1 Supported Printer Events

Report ID Event Data Page

N/A Connection No page 20

N/A Disconnection No page 20

0x06 Power Status Yes page 21

0x07 GAT Data Yes page 22

0x09 CRC Data Yes page 23

0x0A Device State Yes page 24

0xC4 Failure Status Yes page 25

0xC5 Ticket Print Status Yes page 26

0xC6 Transfer Status Yes page 28

0xC8 Metrics Yes page 31

0xCB Printer Status Yes page 32
http:///reader/full/page14http:///reader/full/page31http:///reader/full/page30http:///reader/full/page31http:///reader/full/page8http:///reader/full/page8http:///reader/full/page42http:///reader/full/page41http:///reader/full/page38http:///reader/full/page36http:///reader/full/page35http:///reader/full/page34http:///reader/full/page33http:///reader/full/page32http:///reader/full/page31http:///reader/full/page30


31/83




If the device does not require external power, the power status event need not be sent.

If the device requires external power, and if external power is disconnected, the device must disableitself. The device remains disabled until enabled by the host.

4.3 Report 0x06 Power Status

The presence or absence of external power supply is reported in this event with the Ext. Power flagfor those peripherals which need external power to operate.

Another flag, Need Reset, in this event is used to indicate whether a device must be reset explicitly bythe host if external power is connected after a disconnection state. Most printers will be able togenerate their own reset on connection of power.

4.3.1 Rules for Power Status

1. If the USB communications section of the device is powered by the USB +5 power and if thedevice enumerates with external power not present, after receiving 'Disable' command from

host, the device will report the Device State event to the host, followed by the Power Statusevent. Any subsequent Power Status events, power connected/disconnected events must alsobe reported to the host.

2. 2. In the case where the USB communications section of the device is powered by the USB+5 power, if the device loses power its only response to any command from the host will bePower Status event with the external power bit set to zero.

3. 3.In the case where the USB communications section of the device is powered by the USB +5power, if the device loses power it aborts any diagnostic command and reports Power Statusevent with the external power bit set to zero.

4. 4.In the case where the USB communications section of the device is powered by the USB +5

power, the device is not required to monitor itself for any additional conditions while externalpower is not present.

Table 4.2 0x06 Power Status Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x06

Byte 1NeedReset

Ext.Power

Table 4.3 0x06 Power Status Field Descriptions


Ext. Power 0 External power is NOT connected.

1 External power is connected.

Need Reset 0 The device does not have to be explicitly reset by the hostif external power is connected after a disconnection state.

1 The device must be reset explicitly by the host if externalpower is connected after a disconnection state.Note that Reset is an intrinsic USB function.


32/83




4.4 Report 0x07 GAT Data

This event is sent in response to the 0x05 Request GAT Data Report, on page 11. A block of data isreturned containing various identification, diagnostic and auditing data in a format specific to eachmanufacturer and product.

All data must be in ASCII format. New lines are indicated with controlcharacters (or decimal values 13 and 10).

XML tags are not included in the datathis is done outside the peripheral. The following charactersare not allowed in the GAT data:

/ (slash), decimal value 47

< (less than), decimal value 60

> (greater than), decimal value 62

If the total GAT Data size exceeds 64 bytes it can be broken into a number of sequential reports.

GAT data up to 61 bytes in size may be sent in a single report with the Index set to one (1) and the

Size between 0 61. If the GAT reply is longer than this then the data must be split into sequentialpackets with all packets having Size set to 61 bytes followed by a terminating packet which must haveSize set to less than 61 bytes. In this way the host knows when all data has been received. If the lastdata packet fills a 64-byte report exactly then a null packet must be sent as a terminator. This will havea Size of zero (0). Index numbers start at one (1) and increment with each packet sent. The host canstitch all the GAT packets together in the Index number sequence to reproduce the complete GATreport.

The first report will have Index = 1.

If more reports are needed to return all the GAT data then they are indexed 2, 3, 4etc.


Request GAT ReportTX:

GAT DataRX:[ Index ]

[ Size ]

[ Byte 1 ]

[ Byte 61 ]

Table 4.4 0x07 GAT Data Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x07

Byte 1 Index

Byte 2 Size

Byte 3 Data 1

...

Byte 63 Data 61


33/83




4.5 Report 0x09 CRC Data

This event is sent in response to the 0x08 Calculate CRC command (see page 12). The CRC checksumis calculated using a seed value provided in the 0x08 Calculate CRC command (see page 12).

4.5.1 CRC Rules

1. When a CRC request is acknowledged by the device, the CRC Data event containing the 32bit CRC checksum result must be available on the Input End Point within 20 seconds.

2. The checksum address range is pre-determined by the device firmware and must cover all re-programmable areas of memory, except for USB Identification Strings.

Table 4.5 0x07 GAT Data Field Descriptions


Index 1 to 255 Packet sequence counter for multi-packet reports.

Size 0 to 61 Last packet may contain less than 61 characters.Data 32 to 126 ASCII characters (manufacturer specific), except the

following which are not allowed:/ (slash), decimal value 47< (less than), decimal value 60> (greater than), decimal value 62

Calculate CRC

TX:[ Seed 0 - LSB ]

[ Seed 1 ]

[ Seed 2 ]

[ Seed 3 - MSB ]

CRC Data

RX:[ Result 0 - LSB ]

[ Result 1 ]

[ Result 2 ]

[ Result 3 - MSB ]

Table 4.6 0x09 CRC Data Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x09

Byte 1 Result 0

Byte 2 Result 1

Byte 3 Result 2

Byte 4 Result 3

Table 4.7 0x09 CRC Data Field Descriptions


Result 0 to 255 Result of the CRC-32 calculation. Result 0 is the LSB.


34/83




4.6 Report 0x0A Device State

This event is sent in response to 0x02 Enable (see page 10) and 0x03 Disable (see page 10) commandsfrom the host, and indicates whether the device is enabled or disabled. A device must not report bothEnabled and Disabled. The following scenarios A through C are examples of how this event is

implemented.

Scenario A:

1. Host issues Enable.

2. Device enables itself and thus, also sends Device State Event.

Scenario B:

1. Device has fault.

2. Device disables itself.

3. Host issues Enable command.

4. Device stays disabled.

5. Since there is an active fault/failure, the Device must send fault/failure report. There is noneed to send the Device State Event.

Scenario C, Special situation at Boot, after enumeration:

1. Device boots in Disabled State.

2. Device has Credits Pending, no faults or failures.

3. Host issues Disable command.

4. Device responds with Device State event with Disable bit set.

5. Device communicates all pending credits to the host.

6. Device remains disabled.Table 4.8 0x0A Device State Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0x0A

Byte 1 - - - - - - Disable Enable

Table 4.9 0x0A Device State Field Descriptions


Disable 0 --

1 Device disabled.

Enable 0 --

1 Device enabled.


35/83




4.7 Report 0xC4 Failure Status

A Failure Status reports any faults with the peripheral device.

The flags are meant to be generic enough to be used by any manufacturer of printer equipment.Manufacturers may use Byte 2 to provide a more specific fault code (as defined by GSA).

When instructed by the host, the device must perform a diagnostic test. If any fault condition isdetected, this event is sent to the host unless otherwise specified.

During normal operation, the device must also continually check components that may lead to faultyoperation.

4.7.1 Failure Status Rules

1. If any of the bits are set in this register, there is a fault with the printer.

2. The device must self-disable until re-enabled by host.

3. If a fault clears, it must be reported back to the host as being cleared.

4. A 0xC4 Failure Status event must be sent to the host after receiving a 0x04 Self Testcommand (page 11), after receiving a 0x02 Enable command (page 10), if a fault exists, and assoon as a new fault condition is detected.

5. If the Other bit is set, a diagnostic code is provided.

6. The 0xC4 Failure Status event assumes the highest priority for event transmission to the host.All Transaction ID events must wait until the failure is cleared and device is enabled.

If The NVM fault self clears then the NVM Failure event is sent to the host with this bitcleared. This could occur, for example, if the NVM fault was caused by static or RFI (RadioFrequency Interference).

7. A 0xC4 Failure Status report with all bits set to 0, including the Diagnostics field, indicatesthat there are no more active failures and that the device is ready to report events and/oraccept commands

Table 4.10 0xC4 Failure Status Structure

Bit 7 6 5 4 3 2 1 0

Byte 0 0xC4

Byte 1

Other - - -Temperature

Error

PrintHead

DamagedNVM Firmware

Byte 2 Diagnostics


36/83




4.8 Report 0xC5 Ticket Print Status

The Ticket Print Status event is sent when the printer: 1) starts printing, 2) prints a field of interest,and 3) finishes printing a ticket.

4.8.1 Ticket Print Status Rules

1. A Ticket Print Status event is sent in response to a 0xC2 Print Ticket command (page 15).

When the host acknowledges this event, the relevant bits will be cleared in NVM. If a failureoccurs during this operation, a 0xC4 Failure Status event (page 25) will take priority over aTicket Print Status event.

2. A Ticket Print Status event is sent in response to a 0xC3 Form Feed command (page 16) afterthe paper feeding cycle has started and after completed. If a failure occurs during thisoperation, a Failure Status event will take priority over a Ticket Print Status event.

3. When Print In Progress is reported for the first time in the Ticket Print Status event after a0xC2 Print Ticket command, all other bits must be set to zero (0).

Table 4.11 0xC4 Failure Status Field Descriptions


Firmware 0 Firmware is OK.

1 Firmware has failed.NVM 0 NVM is OK.

1 A fault has been detected in the non-volatilememory.

Print HeadDamaged

0 Print head is OK.

1 Print head is damaged. Replacement may berequired.

TemperatureError

0 No error.

1 Temperature is too high at the print head.

Other 0 Indicates that the Diagnostic code in theDiagnostics byte is cleared.If, however, the Diagnostic code is set to 0 (zero),this indicates that all failures are cleared.

1 A Diagnostic code is provided in the Diagnosticsbyte.

Diagnostics 0 No fault information.

1 to 255 See Table 4.12.

Table 4.12 0xC4 Failure Status Diagnostic Codes

Diagnostic Code Description

2-254 Reserved for future use.

255 Unknown Error.
http:///reader/full/page36http:///reader/full/page26http:///reader/full/page35http:///reader/full/page25


37/83




4. When Print Complete is reported in the Ticket Print Status event, Print In Progress mustbe set to zero (0).

5. F1, F2 and F3 will only be reported in the Ticket Print Status event, set to one (1), when thecorresponding Fields of Interest has completed.

6. If either a Paper Jam or Print Head (open) condition is detected while printing a ticket, theprinter report the jam condition and aborts the print process.

7. Across power cycle, the printer will report all outstanding TID Ticket Print Status.

8. If a 0x03 Disable command (page 10) is received while printing, the printer enters the disablemode and