EBDS Protocol Specification

Revision G5

© 2011 Crane Payment Innovations, Inc.

The information contained herein is the property of CPI, Inc. and is not to be disclosed or
used without the prior written permission of CPI, Inc. This copyright extends to all the
media in which this information may be preserved including magnetic storage, punched
card, paper tape, computer printout or visual display.

CONFIDENTIAL PROPERTY
The document and the information contained in it are the confidential property of CPI, Inc.
It must not be copied, duplicated or used in any manner, or trasnmitted to others without
the written consent of CPI, Inc.
Table of Contents
EBDS Protocol Specification ...................................................................................................................... 1
Table of Contents .......................................................................................................................................... 2
1 Change History ...................................................................................................................................... 7
2 Introduction .......................................................................................................................................... 9
2.1 Acronyms and Definitions ............................................................................................................. 9
2.2 Scope ........................................................................................................................................... 10
2.3 Product Icons .............................................................................................................................. 10
2.4 Recommendation / Warning Icons ............................................................................................. 11
2.5 Byte Conventions ........................................................................................................................ 11
3 Overview of EBDS................................................................................................................................ 12
3.1 Varieties of EBDS ......................................................................................................................... 12
3.2 Interfaces .................................................................................................................................... 13
3.2.1 RS-232 ................................................................................................................................. 13
3.2.2 RS-485 ................................................................................................................................. 13
3.2.3 USB ...................................................................................................................................... 13
3.3 Timing Requirements for Communications ................................................................................ 14
3.3.1 Normal (Polled) Mode......................................................................................................... 14
3.3.2 Special Interrupt Mode ....................................................................................................... 15
3.3.3 ACK/NAK Timing Requirements .......................................................................................... 16
3.3.4 ABDS Timing Requirements ................................................................................................ 16
4 EBDS Concepts .................................................................................................................................... 17
4.1 Polling vs. Special Interrupt Mode .............................................................................................. 17
4.1.1 Polling mode ....................................................................................................................... 17
4.1.2 Special interrupt mode ....................................................................................................... 17
4.2 Extended vs. Non-Extended Mode ............................................................................................. 17
4.2.1 Non-Extended Mode ........................................................................................................... 17
4.2.2 Extended Mode ................................................................................................................... 18
4.3 Escrow vs. Non-Escrow mode ..................................................................................................... 18
4.3.1 Escrow Mode....................................................................................................................... 18
4.3.2 Non-Escrow Mode............................................................................................................... 18
4.4 Power Up Policies........................................................................................................................ 19

Revision G5 20105-002850209-PS Page 2

 4.4.1 Basic Devices ....................................................................................................................... 19
4.4.2 PUP-A .................................................................................................................................. 20
4.4.3 PUP-B .................................................................................................................................. 20
4.4.4 PUP-C................................................................................................................................... 20
4.4.5 Advanced Devices ............................................................................................................... 20
4.4.6 PUP-R .................................................................................................................................. 20
4.4.7 PUP-S ................................................................................................................................... 21
4.4.8 Quick Reference Tables....................................................................................................... 21
4.5 ABDS ............................................................................................................................................ 22
4.6 No Value Documents .................................................................................................................. 22
4.6.1 Barcode ............................................................................................................................... 22
4.6.2 Bookmarks .......................................................................................................................... 22
4.6.3 Coupons .............................................................................................................................. 23
4.7 Calibration ................................................................................................................................... 23
4.8 Flash Download ........................................................................................................................... 23
4.8.1 ABDS Flash Download ......................................................................................................... 23
4.9 Inhibiting The Device................................................................................................................... 24
4.9.1 Non-Extended Mode ........................................................................................................... 24
4.9.2 Extended Mode ................................................................................................................... 24
4.10 Multi-Note Escrow vs. Single Note Escrow ................................................................................. 25
5 Expected Operations ........................................................................................................................... 26
5.1 Start Up Tasks ............................................................................................................................. 26
5.1.1 Power up Handling .............................................................................................................. 27
5.2 Application Currency Handling ................................................................................................... 28
5.2.1 Recommended Document Handling Flowchart .................................................................. 28
5.2.2 Requesting the Note Table ................................................................................................. 29
5.2.3 Controlling the Orientation of Notes .................................................................................. 30
5.2.4 Issuing Credit ....................................................................................................................... 30
5.3 Handling ENQs (Special Interrupt Mode) .................................................................................... 31
5.4 Handling Acceptor Exceptions .................................................................................................... 32
5.4.1 Exceptions Related to Polling .............................................................................................. 32
5.4.2 Exceptions Related to Status Bits........................................................................................ 32

Revision G5 20105-002850209-PS Page 3

6 EBDS General Messaging .................................................................................................................... 35
6.1 Packet Layout .............................................................................................................................. 35
6.1.1 EBDS .................................................................................................................................... 35
6.1.2 ABDS .................................................................................................................................... 35
6.2 Receiving a Reply ........................................................................................................................ 36
6.3 ACK/NAK Processing ................................................................................................................... 37
6.4 Control Byte ................................................................................................................................ 41
6.4.1 ACK/NAK Processing ........................................................................................................... 41
6.4.2 Device Type Message Routing ............................................................................................ 42
6.4.3 Message Type...................................................................................................................... 43
7 EBDS Message Details ......................................................................................................................... 44
7.1 General Messages ....................................................................................................................... 44
7.1.1 (Type 1) Omnibus Command .............................................................................................. 44
7.1.2 (Type 2) Omnibus Reply ...................................................................................................... 49
7.1.3 (Type 3) Bookmark Omnibus Command ............................................................................. 54
7.2 (Type 4) The Calibrate Command ............................................................................................... 55
7.3 (Type 5) Flash Download ............................................................................................................. 56
7.3.1 Phase 1: Starting Download ................................................................................................ 57
7.3.2 Phase 1-B: Setting Baud Rate (Optional) ............................................................................ 58
7.3.3 Phase 2: Downloading......................................................................................................... 60
7.3.4 Phase 3: Finishing the Download ........................................................................................ 62
7.3.5 Flash Download Flow Diagram ............................................................................................ 63
7.3.6 Troubleshooting Flash Download Problems ....................................................................... 64
7.4 (Type 6) Auxiliary Commands ..................................................................................................... 65
7.4.1 (Subtype 0x00) Query Software CRC................................................................................... 67
7.4.2 (Subtype 0x01) Query Cashbox Total .................................................................................. 67
7.4.3 (Subtype 0x02) Query Device Resets .................................................................................. 68
7.4.4 (Subtype 0x03) Clear Cashbox Total ................................................................................... 68
7.4.5 (Subtype 0x04) Query Acceptor Type ................................................................................. 69
7.4.6 (Subtype 0x05) Query Acceptor Serial Number .................................................................. 69
7.4.7 (Subtype 0x06) Query Acceptor Boot Part Number ........................................................... 70
7.4.8 (Subtype 0x07) Query Acceptor Application Part Number ................................................. 71

Revision G5 20105-002850209-PS Page 4

 7.4.9 (Subtype 0x08) Query Acceptor Variant Name................................................................... 72
7.4.10 (Subtype 0x09) Query Acceptor Variant Part Number ....................................................... 72
7.4.11 (Subtype 0x0A) Query Acceptor Audit Life Time Totals ...................................................... 73
7.4.12 (Subtype 0x0B) Query Acceptor Audit QP Measures.......................................................... 75
7.4.13 (Subtype 0x0C) Query Acceptor Audit Performance Measures ......................................... 76
7.4.14 (Subtype 0x0D) Query Device Capabilities.......................................................................... 78
7.4.15 (Subtype 0x0E) Query Acceptor Application ID .................................................................. 80
7.4.16 (Subtype 0x0F) Query Acceptor Variant ID ......................................................................... 81
7.4.17 (Subtype 0x10) Query BNF Status ....................................................................................... 81
7.4.18 (Subtype 0x11) Set Bezel..................................................................................................... 82
7.4.19 (Subtype 0x12) Query Acceptor Audit Life Time Totals Extended ...................................... 83
7.4.20 (Subtype 0x13) Query Acceptor Audit QP Measures Extended.......................................... 85
7.4.21 (Subtype 0x14) Query Acceptor Audit Performance Measures Extended ......................... 86
7.4.22 (Subtype 0x15) Query Asset Number ................................................................................. 87
7.4.23 (Subtype 0x16) Query Acceptor Audit Total Documents Reporting Structure ................... 88
7.4.24 (Subtype 0x17) Query Acceptor Audit Total Documents Recognized ................................ 90
7.4.25 (Subtype 0x18) Query Acceptor Audit Total Documents Validated ................................... 91
7.4.26 (Subtype 0x19) Query Acceptor Audit Total Documents Stacked ...................................... 92
7.4.27 (Subtype 0x1A) Acceptor Diagnostics Self Test................................................................... 94
7.4.28 (Subtype 0x1D) Query Acceptor Diagnostics Sensor Data .................................................. 97
7.4.29 (Subtype 0x23) Query Hardware Status ............................................................................. 98
7.4.30 (Subtype 0x7F) Acceptor Soft Reset.................................................................................... 98
7.5 (Type 7) Extended Commands .................................................................................................... 99
7.5.1 (Subtype 0x01) Extended Barcode Reply .......................................................................... 101
7.5.2 (Subtype 0x02) Extended Note Specification Message .................................................... 102
7.5.3 (Subtype 0x03) Set Extended Note Inhibits ...................................................................... 104
7.5.4 (Subtype 0x04) Set Escrow Timeout / Extended Coupon ................................................. 106
7.5.5 (Subtype 0x05) Set Asset Number .................................................................................... 107
7.5.6 (Subtype 0x06) Query Value Table.................................................................................... 107
7.5.7 (Subtype 0x0B) Note Retrieved......................................................................................... 108
7.5.8 (Subtype 0x0C) SHA-1 Request ......................................................................................... 109
7.5.9 (Subtype 0x0D) Advanced Bookmark Mode ..................................................................... 111

Revision G5 20105-002850209-PS Page 5

 7.5.10 (Subtype 0x10) Cashbox Cleanliness ................................................................................. 112
7.5.11 (Subtype 0x11) Request 16-bit CRC Calculation ............................................................... 113
7.5.12 (Subtype 0x12) Request 32-bit CRC Calculation ............................................................... 115
7.5.13 (Subtype 0x13) Request Recycler Note Table ................................................................... 116
7.5.14 (Subtype 0x14) Set Recycler Note Value Enables ............................................................. 118
7.5.15 (Subtype 0x15) Recycler Omnibus Command/Reply ........................................................ 119
7.5.16 (Subtype 0x16) Dispense Bills ........................................................................................... 123
7.5.17 (Subtype 0x17) Cancel Dispense/Float ............................................................................. 123
7.5.18 (Subtype 0x18) Float Bills .................................................................................................. 124
7.5.19 (Subtype 0x19) Last Cash Movement Summary Report ................................................... 124
7.5.20 (Subtype 0x1A) Missing Note Report ................................................................................ 126
7.5.21 (Subtype 0x1B) Request Physical Recycler Status............................................................. 127
7.5.22 (Subtype 0x1C) RFID Data Request ................................................................................... 129
7.5.23 (Subtype 0x1D) Clear Audit Data Request ........................................................................ 133
7.5.24 (Subtype 0x20) Escrow Session Summary Report............................................................. 134
8 Appendix A – Protocol Examples ...................................................................................................... 138
8.1 Disabling the Device .................................................................................................................. 138
8.1.1 Normal Situation ............................................................................................................... 138
8.1.2 Processing a Document..................................................................................................... 139
8.1.3 Processing a Document in Non-Escrow Mode .................................................................. 140
8.2 Requesting the Note Table ....................................................................................................... 141
8.3 Using Type 6 Audit Commands (0x16, 0x17, 0x18, 0x19) ......................................................... 142
9 Appendix B – Quick Reference Tables for Type 6 Messages ............................................................ 145
10 Appendix C – Quick Reference Tables for Type 7 Messages ............................................................ 146
11 Appendix D - Quick Reference EBDS Message Structure .................................................................. 147

Revision G5 20105-002850209-PS Page 6

1 Change History
Issue Date Description
G1 12/08/2011 Initial Revision
Updated ENQ values
Correct typo in Cashbox Cleanliness Response Message
Added recommendation to Flash Download procedure to store
G2 4/10/12
device information before beginning a download
4/13/12 Fixed Typo in Device Acceptor Diagnostics Self Test Reply
4/23/12 Updated ENQ section to include JAM ENQ for leaving the state.
Added comment regarding ENQ omission if event occurs on very
5/07/12
first poll.
Added section to protocol examples to provide more clarity on
6/01/12
Type 6 subtype 0x16 – 0x19 commands
Updated ENQ table to state ENQ is sent after Jammed state is
9/20/12
exited.
9/21/12 Updated wording for ‘Cheated’ Event.
Updated “Audit Total Documents Reporting Structure” message
to account for incorrect specification of response length.
Clarified “Advanced Bookmark” handling of validated
10/10/12 documents.
Updated section headers to contain Hex numbers where
applicable.
Corrected message index error in “Extended Note Message.”
Added additional byte description to Query BNF status message.
(New Failure Code byte was added).
10/15/12
Added new section on RFID tag read/write requests (Type 7
subtype 0x1C command).
11/06/12 Defined the EBDS Type 7 command for Clear Audit Data Requests
Added clarification about rejected event to cover conditions
11/21/12
when a document is unable to be drawn in by the device.
G3 12/05/12 Finalized wording for “Cheated” event.
Corrected type 6 subtype 4&5 messages to specify the correct
02/01/13
terminator (null 0x00 changed from space 0x20)
Updated QP Measures tables to reflect accurate description of
06/05/13 fields. Some portions were marked as "documents" but in reality
they only reported "banknotes".
Updated details regarding when Note Retrieved (Type 7 subtype
06/14/13
0x0B) can be NAK'd by the device.
Added details to 5.2.1 (Recommended Document Handling) to
07/10/13 clarify possibility of two Stacked events (if the host is unable to
ACK the first one prior to a power loss)
Updated the device capabilities structure to include missing bit
07/19/13
for Clear Audit Command support.
Incorporated the SCR Addendum document. Contains many new
G4 10/18/13
features and details around the SCR device.
Updated Section on incompatible software in regards to flash
2/24/14
download for SC Advance and SCR devices.

Revision G5 20105-002850209-PS Page 7

 Added comment that "Stacked", "Returned" and "Rejected" are
4/1/14
all mutually exclusive.
Improved the Audit structure for SCR device. A field was added
to QP Measures (Escrow Timeout Count) and one to extended
audit General (Total Dispense Sessions).
4/24/14
Removed the following fields from Audit Performance for SCR:
CC0, CC1, Jammed While Rejecting, Stacker Jams, Jams without
recovery enabled,
Added warning to LCM summary to inform customers that the
5/1/14
command will be NAK'd during power up.
8/5/14 Added definition of the "Fast Serial Download Protocol".
Added support for Multi-Note Escrow mode of the SCR.
Added warning about non-extended note mode and banknotes
with greater than seven indices.
G5 3/27/15
Updated Flash Download section with latest details.
Added Type 6 subtype 0x23 command.
Added classification details to Type 7 subtype 0x03 message.

This document replaces the following versions of the EBDS manual:

 Generic EBDS Interface Manual (MEI Part number 20105-002850110)
 Retail – EBDS Protocol Specification (with M/POST for EBDS) (MEI Part number 20150-
002850131-PS)

Revision G5 20105-002850209-PS Page 8

2 Introduction
2.1 Acronyms and Definitions
Keyword Meaning / Context
ABDS Addressable Enhanced Bi-Directional Serial
ACK Acknowledgement. Means the host/device has received the last
communication and it is valid (or the request can be honored).
BDS Bi-Directional Serial
EBDS Enhanced Bi-Directional Serial
Denom Stands for denomination. In reference to a bank note index. (ex. Denom 4
can be the $20 US note)
Document This refers to either a banknote (with value) or a no-value document such as
a barcode, bookmark or coupon.
Fixed Width Refers to devices that can only take currency with a single width across all
denominations. (USD is a fixed width currency)
Gaming Refers to customer environments centered on the casino and
entertainment industries.
Host Refers to the master software/hardware that is controlling the device.
Multi Width Refers to devices that can take currency with varying widths across
denominations. (EUR is a multi-width currency)
NAK Negative Acknowledgement - Means the host/device has received the last
communication and it is NOT valid (or the request can NOT be honored).
Note Refers to a Banknote or a piece of currency.
PUP Power Up Policy. Refers to the routine that the device follows in regards to
processing a note or document that was stranded in the path due to a
temporary power outage.
Retail Refers to customer environments centered on industries that use self-
checkouts, kiosks and smart safes.
Stack (verb) To stack a document means the device has accepted the document and will
store (stack) it in the cashbox where it is no longer retrievable by the
customer.
STS MEI’s STS support tool is an application used to configure some MEI
products. Contact MEI Sales or Technical support for information on the STS
support tool.
Variant Another term for a currency set. (ex. A US variant can contain the $1, $5,
$10, $20, $50 and $100 banknotes.) Variant sets can also contain multiple
currency types (EUR and GBP).
When appropriate, all hexadecimal characters are prefixed by ‘0x’ to ensure they are not confused with
a decimal representation.
Unless otherwise noted, it is the convention to refer to array indexing using a zero based approach.
Meaning the first value is referenced by the number zero ‘0’. Therefore, ‘byte 1’ is the second byte in
the array.

Revision G5 20105-002850209-PS Page 9

2.2 Scope
The scope of this document is to specify the EBDS protocol with the goal of making it easier to
incorporate EBDS devices into business solutions. To this end, the intended audiences of this document
are host system software developers, technical support specialists and system integrators.

This document will provide details aimed at both the Gaming market (casino and entertainment) and
the Retail market (Self-checkout, kiosks, and safes).

This document will examine EBDS as used in the following products:

Family Common Models
Series 2000 AE2600, AE2800
Cashflow SC SC-66, SC-76, SC-83, SC-85
Cashflow SE (Stackerless) SE-83, SE-85, SB-83, SB-85
MEI SC Advance SCN-66, SCN-83, SCN-85
MEI SCR SCR-83

The following legacy products support EBDS but are not mentioned in this document heavily:
Family Model Description
Series 1000 ZT1200 Discontinued products
Series 3000 LE, RS, EX Discontinued products

The rest of the document will outline the technical details of the EBDS protocol and when using
examples, it will only refer to existing products. The terminology and expected results may not apply
with older hardware.

2.3 Product Icons

Some features of EBDS are specific to or vary by the product implementing them. All technical details
will be described using the context of existing products only. Some statements may not apply to older
hardware. To indicate this, the following icons are used when referencing supported hardware:
S2K All series 2000 retail products (AE2600, AE2800)
BNF A Cashflow-SC with the Bunch Note Feeder Option
CFSC All Cashflow-SC products. (Includes Stackerless Configuration)
SC Adv MEI SC Advance products. (Includes Stackerless Configuration)

SCR MEI SC Advance Recycler.

MULTI Note Escrow Only MEI SC Advance Recycler configured for Multi Note Escrow Mode

Single Note Escrow Only MEI SC Advance Recycler configured for Single Note Escrow Mode
Please note that the BNF field can be assumed included with all CFSC and/or SC Adv components
that support the Retail Code base.

Revision G5 20105-002850209-PS Page 10

2.4 Recommendation / Warning Icons
The following warning icons are used to highlight best practices and potential problem areas.
Recommended A feature that is recommended as a best practice.

Gaming Only Feature only applies to Gaming Software. CFSC , SC Adv , or SCR Only.
Retail Only Feature only applies to Retail Software. CFSC , SC Adv , or SCR Only.
Incompatible A feature that is incompatible or mutually exclusive.

Deprecated A feature that is no longer recommended.

Obsolete A feature that is no longer supported.

Warning A warning about a potential problem.

2.5 Byte Conventions

This document contains several examples for manipulating the byte/bit values of the EBDS messages.
One concept that applies to several messages is the need to break a full byte of information into two
nibbles (4 bits). The reason for this is because EBDS is a 7 bit protocol therefore it is not possible to
transmit a full byte (8bits) in a single EBDS byte. To facilitate this, the byte is broken into two bytes; one
containing the upper 4bits and the other containing the lower 4 bits.

For example, the value 0xA7 will be broken down into { 0x0A, 0x07 } in order to be transmitted. If
received by the host, it will need to be rebuilt in order to obtain the correct value by using a shift
operation. Assuming ‘reply’ refers to the returned byte array:
Value = reply[0] << 4 | reply[1];
This shifts the most significant value (0x0A) by four bits to generate ‘0xA0’. The ‘or’ operation is then
used in conjunction with the remaining value to get ‘0xA7’.

Revision G5 20105-002850209-PS Page 11

3 Overview of EBDS
3.1 Varieties of EBDS
The EBDS protocol has evolved over time. As it has changed, the naming of the versions has also
changed. The family tree of EBDS is illustrated below.

Acronym Meaning
BDS Bi-Directional Serial Protocol Obsolete
EBDS Enhanced Bi-Directional Serial Protocol
ABDS Addressable Bi-Directional Serial Protocol
EBDS Plus Enhanced Bi-Directional Serial Protocol Plus

 The BDS protocol is no longer supported on any current cash handling products. This protocol is
discussed here only to extent needed to point out migration issues.
 The EBDS protocol is widely used on Series 2000 as well as legacy Series 1000, 3000 and older
SC-66 models.
 The ABDS protocol is supported by Series 3000, Cashflow-SC, and SC Advance platforms with the
RS-485 option installed. This protocol allows multiple cash acceptors to be connected to a single,
multi-drop, host port.
 EBDS Plus is similar to EBDS with the additional option of extended note reporting and several
command-oriented extensions to the original omnibus command packet. This represents the
current state of the EBDS protocol

Revision G5 20105-002850209-PS Page 12

3.2 Interfaces
Data in EBDS is transmitted using asynchronous data bytes. These may be formatted as:
 9600bps, 7 data bits, even parity, one stop bit
 1200bps, 7 data bits, even parity, one stop bit Obsolete
The EBDS protocols support a number of different types of physical layers. These are laid out below.

3.2.1 RS-232
The RS-232 interface is supported across all products. It should be noted though that some products
require the use of an adapter harness to be used in this mode. EBDS uses the minimum, three wire,
configuration (GND, TXD, RXD) with no handshaking lines. The data transmission across the line
corresponds to the EIA RS-232 spec, which is not repeated here. The formal specification may be found
in ITU-T Recommendation (formally CCITT Recommendation) V.24. A more useful, if less formal
specification, may be found at the Wikipedia web site under the topic RS-232.

3.2.2 RS-485
The RS-485 interface is a specialized interface used to support the multi-drop features of the ABDS
protocol. It is supported by the RS-485 interface adapter harness of the Series 3000 and by the
Cashflow-SC with the RS-485 Interface Board option. When RS-485 is used, all communications occur
over a single balanced pair data line in a true half-duplex mode. No handshaking lines are used.

3.2.3 USB
The EBDS protocol may also be embedded inside the USB virtual communications port protocol. This
may be accomplished with an RS-232 Virtual Com Port Cable or through the use of the appropriate
harness (for Series 2000) or interface board (for Cashflow-SC). No handshake lines are utilized.
The protocol layers involved in embedding EBDS in USB are covered in publicly available USB specs and
are not covered in this document.

Warning Some USB Virtual Com Cables do not support the data transfer parameters required by EBDS
(9600, 7, E, 1). These cables may not work with an EBDS device. In addition, some of these cables
introduce delays that may disrupt some EBDS operations.

Revision G5 20105-002850209-PS Page 13

3.3 Timing Requirements for Communications
The device can operate in two distinct modes. Each mode has a different set of required timing
constraints. These modes are covered in more detail in the Polling vs. Special Interrupt Mode section
(4.1). This section also covers miscellaneous timing requirements that are independent of the operating
mode.

3.3.1 Normal (Polled) Mode

Recommended In normal mode, EBDS operates as a standard host/peripheral system with all
transactions initiated by the host and only replies generated by the peripheral.

In polled mode, the host system is responsible for ensuring the device is polled frequently and on a
stable interval of time. This table outlines the acceptable ranges for communications.
Parameter Lower Upper Description
Limit Limit
Inter-character 0ms 20ms If the maximum inter-character time is exceeded, the
Timing receiver of the packet should discard the current packet
and resume its search for an STX character.
Peripheral Response 0ms 35ms If the peripheral device has not started to respond within
Time this amount of time after a packet is sent to it, the host
should assume that no reply is going to be sent by the
peripheral.
Polling Interval 50ms 1s This is the rate at which the host should communicate
with the peripheral. The recommended polling interval is
200ms.
Note that failure to properly poll the device at all times
may result in impaired or unexpected operation.
50ms 250ms BNF When a bunch note feeder is installed, a faster
polling rate is required to maintain system performance.
Note that failure to properly poll the device at all times
may result in impaired or unexpected operation.
Peripheral Disable 3s - If the peripheral does not receive a poll from the host
Timeout within this time period, it will disable itself to avoid
continuing to accept money on a system with a disabled
host.

Revision G5 20105-002850209-PS Page 14

3.3.2 Special Interrupt Mode
Deprecated In special mode, EBDS adds a facility for the peripheral device to request that the host
perform a poll operation. The host is still required to poll the host on a regular basis, however the time
interval can be much greater compared to polling mode.

When the peripheral detects an event that requires host attention, it sends a single ENQ (0x05). The
ENQ character will never be sent while a reply is being sent, but it can be sent while a host command is
being sent. When the host receives the ENQ, it should poll the peripheral.
Parameter Lower Upper Description
Limit Limit
Inter-character 0ms 20ms If the maximum inter-character time is exceeded, the
Timing receiver of the packet should discard the current packet
and resume its search for an STX character.
Peripheral Response 0ms 35ms If the peripheral device has not started to respond within
Time this amount of time after a packet is sent to it, the host
should assume that no reply is going to be sent by the
peripheral.
Polling Interval 50ms 30s This is the rate at which the host should communicate
with the peripheral. The recommended polling interval is
1 second.
Note that failure to poll the device will cause it to enter
an error condition and disable itself.
Peripheral Disable 33s - If the peripheral does not receive a poll from the host
Timeout within this time period, it will disable itself to avoid
continuing to accept money on a system with a disabled
host.
ENQ Response Time 0ms 100ms If the host does not respond to the ENQ within the
required time, the peripheral will retry sending the ENQ.
Note that failure to quickly respond to ENQs may result in
impaired or unexpected operation.
ENQ Response 3s - If an ENQ is sent and the host does not reply by this limit,
Timeout the peripheral will disable itself be to avoid continuing to
accept money on a system with a disabled host.

Revision G5 20105-002850209-PS Page 15

3.3.3 ACK/NAK Timing Requirements
In general, an ACK to a response can wait until the next scheduled poll and no special timing is required.
A NAK however is subject to a special limit. Under some conditions, the host must NAK the device in
fewer than 100ms to ensure the device does not proceed with money processing. If more than 100ms
elapse, the device will proceed on the assumption that the host ACK is on its way. Since there is no way
to be certain when these conditions exist the following spec applies to all NAK replies:
Parameter Lower Upper Description
Limit Limit
Initial NAK 50ms 100ms When a NAK condition is detected, the host should
Response Time communicate with the peripheral in less than 100ms.
Following NAK 50ms 3s If subsequent NAKs are required, this more relaxed
Response Time timing may be used.
Non- 3s If a device does not eventually respond, the host
acknowledge should consider the device to be out of service.
Timeout

3.3.4 ABDS Timing Requirements

Since ABDS is implemented on a shared RS-485 bus, it is necessary to control which party has its bus
“drivers” turned on. To avoid bus conflicts, the bus driver must be turned on no more than 1ms before
transmission begins and must be turned off no later than 1ms after the transmission is completed.
Parameter Lower Upper Description
Limit Limit
Bus Driver Turn-On 0 1ms The RS-485 Drivers must be turned on before data can
Lead Time be sent, but must not be turned on more than 1 ms
before the start of data transmission.
Bus Driver Turn Off 0 1ms The RS-485 Drivers must not be turned off before the
Hold Time end of data transmission, but they must be off by no
more than 1ms later.

Revision G5 20105-002850209-PS Page 16

4 EBDS Concepts
4.1 Polling vs. Special Interrupt Mode
The preferred method of operations is the polling mode. This ensures the best operational speed.

In the normal polling mode, the device will inhibit itself (not accept any notes) if it does not receive a
message within 4 seconds. However, in special interrupt mode, the device will remain in service as long
as it receives polls at least every 30 seconds.

4.1.1 Polling mode

Recommended In polling mode, the host shall regularly send messages to the connected device at a
specified interval. The device will then in turn, respond back to the poll with a reply message. This reply
message contains all of the information required for the host to understand the current state of the
device. The recommended poll rate in EBDS is 200 milliseconds. For best performance, this poll rate
should remain constant at all times.

4.1.2Special interrupt mode

SCR Obsolete Special Interrupt mode is not supported for the SCR product line.

Special Interrupt mode differs significantly in the implementation of the host machines logic. In special
interrupt mode, EBDS adds the ability for the peripheral device to request that the host perform a poll
operation. The host is still required to poll the host on a regular basis, however the time interval can be
much greater compared to polling mode. The device still requires these regular polls in order to ensure
it is in the correct configuration state and that the host is still active. In addition to the regular poll, the
host shall be required to send a poll message when the device detects a significant event. When the
device detects a significant event that requires host attention such as a note at escrow, it sends a single
ENQ (0x05). The ENQ character will never be sent while a reply is being sent, but it can be sent while a
host command is being sent. When the host receives the ENQ, it should immediately poll the peripheral.
Please see Handling ENQs (Special Interrupt Mode) section for more details on ENQs.

4.2 Extended vs. Non-Extended Mode

There are two different ways to handle currency with the EBDS protocol. Non-extended mode is the
original mode for handling currency and has some limitations with the type of currency it can support.
Extended mode is the recommended mode although it may not be supported on all devices.

4.2.1 Non-Extended Mode

S2K CFSC SC Adv
While extended mode is preferred, it is not supported across all production platforms. In those cases,
non-extended mode must be used. One issue that is raised by non-extended mode is that bank notes
are not identified as to their value, but are merely given an identifier from 1 through 7. This index should
be used to reference a known value for that denom and is reported as part of the standard omnibus
reply from the device. Please see section 7.1.2.3 for further details about the reporting of
denominations. The denom’s index can differ on some hardware/software platforms. If there is any
confusion to the index values for a specific device or variant, please consult the device manual or
contact technical support.

Revision G5 20105-002850209-PS Page 17

Warning Non-Extended Note mode cannot be used with variants that have more than seven
banknote indices.

4.2.2 Extended Mode

CFSC SC Adv SCR
Recommended Whenever possible, extended note reporting should be used to enhance code
portability and reliability. All CFSC, SC Adv, and SCR hardware support this mode. Series 2000 devices are
not capable of this mode and must use the non-extended mode. SCR only supports this mode.

Extended note reporting allows for changes in the currency table and provides for much finer control
over the type and orientation of notes accepted. When the device reports a banknote, it will do so by
issuing an extended message. This is unlike the standard omnibus reply that is used in non-extended
mode. The details on the extended message can be found in section: (Subtype 0x02) Extended Note
Specification Message (7.5.2)

4.3 Escrow vs. Non-Escrow mode

Independent of non-extended mode or extended mode, the device has two other settings to handle
how documents are reported to the host. In escrow mode, the device will wait for a command from the
host as to whether to stack or return a valid document. In non-escrow mode, the device will
automatically stack all valid documents.

4.3.1 Escrow Mode

Recommended In escrow mode, once a document is validated it is held in place (this position is
called ‘Escrow’). A message is sent to the host to inform them that a valid document is at escrow and the
host should choose to either stack or return the document. If told to stack, the device will then issue
another message after the stack is complete to signal to the host that it has successfully stacked the
document and it can now be credited.

4.3.2 Non-Escrow Mode

Deprecated In this mode, the device will not prompt the host for a decision and will instead assume
the host desires the device to stack every valid document. If the document is a note, the host will only
be informed of its value once it is stacked.

Incompatible Non-Escrow mode is incompatible with the power up policies and will not enable until
the power up is complete. If there are any exceptional cases during power up (section 4.4), then the
host must be prepared to handle any escrow related events that may occur.

Incompatible This mode will not work with Barcodes. If barcodes are enabled in the device, then
they will enter the escrow position and wait for the host to explicitly stack or return them.

SCR Obsolete This mode is not supported for the SCR product line.

Revision G5 20105-002850209-PS Page 18

4.4 Power Up Policies
The power up policies are settings that govern how the device will handle exceptional cases during
power up. The main purpose of these policies is to ensure documents are handled as expected if the
power is lost while processing one. Power up policies were first introduced for the gaming industry but
can be used by the retail sector as well. If the device was processing a document before a power loss,
the device can operate differently depending on the policy when re-initializing.
For clarity, the power up policies are divided into two sections to handle basic devices (bill acceptors)
and advanced devices (bill recyclers).

4.4.1 Basic Devices

CFSC SC Adv
There are 3 power up policies (policy A, B or C) and they each share some similarities. The power up
routine can be divided up into 3 distinct sections; each section refers to a possible physical location of
the document before power was lost.

Recommended If there is any confusion to these policies, Pup-A is the recommended default policy.

The behavior of the policies is explained in more detailed in the following sections, but here a quick
overview of the intent behind them:
 Pup-A is designed for higher uptime. The host needs to maintain the value of the note after the
escrow position and the device will leave it up to the host to accept/reject any document at the
escrow position.
 Pup-B and C are designed for higher security. The devices will go out of service if the note is at a
specified position and will not give the host the chance to process this document.

There are three distinct positions in which the note can be during the power up procedure. These
positions are “pre-escrow”, “escrow” and “post-escrow”. They are described here:
 Pre-Escrow: Defined as any point before the note reaches escrow.
 Escrow: The document has been validated by the device and was waiting for the host to inform
the device of the action for the document (stack or return) but did not receive an action from
the host. It is also possible that the device did receive an action but was unable to begin that
action when power was lost.
 Post-Escrow: At this state, the host has already told the device to stack the document and it can
be assumed that the document is no longer retrievable.

The next three sections describe each of the power up policies and the operation of the device in each
of the three possible positions for the document. These conditions are independent of the Escrow Mode
in which the host has configured the device to operate; default behavior is for Escrow Mode (section
4.3).

Revision G5 20105-002850209-PS Page 19

4.4.2 PUP-A
 Pre-Escrow: The document will be automatically rejected by the device. The host will be
informed of this rejection.
 Escrow: The device will re-issue the escrow event but it will have no value associated with it (It is
up to the host to track the value of the document for the purpose of power up handling). The
device will wait for a command from the host to either stack or return the document.
 Post-Escrow: The procedure will complete and the document will be stacked. However, no value
will be reported to the host.

4.4.3 PUP-B
 Pre-Escrow: The document will be automatically rejected by the device. The host will be
informed of this rejection.
 Escrow: The device will go out of order and hold the document at the escrow position.
 Post-Escrow: The procedure will complete and the document will be stacked. If the document
was a banknote, the host will be informed of the value of the note. If the document is not a
banknote, it will be stacked and no value will be reported to the host.

4.4.4 PUP-C
 Pre-Escrow: The document will be automatically rejected by the device. The host will be
informed of this rejection.
 Escrow: The device will go out of order and hold the document at the escrow position.
 Post-Escrow: The procedure will complete and the document will be stacked. However, no value
will be reported to the host.

With policies A and C, it is required for the host to store the value of the note when it reaches the
Escrow position. This way, the host can accurately determine the value of the note should there be a
temporary power loss.

4.4.5 Advanced Devices

SCR
The SCR device introduces an entirely different set of power up policies. Pup-R and Pup-S. These
policies only differ in how they handle post dispensed note events. The sections below outline the
behavior of the system depending on the position and state of the document at time of power loss.

4.4.6 PUP-R
 Pre-Escrow: The document will be automatically rejected by the device. The host will be
informed of this rejection.
 Escrow: The device will re-issue the escrow event and it will have the correct value (if any). The
device will wait for a command from the host to either stack or return the document.
 Post-Escrow: Return the document to the escrow position but report no value. The device will
wait for a command from the host to either stack or return the document.
 Inventoried Note: Device will complete the movement of the document and report the result to
the host.
 Dispensing - Pre-Dispensed Event: Return the note to the recycler.
 Dispensing - Post-Dispensed Event: Complete the movement and report the result to the host.

Revision G5 20105-002850209-PS Page 20

4.4.7 PUP-S
 Pre-Escrow: The document will be automatically rejected by the device. The host will be
informed of this rejection.
 Escrow: The device will re-issue the escrow event and it will have the correct value (if any). The
device will wait for a command from the host to either stack or return the document.
 Post-Escrow: Return the document to the escrow position but report no value. The device will
wait for a command from the host to either stack or return the document.
 Inventoried Note: Device will complete the movement of the document and report the result to
the host.
 Dispensing - Pre-Dispensed Event: Return the note to the recycler.
 Dispensing - Post-Dispensed Event: If the document is still deeply within the bill path the device
will return the document to the escrow position but report no value. The device will wait for a
command from the host to either stack or return the document.

4.4.8 Quick Reference Tables

The following table summarizes the expected PUP behavior for a given situation
CFSC SC Adv
Action on power up based on document position
PUP Mode
Pre-Escrow Escrow Post Escrow
PUP A Reject Document Wait for Host to issue Stack the document and report “No
Stack/Return command Value”
PUP B Reject Document Out Of Order Stack the document with the correct
Value (if a bank note)
PUP C Reject Document Out Of Order Stack the document and report “No
Value”

SCR
Action on power up based on document position Dispensing
PUP
Pre- Escrow Post Inventoried Pre- Post-
Mode
Escrow Escrow Note Dispensed Dispensed
PUP R Reject Remain at Return doc to Complete Return Complete
Document Escrow. escrow. movement document to movement
Reports value. (No value) and report to recycler and report
host to host
PUP S Reject Remain at Return doc to Complete Return If in bill
Document Escrow. escrow. movement document to path, return
Reports value. (No value) and report to recycler doc to
host escrow.
(No value)

Revision G5 20105-002850209-PS Page 21

4.5 ABDS
CFSC SC Adv Deprecated
ABDS stands for Addressable Bi Directional Serial. It is a subset of the BDS protocol that allows multiple
peripherals to be connected on the same bus. It requires an RS-485 multi-drop interface card that
contains hardware ‘dip’ switches to allow setting a specified address value. Each device will
communicate with the same host application instance. Each device is configured with a unique address
(via DIP switch) that the host can use to select the correct device. The host should be aware of the
number of devices linked in this configuration and plan out a proper poll rate to ensure each device still
receives polls within the specified timing requirements (section 3.3).

4.6 No Value Documents

The EBDS protocol supports reporting on documents that don’t have any intrinsic value. The two main
documents are barcodes and bookmarks. There is also a third type of document called a coupon that is
available for some hardware. The support for these documents must be explicitly turned on by the host
through the omnibus command.

4.6.1 Barcode
CFSC SC Adv
A barcode is a bank note sized piece of paper with a barcode pattern in the center of the document. The
barcode value can be read and presented to the host application for acceptance or rejection. It is up to
the host to determine the monetary value of the barcode. This is primarily used in gaming applications.
Note: Not all versions of hardware support barcodes.

4.6.2 Bookmarks
CFSC SC Adv S2K
Bookmarks are meant to be placeholders for someone to re-visit at a later time. For example, if there is
a dispute with a customer, the operator could insert a bookmark that he could refer to at a later time
when it is feasible to bring the machine down. Bookmarks come in two different types. A standard
bookmark is much smaller than a valid bank note and must fall within a certain size range. Once it meets
these size requirements, it is stacked with no value. This bookmark message is described in section
7.1.3. A non-standard bookmark can be enabled in some software and is discussed further in the
(Subtype 0x0D) Advanced Bookmark Mode section (7.5.9).

Size limitations for standard bookmarks are provided in the following table.
Product Bookmark Size
CFSC SC Adv Bookmark dimensions are 2.6” by 4”
S2K Bookmark dimensions are 2.6” by 5”

Revision G5 20105-002850209-PS Page 22

4.6.3 Coupons
S2K
A coupon is a document that is recognized by the device and may or may not have an associated
monetary value. The application of coupons is usually limited to the vending and kiosk industries and
represent a “free vend” or an amount off of a service. EBDS can support reporting the monetary value of
some forms of approved coupons. However, some other non-value coupons will not be supported over
EBDS. If the host machine enables this advanced support (section7.1.1.3), then the device will respond
with a special message when one of these coupons is inserted (section 7.5.4). If the host does not
enable this advanced reporting mode, the device can still stack some supported, value-based coupons
but it will report it as if it were a valid bank note; if the coupon does not have a value, it will be
automatically rejected if the host does not turn on the extended coupon reporting mode.

4.7 Calibration
S2K CFSC SC Adv SCR
Calibration is the act of configuring the sensors of the device. Generally there is no need for customers
to perform this operation and is only mentioned for completeness. The process will require a special
MEI approved calibration document be inserted during this mode. This is typically performed by repair
centers after critical parts have been replaced. The omnibus command has support for putting the
device in this mode. Section (Type 4) The Calibrate Command.

4.8 Flash Download

S2K CFSC SC Adv SCR
Some devices support updating the firmware over the EBDS protocol. The device is placed in a special
mode during the process and will not operate normally until the process is complete. This process is
described in detail in the (Type 5) Flash Download section.

If the device powers up into this mode, then that means either:
1. A previous attempt to flash firmware was unsuccessful.
2. A portion of the memory has become corrupt.
The only way to exit this mode is to download correct firmware.

4.8.1 ABDS Flash Download

CFSC SC Adv
Deprecated Although the ABDS protocol is deprecated, Flash download is available under ABDS for
certain code revisions. To see if the device supports flash download over ABDS, please see the (Subtype
0x0D) Query Device Capabilities command (7.4.14).

Revision G5 20105-002850209-PS Page 23

4.9 Inhibiting The Device
This functionality has two purposes. The host can choose to either inhibit specific documents or it can
disable the device temporarily, preventing it from accepting any notes. In the later mode, the device will
continue to actively respond to the host, but does not accept documents from the end user. This is a
scenario that is best described as a ‘session’ that could be used in a kiosk environment. These operations
differ depending on the mode of the device.

Disabling the device is also covered in Appendix A - Disabling the Device (section 8.1). This section shows
the detailed protocol traces for disabling a device.

Warning It is recommended that the host disable a device only if it is in the idle state (not processing
a note). If the host tells the device to disable after the device has started processing a note, the host
shall still be required to handle this document. The device will not automatically return the document.

4.9.1 Non-Extended Mode

When inhibiting in non-extended mode, all the banknotes are represented by a single byte in the
standard poll. Since there is a maximum of seven notes in non-extended mode, each note is represented
by a bit. To disable a note, set the corresponding bit to ‘0’. ‘1’ means the note is enabled and will be
accepted. This byte value is described in section 7.1.1.1 To disable the device, all banknotes must be
inhibited. Products which support barcodes and bookmarks, need to have these features disabled as
well. See the following sections for disabling barcodes (7.1.1.3) and bookmarks (7.1.3). When all of these
conditions are met, the device will no longer draw in any documents. Please refer to section 7.1.1.1 for
details on the associated byte/bit values for the denominations.

4.9.2 Extended Mode

Extended mode requires a different approach to inhibiting notes and disabling the device. In this mode,
there is support for more than 7 notes. Therefore, to inhibit specific notes, a special message must be
sent to the device. The (Subtype 0x03) Set Extended Note Inhibits message is covered in detail in section
7.5.3. By default, all the notes are enabled upon power up so the host will only need to enable notes
using this message if they were previously inhibited.

Disabling the device in extended mode is very similar to disabling in non-extended mode. The host
needs to disable (set to ‘0’) all bits in the first data byte of the standard omnibus command. This is
detailed in section 7.1.1.1. In addition, the features to accept barcodes (7.1.1.3) and bookmarks (7.1.3)
must be disabled as well. When all of these conditions are met, the device will no longer draw in any
documents. To re-enable acceptance to all notes (provided the host did not inhibit specific notes), the
host needs only to enable barcodes, bookmarks or set the first data byte to a non-zero value.

Revision G5 20105-002850209-PS Page 24

4.10 Multi-Note Escrow vs. Single Note Escrow
SCR
Some SCR firmware supports two different software configurations. The configuration must be made
using the STS tool and once configured in a mode, the document handling procedure will differ. When
applicable, a special marker is used in this document to signify that an EBDS feature is only applicable for
the specified mode.

MULTI Note Escrow Only Multi-note escrow allows the device to store several (up to a configured
maximum) documents in a "temporary escrow storage" location. The documents are held on the
recycler until the host confirms that all documents can be "committed" to the final storage location;
which may be the cassette or recycler. The advantage of a multi-note escrow system is that all of the
original documents in a session can be returned to the customer if the session is canceled.

Single Note Escrow Only Single-note escrow is faster than multi-note escrow and has a simplified
document processing flowchart.

Revision G5 20105-002850209-PS Page 25

5 Expected Operations
This section covers the general use of the devices and how the EBDS protocol is best used in certain
situations.

5.1 Start Up Tasks

When the application first begins communicating with the device, it starts off polling the device.
Depending on the response of the device, appropriate action is taken to set up the device. This is
outlined below. Please be advised that once connected, the device may have to process a note at
escrow as part of the power-up procedure (section 4.4).

In the previous image, the host polls the device until it receives a response. Once the devices starts
communicating with the host, the host can determine if it is in a special download mode or if it can be
begin normal operations. (Flash Download section 7.3).
“Set up Device” refers to the necessary steps that may be specific to the application. Some common
examples are to query the device capabilities and set up the note table if using extended note mode.

Revision G5 20105-002850209-PS Page 26

5.1.1 Power up Handling
As part of this routine, the host may be required to handle the exceptional cases that involve the power
up procedures discussed in section 4.4.

Warning S2K CFSC SC Adv

In all normal cases where the device is not in the middle of processing a note when power is applied, the
device will perform a mechanical check of the stacking mechanism. During this process, the device will
issue a “stacked” message with no value for the denominations. This host should be aware of this
situation and not issue credit.

Revision G5 20105-002850209-PS Page 27

5.2 Application Currency Handling
5.2.1 Recommended Document Handling Flowchart
The host should record the value of the note at Escrow. This recorded value is used when the document
is stacked and the host receives a “Stacked” event. It is important for the host to save the value of note
in order to support situations where the device reports “Stacked – no value” on power up situations.
Since the value is retained from escrow, errors in credit and cash box counts are prevented. The
following diagram depicts the recommended method of handling money in a normal situation.

It is required that the host retains the value of the note at escrow (in non-volatile memory) because of
reasons related to the power loss during operations. Please review the Power Up Policies (4.4) section
thoroughly.

The Stacked event is a very important event and requires host acknowledgement from the system (in
the form of another poll afterwards). In the rare situation that power is lost to the device before
acknowledgment of this event, the device will re-issue the stacked event because it is not guaranteed

Revision G5 20105-002850209-PS Page 28

that host received this event. Therefore it is possible for the host to receive two (2) stacked events for
the same document. The host needs to be aware of this situation to prevent possible miscount issues.

SCR The SCR product adds a new event called "Dispensed" that acts in a very similar manner to the
"Stacked" event. This event must be acknowledged by the host and if there is a power loss before this
acknowledgement is received by the device, the device will re-issue the dispensed event.

5.2.2 Requesting the Note Table

CFSC SC Adv SCR
This section applies to devices that support extended note reporting as described in section 4.2.2. The
device contains an internal note set that it uses to identify and report banknotes. Each entry in the note
set represents one specific type of bank note. For example, the $100 USD has multiple entries in the
note set because there have been multiple types of the bank note released over the years. This note set
can be provided to the host machine for informational purposes. This operation isn’t required since the
necessary data will be transmitted with each stacked bank note but it does allow for more control over
the currency accepted. For example, the host could use this note table to know which index values to
inhibit if it did not want to accept a certain series of a bank note.

When the device is in the idle state, the host can request the note table by issuing a series of special
extended messages ((Subtype 0x02) Extended Note Specification Message section 7.5.2). These
messages contain an index value and this value should be incremented (starting at 1) for each
subsequent command until the device replies with a null value. In this context, a null value is a message
that contains no useful note data; all data bytes will be zeroed out. Each of the device’s responses can
be parsed to retrieve the full note table, one index at a time. A detailed example of this logic is provided
in a protocol trace available in Appendix A – Requesting the Note Table.

Recommended It is recommended that the host does not send these commands while the device is
processing a document. This can result in confusion for the host when it comes time to give credit for a
stacked note or document. The recommended practice is to include this operation as part of the host’s
tasks to perform after the device has powered up. The host should also disable the device during this
operation to prevent any customers from inserting documents. The section Inhibiting The Device (4.9)
describes how to disable the device if extended note reporting mode is enabled.

Revision G5 20105-002850209-PS Page 29

5.2.3 Controlling the Orientation of Notes
Although generally not practiced, some applications may wish to control the direction that the user
inserts notes. To accomplish this, the orientation control bits of the omnibus command may be used to
set the orientation (see section 7.1.1.2). This method is of limited control however. The reason is that
the device also has an internal orientation control. This internal orientation setting is configurable via a
support tool such as MEI’s STS program or by filling out and feeding a configuration coupon. Please
contact MEI Sales or Technical support for information on the STS support tool or configuration coupon.
The internal setting cannot be modified by the EBDS host.
Both of these settings determine the actual orientation setting used according to the following table:
EBDS Setting
4 Way 2 Way 1 Way
4 Way 4 Way 4 Way 4 Way
Internal
Setting

2 Way 4 Way 2 Way 2 Way

1 Way 4 Way 2 Way 1 Way

It can be seen that the most liberal setting is used by the acceptor. In this situation, the only way for the
host to have complete control over the orientation of accepted bank notes is to have the devices
internal settings configured for 1-way acceptance. Conversely, if it desired to have control over the
orientation of notes by means of the devices internal settings, the EBDS interface will have to be set to
1-way acceptance.

For those devices that support extended note reporting, it is possible for the host to attain a greater
level of control over the orientation of accepted notes. When the notes arrive at escrow, the host can
examine the orientation field (see (Subtype 0x02) Extended Note Specification Message) in the
extended note data and return any notes that do not correspond to the desired orientation. In this
mode, the host system has the final say as to the suitability of the note.

5.2.4 Issuing Credit

Issuing credit, from the device standpoint, is defined as the point in which the document has been
validated and is physically not able to be returned to the customer. At this point, the device sends a
stacked message that signals to the host that credit for the document can be issued. If the document is a
bank note, the device will reply with the value of the note. If the document does not have a value (No
Value Documents section 4.6) then there will be an assumed value of 0 and it is up to the host to
determine the value if any.

Warning CFSC SC Adv SCR

It is important to note that some newer versions of software will silently disable the device after issuing
a stack message until the host has sent another poll message. This was done to ensure there is no
chance for the host to encounter any miscounts related to a customer inserting another document
before the host has processed the previous note’s value. As long as a reasonable poll rate is maintained,
this will not impact performance.
The device waits for an additional poll to be sure that the host has successfully handled the stacked
document. This is because when dealing with a bank note, the value of the note is cleared as soon as the
next document is inserted. Without this concept, if for some reason the host did not retrieve this value

Revision G5 20105-002850209-PS Page 30

(ex. corrupted message) the host could become confused as to the value of the document if the device
is reporting zero value due to a new document being processed.

SCR Recycling systems that have the ability to pay out banknotes also need the ability to issue credit to
the user. The counterpart to the stacked event is the dispensed event. Once the dispensed event is
issued, the host can safely adjust the customer's credit appropriately.

5.3 Handling ENQs (Special Interrupt Mode)

The ENQ is special byte with value 0x05 that is used in Special interrupt mode (4.1.2) and is a way for the
device to signal to the host that a significant event or change of status has occurred. When received by
the host, the host should immediately send a standard poll command to the device and process the new
state or status.

Every significant event is represented by one ENQ. Therefore it is possible for the device to send an
additional ENQ message right after responding to a host’s poll because it had a second event that it
needs to tell the host about. The following table outlines the significant events that will result in the
device sending an ENQ.

ENQ Sent When Entering ENQ Sent When Exiting

State or Event
State/Event? State/Event?
Escrowed YES
Stacked YES YES * (see note below)
Returned YES
Rejected YES
Jammed YES YES
Cheated YES YES
Cassette Full YES YES
Cassette Inserted YES YES
Failure YES YES
Paused YES YES
No Push YES
Prestack YES
Calibration YES

CFSC SC Adv
* There is an additional ENQ that will be sent after a stacked message is sent. This is required to ensure
the host has properly received the message and issued credit for the document. The reasoning behind
the behavior is detailed in the Issuing Credit section (5.2.4).

Warning
An ENQ will not be sent out if a significant event occurs on the very first poll. This is because the device
is not configured for special interrupt mode until it has received the first message from the host.

Revision G5 20105-002850209-PS Page 31

5.4 Handling Acceptor Exceptions
This section reviews the suggested corrective actions that can be taken when unusual status values are
returned. Many of these statuses are retuned in the standard omnibus reply (section 7.1.2).

5.4.1 Exceptions Related to Polling

This section covers the exceptions related to overall message handling.

5.4.1.1 Device Does Not Respond to a Poll

It is not unusual for the device to be busy and to miss a poll. Under these conditions the host should
retry at the normal poll rate with the same ACK value (see ACK/NAK Processing section 6.3). If after ten
retries there has been no response, the host should toggle the ACK value and attempt ten more polls.

5.4.1.2 Device Does Not Respond for an Extended Period of Time

If a Flash Download has completed (section 4.8), the device may not respond to the host for an
extended period of time. The device should begin communications within 60 seconds of completing a
flash download.

5.4.2 Exceptions Related to Status Bits

This section goes over some all of the exceptional cases that can be reported by the device. The status
bits are broken down into two types: Events which occur for a single poll or Status bits that are
persistent as long as that status is active.

5.4.2.1 Event: Cheated

The device will use the cheated status event to indicate an error while processing a document. The host
must interpret this message as possible fraudulent activity. In this situation, the device cannot
guarantee the exact location of the document. When the cheated bit is set during a transaction, the
stacked bit will not be sent and credit should not be given by the host.

5.4.2.2 Event: Rejected

If the device returns a status of rejected it means that a document was not recognized as a valid
document. This event is also raised if the device is unable to draw in a document completely. The host
should take no action.

5.4.2.3 Status: Jammed

If the device returns a status of jammed it means that a problem has been encountered transporting the
document (either for acceptance or rejection). If the device reports the jammed status, then it has
already attempted to clear the jam on its own and failed. The host should go out of service for the
duration of the jam.

5.4.2.4 Status: Stacker Full

If the device returns a status of stacker full it means that no more documents may be placed into the
cashbox. The host should go out of service until a new cashbox is inserted.

5.4.2.5 Status: Cashbox Removed

If the device returns a status of cashbox removed it means that the cashbox has been removed or is not
detectable and the device will no longer accept documents. In this case the host should go out of service
until a cashbox has been inserted.

Revision G5 20105-002850209-PS Page 32

5.4.2.6 Status: Paused
If the device returns a status of paused, it means that the user is feeding documents too fast and needs
to remove the current document from the mouth of the device so that it can proceed. The host should
signal this to the user.

5.4.2.7 Status: Calibration in Progress

If the device returns a status of calibration in progress then the device is in a special calibration mode
(section 4.7). If a calibration was not requested by the host, it means that there is a problem with the
device and the host should go out of service.

5.4.2.8 Status: Power Up

If the device returns a status of power up it means that something has caused the device to be reset or
that it has lost power and recovered. The host should perform its initialization tasks (see section 4.4)

5.4.2.9 Event: Invalid Command

If the device returns a status of invalid command it means that there is a defect in the host code or the
transmitted message was corrupted. Normally this error should never occur outside of development and
debug phases of the system. In the field, this error should be logged as a problem with the host system
programming.

5.4.2.10 Status: Failure

If the device returns a status of failure it means that there is a serious problem with the device, chassis,
or the cash box. This problem requires attention and the host will stop normal operations and request a
field service call. In general, the only way for the device to recover from a failure is to cycle power on the
device after correcting the failure condition.

5.4.2.11 Status: Stalled

If the device returns a status of stalled it means that the device encountered a problem transporting the
document to the cashbox and that it is now stalled, with the document near or just at the cashbox. An
attendant is required to examine the source of the problem with the document and to reset the device.
This condition only occurs if the host enables No Push mode (section 7.1.1.3).

5.4.2.12 Status: Flash Download

If the device returns a status of flash download and this is not expected, it means that the device is
lacking application code or that a previous download attempt was interrupted or failed. The host may
either attempt to download the correct firmware or it may go out of service and request a field service
call.

5.4.2.13 Event: Pre-Stack

Only applies when using power up policy ‘C’. This status event is meant to signal when the device is
stacking an actual document during power up versus issuing a no value stack due to the mechanical test
that is part of the normal power up procedure. This event will occur during every stacking procedure
regardless of whether or not the device is in power up.

Revision G5 20105-002850209-PS Page 33

5.4.2.14 Status: Transport Open
SCR
The transport open status is meant to inform the host that the bill path is open and the device cannot
perform normal operations until the situation is correct. This bit can also act like an event for the first
poll after power up to signal to the host that the system was opened while powered down.

5.4.2.15 Status: Disabled

SCR
The disabled status is meant to inform the host that the device cannot begin a transaction. This bit will
be set during several types of operations and is meant to be informative only. No specific action is
required based on this bit however, other statuses may signal to the host how to correct the disabled
situation (such as transport open). While not a full list, some examples of disabled situations are:

 Jammed
 Failure condition detected
 Cashbox Removed or Full
 Device is in the middle of dispensing or floating documents

Revision G5 20105-002850209-PS Page 34

6 EBDS General Messaging
This section will cover the general details about how EBDS messages are created and handled.

6.1 Packet Layout

6.1.1 EBDS
In EDBS, data packets from either the host or the device are laid out according to the following
structure:
Byte 0 1 2 3..L-3 L-2 L-1
Name STX Len CTL Data Bytes ETX CHK
Value 0x02 LL nn nn…nn 0x03 zz
Bytes Covered by CHK
Packet Payload

Byte Name Description

STX The ASCII STX character. Hexadecimal value 0x02. The start of a packet.
Len The count of all of the bytes in the packet including STX, ETX & CHK.
CTL Byte A mix of the ACK/NAK field, a device descriptor and a message type identifier.
Data Bytes The data bytes of the packet. This is Len-5 bytes worth.
ETX The ASCII ETX character. Hexadecimal value 0x03. The end of a packet.
Checksum The XOR checksum of bytes 1 through Len-3.

It is very important to realize that the values used for STX and ETX, namely 0x02 and 0x03 are NOT
unique within the packet structure. It is possible for any of the data bytes or the check byte to be one of
these values. Therefore it is recommended that the host should use the Length byte to determine when
the message packet ends and verify with the Checksum.

6.1.2 ABDS
ABDS differs slightly in the packet layout from the standard EBDS message by adding a new byte that is
used for the address.
The format of an ABDS command from the host is:

Byte 0 1 2 3..5 6 7 8
Name STX Len CTL Data Bytes ADR ETX CHK
Value 0x02 0x09 nn nn…nn nn 0x03 zz
Bytes Covered by CHK
Packet Payload

The format of an ABDS response from the device is:

Byte 0 1 2 3..8 9 10 11
Name STX Len CTL Data Bytes ADR ETX CHK
Value 0x02 0x0C nn nn…nn nn 0x03 zz
Bytes Covered by CHK
Packet Payload

Revision G5 20105-002850209-PS Page 35

The field “ADR” represents the address of the device (1..31, 0x01..0x1F).This value corresponds to the
binary address value set in the device’s DIP switches. The other fields have the same meaning as
described in the standard EBDS packet layout.

6.2 Receiving a Reply

The following is a state transition diagram for host code to receive a reply packet. This model represents
the best known practice for this task.

Revision G5 20105-002850209-PS Page 36

6.2.1.1 Loopback Error Handling
Under some conditions, the host may encounter a fault in which data sent to the device is echoed or
looped back to the host. To handle this, the host should ignore any packet that exactly matches the
packet that was sent by the host to the device.

6.3 ACK/NAK Processing

In an EBDS transaction either side may decide to acknowledge the transfer by ACKing the message, or to
deny acknowledgment by sending a NAK. This information is transmitted in the control byte of each
message. Please see section 6.4 for details on the control byte.
The device will ACK a host message by setting the response ACK bit to the same value as the host’s
original message. For instance, the device will send a 0 if the host sent a 0. If the device sends the
opposite value, it should be considered a NAK and could have a different meaning depending on the
message.
Once the host receives an ACK from the device, it should toggle its bit for the next outbound message. If
the host wishes to NAK the devices last message, it should send a message with the same ACK bit value
as the previous message; this informs the device to resend the last message to the host.
These scenarios are illustrated in the next section.

Revision G5 20105-002850209-PS Page 37

6.3.1.1 Normal Communications

Under normal circumstances, the host

alternates the value of the ACK bit in the
control byte sent to the device and the
device returns a matching value in its ACK
bit in the reply. This is illustrated in this
example:

Revision G5 20105-002850209-PS Page 38

6.3.1.2 Device Timeout

Sometimes, the device is unable to

respond to the host command. In these
cases, the host resends the command
with the same ACK value.
These timing requirements are listed in
section 3.3.

Older devices are more prone to this

scenario as they have less processing
“power”, however all devices will from
time to time be unable to respond to a
host packet. The host system should
retry the command.

Note: This case is equivalent to the cases

where either the host command or
device reply is lost in transit.

Revision G5 20105-002850209-PS Page 39

6.3.1.3 Device NAK

In this example, the device is not ready

to process the packet and explicitly
sends a NAK to indicate this to the host.
The host then retries and the command
is accepted.

Note: This case also occurs during flash

download where a simple retry is NOT
sufficient. See the flash download
section for more details (7.3).

Revision G5 20105-002850209-PS Page 40

6.4 Control Byte
Every message contains a control byte. This byte defines the type of message and device type in addition
to controlling the ACK/NAK sequence.

6.4.1 ACK/NAK Processing

The least significant bit represents the ACK state. The control byte is detailed below. The use of this
concept is detailed in section 6.3 and shown here for completeness.

Revision G5 20105-002850209-PS Page 41

6.4.2 Device Type Message Routing
From its inception, EBDS has been a protocol used to control bill acceptors. Over the years, the need has
existed to support different types of transaction hardware (such as coin acceptors, smart card readers,
and bill recyclers) with EBDS. This proposed protocol extension would allow for new device types to be
added without harm to any existing host code.

Device type message routing is a method of sending commands to different sorts of devices in a single
system. Packets sent by the host are sent to specific types of devices. Devices ignore messages not
addressed to them. In reply packets, devices transmit their device type back to the host for
confirmation.

The device routing of EBDS is encoded by the control byte. The device type field in this byte is used to
identify the type of device intended to receive a command and to identify the type of device generating
the reply.

The Device Type field of the control byte is decoded as follows:

Bit 3 Bit 2 Bit 1 Dec Value Description
0 0 0 0 Bill Acceptor with single escrow.
0 0 1 1 Bill Recycler with single escrow.
0 1 0 2 Reserved for Future Use.
0 1 1 3 Reserved for Future Use.
1 0 0 4 Reserved for Future Use.
1 0 1 5 Reserved for Future Use.
1 1 0 6 Reserved for Future Use.
1 1 1 7 Reserved for Future Use.
Device type message routing does not imply that the devices are connected in a multi-drop bus as in
ABDS. In general, the host shall determine the type of device connected to each port. This can be done
by attempting communications with the different device types starting with 0 and proceeding upward
until a device responds. Once a device responds, the host should validate the device type in the
response field to confirm the type of device attached.

Revision G5 20105-002850209-PS Page 42

6.4.3 Message Type
The final section of the control byte describes the message type. Each of the message types are detailed
further in the following sections.

Bit 6 Bit 5 Bit 4 Value When sent by the host When sent by the device
0 0 0 0 Reserved Reserved
0 0 1 1 Standard Omnibus Command Not Used
0 1 0 2 Not Used Omnibus Reply
0 1 1 3 Omnibus w/ Bookmark Mode Not Used
1 0 0 4 Calibrate Request Calibrate Reply
1 0 1 5 Firmware Download Request Firmware Download Reply
1 1 0 6 Auxiliary Command Request Auxiliary Command Reply
1 1 1 7 Extended Commands Extended Command Reply or
Extended Omnibus Reply

Revision G5 20105-002850209-PS Page 43

7 EBDS Message Details
Every EBDS message adheres to the structure described in the Packet Layout section (6.1). The following
sections go over the technical details of each message and provide more information on the actual
values and their meanings. The section will start by describing the general messages first then moving
on to the more advanced messages. For quick reference, each message section’s header is prefixed with
either the message type, or the subtype as applicable (subtypes apply to type 6 and 7 messages).

7.1 General Messages

This section outlines the general host and device messages. These include the standard omnibus
command and the associated reply. It also touches upon the bookmark message. This covers type 1, 2
and 3 message types according to the Message Type field of the Control Byte.

7.1.1 (Type 1) Omnibus Command

S2K CFSC SC Adv SCR
The concept behind the omnibus command is simple. The host sends a packet to the device with
virtually everything needed to control a bill acceptor, and the device responds with a packet with
virtually everything needed by the host. Thus in theory, only one command is needed. In practice, the
sophistication of the command set long ago reached the point where it was not feasible to fit in all the
data all the time. Thus the auxiliary and extended commands were created. Despite this, the omnibus
command remains the very core of EBDS and the most frequently used command.

Host Omnibus Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x08 0x1n nn nn nn 0x03 zz

The following sub sections describe each data byte in detail. The data may vary and is represented by
the ‘nn’. Finally, the checksum is denoted with a ‘zz’. This convention will be used throughout the
document.

Revision G5 20105-002850209-PS Page 44

7.1.1.1 Data Byte 0
Data Byte 0 has two meanings depending on what mode the device is operating in. If the mode is in
Non-extended Mode, the host uses Data Byte 0 to enable or disable specific notes.
If in Extended Note Reporting Mode, the host cannot control the acceptance of specific notes with this
function. If this byte is a non-zero value, then the device will be enabled and will accept any valid note.
Please see the (Subtype 0x03) Set Extended Note Inhibits command for details on inhibiting notes while
in extended note mode.

Note that denominations may also be disabled through the configuration of the device (by either
configuration coupon or on some models, “DIP” switches). In that case, the note will remain disabled,
even if the EBDS command to enable is sent.
Omnibus Command – Data Byte 0 (Non-extended Note Reporting)
Bit # Name Description
Value
0 Denom1
1 Denom2 0 Disable Denomination n
2 Denom3
3 Denom4
4 Denom5
5 Denom6 1 Enable Denomination n
6 Denom7

Revision G5 20105-002850209-PS Page 45

7.1.1.2 Data Byte 1
This data byte controls some more details about the operational mode of the device. It also contains the
very important command bits that control what to do with a note in escrow.
Omnibus Command – Data Byte 1
Bit # Name Value Description
0 Special Sets the device in special interrupt mode. See section 4.1 for details.
Interrupt 0 Normal (Polled) Mode. Recommended.
Mode 1 Special (Interrupt) Mode. Deprecated
1 High This field controls the validation criteria that are applied to bank notes.
Security CFSC SC Adv SCR Deprecated These devices always operate in a high security
and high acceptance mode so this bit is ignored.
0 Accept notes in high acceptance mode. Recommended.
1 Accept notes in high security mode. Acceptance of valid notes may suffer.
2..3 Orientation This field controls the acceptance of bank notes based on the orientation of those
Control notes as they enter the device. Note that note orientations can also be controlled by
a configuration coupon or on some models, “DIP” switches. In all cases, the most
accommodating of the settings is used. See the Controlling the Orientation of Notes
section (5.2.3) for more details on controlling the orientation of note acceptance.
00 1-way: Accept notes fed right edge first, face up only.
01 2-way: Accept notes fed face up only.
1n 4-way: Accept notes fed any way. Recommended.
4 Escrow This mode determines how documents are handled after the documents have been
Mode validated. Note that documents that are unable to be validated are always rejected.
This concept is discussed in detail in section 4.3.
Escrow Mode is disabled. (Non-escrow mode) Deprecated
0 When the device validates a document, it immediately stacks the
document in the cash box. The host only receives notification when the
document is stacked.
Escrow Mode is enabled. Recommended.
1 When the device validates a document, it informs the host of the
document by sending an escrow event. The host then decides if the
document should be stacked or returned to the consumer.
5 Document 0 No operation.
Stack If a document is in escrow, stack it in the cash box. Note that this
Command * command is only valid if Escrow mode is enabled and a document is in
1
escrow. This command and the Document Return command are mutually
exclusive.
6 Document 0 No operation.
Return If a document is in escrow, return it to the consumer. Note that this
Command * command is only valid if Escrow mode is enabled and a document is in
1
escrow. This command and the Document Stack command are mutually
exclusive.
* Please note that the “Document Stack Command” and “Document Return Command” should be
defaulted to ‘0’ and only set to ‘1’ when a note is in the escrow position. And once the device ACKs the

Revision G5 20105-002850209-PS Page 46

command message, this value can be set back to ‘0’. These commands should never be set to ‘1’
simultaneously.

7.1.1.3 Data Byte 2

This data byte also controls some of the configuration settings for the device. The main highlights are
the bits to control the power up policy as well as the barcode acceptance and extended note mode.
Omnibus Command – Data Byte 2
Bit # Name Value Description
S2K : There are times when the device is unable to give credit for a note due to
a problem in transporting the document, and the document cannot be returned
to the customer. In these cases, this bit determines how such documents should
No-Push be handled.
0
Mode Push non-credit notes into the stacker and continue operating.
0
Recommended.
Do not push non-credit notes. Stall the device with the document still
1
in the path. A manager/technician level intervention is required.
CFSC , SC Adv . A barcode voucher is a document with a unique bar-coded
identity number encoded into it. These identity numbers are referenced against
an external database by the host to determine the validity and value of the
voucher.
1 Barcode Notes: Barcode vouchers must be inserted “face up” with CFSC devices.
0 Barcoded vouchers are disabled.
Barcoded vouchers are enabled. Bar coded vouchers are reported to
1 the host via the
(Subtype 0x01) Extended Barcode Reply (7.5.1).
SCR Please see section 4.4 for full details on recycler pup descriptions.
CFSC , SC Adv . These bits are used to control the behavior of the device when
a document is found in the path during power up. See section 4.4 for more
information on the power up policies.
Action Taken with Note at Position…
Value Policy Setting
Pre-Escrow Escrow Post-Escrow
2 Pup B Wait for host
Return Stack with
3 Pup C 00 Power Up Policy – A: with unknown
document unknown value.
value.
Stack with
Return Go out of
01 Power Up Policy – B: note’s actual
document order
value.
Return Go out of Stack with
10 Power Up Policy – C:
document order unknown value.
11 Reserved. - - -

CONTINUES ON NEXT PAGE

Revision G5 20105-002850209-PS Page 47

Omnibus Command – Data Byte 2 (CONTINUED)
Bit # Name Value Description
There are two methods of reporting the value of banknotes validated/stacked
by the device. For more details on handling note values see Extended vs. Non-
Extended Mode (4.2).
Use non-extended note reporting. Notes are reported as the generic
Denom1 though 7.
 Notes are enable/disabled via the Denom1 through Denom7
0
bits in Omnibus Command – Byte 0
 Notes are reported to the host via the three bit Denomination
field in Omnibus Reply – Byte 2.
Extended CFSC , SC Adv , SCR Use extended note reporting.
4 Note  All notes may be disabled via the Notes field in Omnibus
Reporting Command – Byte 0 by setting the byte value to 0x00.
 Notes are enabled/disabled individually via the Set Note
Inhibits command. See (Subtype 0x03) Set Extended Note
Inhibits for details.
1
 Notes are reported to the host via the Extended Omnibus
Note Reply packets. See
 (Subtype 0x02) Extended Note Specification Message for
details.
 SCR (Subtype 0x15) Recycler Omnibus Command/Reply
contains extended note reporting
No special handling of generic coupons. MEI™ Generic Coupons (if
0 supported) are reported the same as a bank note of the same value.
Free vend coupons are not supported. Recommended
Extended
5 Coupon S2K , Enable detailed reporting of MEI™ Generic Coupons. The host
Reporting receives details on the type and identification of generic coupons fed
1 into the device. See the (Subtype 0x04) Set Escrow Timeout /
Extended Coupon response (7.5.4) for more details about the device’s
message when a coupon is detected.
6 - 0 Reserved

Revision G5 20105-002850209-PS Page 48

7.1.2 (Type 2) Omnibus Reply
S2K CFSC SC Adv SCR
The most common reply to an Omnibus Command is the standard reply. However, if barcode vouchers,
extended note or extended coupon reporting is enabled in the standard omnibus command, then other
reply formats are possible. These replies are detailed in sections 7.5.1, 7.5.2 and 7.5.4 respectively.
There are also other circumstances that my result in the device responding back to the host with a
different type of message. These special cases will be described in a future section when the associated
feature is enabled. The standard omnibus reply has the following structure.
Device Omnibus Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X2n nn nn nn nn nn nn 0x03 zz

The control byte is discussed in section 6.4 and omitted from here. The following sub sections will
describe each data byte in detail.

7.1.2.1 Data Byte 0

This data byte describes the current state of the device.
Omnibus Reply – Data Byte 0
Bit # Name Value Description
0 Idling 1 The device is idling. Not processing a document.
1 Accepting 1 The device is drawing in a document.
2 Escrowed State 1 There is a valid document in escrow.
3 Stacking 1 The device is stacking a document.
4 Stacked Event 1 The device has stacked a document.
5 Returning 1 The device is returning a document to the customer.
6 Returned Event 1 The device has returned a document to the customer.
There are a few points that require further explanation.
 If all seven bits are 0, then the device is out of service.
 All of the states ending in “-ing” are transient status conditions. That means that depending on
polling rate or document feed rate, these states may or may not be seen by the host system.
The host should not use these states for any meaningful purpose beyond information only.
 The "Stacked", "Returned", and "Rejected" (in the next section) bits are mutually exclusive and
will never be sent in the same in the same message.

Revision G5 20105-002850209-PS Page 49

7.1.2.2 Data Byte 1
Data byte 1 contains non state related statuses of the device.
Omnibus Reply – Data Byte 1
Bit # Name Value Description
The device has detected conditions consistent with an attempt to
0 Cheated 1
fraud the system.
The document presented to the device could not be validated and was
1 Rejected 1
returned to the customer.
The path is blocked and the device has been unable to resolve the
2 Jammed 1
issue. Intervention is required.
The cash box is full of documents and no more may be accepted. The
3 Stacker Full 1
device will be out of service until the issue is corrected.
The cash box has been removed. No documents may be accepted. The
Cassette 0
4 device is out of service until the issue is corrected.
Attached
1 The cash box is attached to the device.
S2K . The customer is attempting to feed another note while the
5 Paused 1 previous note is still being processed. The customer must remove the
note to permit processing to continue.
It is possible to field calibrate devices. In general, due to advances in processes
used in manufacturing and continuous self-calibration, this is not needed.
Calibrating a device with an incorrect document will greatly reduce
Calibration performance. For more information on field calibration please refer to section
6
in progress 4.7.
0 Normal operation
The device is in calibration mode. Intervention is required to feed a
1
special calibration document into the device.

Revision G5 20105-002850209-PS Page 50

7.1.2.3 Data Byte 2
Data byte 2 contains additional information on exceptional statuses as well as the reporting of the note
value (Non-extended mode only).
Omnibus Reply – Data Byte 2
Bit # Name Value Description
0 The device is operating normally (Power up process is complete)
0 Power Up The device has been powered up. It is performing its initialization
1
routine and not yet ready to accept documents.
Invalid
1 1 The device received an invalid command.
Command
The device has encountered a problem and is out of service.
2 Failure 1
Intervention is required.
The non-extended note value field. This field is valid when the device is in non-
extended mode and either the escrow or stacked bits are set. (See Omnibus
Reply – Data Byte 0 for details of those events)
Unknown/No credit. This condition is returned for a wide variety of
reasons and may differ based on the device type and software. Some
possible examples are:
 When a bookmark is either escrowed or stacked.
 When a bar coded voucher is escrowed or stacked.
000
 When a cheated or jammed document is stacked.
 When a jammed document is returned to the consumer.
3..5 Note Value
 In extended note mode, a note is in escrow or stacked.
 On power up or cash box install when the device performs a
“run & stack” action.
001 Denom1 – (Example $1 for USD applications)
010 Denom2 – (Example $2 for USD applications)
011 Denom3 – (Example $5 for USD applications)
100 Denom4 – (Example $10 for USD applications)
101 Denom5 – (Example $20 for USD applications)
110 Denom6 – (Example $50 for USD applications)
111 Denom7 – (Example $100 for USD applications)
0 Note path access is closed.
Transport
Note path access is opened (vault, door, or both).
6 Open
1 Warning This bit will also be reported one time upon power up if
SCR
the note path was opened while the unit was powered down.

Revision G5 20105-002850209-PS Page 51

7.1.2.4 Data Byte 3
This data byte contains miscellaneous device state fields
Omnibus Reply – Data Byte 3
Bit # Name Value Description
S2K The device is stalled (in No-Push mode), with a document still in
0 Stalled 1
the path.
Flash A flash download is ready to commence. The host may begin send
1 1
Download download records. See section 4.8 for details.
Deprecated . This bit indicates that the document has reached a
2 Pre-stack 1
point in the stacking process where it can no longer be retrieved.
Raw 0 24 character barcodes will be converted to 18 character barcodes.
3
Barcode 1 24 character barcodes will not be converted to 18 character barcodes.
Device 0 The Query Device Capabilities command is not supported.
4
Capabilities 1 The Query Device Capabilities command is supported.
Disabled 0 Device is enabled.
5
SCR 1 Device is disabled and cannot begin a new transaction.
6 - 0 Reserved
Gaming Only The Device Capabilities bit is suppressed (always set to 0) even though the device
capabilities message (section 7.4.14) is supported. This is done to maintain compatibility with non-
compliant host systems. The exception is with SCR as this product does support the device capabilities
in all situations.

Revision G5 20105-002850209-PS Page 52

7.1.2.5 Data Byte 4
Data byte 4 contains the model number identification of the device. The following tables show how the
device model can be obtained depending on the known device types. The follow tables are incomplete
and meant to serve as examples.
Omnibus Reply – Data Byte 4
Bit # Name Value Description
Model A value that represent the model of the device. This is interpreted in
0..6 nn
Number the tables below.

Series 2000 Hex Decimal ASCII Product

0x41 65 A AE2600 Gen2D, Australia
0x42 66 B AE2800 Gen2D, Russia
0x43 67 C AE2600 Gen2D, Canada
0x44 68 D AE2800 Gen2D, Euro
0x45 69 E Reserved (VN2300 US Economy)
0x46 70 F Reserved (VN2600 Gen2B & 2D, China)
0x47 71 G Reserved (AE2800 Gen2D, Argentina)
0x4D 77 M AE2800 Gen2D, Mexico
0x50 80 P AE2600 Gen2B, C and D, US Premium
0x51 81 Q Discontinued, Philippines
0x57 87 W AE2800 Gen2D, Brazil
0x58 88 X AE2800 Gen2D, US Extended

Cashflow SC Hex Decimal ASCII Product

0x54 84 T Cashflow SC 83
0x55 85 U Cashflow SC 66

SC Advance Hex Decimal ASCII Product

0x54 84 T SC Advance 83
0x55 85 U SC Advance 66

7.1.2.6 Data Byte 5

The final data byte contains the code revision identifier. However, the version number of the code is not
sufficient to identify that software. This is because different software parts use independent version
numbers. Version numbers are only useful for comparing firmware from the same software part.
Omnibus Reply – Data Byte 5
Bit # Name Value Description
The version number of the firmware code in the device. This may be
coded as:
 CFSC , SC Adv , SCR : A seven bit binary value with an
implied divide by 10. (versions 0.0 through 12.7). Example
Code
0..6 nn (0x23 = 35 decimal. 35/10 = version 3.50)
Revision
 S2K : A 3 and 4 digit BCD value with an implied divide by 10.
(versions 0.0 through 7.9). Ignoring the most significant bit,
the next 3 bits make up major build (x111 = 7). Last 4 bits
make up the minor revision (1001 = 9)

Revision G5 20105-002850209-PS Page 53

7.1.3 (Type 3) Bookmark Omnibus Command
S2K CFSC SC Adv
The bookmark omnibus command is a variation of the standard omnibus command. The only difference
is that the control byte has a different value to represent that bookmarks are enabled as seen below.
Host Bookmark Omnibus Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x08 0x3n nn nn nn 0x03 zz

The control byte defines the message type 0x3. The rest of the message is processed exactly like the
standard (Type 1) Omnibus Command.

A bookmark is a piece of paper stacked by the acceptor (with zero value) as an event marker in the cash
box. For example, if there was a dispute with a customer, a technician could insert a bookmark and keep
the device in service and revisit the issue at a later time. This is not to be confused with the EBDS
message that supports an advanced bookmark which supports looser restrictions on the bookmark size.
The bookmark size restrictions for this mode are listed in the following table.
Product Bookmark Size
CFSC SC Adv Bookmark dimensions are 2.6” by 4”
S2K Bookmark dimensions are 2.6” by 5”

Warning : Leaving bookmark enabled may cause folded bank notes to be treated as bookmarks
resulting in lost credit to the customer. In addition, some currencies have valid bank notes that are very
close in dimension to a bookmark. This raises the risk of a valid note being “stolen” (not credited to the
customer).

Revision G5 20105-002850209-PS Page 54

7.2 (Type 4) The Calibrate Command
S2K CFSC SC Adv SCR
Deprecated In the calibration procedure the host issues a calibration command and a calibration
document is fed into the device. Calibration documents are specifically designed for this purpose and
must be kept clean and unwrinkled. It is also important to use the calibration paper specifically designed
for the model. (ex. SC83 vs. SC66 for the CFSC line of products)

Modern devices contain self-calibration routines that continually adjust and tune the recognition sub-
system. Thus field calibration is seldom necessary. However, if a calibration document is required, it
should be obtained from an authorized service center.

The layout of a calibrate command from the host is as follows:

Host Calibrate Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x08 0X4n nn nn nn 0x03 zz

The acceptor responds with a standard omnibus reply with a CTL value of 0x4n.
Device Calibrate Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X4n nn nn nn nn nn nn 0x03 zz

When the acceptor is ready to begin the calibration process, it will set the Calibration bit in Data1, Bit 6
(see section 7.1.2.2 Omnibus Reply – Data Byte 1). After this bit is set the host should return to polling
via the standard omnibus command.

At this point the calibration document can be inserted into the device. The document will be drawn in
and returned. When removed from the device, the calibration procedure is complete. The acceptor will
indicate that the calibration was successful by resetting itself. If the calibration fails, the device remains
in calibration mode until manually reset.

Warning A calibrate command should not be attempted if the device indicates that its status is
anything other than “Idling” (see section 7.1.2.1 Omnibus Reply – Data Byte 0).

Warning SCR The SCR device will only support this mode if there are no notes in the system
(recyclers must be empty).

Revision G5 20105-002850209-PS Page 55

7.3 (Type 5) Flash Download
S2K CFSC SC Adv SCR
MEI Bill Acceptors can be upgraded with new software via the EBDS interface. Host support of the
download process allows the device to be updated to the current code level, without the necessity of
manual intervention.

Download mode is somewhat different in approach than other modes. Normally, transactions are sent
at a rate that allows events from the device to be processed without using up a lot of bandwidth. This is
not the case in download mode. In download mode, a great deal of data needs to be sent to the device.
Thus it is expected that the host shall send data as rapidly as the protocol allows. Once in download
mode, the host has the option to switch to a faster baud rate to transmit packets at a faster rate.

Another consideration is the fact that many devices are unable to process communications traffic while
they are in the midst of programming their flash memory. To allow for this, the response timeout for
device replies should be increased from 50ms to 200ms.

The download process has three distinct phases: Starting, Downloading and Finishing.

Recommended
For automated download procedures that are based on a specific device properties (ex. firmware
download is model number specific), it is recommended that the host query and store these specific
device properties in non-volatile memory before beginning the download process. This guards against
the inability of the host to query specific device properties in the event that a download is interrupted.

Deprecated
The ABDS protocol, while deprecated, does support the new fast download algorithm.

Revision G5 20105-002850209-PS Page 56

7.3.1 Phase 1: Starting Download
The purpose of the starting phase is to get the device out of normal operation mode and into
downloading mode. This is done by first polling the device, with a command as shown below:
Host Initial Poll For Download Process

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x08 0X1n 0x00 0x00 0x00 0x03 zz

This is a standard omnibus command with all acceptance and options off. The ‘n’ in the CTRL byte
represents the correct ACK/NAK toggle. There are two possible responses that may occur. If the device is
not currently in download mode, a standard omnibus reply will be sent. If the device is already in
download mode, the following response will be sent:
Device Initial Poll Reply – Already in Flash Download Mode

Byte 0 1 2 3 4 5 6 7 8
Name STX LEN CTRL Pkt # Pkt # Pkt # Pkt # ETX CHK
Value 0x02 0x09 0X5n 0x0n 0x0n 0x0n 0x0n 0x03 zz

A 16 bit packet number is encoded, four bits at a time, in bytes 3 through 6 (high nibble first). If the
device is already in downloading mode then the starting phase is completed. Otherwise it shall be
necessary to place the device into downloading mode. This is accomplished with the Start Download
command. This command is shown below:
Host Start Download Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x08 0X5n 0x00 0x00 0x00/10 0x03 zz

The host command shall start the device in Download mode and data 2 contains the option of either
being all zeros or having the value 0x10 depending on whether or not extended note mode is supported
with the device configuration. (See 4.2.2 for more details on extended note mode option).
Device Start Download Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X5n nn nn nn 0x00/02 nn nn 0x03 zz

Data 3 contains the status of the device. If the Flash Download bit (denoted by 0x02) is not set, the
device is not yet in download mode and the Start Download command must be resent. When that bit is
set, the device is expecting the host to enter the downloading phase of the download process.

Revision G5 20105-002850209-PS Page 57

7.3.2 Phase 1-B: Setting Baud Rate (Optional)
SC Adv SCR
An optional feature available on selected versions of firmware is the ability to perform a "Fast Serial
Download". To support this feature, the serial port settings need to be adjusted prior to downloading
packets. The serial port settings shall be reverted back to the original values after the last packet has
been acknowledged by the device.

The host will establish the session by requesting a baud rate change using the following command:
Host Request Baud Rate Change

Byte 0 1 2 3 4 5
Name STX LEN CTRL Data 0 ETX CHK
Value 0x02 0x08 0X5n baud 0x03 zz

Data 0 contains the requested Baud rate based on the following enumeration
Data 0 Description
0x01 Baud Rate 9600; Data Bits 8, Parity None; Stop Bit 0ne
0x02 Baud Rate 19,200; Data Bits 8, Parity None; Stop Bit 0ne
0x03 Baud Rate 38,400; Data Bits 8, Parity None; Stop Bit 0ne
0x04 Baud Rate 115,200; Data Bits 8, Parity None; Stop Bit 0ne
Other Reserved for Future Use.

If supported, the device will respond back to the command with an ACK (toggle bits will be the same)
and the Data 0 response will equal the requested value. (ex. if the host requests 19,200, the device will
respond with 19,200). If the device supports fast download but cannot support the requested baud rate,
the device will NAK the request but transmit the maximum supported value (ex. Host requests 115,200
on SC Advance unit, device will NAK and return 38,400).
Device Reply - Baud Rate Change

Byte 0 1 2 3 4 5
Name STX LEN CTRL Data 0 ETX CHK
Value 0x02 0x06 0X5n baud 0x03 zz

Warning If the device firmware does not support the fast serial download feature, the device will not
respond to the baud rate change request. This means the host will be required to perform the download
using the original algorithm.

Revision G5 20105-002850209-PS Page 58

7.3.2.1 Serial Port Settings
A quick reference table to the default and max supported settings for the serial port.

Setting Original ('7 Bit Protocol') Fast ('8 Bit Protocol')

SC Adv 38400
Baud Rate 9600 Max
SCR 115200
Data Bits 7 8
Parity Even None
Stop Bits 1 1

Warning The host should NOT switch the serial port settings until the device has acknowledged the
request to the change baud rate command.

Warning The device will automatically revert back to the original serial port settings if no command is
received within 1 second. This applies to any point during the download process. If this occurs, the
device will remain in flash download mode.

Revision G5 20105-002850209-PS Page 59

7.3.3 Phase 2: Downloading
In this phase, the new code is sent to the device and programmed into flash memory. Depending on
whether the 7 or 8 bit protocol is selected determines the composition of the download message.
If the device sends more than 10 consecutive NAKs, unexpected packets, checksum or other errors, the
host should abort the download process. At this point, the device is out of service and intervention is
required to restore normal operation.

7.3.3.1 7-Bit protocol (Original Algorithm)

Starting at the beginning of the file, the host sends 32 byte blocks of data to the device (Note: the file is
required to be a multiple of 32 bytes long and the MEI firmware files are configured as such).
Downloading is completed through the Download Data command shown below. Each data byte contains
only 4 bits of data located in the least significant nibble.
Host Flash Download Message - 7 Bit Protocol

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Pkt # Pkt # Pkt # Pkt #
Value 0x02 0x49 0X5n 0x0n 0x0n 0x0n 0x0n

7 8 69 70 71 72
Data 1 Data 1 Data 32 Data 32
ooo ETX CHK
Hi Lo Hi Lo
0x0n 0x0n 0x0n 0x0n 0x03 zz

Device Flash Download Reply - 7 Bit Protocol

Byte 0 1 2 3 4 5 6 7 8
Name STX LEN CTRL Pkt # Pkt # Pkt # Pkt # ETX CHK
Value 0x02 0x09 0X5n 0x0n 0x0n 0x0n 0x0n 0x03 zz

The Packet Number reported by the device is the last successfully received packet number.
The ACK/NAK of the reply is important.

 If the device ACKs the packet, the host should step to the next packet.
 If the device NAKs the packet, then the host needs to resynchronize with the device. This is
accomplished by changing the block number to the value contained in the reply plus one. An
example is shown below.

ReplyBlockNum = (((Reply[3] & 0x0F) << 12) +

((Reply[4] & 0x0F) << 8) +
((Reply[5] & 0x0F) << 4) +
((Reply[6] & 0x0F) + 1)) & 0xFFFF;

Revision G5 20105-002850209-PS Page 60

7.3.3.2 8-Bit protocol (Fast Serial Algorithm)
Starting at the beginning of the file, the host sends 64 byte blocks of data to the device. Downloading is
completed through the Download Data command shown below. The full 8-bits can be used for packet
numbers and data packets.

Warning The file is only required to be a multiple of 32 bytes long therefore it is possible for the final
packet to only contain the remaining 32 data bytes. Do not pad the message with empty values.

Host Flash Download Message - 8 Bit Protocol

Byte 0 1 2 3 4
Name STX LEN CTRL Pkt # Pkt #
Value 0x02 0x47/0x27 0X5n 0xnn 0xnn

5 6 67 68 69 70
Data 0 Data 1 ooo Data 63 Data 64 ETX CHK
0xnn 0xnn 0xnn 0xnn 0x03 zz

A 16-bit packet number is stored in little endian format.

Device Flash Download Reply - 8 Bit Protocol

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Pkt # Pkt # ETX CHK
Value 0x02 0x07 0X5n 0xnn 0xnn 0x03 zz

The Packet Number reported by the device is the last successfully received packet number in little
endian format.
The ACK/NAK of the reply is important.

 If the device ACKs the packet, the host should step to the next packet.
 If the device NAKs the packet, then the host needs to resynchronize with the device. This is
accomplished by changing the block number to the value contained in the reply plus one.

Revision G5 20105-002850209-PS Page 61

7.3.4 Phase 3: Finishing the Download
Once the last block of data has been sent to the device, the host must wait. There are two phases to this
wait.
In the first part of this phase, if the host used the 'Fast Serial Download' algorithm to flash the firmware
to the device, the host should now revert the serial port settings back to the original 7-bit protocol.
Otherwise, the host should do nothing. The host should not poll the device and give it time to complete
the flash download and reboot. Usually this lasts for about 15 seconds. After this time, the host can
begin communications; part two of the phase.
Part two consists of the host slowly polling the device (recommended poll rate of 1 second) as the
device reboots. When the device responds, the download process is complete. If a normal response was
given by the device, then programming is complete and the device is ready to go back into service with
the original poll rate. If the device is still in download mode at this point, it means that one of two
scenarios exists:
 The download failed for some reason. (Invalid file, Wrong kind of file, File/Device are
incompatible, Errors in communication etc)
 CFSC SC Adv SCR In devices with multi-part flash programs (Application and Variant), the
host needs to download the next file component of the device application.

Revision G5 20105-002850209-PS Page 62

7.3.5 Flash Download Flow Diagram

Revision G5 20105-002850209-PS Page 63

7.3.6 Troubleshooting Flash Download Problems
On occasion, the flash download may fail for a variety of reasons.

7.3.6.1 Communications Lost

The most common failures in the download process are an interruption due to a loss in communications,
a power loss to the host, or a power loss to the device. In all cases, once communications are re-
established, the device will start in flash download mode and begin requesting the download as
described in one of the following two cases:
 Device did not lose power – The device will report the last successfully downloaded packet. In
this case the host shall begin by downloading the requested packet.
 Device lost power - Device will report “-1” (0x0F for all packet bytes). In this case the host should
begin by downloading the entire firmware from the first packet.

7.3.6.2 Incompatible Firmware

In the event that an attempt is made to download firmware that is incompatible with the intended
device, the download will fail and the firmware will not be loaded into the device. Depending on the
device, one of the following scenarios will occur:
 S2K Device will allow the download to complete and report Failure at the end of the download.
Power must be manually cycled on the device. Once power is cycled, the device will return to
normal operations with the original firmware intact.
 CFSC Device will constantly NAK the host after a period of time. This is because the device
detected that this software is not compatible. Power must be manually cycled on the device.
Once power is cycled, the device will return to normal operations with the original firmware
intact.
 SC Adv SCR Device will detect that the firmware is not compatible and abort the download. If
configured to, the device will automatically perform a power cycle and return to normal
operations with the original firmware intact without the need for manual interaction.
Otherwise, the device will remain in download mode until a manual power cycle is performed or
a valid download is successfully completed.

Revision G5 20105-002850209-PS Page 64

7.4 (Type 6) Auxiliary Commands
The Auxiliary Commands are used to provide functionality outside the scope of the Omnibus command
in the previous sections. These commands can be specific to a certain code base, so be sure to check the
compatibility icons before each section.

All auxiliary commands take the form:

Host Auxiliary Command Layout

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n nn nn nn 0x03 zz

The Command field is the command value for the operation and Data A and Data B are arguments to
that command and are not used by every command. There is no configuration data transmitted in the
command and likewise, no status data supplied by the device as seen below.
Device Auxiliary Message Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name Aux Aux Aux Aux Aux Aux
STX LEN CTRL ETX CHK
Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0B 0X6n nn nn nn nn nn nn 0x03 zz

Since status information is never contained in these messages, it is recommended that the host never
overload the device with many consecutive Auxiliary commands. This is especially important when
processing documents.
Please note that if the command is not supported by the device, it is possible that the device will
respond back with a response for the (Subtype 0x00) Query Software CRC command.

Revision G5 20105-002850209-PS Page 65

The supported commands are listed below:
Data A Data B Cmd Description
0 0 0x00 (Subtype 0x00) Query Software CRC
0 0 0x01 (Subtype 0x01) Query Cashbox Total
0 0 0x02 (Subtype 0x02) Query Device Resets
0 0 0x03 (Subtype 0x03) Clear Cashbox Total
0 0 0x04 (Subtype 0x04) Query Acceptor Type
0 0 0x05 (Subtype 0x05) Query Acceptor Serial Number
0 0 0x06 (Subtype 0x06) Query Acceptor Boot Part Number
0 0 0x07 (Subtype 0x07) Query Acceptor Application Part Number
0 0 0x08 (Subtype 0x08) Query Acceptor Variant Name
0 0 0x09 (Subtype 0x09) Query Acceptor Variant Part Number
0 0 0x0A (Subtype 0x0A) Query Acceptor Audit Life Time Totals
0 0 0x0B (Subtype 0x0B) Query Acceptor Audit QP Measures
0 0 0x0C (Subtype 0x0C) Query Acceptor Audit Performance Measures
0 0 0x0D (Subtype 0x0D) Query Device Capabilities
0 0 0x0E (Subtype 0x0E) Query Acceptor Application ID
0 0 0x0F (Subtype 0x0F) Query Acceptor Variant ID
0 0 0x10 (Subtype 0x10) Query BNF Status
nn 0 0x11 (Subtype 0x11) Set Bezel
0 0 0x12 (Subtype 0x12) Query Acceptor Audit Life Time Totals Extended
0 0 0x13 (Subtype 0x13) Query Acceptor Audit QP Measures Extended
0 0 0x14 (Subtype 0x14) Query Acceptor Audit Performance Measures Extended
0 0 0x15 (Subtype 0x15) Query Asset Number
0 0 0x16
(Subtype 0x16) Query Acceptor Audit Total Documents Reporting
Structure(Subtype 0x16) Query Acceptor Audit Total Documents
Reporting Structure
nn nn 0x17 (Subtype 0x17) Query Acceptor Audit Total Documents Recognized
nn nn 0x18 (Subtype 0x18) Query Acceptor Audit Total Documents Validated
nn nn 0x19 (Subtype 0x19) Query Acceptor Audit Total Documents Stacked
nn nn 0x1A (Subtype 0x1A) Acceptor Diagnostics Self Test
- - 0x1B Reserved (Do Not Use)
- - 0x1C Reserved (Do Not Use)
nn nn 0x1D (Subtype 0x1D) Query Acceptor Diagnostics Sensor Data
0 0 0x23 (Subtype 0x23) Query Hardware Status
0x7F 0x7F 0x7F (Subtype 0x7F) Acceptor Soft Reset
All other values are reserved for future use.

Revision G5 20105-002850209-PS Page 66

7.4.1 (Subtype 0x00) Query Software CRC
S2K CFSC SC Adv SCR
This command is used to query the device for the 16 bit CRC of the flash contents. The query CRC
command takes the form:
Host Query Software CRC Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x00 0x03 zz

Device Query Software CRC Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL CRC 1 CRC 2 CRC 3 CRC 4 N/A N/A ETX CHK
Value 0x02 0x0B 0X6n 0x0n 0x0n 0x0n 0x0n 0x00 0x00 0x03 zz

The 16 bit CRC data is sent in bytes 3 through 6, four bits at a time. This may be extracted as shown
below.

CRC_Value = ((Reply[3] & 0x0F) << 12) +

((Reply[4] & 0x0F) << 8) +
((Reply[5] & 0x0F) << 4) +
((Reply[6] & 0x0F) );

7.4.2 (Subtype 0x01) Query Cashbox Total

S2K
This command is used to query the amount of currency that has been counted going into the cash box.
This count, stored in non-volatile storage, is represented as a 24 bit integer, though most hosts may
choose to store it as a 32 value. The query cash box total command takes the form:
Host Query Cashbox Total Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x01 0x03 cc

Device Query Cashbox Total Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Total 1 Total 2 Total 3 Total 4 Total 5 Total 6 ETX CHK
Value 0x02 0x0B 0X6n 0x0n 0x0n 0x0n 0x0n 0x0n 0x0n 0x03 zz

The Total Value is sent in bytes 3 through 8. This may be extracted as shown below.

Revision G5 20105-002850209-PS Page 67

Total_Value = ((Reply[3] & 0x0F) << 20) +
((Reply[4] & 0x0F) << 16) +
((Reply[5] & 0x0F) << 12) +
((Reply[6] & 0x0F) << 8) +
((Reply[7] & 0x0F) << 4) +
((Reply[8] & 0x0F) );

If the host knows that the cash box was removed while the system was off, it can use the (Subtype 0x03)
Clear Cashbox Total command to clear the current stored total.

7.4.3 (Subtype 0x02) Query Device Resets

S2K CFSC SC Adv SCR
This command is used to query the number of times the device has been reset. This is represented as a
24 bit integer, though most hosts may choose to store it as a 32 bit value. The query device resets
command takes the form:
Host Query Device Resets Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x02 0x03 zz

Device Query Device Resets Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Reset 1 Reset 2 Reset 3 Reset 4 Reset 5 Reset 6 ETX CHK
Value 0x02 0x0B 0X6n 0x0n 0x0n 0x0n 0x0n 0x0n 0x0n 0x03 zz

The Reset Count is sent in bytes 3 through 8. This may be extracted as shown below.

Reset_Count = ((Reply[3] & 0x0F) << 20) +

((Reply[4] & 0x0F) << 16) +
((Reply[5] & 0x0F) << 12) +
((Reply[6] & 0x0F) << 8) +
((Reply[7] & 0x0F) << 4) +
((Reply[8] & 0x0F) );

7.4.4 (Subtype 0x03) Clear Cashbox Total

S2K
This command is used to reset the count of notes entering the cash box. The device will not return any
data. The clear cash box total commands take the form:
Host Clear Cashbox Total Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x03 0x03 zz

Revision G5 20105-002850209-PS Page 68

Device Clear Cashbox Total Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data Data Data Data Data Data ETX CHK
Value 0x02 0x0B 0X6n 0x00 0x00 0x00 0x00 0x00 0x00 0x03 zz

7.4.5 (Subtype 0x04) Query Acceptor Type

CFSC SC Adv SCR
This command is used to determine the type of device installed. The query acceptor type command
takes the form:
Host Query Acceptor Type Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x04 0x03 zz

The data returned by the device takes the form of an ASCII string that is either 20 bytes long or is
terminated by the null character (0x00). The characters after the first null (0x00) are not guaranteed to
be null (0x00). The reply packet is shown below:
Device Query Acceptor Type Reply

Byte 0 1 2 3 4 22 23 24
Name STX LEN CTRL Data 0 Data 1 ooo Data 19 ETX CHK
Value 0x02 0x19 0X6n nn nn nn 0x03 zz

7.4.6 (Subtype 0x05) Query Acceptor Serial Number

S2K CFSC SC Adv SCR
This command is used to return the serial number of the Recognition Unit (Head). The query acceptor
serial number command takes the form:
Host Query Acceptor Serial Number Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x05 0x03 zz

The data returned by the device takes the form of an ASCII string that is either 20 bytes long or is
terminated by the null character (0x00). The characters after the first null (0x00) are not guaranteed to
be null (0x00). The reply packet is shown below:
Device Query Acceptor Serial Number Reply

Byte 0 1 2 3 4 22 23 24
Name STX LEN CTRL Data 0 Data 1 ooo Data 19 ETX CHK
Value 0x02 0x19 0X6n nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 69

The following table shows how this string is encoded for the Cashflow-SC products.
Week Last Location Configuration Sequential Description
of Digit of Code Count
Year Year
The number of the week
00..51 when the device was
manufactured.
The number of the year
0..9 when the device was
manufactured.
The site where the device
0..9
was manufactured.
The configuration code
00..99
(build standard)
00000 A sequential number for
through devices made that week.
99999
Note that on Series 2000 devices this function is not implemented in all models. If the device responds
with a reply that does not have a length of 25 (0x19) then it can be assumed that the device does not
support this command.

7.4.7 (Subtype 0x06) Query Acceptor Boot Part Number

CFSC SC Adv SCR
This command is used to return the software part number of the boot component of the device
firmware. The query acceptor boot part number command takes the form:
Host Query Acceptor Boot Part Number Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x06 0x03 zz

The data returned by the device takes the form of an ASCII string that is 9 bytes long. The reply packet is
shown below:
Device Query Acceptor Boot Part Number Reply

Byte 0 1 2 3 4 11 12 13
Name STX LEN CTRL Data 0 Data 1 ooo Data 8 ETX CHK
Value 0x02 0x0E 0X6n nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 70

The part number is composed of a project number (5-6 digits) and version number (3 digits) with an
optional Check sum digit in the middle. Please see the following table for expected values.
Project Check Version Description
Number Digit (3 Bytes)
(5-6 Bytes) (0-1 Bytes)
Type 1 Application Part Number (Requires Check
28000…28599
Digit)
286000…289999 Type 2 Application Part Number (No Check digit)
Check digit (Not applicable for Type 2 Application
0..9
Part Numbers)
000..999 Formatted as V1.23

7.4.8 (Subtype 0x07) Query Acceptor Application Part Number

CFSC SC Adv SCR
This command is used to return the software part number of the file containing the application
component of the device firmware. The query acceptor application part number command takes the
form:
Host Query Acceptor Application Part Number Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x07 0x03 zz

The data returned by the device takes the form of an ASCII string that is 9 bytes long. The reply packet is
shown below:

Device Query Acceptor Application Part Number Reply

Byte 0 1 2 3 4 11 12 13
Name STX LEN CTRL Data 0 Data 1 ooo Data 8 ETX CHK
Value 0x02 0x0E 0X6n nn nn nn 0x03 zz

The part number is composed of a project number (5-6 digits) and version number (3 digits) with an
optional Check sum digit in the middle. Please see the following table for expected values.
Project Check Version Description
Number Digit (3 Bytes)
(5-6 Bytes) (0-1 Bytes)
Type 1 Application Part Number (Requires Check
28000…28599
Digit) (CFSC Only)
286000…289999 Type 2 Application Part Number (No Check digit)
Check digit (Not applicable for Type 2 Application
0..9
Part Numbers) (CFSC Only)
000..999 Formatted as V1.23

Revision G5 20105-002850209-PS Page 71

Warning Retail Only If the device was loaded with a combined file (a file that contains both the
application and the variant) this command will return the part number for the combined file, not the
actual part number of the underlying application component. In this case, (Subtype 0x0E) Query
Acceptor Application ID can be used to retrieve the part number of the application component.

7.4.9 (Subtype 0x08) Query Acceptor Variant Name

CFSC SC Adv SCR
This command is used to return the name of the variant component of the firmware. The variant
software determines which bank notes are accepted by the device and the name of the variant,
identifies the country of origin of those bank notes. The query acceptor variant name command takes
the form:
Host Query Acceptor Variant Name Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x08 0x03 zz

The data returned by the device takes the form of an ASCII string that is either 32 bytes long or is
terminated by a non-printable character (0x00). The reply packet is shown below.
Device Query Variant Name Reply

Byte 0 1 2 3 4 34 35 36
Name STX LEN CTRL Data 0 Data 1 ooo Data 31 ETX CHK
Value 0x02 0x25 0X6n nn nn nn 0x03 zz

The names of the currencies supported are represented as three character ISO codes. If more than one
currency is supported, they are separated by underscore “_” characters. For example “USD_CAD” would
signify a mixed U.S.A./Canadian bill set. For further information on currency descriptors, please see
http://en.wikipedia.org/wiki/ISO_4217.

7.4.10 (Subtype 0x09) Query Acceptor Variant Part Number

CFSC SC Adv SCR
This command is used to return the software part number of the file containing the variant component
of the device firmware. The query acceptor variant part number command takes the form:
Host Query Acceptor Variant Part Number Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x09 0x03 zz

Revision G5 20105-002850209-PS Page 72

The data returned by the device takes the form of an ASCII string that is 9 bytes long. The reply packet is
shown below.
Device Query Acceptor Variant Part Number Reply

Byte 0 1 2 3 4 11 12 13
Name STX LEN CTRL Data 0 Data 1 ooo Data 8 ETX CHK
Value 0x02 0x0E 0X6n nn nn nn 0x03 zz

The part number is composed of a project number (5-6 digits) and version number (3 digits) with an
optional Check sum digit in the middle. Please see the following table for expected values.
Project Check Version Description
Number Digit (3 Bytes)
(5 Bytes) (1 Byte)
49000…49999 (CFSC)Variant part number
51000…51999 (SC Adv)Variant part number
0..9 Check digit
000..999 Formatted as V1.23

Warning Retail Only If the device was loaded with a combined file (a file that contains both the
application and the variant) this command will return the part number for the combined file, not the
actual part number of the underlying variant component. In this case, (Subtype 0x0F) Query Acceptor
Variant ID can be used to retrieve the part number of the variant component.

7.4.11 (Subtype 0x0A) Query Acceptor Audit Life Time Totals

CFSC SC Adv SCR
This command is used to return life time audit data kept on certain key operating data. The query
acceptor audit life time totals command takes the form:
Host Query Acceptor Audit Life Time Totals Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x0A 0x03 zz

Revision G5 20105-002850209-PS Page 73

This data is formatted as an array of 32-bit integers where each integer is nibble encoded as eight
extended data bytes. The length of this message can be variable depending on the device. The data
takes the following form:
Device Query Acceptor Audit Life Time Totals Reply

Byte 0 1 2 3 10
Name STX LEN CTRL Field 1.0 ooo Field 1.7
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
x-1 x
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

The field data is laid out according to the following rules for the three products:
CFSC SC Adv
Field Size in Data Description
Number Bytes Width
1 8 32 Data Map ID. The revision of data reporting in this command,
Query Acceptor Audit QP Measures and Query Acceptor Audit
Performance Measures.
0 – The initial revision.
2 8 32 Total Operating Hours
3 8 32 Total Motor Starts
4 8 32 Total Documents Reached Escrow Position
5 8 32 Total Notes Recognized
6 8 32 Total Notes Validated

SCR
Field Size in Data Description
Number Bytes Width
1 8 32 Data Map ID. The revision of data reporting in this command,
Query Acceptor Audit QP Measures and Query Acceptor Audit
Performance Measures.
0 – The initial revision.
2 8 32 Total Operating Hours
3 8 32 Total Motor Starts
4 8 32 Total Documents Reached Escrow Position
5 8 32 Total Notes Recognized
6 8 32 Total Notes Validated
7 8 32 Total Notes Stacked to Recycler
8 8 32 Total Notes Stacked to Cashbox
9 8 32 Total Notes Floated Down
10 8 32 Total Notes Dispensed

Revision G5 20105-002850209-PS Page 74

7.4.12 (Subtype 0x0B) Query Acceptor Audit QP Measures
CFSC SC Adv SCR
This command is used to return “QP” audit data kept on the general rate of note acceptance. The query
acceptor audit QP measures command takes the form:
Host Query Acceptor Audit QP Measures Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x0B 0x03 zz

This data is formatted as an array of 16-bit integers where each integer is nibble encoded as four
extended data bytes. The length of this message can be variable depending on the device. The returned
data takes the following form:
Device Query Acceptor Audit QP Measures Reply

Byte 0 1 2 3 10
Name STX LEN CTRL Field 1.0 ooo Field 1.3
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
x-1 x
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

The field data is laid out according to the following rules for the three products:
CFSC SC Adv
Field Size in Data Description
Number Bytes Width
1 4 16 Last 100 notes acceptance rate.
2 4 16 Total Motor Starts.
3 4 16 Total Banknotes Stacked.
4 4 16 Total Documents Reached Escrow Position
5 4 16 Total Banknotes Passed Recognition
6 4 16 Total Banknotes Passed Validation
7 4 16 Total Recognition Rejections.
8 4 16 Total Security Rejections.
9 4 16 Total Orientation Disabled Rejections.
10 4 16 Total Document Disabled Rejections.
11 4 16 Total Fast Feed Error Rejections.
12 4 16 Total Documents Inserted While Disabled.
13 4 16 Total Host Return Document Rejections.
14 4 16 Total Barcodes Decoded.

Revision G5 20105-002850209-PS Page 75

SCR
Field Size in Data Description
Number Bytes Width
1 4 16 Last 100 notes acceptance rate.
2 4 16 Total Motor Starts.
3 4 16 Total Banknotes Stacked.
4 4 16 Total Documents Reached Escrow Position
5 4 16 Total Banknotes Passed Recognition
6 4 16 Total Banknotes Passed Validation
7 4 16 Total Recognition Rejections.
8 4 16 Total Security Rejections.
9 4 16 Total Orientation Disabled Rejections.
10 4 16 Total Document Disabled Rejections.
11 4 16 Total Fast Feed Error Rejections.
12 4 16 Total Documents Inserted While Disabled.
13 4 16 Total Documents Inserted While Recycler Busy.
14 4 16 Total Host Return Document Rejections.
15 4 16 Total Barcodes Decoded.
16 4 16 Total Escrow Timeout Rejections

7.4.13 (Subtype 0x0C) Query Acceptor Audit Performance Measures

CFSC SC Adv SCR
This command is used to return audit data kept on the basic performance of the device. The query
acceptor audit performance measures command takes the form:
Host Query Acceptor Audit Performance Measures Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x0C 0x03 zz

This data is formatted as an array of 16-bit integers where each integer is nibble encoded as four
extended data bytes. The length of this message can be variable depending on the device. The returned
data takes the following form:
Device Query Acceptor Audit Performance Measures Reply

Byte 0 1 2 3 10
Name STX LEN CTRL Field 1.0 ooo Field 1.3
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
x-1 x
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

The field data is laid out according to the following rules for the three products:

Revision G5 20105-002850209-PS Page 76

CFSC SC Adv
Field Size in Data Description
Number Bytes Width
1 4 16 Total Cross Channel 0 Rejects
2 4 16 Total Cross Channel 1 Rejects
3 4 16 Total of All Types of Jams
4 4 16 Total Jam Recovery Efforts
5 4 16 Total Reject Attempts with Jam
6 4 16 Total Stacker Jams
7 4 16 Total number of Jams without Recovery Enabled
8 4 16 Total number of Out of Service conditions
9 4 16 Total number of Out of Order conditions
10 4 16 Total number of Operating Hours
Total number of documents greater than maximum allowable
11 4 16
length
12 4 16 Total number of documents less than minimum allowable length
13 4 16 Total number of documents that failed to reach escrow position
14 4 16 Total number of Calibrations
15 4 16 Total number of Power Resets
16 4 16 Total number of Flash Download attempts
17 4 16 Total number of Cassette Full conditions
18 4 16 Total number of Cassette Removed conditions

SCR
Field Size in Data Description
Number Bytes Width
1 4 16 Total Security Events
2 4 16 Total Security Rejections
3 4 16 Total of All Types of Jams
4 4 16 Total Jam Recovery Efforts
5 4 16 Total number of Out of Service conditions
6 4 16 Total number of Out of Order conditions
7 4 16 Total number of Operating Hours
8 4 16 Total number of docs greater than maximum allowable length
9 4 16 Total number of documents less than minimum allowable length
10 4 16 Total number of documents that failed to reach escrow position
11 4 16 Total number of Calibrations
12 4 16 Total number of Resets
13 4 16 Total number Host Resets
14 4 16 Total number of Flash Download attempts
15 4 16 Total number of Cassette Full conditions
16 4 16 Total number of Cassette Removed conditions
17 4 16 Total number Out of Service for Jammed
18 4 16 Total number Out of Service for Jammed on Reset
19 4 16 Total number Out of Service for Recycler Opened

Revision G5 20105-002850209-PS Page 77

7.4.14 (Subtype 0x0D) Query Device Capabilities
CFSC SC Adv SCR
This command is used to query the device capabilities. In general, this command should only be sent to
devices that have indicated support by setting the DeviceCaps bit in a standard poll reply (see section
7.1.2.4.
For the CFSC and SC Adv the support is for Retail Only . SCR is supported in all instances.

The Query Device Capabilities command takes the form:

Host Query Device Capabilities Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x0D 0x03 zz

Device Query Device Capabilities Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Cap 0 Cap 1 Cap 2 Cap 3 Cap 4 Cap 5 ETX CHK
Value 0x02 0x0B 0X6n nn nn nn nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 78

The Cap bytes are used to represent various device software capabilities. They are specified in the
following table:
Cap Byte Bit Capability
0 0 Obsolete 1 = Extended PUP mode is supported.
1 1 = Extended orientation handling is supported.
2 1 = QueryAcceptorApplicationID and
QueryAcceptorVariantID are supported.
3 1 = QueryBNFStatus is supported
4 1 = Test Documents are supported.
5 1 = Set Bezel is supported.
6 1 = Easitrax is supported (with Query Asset Number)
1 0 1 = Note Retrieved is supported (see 7.5.7)
1 1 = Advanced Bookmark mode is supported (see 7.5.9)
2 1 = Device is capable of ABDS download
3 1 = Device supports Clear Audit Command (see 7.5.23)
4 1 = Multi-note escrow is supported
5 1 = 32 bit Unix timestamp supported.
6 Reserved, 0
2 0 1 = 1 Denomination recycling is supported
1 1 = 2 Denomination recycling is supported
2 1 = 3 Denomination recycling is supported
3 1 = 4 Denomination recycling is supported
4
5
6
3 All Reserved, 0
4 All Reserved, 0
5 All Reserved, 0
Note that reserved fields may be used to describe new capabilities at any time. Host code should not
interrogate such reserved fields.

Revision G5 20105-002850209-PS Page 79

7.4.15 (Subtype 0x0E) Query Acceptor Application ID
CFSC SC Adv SCR Retail Only
This command is used to return the software part number of the actual application component of the
device firmware. This is only applicable when the device has been loaded with a combine file (a file that
contains both the application and the variant) because the (Subtype 0x07) Query Acceptor Application
Part Number command will return the part number of the combine file, not the underlying component’s
part number. The device capabilities map (section 7.4.14) has an entry as to whether or not the device
supports this command. The query acceptor application part number command takes the form:
Host Query Acceptor Application ID Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x0E 0x03 zz

The data returned by the device takes the form of an ASCII string that is 9 bytes long. The reply packet is
shown below:
Device Query Acceptor Application ID Reply

Byte 0 1 2 3 4 11 12 13
Name STX LEN CTRL Data 0 Data 1 ooo Data 8 ETX CHK
Value 0x02 0x0E 0X6n nn nn nn 0x03 zz

The part number is composed of a project number (5-6 digits) and version number (3 digits) with an
optional Check sum digit in the middle. Please see the following table for expected values.
Project Check Version Description
Number Digit (3 Bytes)
(5-6 Bytes) (0-1 Bytes)
Type 1 Application Part Number (Requires Check
28000…28599
Digit) (CFSC Only)
286000…289999 Type 2 Application Part Number (No Check digit)
Check digit (Not applicable for Type 2 Application
0..9
Part Numbers) (CFSC Only)
000..999 Formatted as V1.23

Revision G5 20105-002850209-PS Page 80

7.4.16 (Subtype 0x0F) Query Acceptor Variant ID
CFSC SC Adv SCR Retail Only
This command is used to return the software part number of the actual variant component of the device
firmware. This is only applicable when the device has been loaded with a combine file (a file that
contains both the application and the variant) because the (Subtype 0x09) Query Acceptor Variant Part
Number command will return the part number of the combine file, not the underlying component’s part
number. The device capabilities map (section 7.4.14) has an entry as to whether or not the device
supports this command. The query acceptor variant part number command takes the form:
Host Query Acceptor Variant ID Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x0F 0x03 zz

The data returned by the device takes the form of an ASCII string that is 9 bytes long. The reply packet is
shown below:
Device Query Acceptor Variant ID Reply

Byte 0 1 2 3 4 11 12 13
Name STX LEN CTRL Data 0 Data 1 ooo Data 8 ETX CHK
Value 0x02 0x0E 0X6n nn nn nn 0x03 zz

The part number is composed of a project number (5-6 digits) and version number (3 digits) with an
optional Check sum digit in the middle. Please see the following table for expected values.
Project Check Version Description
Number Digit (3 Bytes)
(5 Bytes) (1 Byte)
49000…49999 (CFSC)Variant part number
51000…51999 (SC Adv)Variant part number
0..9 Check digit
000..999 Formatted as V1.23

7.4.17 (Subtype 0x10) Query BNF Status

CFSC SC Adv Retail Only
This command is used to determine the status of the Bunch Note Feeder attachment. This command
may only be called if the QueryBNFStatus bit is set in the device capability map (see command (Subtype
0x0D) Query Device Capabilities)The command takes the form:
Host Query BNF Status Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x10 0x03 zz

Revision G5 20105-002850209-PS Page 81

Device Query BNF Status Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name Failure
STX LEN CTRL Present Status N/A N/A N/A ETX CHK
Code
Value 0x02 0x0B 0X6n 0x00/01 0x00/01 0xnn 0x00 0x00 0x00 0x03 zz

The following table can be used to interpret the Present, Status, and Failure code bytes:
Name Value Meaning
0 A BNF is not detected.
Present 1 A BNF is detected.
Other Reserved
0 OK
Status 1 An error has been detected
Other Reserved
0x00 No Failure (Or unknown failure if error detected)
0x01 Motor Stall
0x02 Cartridge Removed
Failure Code 0x03 Feed Error 1 (Stub out)*
0x04 Feed Error 2 (Stub out – Covered Progress Sensor)*
0x05 Too Many Rejects
Other Reserved

*Distinguishing between the two feed errors:

In the first condition, the notes were unable to be drawn into the unit while the second condition
suggests the notes were jammed deeper in the bill path.

The Failure code byte was added at a later time so it may not be functional in older versions of
firmware. In cases where the firmware does not support the failure code byte, the device will always
respond with 0x00 for this value.

It is important to note that the device will NOT send any message to the host if the BNF status changes.
The burden is on the host to regularly query the BNF status in order to capture any change.

7.4.18 (Subtype 0x11) Set Bezel

CFSC SC Adv SCR Retail Only
This command is used to override the default bezel configuration of the device bezel. This command
may only be called if the SetBezel bit is set in the device capability map (see section 7.4.14). The
command takes the form:
Host Set Bezel Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00/01/02/03 0x00 0x11 0x03 zz

Where Bezel value is:

Revision G5 20105-002850209-PS Page 82

 Bezel Code Bezel
0x00 Standard Bezel
0x01 Platform Bezel
0x02 Enhanced Diagnostic Bezel
0x03 Bat Bezel

The device does not respond with any meaningful data:

Device Set Bezel Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X6n 0x00 0x00 0x00 0x00 0x00 0x00 0x03 zz

Note: Under some conditions, the device may perform a soft reset after this command.

7.4.19 (Subtype 0x12) Query Acceptor Audit Life Time Totals Extended
SC Adv SCR
This command is used to return the extended life time audit data kept on certain key operating data.
The query acceptor audit life time totals command takes the form:
Host Query Acceptor Audit Life Time Totals Extended Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x12 0x03 zz

This data is formatted as an array of 32-bit integers where each integer is nibble encoded as eight
extended data bytes. The length of this message can be variable depending on the device. The data
takes the following form:
Device Query Acceptor Audit Life Time Totals Extended Reply

Byte 0 1 2 3 10
Name STX LEN CTRL Field 1.0 ooo Field 1.7
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
LL-2 LL-1
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

Revision G5 20105-002850209-PS Page 83

The field data is laid out according to the following rules for the two products:
SC Adv
Field Size in Data Description
Number Bytes Width
1 8 32 Total Banknotes Stacked
2 8 32 Total Barcode Vouchers Decoded
3 8 32 Total Barcode Vouchers Stacked
4 8 32 Total Value Coupons Recognized
5 8 32 Total Value Coupons Stacked
6 8 32 Total Other Docs Recognized
7 8 32 Total Other Docs Stacked
8 8 32 Total Calibrations
9 8 32 Audit Last Cleared
10 8 32 Last Calibration
11 8 32 Last Download
12 8 32 Last Audit Retrieval

SCR
Field Size in Data Description
Number Bytes Width
1 8 32 Total Banknotes Stacked
2 8 32 Total Barcode Vouchers Decoded
3 8 32 Total Barcode Vouchers Stacked
4 8 32 Total Value Coupons Recognized
5 8 32 Total Value Coupons Stacked
6 8 32 Total Other Docs Recognized
7 8 32 Total Other Docs Stacked
8 8 32 Total Calibrations
9 8 32 Total Downloads Requested
10 8 32 Audit Last Cleared
11 8 32 Last Calibration
12 8 32 Last Download
13 8 32 Last Audit Retrieval

Revision G5 20105-002850209-PS Page 84

7.4.20 (Subtype 0x13) Query Acceptor Audit QP Measures Extended
SC Adv SCR
This command is used to return extended “QP” audit data kept on the general rate of note acceptance.
The query acceptor audit QP measures command takes the form:
Host Query Acceptor Audit QP Measures Extended Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x13 0x03 zz

This data is formatted as an array of 32-bit integers where each integer is nibble encoded as eight
extended data bytes. The length of this message can be variable depending on the device. The returned
data takes the following form:
Device Query Acceptor Audit QP Measures Extended Reply

Byte 0 1 2 3 7
Name STX LEN CTRL Field 1.0 ooo Field 1.3
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
LL-2 LL-1
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

The field data is laid out according to the following rules for the two products:
SC Adv SCR
Field Size in Data Description
Number Bytes Width
1 8 32 Total Motor Starts.
2 8 32 Total Documents Stacked.
3 8 32 Total Documents Reached Escrow Position
4 8 32 Total Documents Passed Recognition
5 8 32 Total Documents Passed Validation
6 8 32 Total Barcodes Decoded
7 8 32 Total Documents Reject for Other Reason

Revision G5 20105-002850209-PS Page 85

7.4.21 (Subtype 0x14) Query Acceptor Audit Performance Measures Extended
SC Adv SCR
This command is used to return audit data kept on the extended performance data of the device. The
query acceptor audit performance measures command takes the form:
Host Query Acceptor Audit Performance Measures Extended Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x14 0x03 zz

This data is formatted as an array of 32-bit integers where each integer is nibble encoded as eight
extended data bytes. The length of this message can be variable depending on the device. The returned
data takes the following form:
Device Query Acceptor Audit Performance Measures Extended Reply

Byte 0 1 2 3 7
Name STX LEN CTRL Field 1.0 ooo Field 1.3
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
LL-2 LL-1
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

The field data is laid out according to the following rules for the two products:
SC Adv
Field Size in Data Description
Number Bytes Width
1 8 32 Total Jammed then Returned to Service
2 8 32 Last Out of Service Condition
3 8 32 Last Out of Order Condition
4 8 32 Total resets
5 8 32 Total BNF Stub-outs
6 8 32 Total BNF Obstructed Stub-outs
7 8 32 Total BNF Number of Bunches
8 8 32 Total BNF Motor Stalls
9 8 32 Total BNF Motor Stall Cartridge Recoveries
10 8 32 Total BNF Motor Stall From Recoveries

Revision G5 20105-002850209-PS Page 86

SCR
Field Size in Data Description
Number Bytes Width
1 8 32 Total Jammed then Returned to Service
2 8 32 Last Out of Service Condition
3 8 32 Last Out of Order Condition
4 8 32 Total resets
5 8 32 Total BNF Stub-outs
6 8 32 Total BNF Obstructed Stub-outs
7 8 32 Total BNF Number of Bunches
8 8 32 Total BNF Motor Stalls
9 8 32 Total BNF Motor Stall Cartridge Recoveries
10 8 32 Total BNF Motor Stall From Recoveries
11 8 32 Total Documents Stacked to Recycler
12 8 32 Total Documents Stacked to Cashbox
13 8 32 Total Documents Floated Down
14 8 32 Total Documents Dispensed
15 8 32 Total Dispense Sessions

7.4.22 (Subtype 0x15) Query Asset Number

CFSC SC Adv SCR
This command is used to determine the asset number stored in the device. It is not support by all
devices. Devices with Retail code should use the command (Subtype 0x0D) Query Device Capabilities to
determine if this function is supported.
Host Query Asset Number Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x15 0x03 zz

The data returned by the device takes the form of an ASCII string that is either 16 bytes long or is
terminated by space character (0x20). The reply packet is shown below:
Device Query Asset Number Reply

Byte 0 1 2 3 4 18 19 20
Name STX LEN CTRL Data 0 Data 1 ooo Data 15 ETX CHK
Value 0x02 0x15 0X6n nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 87

7.4.23 (Subtype 0x16) Query Acceptor Audit Total Documents Reporting Structure
CFSC SC Adv SCR
This command is used in conjunction with commands “(Subtype 0x17) Query Acceptor Audit Total
Documents Recognized”, “(Subtype 0x18) Query Acceptor Audit Total Documents Validated” and
“(Subtype 0x19) Query Acceptor Audit Total Documents Stacked” to query details on the total number
of documents processed by the device. The max number of notes in the note table is device specific.
The purpose of this command is to describe to the host how the other messages are structured when
queried.

Recommended After reading this section, please see the appendix (Using Type 6 Audit Commands
(0x16, 0x17, 0x18, 0x19)) for an example that shows the proper use of this command.
Host Query Acceptor Audit Total Documents Reporting Structure Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x16 0x03 zz

The response contains 4 data bytes that each represents a specific configuration for the other messages.
The response is shown here:
Device Query Acceptor Audit Total Documents Reporting Structure Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X6n nn nn nn nn 0x00 0x00 0x03 zz

The first 4 fields can be processed as such:

 Data0: Max number of orientations supported. This will most likely be 4 for all devices which
represent: Right-Up, Right-Down, Left-Up and Left-Down note orientations.
 Data1: Max number of fields supported. This represents the maximum number of banknotes
supported by the device. For example, CFSC will report 50 (0x32).
 Data2: Number of fields reported per query (set size). Due to EBDS message length limitations
(127 bytes), multiple queries need to be sent to the device in order to retrieve the full data for
note table entry (as reported by Data1). This value dictates the maximum number of entries
reported back for each subsequent support message. For example, CFSC will report 25 (0x19)
meaning half of the 50 banknote table entries will be returned at one time. If the value is not an
even multiple of the number of fields supported (as is the case with SC Adv) then the EBDS
message for the final set of data will be shortened to contain only the pertinent data.
 Data3: Field Data width. This is the size of each field. CFSC will return a 0x04 meaning each table
entry value takes up 4 EBDS bytes. This is required because of EBDS data limitations for each
byte (7 bits), therefore only the lower nibble of an extended data byte is used.

Revision G5 20105-002850209-PS Page 88

For a visual representation, the following table depicts the CFSC structure:
Note Table Index
Field Orientation 0 1 2 ooo 24 ooo 49
Right Up 16-bit 16-bit 16-bit 16-bit 16-bit
value value value value value
Recognized
Right Down … … … … …
(7.4.24)
Left Up … … … … …
Left Down … … … … …
Right Up … … … … …
Validated Right Down … … … ooo … ooo …
(7.4.25) Left Up … … … … …
Left Down … … … … …
Right Up … … … … …
Stacked Right Down … … … … …
(7.4.26) Left Up … … … … …
Left Down … … … … …
Each 16-bit value takes up 4 bytes of the EBDS message. The maximum amount of data that can be
reported in a single message (per orientation) is contained within the thick black border.
More detailed examples are provided in the other related messages.

Revision G5 20105-002850209-PS Page 89

7.4.24 (Subtype 0x17) Query Acceptor Audit Total Documents Recognized
CFSC SC Adv SCR
This command is used to query the device for total number of documents that passed the recognition
engine. The host shall be required to send along two parameters that control which section of the data
is returned.

Recommended After reading this section, please see the appendix (Using Type 6 Audit Commands
(0x16, 0x17, 0x18, 0x19)) for an example that shows the proper use of this command.
Host Query Acceptor Audit Total Documents Recognized Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n nn nn 0x17 0x03 zz

Please refer to (Subtype 0x16) Query Acceptor Audit Total Documents Reporting Structure for more
details on how to set up this command in order to retrieve the desired fields.

The parameter fields are Data A and Data B:

 Data A: Orientation of interest. This must be in range of Data0 values as returned by the
reporting structure command and is usually going to correspond to one of these following
values:
o 0x00 = Right-Up
o 0x01 = Right-Down
o 0x02 = Left-Up
o 0x03 = Left-Down
 Data B: Data set of interest (0 based). This field is calculated from the reporting structure
message values for Data1 and Data2. If the device reported a max field size of 50 (0x32) and a
set size of 25 (0x19) then possible values for this parameter are ‘0’ and ‘1’. This is achieved by
dividing the max field count by the set size (50 / 25 = 2) and since it is zero based, using either ‘0’
or ‘1’.

The device will respond back with a message that has the following structure.
Device Query Acceptor Audit Total Documents Recognized Reply

Byte 0 1 2 3 3+(Z-1)
Name STX LEN CTRL Field 1.0 ooo Field 1.(Z-1)
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
LL-2 LL-1
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

Revision G5 20105-002850209-PS Page 90

To format this message correctly, the field width must be known (generally = 0x04) and it is returned
during the report structure message as Data3. In addition, the set size should also be known (Data2
from the reporting structure response)
 Z: Field data width. (Data3)
 N: Number of fields reported per query. (Data2)
Each field value can be constructed using the following formula:
Total_Recognized = ((Reply[3] & 0x0F) << 12) +
((Reply[4] & 0x0F) << 8) +
((Reply[5] & 0x0F) << 4) +
((Reply[6] & 0x0F) );

7.4.25 (Subtype 0x18) Query Acceptor Audit Total Documents Validated

CFSC SC Adv SCR
This command is used to query the device for total number of documents that passed the validation
engine. The host shall be required to send along two parameters that control which section of the data
is returned.

Recommended After reading this section, please see the appendix (Using Type 6 Audit Commands
(0x16, 0x17, 0x18, 0x19)) for an example that shows the proper use of this command.
Host Query Acceptor Audit Total Documents Validated Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n nn nn 0x18 0x03 zz

Please refer to (Subtype 0x16) Query Acceptor Audit Total Documents Reporting Structure for more
details on how to set up this command in order to retrieve the desired fields.

The parameter fields are Data A and Data B:

 Data A: Orientation of interest. This must be in range of Data0 values as returned by the
reporting structure command and is usually going to correspond to one of these following
values:
o 0x00 = Right-Up
o 0x01 = Right-Down
o 0x02 = Left-Up
o 0x03 = Left-Down
 Data B: Data set of interest (0 based). This field is calculated from the reporting structure
message values for Data1 and Data2. If the device reported a max field size of 50 (0x32) and a
set size of 25 (0x19) then possible values for this parameter are ‘0’ and ‘1’. This is achieved by
dividing the max field count by the set size (50 / 25 = 2) and since it is zero based, using either ‘0’
or ‘1’.

Revision G5 20105-002850209-PS Page 91

The device will respond back with a message that has the following structure.
Device Query Acceptor Audit Total Documents Validated Reply

Byte 0 1 2 3 3+(Z-1)
Name STX LEN CTRL Field 1.0 ooo Field 1.(Z-1)
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
LL-2 LL-1
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

To format this message correctly, the field width must be known (generally = 0x04) and it is returned
during the report structure message as Data3. In addition, the set size should also be known (Data2
from the reporting structure response)
 Z: Field data width. (Data3)
 N: Number of fields reported per query. (Data2)
Each field value can be constructed using the following formula:
Total_Validated = ((Reply[3] & 0x0F) << 12) +
((Reply[4] & 0x0F) << 8) +
((Reply[5] & 0x0F) << 4) +
((Reply[6] & 0x0F) );

7.4.26 (Subtype 0x19) Query Acceptor Audit Total Documents Stacked

CFSC SC Adv SCR
This command is used to query the device for total number of documents that have been stacked into
the cashbox. The host shall be required to send along two parameters that control which section of the
data is returned.

Recommended After reading this section, please see the appendix (Using Type 6 Audit Commands
(0x16, 0x17, 0x18, 0x19)) for an example that shows the proper use of this command.
Host Query Acceptor Audit Total Documents Stacked Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n nn nn 0x19 0x03 zz

Please refer to (Subtype 0x16) Query Acceptor Audit Total Documents Reporting Structure for more
details on how to set up this command in order to retrieve the desired fields.

Revision G5 20105-002850209-PS Page 92

The parameter fields are Data A and Data B:
 Data A: Orientation of interest. This must be in range of Data0 values as returned by the
reporting structure command and is usually going to correspond to one of these following
values:
o 0x00 = Right-Up
o 0x01 = Right-Down
o 0x02 = Left-Up
o 0x03 = Left-Down
 Data B: Data set of interest (0 based). This field is calculated from the reporting structure
message values for Data1 and Data2. If the device reported a max field size of 50 (0x32) and a
set size of 25 (0x19) then possible values for this parameter are ‘0’ and ‘1’. This is achieved by
dividing the max field count by the set size (50 / 25 = 2) and since it is zero based, using either ‘0’
or ‘1’.

The device will respond back with a message that has the following structure.
Device Query Acceptor Audit Total Documents Stacked Reply

Byte 0 1 2 3 3+(Z-1)
Name STX LEN CTRL Field 1.0 ooo Field 1.(Z-1)
Value 0x02 LL 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
LL-2 LL-1
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

To format this message correctly, the field width must be known (generally = 0x04) and it is returned
during the report structure message as Data3. In addition, the set size should also be known (Data2
from the reporting structure response)
 Z: Field data width. (Data3)
 N: Number of fields reported per query. (Data2)
Each field value can be constructed using the following formula:
Total_Stacked = ((Reply[3] & 0x0F) << 12) +
((Reply[4] & 0x0F) << 8) +
((Reply[5] & 0x0F) << 4) +
((Reply[6] & 0x0F) );

Revision G5 20105-002850209-PS Page 93

7.4.27 (Subtype 0x1A) Acceptor Diagnostics Self Test
CFSC SC Adv
This command is intended for service level technicians and provides information on the current
hardware status. It serves two purposes.
 It can request that the device initiate a self diagnostic test.
 It can request the diagnostic results of a test from the device.
The command requires the host pass along two parameters to inform the device of the desired
operation. This command has the following structure.
Host Acceptor Diagnostics Self Test Command

Byte 0 1 2 3 4 5 6 7
Name Operation Test Command
STX LEN CTRL ETX CHK
Type Level
Value 0x02 0x08 0X6n nn nn 0x1A 0x03 zz

The first parameter is called the operation type. Possible values are:
 0x01: START test at the specified level
 0x02: Query test result of the specified level

NOTE: Sending a query prior to a START command might result in stale data.
The second parameter is the test level. Possible values are:
 0x01: Test Level 1 (Sensors test)
 0x02: Test Level 2 (MMI and Motors test)

All other values should be considered reserved for future use.

Depending of the test level, the results might not always be available immediately. If results are not
ready, the device will respond with a standard reply (11 bytes) with 0x7F in the first 2 data fields,
indicating invalid results. The host needs to repeat his request at a later time.

The devices reply format and data depend on the context. Possible responses are for:
 Start Test
 Results for Test Level 1
 Results for Test Level 2
 Results not ready

Start Diagnostic test response contains no data.

Device Acceptor Diagnostics Self Test Reply : CONTEXT = Start Test

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X6n 0x00 0x00 0x00 0x00 0x00 0x00 0x03 zz

Revision G5 20105-002850209-PS Page 94

The results for test level 1 has the following structure.
Device Acceptor Diagnostics Self Test Reply : CONTEXT = Test Level 1

Byte 0 1 2 3 6
Name STX LEN CTRL Field 0.0 ooo Field 0.3
Value 0x02 0X55 0X6n 0x0n 0x0n

Field 1
0x0n ooo 0x0n
83 84
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

For all fields results (except MMI button – described in the table) as follows:
 0x0000 = Test Passed
 0x00FF = Test Skipped
 <other> = Failure code

The field data is laid out according to the following rules for the SC product:
Field Size in Data Description
Number Bytes Width
0 4 16 Start Sensor
1 4 16 Cross Channel 1
2 4 16 Cross Channel 2
3 4 16 Barcode 1
4 4 16 Barcode 2
5 4 16 Stacker Home
6 4 16 Recognition Sensor 1
7 4 16 Recognition Sensor 2
8 4 16 Recognition Sensor 3
9 4 16 Recognition Sensor 4
10 4 16 Recognition Sensor 5
11 4 16 Recognition Sensor 6
12 4 16 Recognition Sensor 7
13 4 16 Recognition Sensor 8
14 4 16 Recognition Sensor 9
15 4 16 Recognition Sensor 10
16 4 16 CBM_8052
17 4 16 DBM_8052
MMI Button
18 4 16 0: NOT pressed
1: Pressed
19 4 16 General IO

Revision G5 20105-002850209-PS Page 95

Each field’s data can be constructed using the following formula as an example:
Start Sensor Value = ((Reply[3] & 0x0F) << 12) +
((Reply[4] & 0x0F) << 8) +
((Reply[5] & 0x0F) << 4) +
((Reply[6] & 0x0F) );

A Test level 2 response has the following structure.

Device Acceptor Diagnostics Self Test Reply : CONTEXT = Test Level 2

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X6n nn nn 0x00 0x00 0x00 0x00 0x03 zz

Only the first two data bytes contain information.

 Data0: Transport Motor test result
 Data1: Stacker Motor test result

The field data is laid out according to the following rules for the SC product:
Data 0 Description
0x7F Results not ready
0 PASS
1 FAILED Transport Tach
2 FAILED BNF Motor

Data 1 Description
0x7F Results not ready
0 PASS
1 FAILED OFF Home

If the device is not yet ready to respond to a host’s request for the test results, it returns a message with
the following structure.
Device Acceptor Diagnostics Self Test Reply : CONTEXT = Results Not Ready

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X6n 0x7F 0x7F 0x00 0x00 0x00 0x00 0x03 zz

The two 0x7Fs for the first two data bytes represent that the device has not yet completed the test. The
host should re-query at a later time.

Revision G5 20105-002850209-PS Page 96

7.4.28 (Subtype 0x1D) Query Acceptor Diagnostics Sensor Data
CFSC SC Adv
This command is sent to the device to query a specified sensor’s current data values and is intended for
use by service level technicians only. The host can pass in a value representing the desired sensor as
parameter. The host command has the following structure.
Host Acceptor Diagnostics Query Sensor Data Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Sensor N/A Command ETX CHK
Value 0x02 0x08 0X6n nn 0x00 0x1D 0x03 zz

The following list describes the supported sensors. All other values should be considered reserved for
future use.
 0x01 = Stacker Home Sensor

The device will reply with the following message structure.

Device Acceptor Diagnostics Query Sensor Data Reply

Byte 0 1 2 3 6
Name STX LEN CTRL Field 1.0 ooo Field 1.3
Value 0x02 0x1D 0X6n 0x0n 0x0n

Field 2
0x0n ooo 0x0n
27 28
Field N ETX CHK
0x0n ooo 0x0n 0x03 zz

This table outlines the layout of the returned data for the Stacker Home Sensor.
Field Size in Data Description
Number Bytes Width
State
0 4 16 0: UNBLOCKED
1: BLOCKED
1 4 16 Adjusted Reading
2 4 16 Reading
3 4 16 Offset Reading
4 4 16 Threshold
5 4 16 Circuit Offset
These data values can be determined by using the following code example:
Home Sensor State Value = ((Reply[3] & 0x0F) << 12) +
((Reply[4] & 0x0F) << 8) +
((Reply[5] & 0x0F) << 4) +
((Reply[6] & 0x0F) );

Revision G5 20105-002850209-PS Page 97

7.4.29 (Subtype 0x23) Query Hardware Status
SCR
This command is used to query the device's hardware status.
Host Query Hardware Status Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x00 0x00 0x23 0x03 zz

Device Query Hardware Status Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name Jam
STX LEN CTRL N/A N/A N/A N/A N/A ETX CHK
Location
Value 0x02 0x0B 0X6n 0xnn 0x00 0x00 0x00 0x00 0x00 0x03 zz

The following table can be used to interpret the data bytes:

Name Value Meaning
0x00 No Jam Detected
0x01 Jam Detected in the Bill Acceptor
Jam Location 0x02 Jam Detected in Recycler Transport
0x03 Jam Detected in Cashbox
Other Reserved
All Other
Any Reserved
Data Bytes

The "Jam Location" field is only populated when the device is in the Jammed state. It is important to
note that the device will NOT send any message to the host if the status changes. The burden is on the
host to query the status when applicable.

7.4.30 (Subtype 0x7F) Acceptor Soft Reset

S2K CFSC SC Adv SCR
This command is used to reset the device. There is not necessarily a reply to this command, but some
data may be sent by the device. The host system should ignore all data sent by the device for at least
one second. Further, the device may take as much as fifteen seconds to return to normal operation after
being reset and the host should poll, once per second, for at least fifteen seconds until the device
replies. The acceptor soft reset command takes the form:
Host Soft Reset Command

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Data A Data B Command ETX CHK
Value 0x02 0x08 0X6n 0x7F 0x7F 0x7F 0x03 zz

Warning It is not recommended to use this command to clear error conditions such as jammed,
failure, or cashbox full as this can result in undesired behavior.

Revision G5 20105-002850209-PS Page 98

7.5 (Type 7) Extended Commands
The extended commands utilize message type 7 to provide functionality outside of the standard
omnibus commands. The use of message type 7 is complicated by the fact that it can be used by either
the host or device at anytime. Since this message type is designed to provide further customization,
there is no standard length among the different messages. Another key difference for this message is
the use of a sub-type byte. This byte is used to identify the purpose of the message. A general structure
is listed below.
Extended Message Layout (Host or Device)

Byte 0 1 2 3 4 5 6 7
Name STX LEN CTRL Sub Type Data 0 Data N ETX CHK
ooo
Value 0x02 LL 0X7n nn nn nn 0x03 zz

The length varies depending on the number of data bytes present. It is also important to note that every
host message must contain, at a minimum, the 3 data bytes present in a standard omnibus command.
The device will continue to use the configuration data from these bytes to ensure proper operations.
Similarly, the device will provide at least 6 data bytes in every response to represent the values found in
the standard omnibus reply message. These data bytes are decoded in the same fashion as described in
the General Messages section. The extended data bytes reside between the last normal data byte and
the ETX value and can vary in length.

When the host issues a type 7 command that requires an immediate response from the device, the
device responses contain the same sub type byte value so the host can be assured that the response is
for the correct message. This is unlike the Auxiliary commands (Type 6) which do not have any unique
identifier for the device’s response.

Revision G5 20105-002850209-PS Page 99

The table listed below contains a short description of each Type 7 message. Any missing sub types
should be assumed reserved for future use
Sub Type Description
0x01 (Subtype 0x01) Extended Barcode Reply
0x02 (Subtype 0x02) Extended Note Specification Message
0x03 (Subtype 0x03) Set Extended Note Inhibits
0x04 (Subtype 0x04) Set Escrow Timeout / Extended Coupon
0x05 (Subtype 0x05) Set Asset Number
0x06 (Subtype 0x06) Query Value Table
0x0B (Subtype 0x0B) Note Retrieved
0x0C (Subtype 0x0C) SHA-1 Request
0x0D (Subtype 0x0D) Advanced Bookmark Mode
0x10 (Subtype 0x10) Cashbox Cleanliness
0x11 (Subtype 0x11) Request 16-bit CRC Calculation
0x12 (Subtype 0x12) Request 32-bit CRC Calculation
0x13 (Subtype 0x13) Request Recycler Note Table
0x14 (Subtype 0x14) Set Recycler Note Value Enables
0x15 (Subtype 0x15) Recycler Omnibus Command/Reply
0x16 (Subtype 0x16) Dispense Bills
0x17 (Subtype 0x17) Cancel Dispense/Float
0x18 (Subtype 0x18) Float Bills
0x19 (Subtype 0x19) Last Cash Movement Summary Report
0x1A (Subtype 0x1A) Missing Note Report
0x1B (Subtype 0x1B) Request Physical Recycler Status
0x1C (Subtype 0x1C) RFID Data Request
0x1D (Subtype 0x1D) Clear Audit Data Request
0x20 (Subtype 0x20) Escrow Session Summary Report

Revision G5 20105-002850209-PS Page 100

7.5.1 (Subtype 0x01) Extended Barcode Reply
CFSC SC Adv
If bar coded vouchers are enabled, then the device sends this reply when a bar coded voucher is in
escrow. This reply contains an additional 28 bytes of ASCII encoded data that represents the bar code
value. This data ends when the first 0x28, ASCII “(“ character occurs. The following is the layout of this
packet:
Device Extended Barcode Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name Data Data Data Data Data Data
STX LEN CTRL Sub Type
0 1 2 3 4 5
Value 0x02 0x28 0X7n 0x01 nn nn nn nn nn nn

10 11 37 38 39
Ext Data Ext Data Ext Data
ETX CHK
0 1 ooo 27
nn nn nn 0x03 zz

A typical data payload for an 18 digit bar-coded voucher might be encoded as:

012345678901234567((((((((((

It is then the responsibility of the host system to determine what (if any) value to assign to this voucher.
The host must command the device to either stack or return the voucher. It is important to note that
when the voucher is stacked, a standard omnibus reply with a non-extended note value of unknown is
sent by the device. Thus, the only chance the host system has to capture the bar coded data is when the
voucher is at escrow.

Note: This message only applies to hardware that supports barcodes.

Revision G5 20105-002850209-PS Page 101

7.5.2 (Subtype 0x02) Extended Note Specification Message
CFSC SC Adv SCR
This message serves two purposes; one purpose for this message is to allow the host to query the
extended note details for a specified index. The other use is by the device to inform the host when a
bank note has reached the escrow position or been stacked.
The first case is the only time the host would use this message and the format of this command is shown
below:
Host Query Extended Note Specification

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 Index ETX CHK
Value 0x02 0x0A 0X7n 0x02 nn nn nn nn 0x03 zz

The first extended data byte is the Index. This index value starts at ‘1’ and represents the index of the
extended note table data in the device. The section “Requesting the Note Table” outlines how to use
this index in order to retrieve the full note set table from the device. A more detailed protocol trace
example for this command can be found in section 8.2.

The reply contains 18 additional bytes of data that describe the bank note in great detail. This message
can be sent from the device for two reasons:
 Response to a host’s query extended note command
 Device is running in extended note mode and a valid banknote has either reached escrow or
been stacked.
The following is the layout of the reply packet:
Device Extended Note Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name Data Data Data Data Data Data
STX LEN CTRL Sub Type
0 1 2 3 4 5
Value 0x02 0x1E 0X7n 0x02 nn nn nn nn nn nn

10 11 27 28 29
Ext Data Ext Data Ext Data
ETX CHK
0 1 ooo 17
nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 102

If this is a reply to the Host Query Command, the index will match the same value sent from the host.
Otherwise, the index value is not used and set to 0x00 for any escrowed or stacked notes.
Refer to the following table for a full description of how to decode this message:
Field Byte Field Description Sample Value
Offset (2000 Yen Note)
Index 0 Not used for escrow or stacked notes 0x00
ISO Code 1..3 A three character ASCII currency code. See “JPY”
ISO_4217 at the Wikipedia for details.
Base Value 4..6 A three character ASCII coded decimal value “002”
Sign 7 An ASCII coded sign value for the Exponent. This “+”
field is either a “+” or a “-“
Exponent 8..9 ASCII coded decimal value for the power of ten “03”
that the base is to either be multiplied by (if Sign
is “+”) or divided by (if Sign is “-“)
Orientation 10 A single character binary field that encodes the 0x00
orientation of the bank note.
0x00 = Right Edge, Face Up
0x01 = Right Edge, Face Down
0x02 = Left Edge, Face Up
0x03 = Left Edge, Face Down
Note: In general, this field is only correct if the
Extended orientation bit is set in device
capabilities map. See section 0.
Type 11 An ASCII letter that documents the note type. “A”
This corresponds to the data in the variant
identity card.
Series 12 An ASCII letter that documents the note series. “A”
This corresponds to the data in the variant
identity card.
Compatibility 13 An ASCII letter that documents the revision of the “B”
recognition core used. This corresponds to the
data in the variant identity card.
Version 14 An ASCII letter that documents the version of the “A”
note’s recognition criteria. This corresponds to
the data in the variant identity card.
Banknote 15 Banknote classification values as follows: 0x00
Classification 0x00 = Classification is disabled
0x01 = Class 1 (unidentified banknote)
0x02 = Class 2 (suspected counterfeit)
0x03 = Class 3 (suspected zero value note)
0x04 = Class 4 (genuine banknote)
Reserved 15..17 3 bytes reserved for future use. N/A
In this example: Banknote Value = 002 x 10+03 = 2 x 1000 = ¥2000 fed right edge first, face up.

A special case is that of an unknown item stack in extended note mode. In this case the entire eighteen
bytes of extended note data are zero bytes.

Revision G5 20105-002850209-PS Page 103

The classification feature is only enabled by specific devices in certain geographical markets. When not
enabled, the value will always be 0x00.

Warning Also, be aware that under some circumstances, a no-value note can be returned in “Non-
extended” mode. See section 7.1.2.3 (Data Byte 2). The host code needs to able to handle either reply
type for this case.

Warning SCR The device will always respond with a (Subtype 0x15) Recycler Omnibus
Command/Reply message in place of this message for escrowed and stacked banknotes. This message is
only sent as a response if the host queried the note table.

7.5.3 (Subtype 0x03) Set Extended Note Inhibits

CFSC SC Adv SCR
This command is used to control the acceptance of bank notes on a note type basis. It is only used when
the device is running in extended note mode (section 4.2.2). This command is formatted as follows:
Host Set Extended Note Inhibits

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 LL 0X7n 0x03 nn nn nn

7 8 LL-3 LL-2 LL-1

Enable 1 Enable 2 ooo Enable N ETX CHK
nn nn nn 0x03 zz

The Enable data is used to enable notes by index. This is shown below for two of our common products.
CFSC Supports up to 50 denomination types, therefore the command requires 8 extended data bytes.
This will make the message length 0x11:
Byte Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Enable 1 Note 7 Note 6 Note 5 Note 4 Note 3 Note 2 Note 1
Enable 2 Note 14 Note 13 Note 12 Note 11 Note 10 Note 9 Note 8
Enable 3 Note 21 Note 20 Note 19 Note 18 Note 17 Note 16 Note 15
Enable 4 Note 28 Note 27 Note 26 Note 25 Note 24 Note 23 Note 22
Enable 5 Note 35 Note 34 Note 33 Note 32 Note 31 Note 30 Note 29
Enable 6 Note 42 Note 41 Note 40 Note 39 Note 38 Note 37 Note 36
Enable 7 Note 49 Note 48 Note 47 Note 46 Note 45 Note 44 Note 43
Enable 8 - - - - - - Note 50

Revision G5 20105-002850209-PS Page 104

SC Adv SCR Supports up to 128 denomination types, therefore the command requires 19 extended
data bytes. This will make the message length 0x1C:
Byte Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Enable 1 Note 7 Note 6 Note 5 Note 4 Note 3 Note 2 Note 1
Enable 2 Note 14 Note 13 Note 12 Note 11 Note 10 Note 9 Note 8
Enable 3 Note 21 Note 20 Note 19 Note 18 Note 17 Note 16 Note 15
Enable 4 Note 28 Note 27 Note 26 Note 25 Note 24 Note 23 Note 22
Enable 5 Note 35 Note 34 Note 33 Note 32 Note 31 Note 30 Note 29
Enable 6 Note 42 Note 41 Note 40 Note 39 Note 38 Note 37 Note 36
Enable 7 Note 49 Note 48 Note 47 Note 46 Note 45 Note 44 Note 43
Enable 8 Note 56 Note 55 Note 54 Note 53 Note 52 Note 51 Note 50
Enable 9 Note 63 Note 62 Note 61 Note 60 Note 59 Note 58 Note 57
Enable 10 Note 70 Note 69 Note 68 Note 67 Note 66 Note 65 Note 64
Enable 11 Note 77 Note 76 Note 75 Note 74 Note 73 Note 72 Note 71
Enable 12 Note 84 Note 83 Note 82 Note 81 Note 80 Note 79 Note 78
Enable 13 Note 91 Note 90 Note 89 Note 88 Note 87 Note 86 Note 85
Enable 14 Note 98 Note 97 Note 96 Note 95 Note 94 Note 93 Note 92
Enable 15 Note 105 Note 104 Note 103 Note 102 Note 101 Note 100 Note 99
Enable 16 Note 112 Note 111 Note 110 Note 109 Note 108 Note 107 Note 106
Enable 17 Note 119 Note 118 Note 117 Note 116 Note 115 Note 114 Note 113
Enable 18 Note 126 Note 125 Note 124 Note 123 Note 122 Note 121 Note 120
Enable 19 - - - - - Note 128 Note 127

If the bit equals 1 then the note is enabled.

The device will reply with a standard Omnibus reply detailed in section 7.1.2 with no extended data:
Device Extended Note Inhibits Reply

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 ETX CHK
Value 0x02 0x0B 0X2n nn nn nn nn nn nn 0x03 zz

In some firmware, an alternate reply is given. This reply also contains no extended data.
Device Extended Note Inhibits Reply - Alternate

Byte 0 1 2 3 4 5 6 7 8 9 10 11
Name Data Data Data Data Data Data
STX LEN CTRL Subtype ETX CHK
0 1 2 3 4 5
Value 0x02 0x0C 0X7n 0x03 nn nn nn nn nn nn 0x03 zz

Warning In order to avoid possible confusion processing the extended note data, this command should
only be sent when the device is in the idle state.

Revision G5 20105-002850209-PS Page 105

7.5.4 (Subtype 0x04) Set Escrow Timeout / Extended Coupon
S2K CFSC SC Adv SCR
This command is generally used to set the escrow timeout of the device. However, it can also serve an
alternative function in reporting a special coupon if that mode is enabled (Section 7.1.1.3).
CFSC SC Adv SCR Gaming Only
The Set Escrow command is formatted as follows:
Host Set Escrow Timeout Command

Byte 0 1 2 3 4 5 6 7 8 9 10
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 Notes Barcode ETX CHK
Value 0x02 0x0B 0X7n 0x04 nn nn nn nn nn 0x03 zz

The Notes and Barcode fields set the timeout for bank notes and barcodes in seconds. This is a value
from 1 through 127 seconds, or zero to disable the timeout. By default, both timeouts are disabled in
most software implementations. The reply contains no extended data:
Device Set Escrow Timeout Reply

Byte 0 1 2 3 4 5 6 7 8 9 10 11
Name Subtype Data Data Data Data Data Data
STX LEN CTRL ETX CHK
0 1 2 3 4 5
Value 0x02 0x0C 0X7n 0x04 nn nn nn nn nn nn 0x03 zz

S2K If extended coupon reporting is enabled then the device will send this reply when a special coupon
is detected. The reply contains 6 additional bytes of data that describe the coupon in detail. The
following is the layout of this packet:
Device Extended Coupon Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name Data Data Data Data Data Data
STX LEN CTRL Sub Type
0 1 2 3 4 5
Value 0x02 0x12 0X7n 0x04 nn nn nn nn nn nn

10 11 12 13 14 15 16 17
Coupon Coupon Coupon Coupon
N/A N/A ETX CHK
Data 0 Data 1 Data 2 Data 3
0x0n 0x0n 0x0n 0x0n 0x00 0x00 0x03 zz

The coupon bytes 0 through 3 represent a 16 bit value that may be broken down as:
Bit # Value Description
15..3 n 13 Bit Vender ID
0x00 Free Vend
0x01 $1 Coupon
2..0 0x02 $2 Coupon
0x03 $5 Coupon
Other Reserved

Revision G5 20105-002850209-PS Page 106

7.5.5 (Subtype 0x05) Set Asset Number
CFSC SC Adv SCR
This command is used to write a string into the asset number of the device and the optional non-volatile
memory tag installed in the cash box. This allows the cash box to be linked back to a specific device at a
later time when the tag is read. This command is shown below:
Host Set Asset Number Command

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x1A 0X7n 0x05 nn nn nn

7 8 23 24 25
Asset 0 Asset 1 ooo Asset 16 ETX CHK
nn nn nn 0x03 zz

The asset bytes contain an asset string (alpha-numeric) that is programmed into the device. This
supports up to 17 bytes of data however, most devices will only use 16 bytes of data. The last Asset
block should be left as 0x00 to ensure compatibility with all devices. The reply contains no extended
data:
Device Set Asset Number Reply

Byte 0 1 2 3 4 5 6 7 8 9 10 11
Name Data Data Data Data Data Data
STX LEN CTRL Subtype ETX CHK
0 1 2 3 4 5
Value 0x02 0x0C 0X7n 0x05 nn nn nn nn nn nn 0x03 zz

7.5.6 (Subtype 0x06) Query Value Table

CFSC SC Adv Deprecated Gaming Only
This command sends a request to the device for the entire note table. The device will respond with a
message containing all known denominations. The purpose of this message is to allow the host to know
the exact denomination of a note that is usually only reported as Note Index Value “X”.
Warning This message is only compatible with variants of a single currency and running in Non-
Extended Mode (4.2.1).
There are no extended data bytes sent to the device:
Host Query Value Table Command

Byte 0 1 2 3 4 5 6 7 8
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x09 0X7n 0x06 nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 107

The device will reply with a message that contains the note table in the extended data.
Device Query Value Table Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x52 0X7n 0x06 nn nn nn nn nn nn

10 19 70 79 80 81
Denom 0 ooo Denom 6 ETX CHK
0x0n o o o 0x0n 0x0n ooo 0x0n 0x03 zz

See the table below for an example of the data layout for each denomination.
Field Byte Field Description Sample Value
Offset (2000 Yen Note)
Index 0 Note Value Index reported starting with ‘1’ and 0x03
ending with the final index ‘7’.
ISO Code 1..3 A three character ASCII currency code. See “JPY”
ISO_4217 at the Wikipedia for details.
Base Value 4..6 A three character ASCII coded decimal value “002”
Sign 7 An ASCII coded sign value for the Exponent. This “+”
field is either a “+” or a “-“
Exponent 8..9 ASCII coded decimal value for the power of ten “03”
that the base is to either be multiplied by (if Sign
is “+”) or divided by (if Sign is “-“)
In this example: Note Value = 002 x 10+03 = 2 x 1000 = ¥2000.

If a Value Index does not have a corresponding denomination value, then all fields will be 0x00 following
the Value Index.

7.5.7 (Subtype 0x0B) Note Retrieved

CFSC SC Adv SCR
The note retrieved message is used to turn on optional functionality in the device. Some software has
the ability to report to the host when the customer has retrieved a returned or rejected note from the
device. Once a document is returned/rejected by the device, the document will sit partially in the device
in a manner that is convenient for the customer. This message allows the host to detect the moment the
customer removes the note from the mouth of the device.

SCR For dispensing operations, the note retrieved event is not sent because this functionality is
captured in the Recycler Omnibus Reply as part of the recycler status bit fields. Please refer to section
7.5.15.1 for more details.

Revision G5 20105-002850209-PS Page 108

The host must enable this feature every time the device powers up. This is done with the following
message. (The same message structure can also be used to disable the feature).
Host Enable/Disable Note Retrieved Functionality Command

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 Status ETX CHK
Value 0x02 0x0A 0X7n 0x0B nn nn nn 0x00/01 0x03 zz

To enable this feature, the host would send a 0x01 as the status byte. To disable, the host can send a
0x00 as the status byte.

The device will respond to the enable/disable command with an ACK or NAK:
Device Enable/Disable Note Retrieved Functionality Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x0B nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

The device ACKs with 0x01 if it can honor the hosts request to either enable or disable. The device will
NAK the command if it is not supported for the current configuration. (ex. BNF is attached).

If the functionality has been enabled, the device will send out a message each time the note is removed
after a return/reject. This message will have the following structure:
Device Note Retrieved Event

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x0B nn nn nn nn nn nn

10 11 12
Event ETX CHK
0x7F 0x03 zz

The 0x7F for the Event byte signifies that the note has been removed by the user.

7.5.8 (Subtype 0x0C) SHA-1 Request

CFSC SC Adv
The SHA-1 Request is a message that informs the device to perform a SHA calculation over the code
space. The purpose of this is to verify the integrity of the code space.

The Host shall tell the device to begin the SHA calculation by sending the following message with the
starting address and seed parameters:

Revision G5 20105-002850209-PS Page 109

Host SHA-1 Request

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x39 0X7n 0x0C nn nn nn

7 14
Start Address
0x0n ooo 0x0n

15 22 47 54 55 56
Seed 0 ooo Seed 4 ETX CHK
0x0n ooo 0x0n 0x0n ooo 0x0n 0x03 zz

The Start address is an 8 byte value that uses only the lower nibble to send data. The same encoding is
found on the 5 seed values as well. Each of the seed values is 8 bytes. For example, a starting address of
0x1234ABCD will be encoded as 8 bytes = {0x01, 0x02, 0x03, 0x04, 0x0A, 0x0B, 0x0C, 0x0D}.

The device will either ACK or NAK the request.

Device SHA-1 Request Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x0C nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

If the device ACKs the request, it will begin running the SHA calculation. Since this is such a processor
intensive function, it can take the device up to 60 seconds for the device to respond with a SHA
calculation result. The host should continue to poll the device with standard omnibus commands until
the device responds with the SHA results described in the following message:
Device SHA-1 Results

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x34 0X7n 0x0C nn nn nn nn nn nn

10 17 43 50 51 52
Result 0 ooo Result 4 ETX CHK
0x0n ooo 0x0n 0x0n ooo 0x0n 0x03 zz

The results are posted back in a similar format as the host to device message. The results are sent in the
lower nibble of each extended data byte.

Revision G5 20105-002850209-PS Page 110

7.5.9 (Subtype 0x0D) Advanced Bookmark Mode
CFSC SC Adv
The Advanced bookmark message is used to enable/disable a special mode of the device. This is
available on newer firmware. When a device is in advanced bookmark mode, it will allow the very next
document to be processed by the host even if it does not have any value. If the document meets certain
size restrictions, the host can decide to accept or return the document. If stacked, the document will be
reported as “No Value.”
To prevent accidentally stacking a valid document (banknote or barcode), the device automatically
reject all validated documents.
Warning Even though the device will auto reject a valid note in this mode, there is no guarantee that
the device will reject ALL valid notes in this mode because the device may possibly not detect the
document as a valid banknote; the burden is placed on the host implementation to ensure no miscounts
occur when using this message. This mode is designed for attended services and allows the attendant to
insert a slip or receipt that should be placed with the currency.

The device will automatically leave the mode if any of the following conditions are met:
 Power is lost
 Host informs the device to leave the mode.
 Calibration mode is entered.
 A document is stacked
The most important one is the last one: “A document is stacked.” This means the mode does not persist
and will only be enabled for a single document. Once this document is stacked, the device will resume
normal operations.

If this mode is enabled along with the normal bookmark mode, then advanced bookmark mode takes
precedence; all valid notes and barcodes will automatically be rejected.

The host must enable this feature every time a custom bookmark is to be accepted. This is done with the
following message. (The same message structure can also be used to disable the feature).
Host Enable/Disable Advanced Bookmark Mode Command

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 Status ETX CHK
Value 0x02 0x0A 0X7n 0x0D nn nn nn 0x00/01 0x03 zz

The Status byte tells the device to enable (0x01) or disable (0x00) the mode.

Revision G5 20105-002850209-PS Page 111

The device will respond to the command with an ACK or NAK message:
Device Enable/Disable Advanced Bookmark Mode Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x0D nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

If the device ACKs the message with 0x01, then the mode has been entered. The device may NAK the
message if it is currently busy (processing a note or powering up).

When the device stacks a document in this mode, the Standard Omnibus Reply (section 7.1.2) is
reported with the stacked bit set and no value reported in data byte 2.

7.5.10 (Subtype 0x10) Cashbox Cleanliness

CFSC SC Adv
This feature supports additional MMI blink codes on the SC device that report the status of the cashbox
cleanliness. The EBDS commands allow the host machine to be made aware of these status changes
when the cashbox is in need of servicing. This functionality needs to be turned on by the host every time
the device powers up. This message has the following structure:
Host Enable/Disable Cashbox Cleanliness Reporting Command

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 Enable ETX CHK
Value 0x02 0x0A 0X7n 0x10 nn nn nn 0x00/01 0x03 zz

The Enable byte tells the device to enable (0x01) or disable (0x00) the mode.

The device will respond to the command with an ACK or NAK message:
Device Enable/Disable Cashbox Cleanliness Reporting Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x10 nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

Revision G5 20105-002850209-PS Page 112

If the device ACKs the message with 0x01, then the mode has been enabled. If the device NAKs the
message then the mode has not been entered. Once this feature is enabled, the device will run a check
whenever a cashbox is inserted. If the cashbox is in need of servicing, the host will be informed. There
are three states for the cashbox:
 Acceptable (No cleaning required)
 Cleaning Recommended – Device will remain in service but should be cleaned when the box is
retrieved.
 Cleaning Required – Device will remain out of service until a clean cashbox is inserted.

No message will be sent if the cashbox is acceptable. If the cashbox is in the “Cleaning Recommended“
or the “Cleaning Required” states, then the device will send a message to the host with the following
structure:
Device Cashbox Cleanliness Event

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x10 nn nn nn nn nn nn

10 11 12
Event ETX CHK
0x11/10 0x03 zz
This event message will only ever be sent once per instance. The event field reports the status of the
cashbox:
 0x11 = Cleaning Recommended.
 0x10 = Cleaning Required.

7.5.11 (Subtype 0x11) Request 16-bit CRC Calculation

CFSC SC Adv
The 16-bit CRC Request is a message that informs the device to perform a 16-bit CRC calculation over
portions of the code space. The purpose of this is to verify the integrity of the code space. It could also
be used to verify the installed application and\or variant has not been updated.

This command should only be sent to the device after power up, and not during document or note table
processing.
This request also does not persist across power ups so if the device was restarted after a request was
posted, but before the results were retrieved, then the host needs to re-issue this command.

The Host shall tell the device to begin the 16-bit CRC calculation by sending the following message:
Host Request 16-bit CRC

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x0E 0X7n 0x11 nn nn nn

7 8 11 12 13
Segment Seed.0 Seed.3 ETX CHK
ooo
0x0n 0x0n 0x0n 0x03 zz

Revision G5 20105-002850209-PS Page 113

The Segment defines the portion of code space over which it is requested to perform the CRC
calculation.
 0x00: Reserved
 0x01: Application code space
 0x02: Variant code space
 0x03: Combined (application and variant) code space.

The four seed values contain the data in the lower nibble. For example, the seed value 0x1234 is
encoded as 4 bytes {0x01, 0x02, 0x03, 0x04}.

There is no ability to change the starting address; the device begins all calculations at the beginning of
the appropriate code space.
The device will either ACK or NAK the request with the following message:
Device Request 16-bit CRC Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x11 nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

The device might NAK the request if not in idle state or if it is already in the middle of handling another
CRC request.
If the device ACKs the request, it will begin running the CRC calculation. Since this is such a processor
intensive function, it can take several seconds for the device to respond with a result. The host should
continue to poll the device with a standard omnibus command until it responds with the CRC results
described in the following message:
Device 16-bit CRC Results

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x10 0X7n 0x11 nn nn nn nn nn nn

10 13 14 15
Result.0 Result.3 ETX CHK
ooo
0x0n 0x0n 0x03 zz

The CRC results come back in the form 4 byte values. Each byte contains data in only the last nibble.
Result is transferred MSB first (Big Endian).

Revision G5 20105-002850209-PS Page 114

7.5.12 (Subtype 0x12) Request 32-bit CRC Calculation
CFSC SC Adv
The 32-bit CRC Request is a message that informs the device to perform a 32-bit CRC calculation over
portions of the code space. The purpose of this is to verify the integrity of the code space. It could also
be used to verify the installed application and\or variant has not been updated.

This command should only be sent to the device after power up, and not during document or note table
processing.
This request also does not persist across power ups so if the device was restarted after a request was
posted, but before the results were retrieved, then the host needs to re-issue this command.
The Host shall tell the device to begin the 32-bit CRC calculation by sending the following message:
Host Request 32-bit CRC

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x12 0X7n 0x12 nn nn nn

7 8 15 16 17
Segment Seed.0 Seed.7 ETX CHK
ooo
0x0n 0x0n 0x0n 0x03 zz

The Segment defines the portion of code space over which it is requested to perform the CRC
calculation.
 0x00: Reserved
 0x01: Application code space
 0x02: Variant code space
 0x03: Combined (application and variant) code space.

The four seed values contain the data in the lower nibble. For example, the seed value 0x1234ABCD is
encoded as 8 bytes {0x01, 0x02, 0x03, 0x04, 0x0A, 0x0B, 0x0C, 0x0D}.

There is no ability to change the starting address; the device begins all calculations at the beginning of
the appropriate code space.

The device will either ACK or NAK the request with the following message:
Device Request 32-bit CRC Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x12 nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

Revision G5 20105-002850209-PS Page 115

The device might NAK the request if not in idle state or if it is already in the middle of handling another
CRC request.

If the device ACKs the request, it will begin running the CRC calculation. Since this is such a processor
intensive function, it can take several seconds for the device to respond with a result. The host should
continue to poll the device with a standard omnibus command until it responds with the CRC results
described in the following message:
Device 32-bit CRC Results

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x14 0X7n 0x12 nn nn Nn nn nn nn

10 17 18 19
Result.0 Result.7 ETX CHK
ooo
0x0n 0x0n 0x03 zz

The CRC results come back in the form 8 byte values. Each byte contains data in only the last nibble.
Result is transferred MSB first (Big Endian).

7.5.13 (Subtype 0x13) Request Recycler Note Table

SCR
The purpose of this message is to allow the host to discover the note values that are recyclable by the
SCR. The values returned are constrained by the values of notes the SCR variant is capable of accepting
and also the configuration data stored by the SCR.

The indices in this table are and the associated note values can be altered by changing the configuration
of the unit so these entries should always be queried upon connection to the device (after power up is
complete).

Warning The device is not able to report accurate information about the note table until the
inventory sequence has completed. Therefore, any note table requests during any of the following
situations will be NAK'd.
 Power up sequence
 Cashbox is removed or the transport path is open
 Inventory sequence is running (ex. after a cashbox is inserted)
 Unknown documents detected
 Missing note report ready. See (Subtype 0x1A) Missing Note Report.

Host Recycler Note Table Command

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 Index ETX CHK
Value 0x02 0x0A 0X7n 0x13 nn nn nn ii 0x03 zz

Revision G5 20105-002850209-PS Page 116

The index value specifies the index of the note table and uses 1-based indexing (value 1 is the first note
table entry).

The device will respond to the request with a full description of the banknote at that location
Device Recycler Note Table Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x1A 0X7n 0x13 nn nn nn nn nn nn

10 11 23 24 25
Ext Data 0 Ext Data 1 ooo Ext Data 13 ETX CHK
nn nn nn 0x03 zz

The device will reply with 14 additional bytes of data that describe the note value associated with the
index requested. The following table outlines how to decode the extended data bytes.
Field Byte Field Description Sample Value
Offset (2000 Yen Note)
Recycler 0..1 Recycler status bit field for this denomination. 0x03
Status Please refer to section 7.5.15.1 for further
information.
Current Fill 2 The number of notes of this type in the recycler. 0x78
Count
Current 3 The number of notes of this type that the recycler 0x78
Capacity can hold in the current configuration.
Index 4 Index into the recycler note set 0x05
ISO Code 5..7 A three character ASCII currency code. See “JPY”
ISO_4217 at the Wikipedia for details.
Base Value 8..10 A three character ASCII coded decimal value “002”
Sign 11 An ASCII coded sign value for the Exponent. This “+”
field is either a “+” or a “-“
Exponent 12..13 ASCII coded decimal value for the power of ten “03”
that the base is to either be multiplied by (if Sign
is “+”) or divided by (if Sign is “-“)
In this example: Banknote Value = 002 x 10+03 = 2 x 1000 = ¥2000 is enabled for recycling and the
capacity has been reached (full).

Warning When an index is requested for which no note value is assigned, the extended data will be
all null values (0x00). The first occurrence of this null response indicates the end of the note table (as
you step up from index 1 to n for each query). Please note that index 0 will also respond with null values
as it is not supported (index starts at 1).

Warning The current capacity should not be used to determine when the recycler is full as possible
differences in distances between the notes could result in plus/minus a few notes. Instead, the host
should always refer to the recycler status 'Full' bit when determining if the recycler system is full.

Revision G5 20105-002850209-PS Page 117

7.5.14 (Subtype 0x14) Set Recycler Note Value Enables
SCR
This command is used to control the recycling of banknotes on a note value basis. This command will
only be processed by the device is the device is currently idle otherwise it is NAK'd. To ensure the
device is idle, the host should disable the device prior to sending this command.
Host Set Recycler Note Value Enables Command

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x0B 0X7n 0x14 nn nn nn

7 8 9 10
Enables Reserved ETX CHK
nn 0x00 0x03 zz

The extended bytes are used in the following fashion to enable the specified denominations:
Byte Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Enabled Bill Value 7 Bill Value 6 Bill Value 5 Bill Value 4 Bill Value 3 Bill Value 2 Bill Value 1
Reserved Reserved for future use.

The number of denominations that can be recycled concurrently can be discovered through the device
capabilities bit (see 7.4.14). To disable recycling, send this command with all the enabled bits cleared.

Device Set Recycler Note Value Enables Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x14 nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

Warning Setting an unsupported number of denominations or attempting to disable recycling for a

denomination with notes currently in the recycler will result in the device NAKing the command.

Revision G5 20105-002850209-PS Page 118

7.5.15 (Subtype 0x15) Recycler Omnibus Command/Reply
SCR
This command represents the main polling command for the SCR device. The command contains all of
the functionality of the standard omnibus command with the additional support for the recycler
controls. One additional byte has been added to the host command and governs the operations of the
recycler device.

Host Recycler Note Processing Command

Byte 0 1 2 3 4 5 6 7 8 9
Name Recycler
STX LEN CTRL Sub Type Data 0 Data 1 Data 2 ETX CHK
Control
Value 0x02 0x0A 0X7n 0x15 nn nn nn nn 0x03 zz

Recycler Control Byte

Bit # Name Value Description
Stack to Single Note Escrow Only Stack the banknote to recycler (One of
0 1
Recycler the recyclers must be configured for the banknote at escrow).
Stack to MULTI Note Escrow Only Stack the document to the temporary
1
Escrow escrow storage location.
Store MULTI Note Escrow Only Store (Commit) all documents currently
2 Escrowed in escrow storage to their respective final destinations. The device will
Documents enter the storing state.
Return
MULTI Note Escrow Only Return all documents currently in the
3 Escrowed
Documents escrow storage location.

4-6 Reserved

Warning The three command bits for controlling document movement: Stack (data 1, bit 5), Return
(data 1, bit 6) and the new Stack to Recycler (recycler control, bit 0) are mutually exclusive. If two or
more of these command bits are set, the device will NAK the command and perform no action with the
document.

Warning If the host issues a "stack to recycler" for a document that is not enabled for recycling, the
device will NAK the request and perform no action with the document.

Revision G5 20105-002850209-PS Page 119

While in a recycling enabled session (host is using this subtype 0x15 command) with extended note
mode enabled, all device responses that would normally be a type 7 subtype 0x02 (extended note reply)
are replaced with a more detailed Recycler omnibus reply as detailed below:
Device Recycler Note Processing Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x20 0X7n 0x15 nn nn nn nn nn nn

10 11 29 30 31
Ext Data 0 Ext Data 1 ooo Ext Data 19 ETX CHK
nn nn nn 0x03 zz

Please refer the table below for a full description on how to decode the extended data bytes that are
returned.
Field Byte Field Description Sample Value
Offset (2000 Yen Note)
Recycler 0..1 Recycler status bit field for this denomination. 0x05
Status Please refer to section 7.5.15.1 for further
information.
Index 2 Not used for subytype 0x15 responses. Always 0x00
0x00
ISO Code 3..5 A three character ASCII currency code. See “JPY”
ISO_4217 at the Wikipedia for details.
Base Value 6..8 A three character ASCII coded decimal value “002”
Sign 9 An ASCII coded sign value for the Exponent. This “+”
field is either a “+” or a “-“
Exponent 10..11 ASCII coded decimal value for the power of ten “03”
that the base is to either be multiplied by (if Sign
is “+”) or divided by (if Sign is “-“)
Orientation 12 A single character binary field that encodes the 0x00
orientation of the bank note.
0x00 = Right Edge, Face Up
0x01 = Right Edge, Face Down
0x02 = Left Edge, Face Up
0x03 = Left Edge, Face Down
Note: In general, this field is only correct if the
Extended orientation bit is set in device
capabilities map. See section 7.4.14.
Type 13 An ASCII letter that documents the note type. “A”
This corresponds to the data in the variant
identity card.
Series 14 An ASCII letter that documents the note series. “A”
This corresponds to the data in the variant
identity card.
<Table Continues on Next Page>

Revision G5 20105-002850209-PS Page 120

 <Continuation from Previous Page>
Field Byte Field Description Sample Value
Offset (2000 Yen Note)
Compatibility 15 An ASCII letter that documents the revision of the “B”
recognition core used. This corresponds to the
data in the variant identity card.
Version 16 An ASCII letter that documents the version of the “A”
note’s recognition criteria. This corresponds to
the data in the variant identity card.
Reserved 17..19 3 bytes reserved for future use. 0x00
In this example: Banknote Value = 002 x 10+03 = 2 x 1000 = ¥2000 fed right edge first, face up. Recycling
is enabled and the recycler is currently empty.

7.5.15.1 Recycler Status Byte Definition

The recycler status bytes are used in the following commands:
 (Subtype 0x13) Request Recycler Note Table
 (Subtype 0x15) Recycler Omnibus Command/Reply - Response only.
 (Subtype 0x1B) Request Physical Recycler Status - Only uses the first status byte (0).
The two byte sequence can be decoded as follows:
Recycler Status Byte 0
Bit # Name Value Description
0 Recycling 0 This document type (value) is not enabled for recycling.
Enabled 1 This document type (value) is enabled for recycling.
1 Recycler Full 0 Recycler can store additional documents for this document type
(value).
1 Recycler is at capacity (full) for this document type (value).
2 Recycler 0 Recycler is not empty for this document type (value).
Empty 1 Recycler is empty for this document type (value).
3 Escrow to 1 Single Note Escrow Only Document is being sent from escrow to
Recycler recycler. This is a transient state so it will be reported while document
is being moved. Guaranteed to be set during the stacked bit.
4 Recycler to 1 Document is being sent from Recycler to Cashbox (Floating down).
Cashbox This is a transient state so it will be reported while document is being
moved. Guaranteed to be set during the stacked bit.
5 Recycler to 1 Document is being sent from Recycler to Customer (Dispensing). This
Customer is a transient state so it will be reported while document is being
moved. Guaranteed to be set during the dispensed and retrieved
events (see recycler status byte 1).
6 Escrow to 1 MULTI Note Escrow Only Document is being sent from the
Escrow standard escrow position to the escrow storage state. This is a
Storage transient state that will be reported while a document is being
moved. Guaranteed to be set during the stacked bit.

Revision G5 20105-002850209-PS Page 121

Recycler Status Byte 1
Bit # Name Value Description
0 Dispensed 1 A document being sent from the recycler to the customer has crossed
the secure threshold of the recycler cash unit. Credit should be
adjusted accordingly (i.e. debited from the customer balance). Sent
once per document dispensed.
1 Retrieved 1 A document being sent from the recycler to the customer has been
retrieved by the customer.
2 Unknown 1 Recycler contains documents for which it has no record of type or
Documents value. The host should query the physical recycler status and move
Detected these documents to the cash box to resume normal recycler
operation. The device is disabled until the situation is corrected.
3 Missing Note 1 Notes have been removed from inventory unexpectedly. The device
Report is ready to inform the host about the missing notes. The device is
Ready disabled until the host queries the missing note report (see Section
7.5.20).
4 Escrow 1 MULTI Note Escrow Only The device has finalized an escrow
Session session completely and is ready for the host to query the report. The
Summary device is silently disabled until the full report is processed. (see
Report Section 7.5.24)
Ready
5 Escrow 1 MULTI Note Escrow Only The device has one or more documents
Documents in the temporary escrow session.
in the
System
6 Escrow 1 MULTI Note Escrow Only The temporary escrow storage location
Storage Full is full and the host must process the session (commit or return). The
"Escrow Documents in the System" bit will always be set if this bit is
set. The device is silently disabled until the documents are processed.

Revision G5 20105-002850209-PS Page 122

7.5.16 (Subtype 0x16) Dispense Bills
SCR
This command is issued by the host to initiate a cash dispense (moving cash from Recycler to Customer).
The host passes the index of the desired note value to be dispensed and a count of the number of notes
to be dispensed in this action.
Host Dispense Bills Command

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x0B 0X7n 0x16 nn nn nn

7 8 9 10
Index Count ETX CHK
nn nn 0x03 zz

Index field represents the recycler note value index and is 1-based. Example: "1" equals the first entry in
the recycler note table as was retrieved with command (Subtype 0x13) Request Recycler Note Table.
Warning Two special values exist to support the host when unknown documents are detected. Index
value 0x7F represents unknown docs on recycler 1 while 0x7E represents unknown documents on
recycler 2.

Count field is the number of banknotes to dispense. A special value 0x7F can be used to mean all
banknotes.

The device will respond with a recycler omnibus reply to this command.

7.5.17 (Subtype 0x17) Cancel Dispense/Float

SCR
This command allows the host to cancel an ongoing cash dispense or float activity. Upon receiving this
command, the device will finish dispensing/floating the current note but will not process any queued up
notes.

Host Cancel Dispense/Float Command

Byte 0 1 2 3 4 5 6 7 8
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x09 0X7n 0x17 nn nn nn 0x03 zz

The device will respond with a recycler omnibus reply to this command.

Revision G5 20105-002850209-PS Page 123

7.5.18 (Subtype 0x18) Float Bills
SCR
This command is issued by the host to initiate a cash float-down (moving cash from Recycler to Cash
Box). The host passes the index of the desired note value to be moved and a count of the number of
notes to be moved in this action.
Host Float Bills Command

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x0B 0X7n 0x18 nn nn nn

7 8 9 10
Index Count ETX CHK
nn nn 0x03 zz

Index field represents the recycler note value index and is 1-based. Example: "1" equals the first entry in
the recycler note table as was retrieved with command (Subtype 0x13) Request Recycler Note Table.
Warning Two special values exist to support the host when unknown documents are detected. Index
value 0x7F represents unknown docs on recycler 1 while 0x7E represents unknown documents on
recycler 2.

Count field is the number of banknotes to dispense. A special value 0x7F can be used to mean all
banknotes.

The device will respond with a recycler omnibus reply to this command.

7.5.19 (Subtype 0x19) Last Cash Movement Summary Report

SCR
This command is issued by the host to request the Last Cash Movement Session Summary Report from
the device. A cash movement is defined as either a dispense or a float so it does not include standard
user feeding or rejections. The values will persist until the start of the next cash movement session. The
purpose of the command is to provide the host with an accurate description of recycler movements.

Recommended While it is permitted to issue this command during a note movement session, for the
most accurate information it is recommended that this command is sent after the movements have
completed.

Warning The device will NAK the command during power up since the system need to perform
inventory calculations to ensure all documents are reported correctly.

Host Last Cash Movement Summary Request

Byte 0 1 2 3 4 5 6 7 8
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x09 0X7n 0x19 nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 124

Device Last Cash Movement Summary Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x1D 0X7n 0x19 nn nn nn nn nn nn

10 11 26 27 28
Ext Data 0 Ext Data 1 ooo Ext Data 16 ETX CHK
nn nn nn 0x03 zz

The extended data fields can be parsed in the following manner:

Field Byte Field Description
Offset
Session type 0 This value gives the source and destination for the cash that was
moved in the last session.
Value Description
0x00 No Movement Record
0x01 Recycler to Customer.
0x02 Recycler to Cashbox
All Other Reserved for future use
Termination 1 This value indicates the condition that terminated the cash
Condition movement session.
Value Description
0x00 Move Successful.
0x01 Note Jam.
0x02 Insufficient Inventory. (source empty)
0x03 Insufficient Storage. (destination full)
0x04 Cancelled by Host.
0x05 Cheat Detected.
0x06 Power Failed
0x07 No Documents to Move
0x08 Movement In Progress
0x09 System Out Of Service
0x0A Inventory Error.
All others Reserved for future use.
Recycler Unknown 2 The number of unknown type documents that were moved in the
Document count last cash movement session.
Recycler Note Value 3 The number of value index 1 type notes that were moved in the
Index 1 count last cash movement session.
ooo ooo ooo
Recycler Note Value 9 The number of value index 7 type notes that were moved in the
Index 7 count last cash movement session.
Reserved 10-16 Reserved for future use.

Revision G5 20105-002850209-PS Page 125

7.5.19.1 Additional termination condition descriptions:
Most of the termination conditions are self-explanatory but here are some further descriptions from
some of the fields.
 No Documents to Move - The host has requested note movement with a count of 0.
 Movement In Progress - This is a transient state that is issued if the hosts requests the last cash
movement summary while the last movement request is still be executed.
 System Out Of Service - This termination condition will be set if an out of service (or out of
order) condition occurs during a note movement (such as the cashbox being removed).
 Inventory Error - An unexpected error with inventory occurred during the note movement.
Device will report either an "unexpected document" or "missing note report" flag.

7.5.20 (Subtype 0x1A) Missing Note Report

SCR
This command is issued by the host to request the Missing Note Report from the device. The values the
device replies with are generated when the device powers up and estimates the current note inventory
in the recyclers compared to the previously recorded note inventory. If the system detects a
discrepancy, the device will not enable and will force the host to process the missing note report. The
device will inform the host that notes are missing through the "Missing Note Report Ready" bit field of
the recycler status byte (see section 7.5.15.1). The subtype 0x1A command allows the host to query the
missing notes and act appropriately. Once this command is issued, the device will re-enable.

Host Missing Note Report Request

Byte 0 1 2 3 4 5 6 7 8
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x09 0X7n 0x1A nn nn nn 0x03 zz

Device Missing Note Report Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x1A 0X7n 0x1A nn nn nn nn nn nn

10 11 23 24 25
Ext Data 0 Ext Data 1 ooo Ext Data 13 ETX CHK
nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 126

Refer to the following table for a full description of how to decode the extended data bytes:
Field Byte Offset Field Description
Recycler Note 0 The number of machine inventoried notes of recycler value
Value Index 1 index 1 type that were unaccounted for during power up(s).
disappeared note
count
Recycler Note 1 The number of machine inventoried notes of recycler value
Value Index 2 index 2 type that were unaccounted for during power up(s).
disappeared note
count
ooo ooo ooo
Recycler Note 6 The number of machine inventoried notes of recycler value
Value Index 7 index 7 type that were unaccounted for during power up(s).
disappeared note
count
Reserved 7-13 Reserved for future use.

7.5.21 (Subtype 0x1B) Request Physical Recycler Status

SCR
The purpose of this message is to allow the host to discover the current status of the physical cash units
that make up the logical recycling unit. The index provided by the host references the cash unit being
queried. Cash units are numbered from the upper most position to the lower most and begin at index
one. I.e. in a two drum recycling unit index one will refer to the upper most drum in the recycler and
index 2 will refer to the lower most drum.

Host Request Physical Recycler Status Command

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 Index ETX CHK
Value 0x02 0x0A 0X7n 0x1B nn nn nn ii 0x03 zz

The index value specifies the index of the physical recycler and uses 1-based indexing (value 1 is the
uppermost recycler).

Device Physical Recycler Status Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x29 0X7n 0x1B nn nn nn nn nn nn

10 11 38 39 40
Ext Data 0 Ext Data 1 ooo Ext Data 28 ETX CHK
nn nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 127

Refer to the following table for a full description of how to decode the extended data bytes:
Field Byte Field Description
Offset
Unit Status 0 Bit # Name Description
0 Unit Present This bit is set if there is a cash unit
at this position.
1 Unknown This bit is set when documents of
Document(s) unknown value are found in the
cash unit.
2 Fault Cash Unit has encountered a
problem and is out of service.
Intervention is required.
3 Missing Note(s) This bit is set when the system has
detected that one or more notes
are missing according to the
internal inventory counts.
4-6 Reserved Reserved for future use.

Recycler Note Value 1 The status of recycler value index 1 type notes for this physical
Index 1 status cash unit. See 7.5.15.1 for status details.
Recycler Note Value 2 The number of recycler value index 1 type notes for this physical
Index 1 count cash unit.
Recycler Note Value 3 The status of recycler value index 2 type notes for this physical
Index 2 status cash unit. See 7.5.15.1 for status details.
Recycler Note Value 4 The number of recycler value index 2 type notes for this physical
Index 2 count cash unit.
ooo ooo ooo
Recycler Note Value 13 The status of recycler value index 7 type notes for this physical
Index 7 status cash unit. See 7.5.15.1 for status details.
Recycler Note Value 14 The number of recycler value index 7 type notes for this physical
Index 7 count cash unit.
Reserved 15-28 Reserved for future use.

Revision G5 20105-002850209-PS Page 128

7.5.22 (Subtype 0x1C) RFID Data Request
SC Adv Retail Only
The RFID Data Request command allows the host to perform read/write operations to the RFID tag that
is located on the cassette. This feature is only available for the systems that are configured with the
Retail Easitrax hardware which includes the Retail Easitrax Antenna Board. While not required, this
feature is used in conjunction with additional PC software that interacts with the cassette once it has
been removed from the device in order to retrieve the data and provide storage and reporting as
necessary.

This new command structure provides the host with access to a section of non-volatile memory that will
be stored on the cassette. There are no restrictions to the use of these fields and the data stored using
this command will not impact the normal operations of the device. This command also provides the
ability to directly read the RFID tag's unique serial number.

For the following command structures, there are 3 important sections: the Control Byte, the Block
Location and the RFID Data Bytes.

7.5.22.1 Control Byte

This byte defines several important pieces of information. The first bit (least significant) defines the
operation type (read vs. write). The next 3 bits are used by the device response message to give the host
the status of the operation. If the device fails to perform an operation, the status byte will reflect this
error condition.
Control Byte Layout
Bit Name Value Description When Valid
#
0 Read Operation.
0 Operation All Commands
1 Write Operation.
Status OK. (No Errors). This is also the
000
setting for all Host -> Device commands
001 No RFID tag is detected
010 Failed Read
Device replies only. Not used
1-3 Status 011 Failed Write
for the Host command.
100 Easitrax Disabled
101 <reserved>
110 <reserved>
111 <reserved>
4-6 <reserved> N/A

Revision G5 20105-002850209-PS Page 129

7.5.22.2 Block Location
The block location field is used for both read and write operations to specify the target block number
and is present in both host and device messages. It is provided as feedback in the device message as a
confirmation of the data that was read or written. The acceptable values for this field are defined here:
Hex Value Block Permissions Description
0x00 -> 0x3F Read / Write Targets the 64 Retail Customer Data Blocks
0x40 -> 0x7D None Unallocated Space. No access.
0x7E Read Only Identifier for the RFID Tag’s Age block
0x7F Read Only Identifier for the RFID Tag's unique serial number block

The tag age value represents the estimated number of writes that have been performed on the tag by
MEI specific write requests. This value will not reflect the RFID Writes requested by the customer. The
returned age value can be used to identify the remaining life of the RFID tag which is specified for a
minimum 100,000 write operations.

7.5.22.3 RFID Data Bytes

This field is 32 EBDS bytes long and only applicable for the host write command and the device read
command. It is omitted for the host read command and the device write command. The RFID Byte fields
use only the lower nibble of the EBDS byte to send data. For example, if the first byte of the RFID block
contains 0xAF, it will be encoded as 2 bytes when transmitted across EBDS = {0x0A, 0x0F}. This is why
the field contains 32 data bytes to represent the 16 bytes of RFID tag memory.

Warning If the host requests a read operation and the device encounters an error condition, these
data bytes will be omitted in the device’s response. The host should reference the Control Byte status
bits for the error condition reason.

The Host has two options for sending this command. The first option is the read command which only
specifies the Control Byte and the Block Location value.
Host RFID Read Request Command

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x0B 0X7n 0x1C nn nn nn

7 8 9 10
Control Block
ETX CHK
Byte Location
nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 130

The other command that is available to the host is the write command. This command requires the
Control Byte, Block Location and 32 RFID Data Bytes.
Host RFID Write Request Command

Byte 0 1 2 3 4 5 6
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2
Value 0x02 0x2B 0X7n 0x1C nn nn nn

7 8 9 40 41 42
Control Block RFID Byte RFID Byte
ETX CHK
Byte Location 0 ooo 31
nn nn 0x0n 0x0n 0x03 zz

While fast (usually on the order of 300 - 500 milliseconds), the read / write operations to the RFID tag do
not happen immediately. This means that the device will respond back to the host request at a later
time. To ensure the reliable communications, the device will either ACK or NAK all read / write
commands when they are received. This response will not contain the requested data or status but it
will let the host know that the device is working on the RFID request. This message structure is shown
below:
Device RFID Request Acknowledgment

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x1C nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

If for any reason the device is unable to honor the host request, a NAK will be sent to the host. The
device will NAK the host in the following situations:
 Device is in power up mode. The RFID is not ready for communications until the power up
procedure has completed.
 An invalid block location was specified by the host.
 There is a current transaction underway. If a document has been inserted and is being
processed, the device will NAK all RFID requests.
 Device is in calibration mode.
 Cashbox is removed
 If there is another pending RFID request. The host must wait until the other RFID request has
completed before sending another request.
 If the device is not configured for the RETAIL environment, the device will always NAK these
commands.

Revision G5 20105-002850209-PS Page 131

Warning When a cashbox is first inserted, the device must perform an initialization sequence with the
RFID tag. During the initialization sequence, which can last several seconds, the device will not be able to
support any RFID tag requests. The device will NAK these requests until the startup sequence is
complete.

If the device ACKs the original request, it will process that request and issue a response once complete.
This response will be issued as a reply to a general host omnibus command. Both the Control Byte and
the Block Location will be present for the response. If the original request was for a read, then the
device response will contain 32 additional bytes of the RFID Data:
Device RFID Read Request Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name Sub
STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Type
Value 0x02 0x2E 0X7n 0x1C nn nn nn nn nn nn

10 11 12 43 44 45
RFID RFID
Control Block
Byte Byte ETX CHK
Byte Location ooo
0 31
nn nn 0x0n 0x0n 0x03 zz

The results are posted back in a similar format as the host command. The RFID Data bytes are sent in the
lower nibble of each EBDS byte. If the host requested the RFID Tag's serial number or the Estimated Tag
Age (by issuing a read with block location = 0x7F or 0x7E) then the returned value will be stored in the
first 8 EBDS RFID Data bytes and the rest of the EBDS RFID Data bytes will be 0x00. This is because these
numbers are stored in a special data block as a 32 bit integer and padded with 0x00 values.

If the original request was for a write command, the RFID Data fields will be omitted from the response
as shown here:
Device RFID Write Request Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name Sub
STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Type
Value 0x02 0x0E 0X7n 0x1C nn nn nn nn nn nn

10 11 12 13
Control Block
ETX CHK
Byte Location
nn nn 0x03 zz

Revision G5 20105-002850209-PS Page 132

Recommended
Lifetime data writes are limited. Each block is specified to work for a minimum of 100,000 writes (but
not guaranteed). If the host must perform an excessive number of write operations, some form of “wear
leveling” should be implemented. The idea is that the host could step through several the available
blocks in order to spread out the writes across the memory map. Be advised that the Tag Age value that
is available does not include writes to the customer specific region.

7.5.23 (Subtype 0x1D) Clear Audit Data Request

SC Adv SCR
The Clear Audit Data Request command allows the host to perform a clear of the audit data on the SC
Advanced. This command will clear all audit information except for the lifetime audit section; these will
be protected and will not be cleared by this command.

The host command to initiate the clear audit process is as follows:

Host Clear Audit Request

Byte 0 1 2 3 4 5 6 7 8
Name STX LEN CTRL Subtype Data 0 Data 1 Data 2 ETX CHK
Value 0x02 0x09 0X7n 0x1D nn nn nn 0x03 zz

Since the command needs to clear large sections of memory, the command may take a few seconds to
complete. The device will inform the host that the operation is complete by posting back a completion
response at later time. However, the device will post an acknowledgement of the host request
immediately as follows:
Device Clear Audit Data Request Acknowledgment

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x1D nn nn nn nn nn nn

10 11 12
ACK/NAK ETX CHK
0x01/00 0x03 zz

If for any reason the device is unable to honor the host request, a NAK will be sent to the host
(represented by 0x00 for byte 10). The device will NAK the host in the following situations:
 Device is in power up mode.
 A current transaction underway. If a document has been inserted and is being processed, the
device will NAK all Clear Audit Data Request
 Device is in calibration mode.
 The device is currently servicing another type 7 message request.

If the device ACKs the original request, it will process that request and issue a completion response. This
response will be issued as a reply to a general host omnibus command. The message will contain a data
byte that will tell the host if the operation passed or failed.

Revision G5 20105-002850209-PS Page 133

Device Clear Audit Data Request Results Reply

Byte 0 1 2 3 4 5 6 7 8 9
Name STX LEN CTRL Sub Type Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Value 0x02 0x0D 0X7n 0x1D nn nn nn nn nn nn

10 11 12
Pass/Fail ETX CHK
0x11/10 0x03 zz

7.5.24 (Subtype 0x20) Escrow Session Summary Report

SCR
The escrow session summary report is a way for the device to share an accurate description of multiple
documents that were recently (or currently being) processed. While most instances will only need a
single message, the structure includes the ability to send and receive multiple messages to support
instances where many different classes of documents must be reported.

This command uses a similar mechanism to the "Missing Note Report" where the device will not enable
itself until the report has been fully processed by the host. The device will inform the host that an
escrow session has been completed by setting the "Escrow Session Summary Report Ready" bit field of
the recycler status byte (see section 7.5.15.1). This bit will be set in one of the following conditions:

 All documents at escrow have completed the storing process and the device is now ready to
begin a new transaction session.
 The device has encountered a jam or other out of service situation during the storing of escrow
documents. The host must process the intermediate report and correct the out of service
condition. Once the rest of the documents are processed, the host should expect to receive
another escrow session summary report finalizing the session.

The host specifies the report index during its request.

Host Escrow Session Summary Request

Byte 0 1 2 3 4 5 6 7 8 9
Sub Report
Name STX LEN CTRL Data 0 Data 1 Data 2 ETX CHK
Type Index
Value 0x02 0x09 0X7n 0x20 nn nn nn nn 0x03 zz

Report Index starts at '1' and increments if additional reports are required (as defined by the
device's response).

Revision G5 20105-002850209-PS Page 134

Device Escrow Session Summary Reply

Byte 0 1 2 3 4 5 6 7 8 9
Sub
Name STX LEN CTRL Data 0 Data 1 Data 2 Data 3 Data 4 Data 5
Type
Value 0x02 LL 0X7n 0x20 nn nn nn nn nn nn

10 11 12
Report Index End of Report ? Status
nn 0x00 or 0x01 0x00 to 0x06

13 14 15 16 17 18
Banknote
# at Escrow # to Cassette # to Recycler # Missing <reserved>
Index
nn nn nn nn nn 0x00

Structure for bytes 13-18 repeat for up to a maximum of 19 entries

LL-2 LL-1
ETX CHK
0x03 zz

A maximum of 19 entries can be reported in a single message so if additional entries must be reported,
they will be part of the next message (see the Report Index below).

7.5.24.1 Report Index (Byte 10)

The report index will always match the value sent from the host for the same field. The host should
initiate the report session with a value of '1'.

7.5.24.2 End of Report (Byte 11 )

True ('1') when there are no further entries to report. False ('0') indicates that the host needs to request
the next report with the next index value.

Revision G5 20105-002850209-PS Page 135

7.5.24.3 Status Byte Values (Byte 12)
Value Name Description
0x00 STORING_COMPLETE The device has successfully completed the escrow storing
procedure.
0x01 STORING_IN_PROGRESS The device is currently storing the escrowed documents.
The counts will be accurate at the time in which the request
was received. Any document in flight at the time will be
reported as "at escrow."
0x02 OUT_OF_SERVICE The device has halted escrow storing procedure for one of
the following reasons.
 Cassette full during escrow movements with
pending documents destined for cassette
 A document becomes jammed. Jammed document
will be reported as currently in escrow.
 Cassette removed or transport opened while
storing escrowed documents. Documents in flight
will be counted as "at escrow."
Note - The device will only prompt for an escrow session
summary report if the escrowed documents were in the
middle of a storing procedure. Entering an out of service
state while idle (in an escrow session) will not prompt the
generation of a report but the device will respond with this
value if a report is requested by the host.
Additionally, if the cassette goes full on the final escrow
document (no more pending for cassette) this report event
will not be raised. Instead, the session status will be
STORING_COMPLETE.
0x03 MISSING_DOCUMENTS The device came back into service and has detected that
one or more escrowed documents are missing.
0x04 NOTHING_TO_REPORT Device is not currently in an escrow session.
0x05 OUT_OF_SEQUENCE The incorrect report index has been requested. Indexing
must start at 1 for each set of reports and increment by a
single value until the 'End of Report' value is set.
0x06 MULTI_NOTE_ESCROW The device is not configured for multi-note escrow mode.
_NOT_CONFIGURED

Revision G5 20105-002850209-PS Page 136

7.5.24.4 Entry Structure (Bytes 13-18 + )
The entry structure contains details on the banknotes processed. The documents are grouped by
banknote index value which maps directly to the values returned from the banknote table as seen in
section 7.5.2 - (Subtype 0x02) Extended Note Specification Message.
Name Description
Banknote Index The banknote index for the processed document.
# at Escrow Number of documents currently in the temporary escrow storage area. This
value is also used to represent any documents currently in flight or jammed.
# to Cassette Number of escrowed documents that were successfully stacked to the
cassette.
# to Recycler Number of escrowed documents that were successfully stored on one of the
recyclers.
# Missing Number of escrowed documents that went missing unexpectedly.
<reserved> Reserved for future protocol expansion.

Revision G5 20105-002850209-PS Page 137

8 Appendix A – Protocol Examples
This appendix will provide detailed examples of EBDS behavior in certain situations. There will be
examples in the form of host commands and the device’s replies. Repeated messages (due to polling)
may be omitted for the sake of brevity. The host and device messages will be shown in Hex value.

8.1 Disabling the Device

This section shows the proper way to disable a device so it will not process any documents. Although
these examples are for a device that is operating in the extended note mode, the concept applies for a
device running in non-extended note mode as well.

In the following sections, barcode acceptance is set to false in messages. Extended coupon mode should
also be disabled if applicable. See section 7.1.1.3 for more details on this coupon bit.

8.1.1 Normal Situation

In this situation, the device is in the idle state (not processing any document).
Msg # Host Message Device Response Description
1 02 08 10 7F 1C 12 03 69 Base line poll message.
Denoms enabled.
Barcode acceptance enabled.
1B 02 0B 20 01 10 00 10 54 10 03 6E Device is IDLE
2 02 08 11 00 1C 10 03 15 Denoms disabled.
Barcode acceptance disabled.
2B 02 0B 21 01 10 00 10 54 10 03 6F Device is IDLE

In this case, the device responded back to the disable command by reporting that it is in the idle state.
At this point, the host can safely assume the device is disabled and will not draw in any documents.

Revision G5 20105-002850209-PS Page 138

8.1.2 Processing a Document
In this example, the device will be disabled after it has started to process a document. In this condition,
the device will not automatically return the document that is being processed. It is up to the host to
ensure that any document that was inserted before disabling the device is processed correctly. The
same “disable” command shall continue to be set by the host throughout this process.
Msg # Host Message Device Response Description
1 02 08 10 7F 1C 12 03 69 Base line poll message.
Denoms enabled.
Barcode acceptance enabled.
1B 02 0B 20 01 10 00 10 54 10 03 6E Device is IDLE

At this point, the customer inserts a banknote

2 02 08 11 00 1C 10 03 15 Denoms disabled.
Barcode acceptance disabled.
2B 02 0B 21 02 10 00 10 54 10 03 6C Device is ACCEPTING
3 02 08 10 00 1C 10 03 14
3B 02 1E 70 02 04 10 00 10 54 10 00 Document at Escrow. (It is an
55 53 44 30 30 31 2B 30 30 03 43 extended note message saying
41 42 45 00 00 00 03 72 there is a $1 USD)
4 02 08 11 00 5C 10 03 55 Host issues “Return”
4B 02 1E 71 02 04 10 00 10 54 10 00
55 53 44 30 30 31 2B 30 30 03 43
41 42 45 00 00 00 03 73
5 02 08 10 00 1C 10 03 14
5B 02 0B 20 20 10 00 10 54 10 03 4F Device is RETURNING
6 02 08 11 00 1C 10 03 15
6B 02 0B 21 41 10 00 10 54 10 03 2F Device is IDLE with RETURNED
bit set.
7 02 08 10 00 1C 10 03 14
7B 02 0B 20 01 10 00 10 54 10 03 6E Device is IDLE

In the first response (1B), the device is idle so the host will attempt to disable the device. However, in
response to the disabling (2), the device responds with accepting (2B). At this point, the host must be
prepared to handle any documents that the device reports. In this case, when the device reported the
$1 USD at escrow (3B), the host issued the return command (4). The host can safely assume the device is
disabled once the idle state is returned in the final message (7B).

Revision G5 20105-002850209-PS Page 139

8.1.3 Processing a Document in Non-Escrow Mode
Deprecated If this mode is implemented, the host must be prepared to issue credit for any stacked
document after the device has been disabled.
Msg # Host Message Device Response Description
1 02 08 10 7F 0C 10 03 7B Base line poll message.
Denoms enabled.
Barcode acceptance enabled.
1B 02 0B 20 01 10 00 10 54 10 03 6E Device is IDLE

At this point, the customer inserts a banknote

2 02 08 11 00 0C 10 03 05 Denoms disabled.
Barcode acceptance disabled.
2B 02 0B 21 02 10 00 10 54 10 03 6C Device is ACCEPTING
3 02 08 10 00 0C 10 03 04
3B 02 0B 20 08 10 00 10 54 10 03 67 Device is STACKING
4 02 08 11 00 0C 10 03 05
4B 02 1E 71 02 11 10 00 10 54 10 00 Device STACKED a $1 USD
55 53 44 30 30 31 2B 30 30 01 43 note.
41 42 45 00 00 00 03 64
5 02 08 10 00 0C 10 03 04
5B 02 0B 20 01 10 00 10 54 10 03 6E Device is IDLE

Since the device is operating in non-escrow mode, it will automatically stack the note that was inserted
before the host disabled the device. The host can safely assume the device is disabled once the idle
state is returned in the final message (5B).

Revision G5 20105-002850209-PS Page 140

8.2 Requesting the Note Table
This section shows the recommended way to request the note table from the device. This assumes the
device supports extended note mode.
Msg # Host Message Device Response Description
1 02 08 10 7F 1C 12 03 69 Base line poll message.
Denoms enabled.
Barcode acceptance enabled.
1B 02 0B 20 01 10 00 10 54 10 03 6E Device is IDLE
2 02 08 11 00 1C 10 03 15 Disable the device to guard
against miscounts. (see
Disabling the Device)
2B 02 0B 21 01 10 00 10 54 10 03 6F Device is IDLE
3 02 0A 70 02 00 1C 10 01 Request the note information
03 75 for the 1st index
3B 02 1E 70 02 01 10 00 10 54 10 01 1st Index is a $1 USD Type “C”
55 53 44 30 30 31 2B 30 30 00 43 Series “A” (See section 7.5.2
41 42 45 00 00 00 03 75 for details on how to decode
this message)
4 02 0A 71 02 00 1C 10 02 Request the note information
03 77 for the 2nd index
4B 02 1E 71 02 01 10 00 10 54 10 02 2nd Index is a $2 USD Type “C”
55 53 44 30 30 32 2B 30 30 00 43 Series “A”
41 42 41 00 00 00 03 70

Omitted indices 3 through 19 for brevity

5 02 0A 71 02 00 1C 10 14 Request the note information

03 61 for the 20th index
5B 02 1E 71 02 01 10 00 10 54 10 14 20th Index is a $100 USD Type
55 53 44 30 30 31 2B 30 32 00 44 “D” Series “C”
43 42 42 00 00 00 03 61
6 02 0A 70 02 00 1C 10 15 Request the note information
03 61 for the 21st index
6B 02 1E 70 02 01 10 00 10 54 10 15 21st Index is a $100 USD Type
55 53 44 30 30 31 2B 30 32 00 47 “G” Series “A”
41 42 41 00 00 00 03 63
7 02 0A 71 02 00 1C 10 16 Request the note information
03 63 for the 22nd index
7B 02 1E 71 02 01 10 00 10 54 10 00 A null response from the
00 00 00 00 00 00 00 00 00 00 00 device for this index. This
00 00 00 00 00 00 03 28 marks the end of the note
table.
8 02 08 10 7F 1C 12 03 69 Re-enable the device
8B 02 0B 20 01 10 00 10 54 10 03 6E

In this example, there are 21 notes in the note set. This value can differ from version to version so the
host shall never use a hard coded value for the number of indices in a note set.

Revision G5 20105-002850209-PS Page 141

8.3 Using Type 6 Audit Commands (0x16, 0x17, 0x18, 0x19)
Examples for the type 6 auxiliary commands for requesting audit data are provided in this section. It
covers an example using a CFSC device but the same logic can be applied for the SC Adv. In order to
retrieve the full audit data structure, each device may require a different number of host commands. It
is important that the host use the following procedure to ensure that it can support any product type.

The first message (0x16) describes the structure that must be used for the other commands (0x17, 0x18
and 0x19). So this structure message must be sent before any of the other commands. This sequence is
shown here.
Msg # Host Message Device Response Description
1 02 08 10 7F 1C 12 03 69 Base line poll message.
Denoms enabled.
Barcode acceptance enabled.
1B 02 0B 20 01 10 00 10 55 25 03 5A Device is IDLE
2 02 08 11 00 1C 10 03 15 Disable the device to guard
against miscounts. (see
Disabling the Device)
2B 02 0B 21 01 10 00 10 55 25 03 5B Device is IDLE
3 02 08 60 00 00 16 03 7E Request Audit Reporting
Structure.
3B 02 0B 60 04 32 19 04 00 00 03 40 Device response for audit
structure. See below for
decoding.

The four data bytes of the response can be deciphered as follows

Value
Data Field From
Byte Name Above Description
Data0 Orientation 0x04 Num of orientations supported In this case, there are 4 orientations
supported.
Data1 Max Fields 0x32 Maximum number of fields. There are 50 (0x32) fields supported. This
means there are a maximum of 50 banknote/document entries in the
audit data table
Data2 Set Size 0x19 Number of fields report per query. This device reported 25 (0x19)
fields will be reported for each host request during the other audit
commands
Data3 Data Width 0x04 Width of the data. A 4 signifies that the returned data fields are
grouped by bytes of 4. Since EBDS is a 7 bit protocol only the last
nibble of each EBDS byte is filled with data in the data for these
messages. This means the 4 bytes will generate 16 bits of real data (4
bits for each byte). Other devices may report a data with of 8 bytes
which will translate to 32 bit accuracy.

Using these values obtained from the subtype 0x16 message, we can now properly send and decipher
the responses to the other commands (0x17, 0x18 and 0x19).

Revision G5 20105-002850209-PS Page 142

In order to retrieve the full set of data, each orientation must be queried for each set. The number of
sets can be determined by dividing the Max Fields by the Set Size. In the above case, there will be 2 sets
for each orientation (50 / 25 = 2). Therefore, to get the total number of recognized documents for the
entire bill set, 8 commands must be sent by the host (4 orientations x 2 sets per orientation).
The example communication session continues here using the Recognized command (0x17):
Msg # Host Message Device Response Description
4 02 08 61 00 00 17 03 7E Data0 (0x00) = RU orientation
Data1 (0x00) = Set 0
Data2 (0x17) = Recognized
fields
4B 02 69 61 00 00 01 00 00 00 00 00 Response shall be broken
00 00 00 00 00 00 00 00 00 00 00 down into sections based on
04 00 00 00 03 00 00 00 00 00 00 the Data Width value that was
00 01 00 00 00 00 00 00 00 00 00 determined above. In this
00 00 00 00 00 00 02 00 00 00 00 case, there are 4 bytes per
00 00 00 00 00 00 00 00 00 00 00 entry. First field contains value
00 00 00 00 00 00 00 00 00 00 00 of 0x0010 after parsing.
00 00 00 00 00 00 00 00 00 00 00 (Remember that data is only
00 00 00 00 00 00 00 00 00 00 00 stored in the lower nibble of
00 00 00 00 03 0D each byte). Set Size number of
fields will be returned (25 in
this case)
5 02 08 60 00 01 17 03 7E Data0 (0x00) = RU orientation
Data1 (0x01) = Set 1
Data2 (0x17) = Recognized
fields
5B 02 69 60 00 00 00 00 00 00 00 00 Parse the response in the
00 00 00 00 00 00 00 00 00 00 00 same fashion as previously
00 00 00 00 00 00 00 00 00 00 00 shown.
00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 06 00 00 00 00
00 00 00 0B 03 04
6 02 08 61 01 00 17 03 7F Data0 (0x01) = RD orientation
Data1 (0x00) = Set 0
Data2 (0x17) = Recognized
fields
6B <response omitted for brevity>
7 02 08 60 01 01 17 03 7F Data0 (0x01) = RD orientation
Data1 (0x01) = Set 1
Data2 (0x17) = Recognized
fields
7B <response omitted for brevity>

Revision G5 20105-002850209-PS Page 143

At this point, the host shall continue to gather all the data by looping through the remaining orientations
and then proceeding to the Validated (0x18) and Stacked (0x19) commands. To summarize the logic:
 Host shall issue subtype 0x16 command to determine how to interpret the rest of the audit
command structure.
 For each Command (Recognized, Validated, Stacked)
o For each Orientation (Determined from 0x16 response)
 For each Data set (Determined from 0x16 response)
 Send command and parse the response.
 Host must ensure the responses are parsed correctly based on the values returned in the 0x16
message. Data Width must be taken into account since it can differ between devices. Set Size
determines the proper index for values returned for each message as well.

The final step would be to re-enable the device after retrieving the audit counters.
Msg # Host Message Device Response Description
n 02 08 11 7F 1C 12 03 68 Re-enable the device
nB 02 0B 21 01 10 00 10 55 25 03 5B

Revision G5 20105-002850209-PS Page 144

9 Appendix B – Quick Reference Tables for Type 6 Messages
Data A Data B Cmd Description
0 0 0x00 (Subtype 0x00) Query Software CRC
0 0 0x01 (Subtype 0x01) Query Cashbox Total
0 0 0x02 (Subtype 0x02) Query Device Resets
0 0 0x03 (Subtype 0x03) Clear Cashbox Total
0 0 0x04 (Subtype 0x04) Query Acceptor Type
0 0 0x05 (Subtype 0x05) Query Acceptor Serial Number
0 0 0x06 (Subtype 0x06) Query Acceptor Boot Part Number
0 0 0x07 (Subtype 0x07) Query Acceptor Application Part Number
0 0 0x08 (Subtype 0x08) Query Acceptor Variant Name
0 0 0x09 (Subtype 0x09) Query Acceptor Variant Part Number
0 0 0x0A (Subtype 0x0A) Query Acceptor Audit Life Time Totals
0 0 0x0B (Subtype 0x0B) Query Acceptor Audit QP Measures
0 0 0x0C (Subtype 0x0C) Query Acceptor Audit Performance Measures
0 0 0x0D (Subtype 0x0D) Query Device Capabilities
0 0 0x0E (Subtype 0x0E) Query Acceptor Application ID
0 0 0x0F (Subtype 0x0F) Query Acceptor Variant ID
0 0 0x10 (Subtype 0x10) Query BNF Status
nn 0 0x11 (Subtype 0x11) Set Bezel
0 0 0x12 (Subtype 0x12) Query Acceptor Audit Life Time Totals Extended
0 0 0x13 (Subtype 0x13) Query Acceptor Audit QP Measures Extended
0 0 0x14 (Subtype 0x14) Query Acceptor Audit Performance Measures Extended
0 0 0x15 (Subtype 0x15) Query Asset Number
0 0 0x16 (Subtype 0x16) Query Acceptor Audit Total Documents Reporting
Structure
nn nn 0x17 (Subtype 0x17) Query Acceptor Audit Total Documents Recognized
nn nn 0x18 (Subtype 0x18) Query Acceptor Audit Total Documents Validated
nn nn 0x19 (Subtype 0x19) Query Acceptor Audit Total Documents Stacked
nn nn 0x1A (Subtype 0x1A) Acceptor Diagnostics Self Test
- - 0x1B Reserved (Do Not Use)
- - 0x1C Reserved (Do Not Use)
nn nn 0x1D (Subtype 0x1D) Query Acceptor Diagnostics Sensor Data
0 0 0x23 (Subtype 0x23) Query Hardware Status
0x7F 0x7F 0x7F (Subtype 0x7F) Acceptor Soft Reset

Revision G5 20105-002850209-PS Page 145

10 Appendix C – Quick Reference Tables for Type 7 Messages
Sub Type Description
0x01 (Subtype 0x01) Extended Barcode Reply
0x02 (Subtype 0x02) Extended Note Specification Message
0x03 (Subtype 0x03) Set Extended Note Inhibits
0x04 (Subtype 0x04) Set Escrow Timeout / Extended Coupon
0x05 (Subtype 0x05) Set Asset Number
0x06 (Subtype 0x06) Query Value Table
0x0B (Subtype 0x0B) Note Retrieved
0x0C (Subtype 0x0C) SHA-1 Request
0x0D (Subtype 0x0D) Advanced Bookmark Mode
0x10 (Subtype 0x10) Cashbox Cleanliness
0x11 (Subtype 0x11) Request 16-bit CRC Calculation
0x12 (Subtype 0x12) Request 32-bit CRC Calculation
0x13 (Subtype 0x13) Request Recycler Note Table
0x14 (Subtype 0x14) Set Recycler Note Value Enables
0x15 (Subtype 0x15) Recycler Omnibus Command/Reply
0x16 (Subtype 0x16) Dispense Bills
0x17 (Subtype 0x17) Cancel Dispense/Float
0x18 (Subtype 0x18) Float Bills
0x19 (Subtype 0x19) Last Cash Movement Summary Report
0x1A (Subtype 0x1A) Missing Note Report
0x1B (Subtype 0x1B) Request Physical Recycler Status
0x1C (Subtype 0x1C) RFID Data Request
0x1D (Subtype 0x1D) Clear Audit Data Request
0x20 (Subtype 0x20) Escrow Session Summary Report

Revision G5 20105-002850209-PS Page 146

11 Appendix D - Quick Reference EBDS Message Structure
Controller Message Acceptor Message

STX (0x02) STX (0x02)

Length (0x08) Length (0x0B)

Message Type / ACK Message Type / ACK (See Controller Description)

Bit 0 Message Sequence Toggles
Bit 1-3 Reserved Always 0 Byte 0
Bit 4-6 Message Type (See Below) Bit 0 Idling Waiting for a Document.
High Nibble Type Bit 1 Accepting Taking a Document
0x0n Reserved Bit 2 Escrowed Document is in Escrow
0x1n Standard Host Command Bit 3 Stacking Stacker is moving
0x2n Standard Device Reply Bit 4 Stacked Document was Stacked
0x3n Host Command + Bookmark Bit 5 Returning Returning a Document
0x4n Calibrate Request Bit 6 Returned Document was Returned
0x5n Flash Download
0x6n Auxiliary Commands Byte 1
0x7n Extended Message Set Bit 0 Cheated A cheat was detected
Bit 1 Rejected Document was Rejected
Byte 0 Bit 2 Jammed Document is Jammed
Bit 0 Denom 1 Accept Enable Bit 3 Stacker Full Stacker is Full
Bit 1 Denom 2 Accept Enable Bit 4 LRC Status LRC Installed
Bit 2 Denom 3 Accept Enable Bit 5 Paused Acceptor is Paused
Bit 3 Denom 4 Accept Enable Bit 6 Calibration Acceptor is Calibrating
Bit 4 Denom 5 Accept Enable
Bit 5 Denom 6 Accept Enable Byte 2
Bit 6 Denom 7 Accept Enable Bit 0 Power Up The device was reset
Bit 1 Invalid Command Bad command from host
Byte 1 Bit 2 Failure Out of Service
Bit 0 Special Interrupt Mode Mode Enabled Bit 3-5 Bit 5 4 3 Note Value / Denom
Bit 1 High Security Enabled 0x00 0 0 0 None/No value
Bit 2-3 Note Orientation Enable (See Below) 0x08 0 0 1 Denom 1
Bit 3 2 Orientation 0x10 0 1 0 Denom 2
0 0 1 Way 0x18 0 1 1 Denom 3
0 1 2 Way 0x20 1 0 0 Denom 4
1 x 4 Way 0x28 1 0 1 Denom 5
Bit 4 Escrow Mode Escrow Enabled 0x30 1 1 0 Denom 6
Bit 5 Stack Command Bit Stack the Document 0x38 1 1 1 Denom 7
Bit 6 Return Command Bit Return Document Bit 6 Transport Open Bill path is open.

Byte 2 Byte 3
Bit 0 Push/No Push Modes No Push Mode Bit 0 Push/No Push Acceptor is stalled.
Bit 1 Decode Bar Codes Enable Bit 1 Flash Download Starting Flash D/L.
Bit 2 Power Up B Sequence Enable Bit 2 Pre-stack Deprecated
Bit 3 Power Up C Sequence Enable Bit 3 Raw barcode Supports 24 byte codes
Bit 4 Extended Note Set Enable Bit 4 Device Caps Allows QryDeviceCaps
Bit 5 Extended Coupon Enable Bit 5 Disabled Device is disabled
Bit 6 Currently 0 RFU Bit 6 Currently 0 RFU

ETX (0x03) Byte 4

All Model # (00-7FH)
Checksum
Byte 5
All Code Revision (00-7FH)

ETX (0x03)

RFU = Reserved Future Use Checksum

Revision G5 20105-002850209-PS Page 147