CashCode NET

Interface

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 1 of 60

Contents
1

General Information................................................................................................................4
1.1

Introduction.................................................................................................................................................. 4

1.2

Operational and Application Notes............................................................................................................... 4

Communication Format.........................................................................................................5
2.1

Data format.................................................................................................................................................. 5

2.2

Message Format.......................................................................................................................................... 5

2.3

Transmission and reception message formats............................................................................................. 7

2.4

Peripheral Addresses................................................................................................................................... 8

2.5

Software Operational Rules......................................................................................................................... 8

2.6

Typical Session Examples........................................................................................................................... 9

2.7

Timing Definitions....................................................................................................................................... 11

2.8

Timing Specifications................................................................................................................................. 11

CONTROLLER/BILL-TO-BILL UNIT Communication Specification................................12

3.1

Introduction................................................................................................................................................ 12

3.2

Command Protocol.................................................................................................................................... 12

3.3

Controller Commands................................................................................................................................ 12

3.4

Controller Command Format..................................................................................................................... 13

CONTROLLER/COIN CHANGER Communication Specification.....................................24

4.1

Introduction................................................................................................................................................ 24

4.2

Command Protocol.................................................................................................................................... 24

4.3

Controller Commands................................................................................................................................ 24

4.4

Controller Command Format..................................................................................................................... 24

CONTROLLER/BILL VALIDATOR Communication Specification....................................31

5.1

Introduction................................................................................................................................................ 31

5.2

Command Protocol.................................................................................................................................... 31

5.3

Controller Commands................................................................................................................................ 31

5.4

Controller Command Format..................................................................................................................... 32

CONTROLLER/ Card Reader Communication Specification...........................................44

6.1

Introduction................................................................................................................................................ 44

6.2

Card Reader States................................................................................................................................... 44

6.3

Command Protocol.................................................................................................................................... 45

6.4

Controller Commands................................................................................................................................ 45

6.5

Controller Command Format..................................................................................................................... 45

6.6

Non-Response Time................................................................................................................................... 51

APPENDIX Example CCNET Message Sequences.........................................................52

7.1

Power Up & Reset sequence..................................................................................................................... 53

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 2 of 60

7.2

Enable sequence....................................................................................................................................... 53

7.3

Disable sequence....................................................................................................................................... 54

7.4

Bill Accept sequence (Bill stacked)............................................................................................................ 54

7.5

Bill Accept sequence (Bill returned)........................................................................................................... 55

7.6

Bill Dispense sequence (Bill dispensed).................................................................................................... 56

7.7

Bill Unload sequence (Bill unloaded)......................................................................................................... 57

7.8

Set cassette type sequence....................................................................................................................... 58

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 3 of 60

1
1.1

General Information
Introduction

This document defines a serial network interface. The interface is Master-Slave arrangement where all
peripherals are Slave to a Master Controller.

1.2

Operational and Application Notes

The serial network interface, or serial bus interface, is configured for Master- Slave operation. There is
one Master with the capability of communicating with some peripherals. The Master is defined as
Controller and Slave as Peripheral.
Each peripheral is assigned a unique address and command set. The Controller will poll the Bus for
Peripheral activity. That is, each Peripheral is asked for activity, and responds with either acknowledge,
negative acknowledge, invalid command acknowledge, or specific data dependent on its current activity.
If a Peripheral does not respond within a predefined time, (t-non-response as defined in the peripheral
sections) it is assumed that it is not present on the Bus.

Bus interference or crashes are prevented because each Peripheral only responds upon being polled.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 4 of 60

2
2.1

Communication Format.
Data format

Baud Rate:
Start bit:
Data bit:
Parity:
Stop bit:

2.2

9600 bps/19200 bps (no negotiation, hardware selectable)

1
8 (bit 0 = LSB, bit 0 sent first)
Parity none
1

Message Format
SYNC

SYNC:
ADR :
LNG :
CMD :
DATA
CRC:

ADR

LNG

1 byte
1 byte
1 byte*
1 byte
0 to 250 bytes
2 bytes

CMD

DATA

CRC

Message transmission start code [02H], fixed

Peripheral address
Data length (Total number of bytes including SYNC and CRC)
Command
Data necessary for command (omitted if not required by CMD)
Check code by CRC method, LSB first
Object section to be from and including SYNC to end of DATA
(Initial value = 0)

Error control method:

Error detection CRC method

CRC - CCITT using whole byte shifting into a two-byte frame
P(X) = X16 + X12 + X5 + l

* if a package cannot be fitted into 250-byte frame a wider frame may be used by setting LNG to 0; the
actual packet length is inserted into DATA block bytes 0 and 1 if CMD (if present in the frame) does not
require subcommand, otherwise in DATA block bytes 1 and 2; two-byte LNG always follows MSB first.
case 1 (CMD present, no subcommand):
SYNC

ADR

CMD

LNG HIGH

LNG LOW

DATA

CRC

case 2 (CMD present, subcommand present):

SYNC

ADR

CMD

SUBCMD

LNG HIGH

LNG LOW

DATA

CRC

case 3 (CMD not present, no subcommand):

SYNC

ADR

LNG HIGH

LNG LOW

DATA

CRC

This allows accommodation of data packages of up to 65528 bytes; please keep in mind that lengthy
exchanges compromise bus bandwidth.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 5 of 60

Example of CCNET CRC calculation using C-language source code:

#define POLYNOMIAL 0x08408
unsigned int GetCRC16(unsigned char* bufData, unsigned int sizeData)
{
unsigned int TmpCRC, CRC, i;
unsigned char j;
CRC = 0;
for(i=0; i < sizeData; i++)
{
TmpCRC = CRC ^ bufData[i];
for(j=0; j < 8; j++)
{
if(TmpCRC & 0x0001) {TmpCRC >>= 1; TmpCRC ^= POLYNOMIAL;}
else TmpCRC >>= 1;
}
}
return CRC;
}
Example of CCNET CRC calculation using PASCAL-language source code:
const _CR_CCNET_CRC_POLY = $08408

function GetCRC16(InData: array of byte; DataLng: word): word;

var i,TmpCRC: word;
j: byte;
begin
result:=0;
for i:=0 to (DataLng-1) do
begin
TmpCRC:=result xor InData[i];
for j:=0 to 7 do
begin
if (TmpCRC and $0001)<>0 then
begin
TmpCRC:=TmpCRC shr 1;
TmpCRC:=TmpCRC xor _CR_CCNET_CRC_POLY;
end
else
TmpCRC:=TmpCRC shr 1;
end;
result:=TmpCRC;
end;
end;
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 6 of 60

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 7 of 60

2.3

Transmission and reception message formats

Transmission and reception message format is divided into the following four types.

(1) Command transmission CONTROLLER to PERIPHERAL

SYNC
SYNC :
ADR :
LNG :
CMD :
DATA :
CRC :

ADR

LNG

CMD

DATA

CRC

[02H]
Peripheral address
Data length
Command
Data necessary for command (omitted if not required by CMD)
Check code by CRC method

(2) ACK response PERIPHERAL to CONTROLLER/ CONTROLLER to PERIPHERAL

SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :

ADR

LNG

DATA

CRC

[02H]
Peripheral address
[06H]
[00H]
Check code by CRC method

(3) NAK response PERIPHERAL to CONTROLLER/ CONTROLLER to PERIPHERAL

SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :

ADR

LNG

DATA

CRC

[02H]
Peripheral address
[06H]
[FFH]
Check code by CRC method

Sent in PERIPHERAL to CONTROLLER direction if command from controller was not correctly received.
(4) Response message PERIPHERAL to CONTROLLER
SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :

ADR

LNG

DATA

CRC

[02H]
Peripheral address
Data length
Responses Data
Check code by CRC method

(5) ILLEGAL COMMAND Response message PERIPHERAL to CONTROLLER

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 8 of 60

SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :

ADR

LNG

DATA

CRC

[02H]
Peripheral address
[06]
[30H]
Check code by CRC method

Sent by the PERIPHERAL if command from CONTROLLER is not valid in reference to the current
peripheral state.

2.4

Peripheral Addresses

The addresses below are defined.

Address
Definition
00H
01H
02H
03H
04H
05H
.
.
.
0DH
0EH
0FH

2.5

Forbidden
Bill-to-Bill unit
Coin Changer
Bill Validator
Card Reader
Reserved for Future Standard Peripherals
.
.
.
Reserved for Future Standard Peripherals
Reserved for Future Broadcast Transmissions
Reserved for Future Standard Peripherals

Software Operational Rules

During multi-byte messages the most significant byte is sent first.
If the Peripheral has not responded to a poll for its maximum non-response time, the Controller must
continue to poll the Peripheral at least every ten seconds with a RESET command.
All messages, from Controller or Peripheral, must be sent as quickly as possible. There is no
minimum tresponse time. All data block transmissions must be started within 10 mS.
Any data (bytes or bits) within a command or response that are not specifically defined must be left in
a 0 state.
The Controller may reset Peripheral by sending the signal BUS RESET for a minimum of 100 mS.
This informs Peripheral to abort any activity and return to its power-on reset state. It is recommended
that the Controller re-initialize each Peripheral after this type of reset. WARNING: BUS RESET is
device and implementation dependant and may not be present within some devices.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 9 of 60

2.6

Typical Session Examples

The Controller must respond to data from a Peripheral with an Acknowledgment (ACK) or Negative
Acknowledgment (NAK) message. The 10 mS time-out (t-response) described in the Timing section of
this document is the equivalent of a NAK message.
A Peripheral must respond to command from the Controller with response message, or ACK message, or
NAK message. The 10 mS time-out (t-response) described in the Timing section of this document is the
equivalent of a NAK message.
The tfree must be obeyed by the Controller between the end of any ACK or NAK confirmation response
and start of the next command transmission. Currently t free is defined as 10 mS of Bus silence, but for
reliable operation of future multi-device buses the recommended value of t free is 20mS.

2.6.1 The diagram below represents a typical transmission when PERIPHERAL has no data to return.
Controller
ller
r
l
er

Command

Peripheral

ACK message
d

Less or
equal to 10
mS

2.6.2 The diagram below represents a typical transmission when PERIPHERAL has data to return.
Controller

Peripheral
Poll command
Status
ACK message

From 100 to
200 mS

Poll command
Status

Less or
equal to 10
mS
Bus silence
of tfree msec

ACK message

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 10 of 60

2.6.3

The diagram below represents a typical transmission when the Controller determines a CRC is not
correct.

Controller

Peripheral

Poll Command
command
Status

Less or
equal to 10
mS

NAK message
From 100
to 200 mS

Poll
command

Bus silence
of tfree msec

Status
ACK message

2.6.4

The diagram below represents a typical transmission when Peripheral determines a CRC is not
correct. The Peripheral responds by sending a NAK message to the Controller to indicate that the
information was not received correctly.

Controller

Peripheral
Poll Command
command
NAK message

From 100
to 200 mS

Poll
command

Less or
equal to 10
mS

Status data

ACK message

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 11 of 60

2.7

Timing Definitions

Baud rate
tinter-byte(max.)
tresponse(max.)
tbus reset(min.)
tnon-response (max.)
tpoll
tfree

2.8

Timing Specifications

Baud Rate
tinter-byte(max.)
tresponse(max.)
tbus reset(min.)
Tnon-response (max.)
tpoll
tfree

The rate of bit transfer per second

The maximum time allowed between bytes in a block transmission
The maximum time Peripheral will take to respond to a valid
communication
The minimum time of sending signal BUS RESET
The maximum non-response time
The interval of time between two commands Poll
The interval of time between confirmation ACK or NAK and next
command

9600/19200 +1%/-2% NRZ (non-return to

zero), non-negotiable, hardware selectable
5.0 ms
10.0 ms
100 ms
5.0 S
100-200 ms
10 ms (recommended 20 ms or more)

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 12 of 60

CONTROLLER/BILL-TO-BILL UNIT Communication Specification

3.1

Introduction

This section defines the communication bytes sent and received between Bill-to-Bill unit and the
Controller. Unless stated otherwise, all information is assumed to be in a hexadecimal format. The Bill-toBill units address is 01H.

3.2

Command Protocol

The IDENTIFICATION, GET BILL TABLE and DOWNLOAD commands may be sent by the Controller
when Bill-to-Bill unit is in the following states only: Power up, Initialise or Unit Disabled. If a command
cannot be executed by the Bill-to-Bill unit in a given state COMMAND INVALID response is issued.

3.3

Controller Commands

Command
RESET
GET STATUS

HEX Code
30H
31H

SET SECURITY

32H

POLL

33H

ENABLE BILL TYPES

34H

STACK

35H

RETURN

36H

IDENTIFICATION

37H

HOLD

38H

CASSETTE STATUS
DISPENSE

3BH
3CH

UNLOAD

3DH

ESCROW CASSETTE
STATUS
ESCROW CASSETTE
UNLOAD
SET CASSETTE TYPE
GET BILL TABLE
DOWNLOAD
(see details for subcommands)

Description
Command for Bill-to-Bill unit to self-reset
Request for Bill-to-Bill unit set-up status
Sets Bill-to-Bill unit Security Mode. Command is
followed by set-up data. See command format
Request for Bill-to-Bill unit activity Status
Indicates Bill Type enable or disable. Command is
followed by set-up data. See command format
Sent by Controller to stack a bill in escrow into drop
cassette or into one of the recycling cassettes
Sent by Controller to return a bill in escrow
Request for Model, Serial Number, Software Version
of Bill-to-Bill unit, Country ISO code, Asset Number
Command for holding the Bill-to-Bill unit in Escrow
state
Request for Bill-to-Bill unit cassette status
Command to dispense a bill of specific type
Command to unload bills from recycling cassette(s) to
drop cassette

3EH

Request for recycling cassette(s) status

3FH

Command for routing bills to recycling cassette(s)

40H
41H

Assigns cassettes to bill types

Request for bill type assignments

50H

Command for transition to download mode.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 13 of 60

3.4

Controller Command Format

RESET
Controller Command
RESET

Code
30H

Controller Data
No data bytes

This command is used to tell the Bill-to-Bill unit that it must return to its default operating mode. It must
abort all communication, reject any bills in the validation process, return any bills in the escrow position,
and disable all other activity until otherwise instructed by the Controller.

GET STATUS
Controller Command
GET STATUS
Z1-Z3
Z4-Z6
Z7-Z9

Code
31H

Bill-to-Bill unit Response Data

9 bytes: Z1 Z9

Bill Type, 3 bytes. Indicates the bill enables for bill types 0 to 23.
Bill Security Levels, 3 bytes. Indicates the security level for bill types 0 to 23.
Bill Type Routing, 3 bytes. Indicates what bill types can be routed to the Bill-to-Bill units
cassettes. Valid bill types are 0 to 23.

Bill Type
Byte Z1 bits
Byte Z2 bits
Byte Z3 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
Bill Security Levels
Byte Z4 bits
Byte Z5 bits
Byte Z6 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
Bill Type Routing
Byte Z7 bits
Byte Z8 bits
Byte Z9 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types can be routed if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 14 of 60

SET SECURITY
Controller Command
SET SECURITY

Code
32H

Controller Data
3 Bytes: Y1 Y3

Byte Y1 bits
Byte Y2 bits
Byte Y3 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
A bit is set to indicate the type of bill(s), which are set to a high security level.

POLL
Controller Command
POLL

Code
33H

Bill-to-Bill unit Response Data

1 or 2 bytes: Z1 or Z1- Z2

Indicates status of the Bill-to-Bill unit and its activity. The Bill-to-Bill unit may send 1or 2 of the following
data bytes:
Response data
bytes
Z1
Z2
10H
11H

12H
12H
13H
14H
15H
17H

18H

19H

Description
Power Up
Power Bill

The state of Bill-to-Bill unit after power up

Power up with bill in validating head. After a RESET
command from the Controller, the Bill-to-Bill unit returns
the bill and continues initializing.
Power up with bill in Bill-to-Bill unit. Always followed by location byte (see below).
00H Power w/Bill in Transport Power up with bill in transport section. After a RESET
Path
command from the Controller, the Bill-to-Bill unit stacks
the bill to the drop cassette and continues initializing.
01H Power w/Bill in
Power up with bills in dispenser. After a RESET
Dispenser
command from the Controller, the Bill-to-Bill unit returns
the bills to exit bezel and continues initializing.
Initialize
The state, in which Bill-to-Bill unit executes initialization
after RESET command from the Controller.
Idling
In this state Bill-to-Bill unit waits for bill insertion.
Accepting
In this state Bill-to-Bill unit executes scanning of a bill
and determines its denomination.
Stacking
In this state, the Bill-to-Bill unit transports a bill from
Escrow position to the recycling cassette or to the drop
box and remains in this state until the bill is stacked or
returned if jammed.
Returning
In this state Bill-to-Bill unit transports a bill from Escrow
position to entry bezel and remains in this state until
the bill is removed by customer.
The Bill-to-Bill unit has been disabled by the Controller
Unit Disabled
and also the state in which Bill-to-Bill unit is after
initialization

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 15 of 60

1AH
1BH
1CH
1CH
1CH
1CH
1CH
1CH
1CH
1CH
1CH
1CH
1CH
1CH
1CH
1DH
1EH

1FH

20H

21H
25H
26H
27H
28H

The state, in which the bill is held in Escrow position

after the HOLD command from the Controller.
The state, in which Bill-to-Bill unit cannot answer a
detailed command right now. On expiration of time YH,
YH
Device Busy
peripheral is accessible for polling. YH is expressed as
multiple of 100 milliseconds.
Generic rejecting code. Always followed by rejection reason byte (see below).
Rejecting due to
60H
Insertion error
Insertion
Rejecting due to
61H
Magnetic error
Magnetic
Rejecting due to bill
62H
Bill remains in the head, and new bill is rejected.
Remaining in the head
Rejecting due to
63H
Compensation error/multiplying factor error
Multiplying
Rejecting due to
64H
Conveying error
Conveying
Rejecting due to
65H
Identification error
Identification1
Rejecting due to
66H
Verification error
Verification
67H Rejecting due to Optic
Optic error
68H Rejecting due to Inhibit
Return by inhibited denomination error
Rejecting due to
69H
Capacitance error
Capacity
Rejecting due to
6AH
Operation error
Operation
6CH Rejecting due to Length
Length error
Bill-to-Bill unit enters this state after DISPENSE
command. In this state Bill-to-Bill unit transports a bill
Dispensing
from recycling cassette(s) to customer through
dispenser and remains in this state until the bill(s) are
removed by customer or jammed.
Unloading
Transporting bills to drop cassette.
Bill-to-Bill unit pass to this state after RECYCLING
CASSETTE UNLOAD command if high bit of data byte
is set. In this state Bill-to-Bill unit transports bill(s) from
Custom returning
recycling cassette to customer through dispenser and
remains in this state until the customer removes the
bill(s).
Bill-to-Bill unit passes to this state after RECYCLING
CASSETTE UNLOAD command if high bit of data byte
Recycling unloading
is dropped. In this state Bill-to-Bill unit transports bill
from recycling cassette to recycle cassette of
appropriate bill type or to drop cassette.
Unloading of the recycling cassette is carried out and
Setting cassette type
cassette is reassigned to new bill type
Dispensed
Dispensing is completed.
Unloaded
Unloading is completed
Custom bills returned
Bills are returned to customer.
Recycling cassette
Recycling Cassette unloading is completed.
unloaded
Holding

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 16 of 60

29H
30H
41H
42H
43H
44H
45H
46H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
47H
48H
48H
48H
48H
48H
48H
80H
81H

Set cassette type

Invalid command
Drop Cassette Full
Drop Cassette out of
position
Bill Validator Jammed
Cassette Jammed

Setting recycling cassette type is completed.

Command from the Controller is not valid.
Drop Cassette full condition
The Bill-to-Bill unit has detected the drop cassette to
be open or removed.
Bill(s) are jammed in the acceptance path.
A bill are jammed in drop cassette.
The Bill-to-Bill unit sends this event if the intentions of
Cheated
the user to deceive the Bill-to-Bill unit are detected.
The Bill-to-Bill unit reaches this state when the user
tries to insert a bill before the previous bill is stacked.
Pause
Bill-to-Bill unit stops motion of the bill until the entry
channel is cleared.
Generic Failure codes. Always followed by failure description byte (see below).
50H Stack Motor Failure
Drop Cassette Motor failure
Transport Motor Speed
51H
Transport Motor Speed out of range
Failure
52H Transport Motor Failure
Transport Motor failure
53H Aligning Motor Failure
Aligning Motor failure
54H Initial Box Status Failure Initial cassette Status failure
One of the optic sensors has failed to provide its
55H Optic Canal Failure
response.
56H Magnetic Canal Failure
Inductive Sensor failure
57H Cassette 1 Motor Failure Recycling Cassette 1 Motor Failure
58H Cassette 2 Motor Failure Recycling Cassette 2 Motor Failure
59H Cassette 3 Motor Failure Recycling Cassette 3 Motor Failure
Bill-to-Bill unit Transport
5AH
One of the Bill-to-Bill unit Transport Motors failure
Motor Failure
5BH Switch Motor 1 Failure
Switch Motor 1 Failure
5CH Switch Motor 2 Failure
Switch Motor 2 Failure
Dispenser Motor 1
5DH
Dispenser Motor 1 Failure
Failure
Dispenser Motor 2
5EH
Dispenser Motor 2 Failure
Failure
Capacitance Canal
5FH
Capacitance sensor failed to respond
Failure
Bill-to-Bill unit Jammed. Always followed by location byte (see below).
Bill Jammed in Cassette
70H
A bill is jammed in Recycling Cassette 1
1
Bill Jammed in Cassette
71H
A bill is jammed in Recycling Cassette 2
2
Bill Jammed in Cassette
72H
A bill is jammed in Recycling Cassette 3
3
Bill Jammed in Transport
73H
A bill is jammed in Transport Path
Path
74H Bill Jammed in Switch
A bill is jammed in Switch
Bill Jammed in
75H
A bill is jammed in Dispenser
Dispenser
Events with credit.
YH
Escrow position
Y = bill type (0 to 23)
YH
Bill stacked
Y = bill type (0 to 23)

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 17 of 60

82H

YH

Bill returned

Y = bill type (0 to 23)

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 18 of 60

ENABLE BILL TYPES

Controller Command
ENABLE BILL TYPES

Code
34H

Controller Data
6 bytes: Y1 Y6

Byte Y1 bits
Byte Y2 bits
Byte Y3 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
NOTE: Sending 000000H disables the Bill-to-Bill unit.
Byte Y4 bits
Byte Y5 bits
Byte Y6 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types with escrow enabled if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
NOTE: On power-up or reset all bill acceptance and escrow are disabled.

STACK
Controller Command
STACK

Code
35H

Controller Data
No data bytes

This command forces a bill in escrow position to be sent to drop cassette or one of the recycling
cassettes.
NOTE:
After a STACK command the Bill-to-Bill unit should respond to a POLL command with the BILL
STACKED message within 30 seconds. If this command is sent when the Bill-to-Bill unit is not in
ESCROW state the ILLEGAL COMMAND message is returned.

RETURN
Controller Command
RETURN

Code
36H

Controller Data
No data bytes

This command causes the Bill-to-Bill unit to return a bill in escrow position to the customer.

NOTE: After a RETURN command the Bill-to-Bill unit should respond to a POLL command with the
BILL RETURNED message within 30 seconds. If this command is sent when the Bill-to-Bill unit is not in
ESCROW state the ILLEGAL COMMAND message is returned.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 19 of 60

IDENTIFICATION
Controller Command
IDENTIFICATION
Bytes
Z1-Z15
Z16-Z27
Z28-Z34

Code
37H

Bill-to-Bill unit Response Data

34 bytes:
Z1 Z34

Description
Part Number 15 bytes, ASCII characters
Serial Number 12 bytes Factory assigned serial number, ASCII characters
Asset Number 7 bytes, unique to every Bill Validator, binary data

Bytes Z1-Z27 must be sent as ASCII Characters. Zero (30H) and Blank (20H) are acceptable. Asset
Number must be sent as binary code.
15 bytes

BB-US1701

12 bytes

7 bytes

00K038AS3419 Binary code

Asset Number

Serial Number
Part Number

HOLD
Controller Command
HOLD

Code
38H

Controller Data
No data bytes

This command allows the Controller to hold Bill-to-Bill unit in a state Escrow during 10 s. After this time
the Controller should send the STACK or RETURN command. For continued holding in an Escrow state it
is necessary to resend this command. Otherwise Bill-to-Bill unit will execute return of a bill.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 20 of 60

CASSETTE STATUS
Controller Command
CASSETTE STATUS
Z1-Z32

Code
3BH

Bill-to-Bill unit Response Data

32 bytes: Z1-Z32

Cassette Status 32 bytes.

Indicates the greatest number of bills that the Bill-to-Bill unit knows definitely is present in the bill
cassettes. The 32-byte string consists from 16 two-byte words. Each two-byte position in the 32-byte
string indicates the number of cassette. For example, the first two bytes sent indicate the number of
cassette 1. First byte of word has the following format:
(abc zzzzz)
If a = 0 Cassette not present.
If b = 1 Cassette hasnt any type (type NULL).
If c = 1 Cassette has type ESCROW.
zzzzz - Type of bill. This bits is valid if bits b,c = 0 and a = 1 only
Second byte of word indicates number of bills in cassette.
Unsent bytes are assumed to be zero.

DISPENSE
Controller Command
DISPENSE

Code
3CH

Controller Data
27 bytes: Y1-Y27

Y1-Y3
Bill Type to be dispensed - 3 bytes. A bit is set to indicate bill type to be dispensed.
Byte Y1 bits
Byte Y2 bits
Byte Y3 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill Types to be dispensed if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
Y4-Y27

These bytes contain number of bills to dispense for those types, which are specified in
bytes Y1-Y3. Zero bytes are not sent. For example, if in bytes Y1-Y3 two bits are set, Y4
and Y5 will be sent only.

NOTE: The total number of bills to dispense must not exceed 20 bills.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 21 of 60

UNLOAD
Controller Command
UNLOAD

Code
3DH

Controller Data
2 bytes: Y1-Y2

This command unloads the bills from the recycling cassettes to drop cassette.
Y1
Cassette number code
Y2
Iindicates the number of bills to be unloaded.

EXTRA CAPABILITIES RECYCLING CASSETTE COMMANDS

RECYCLING CASSETTE STATUS

Controller Command
RECYCLING CASSETTE

Code
3EH

Bill-to-Bill unit Response Data

1 byte: Z1

Z1
(Fyyy yyyy)
F = Recycling Cassette Full Status.
yyy yyyy = number of bills in the recycling cassette.
NOTE:

RECYCLING
UNLOAD
Controller Command
RECYCLING CASSETTE
Y1

If a Bill-to-Bill unit can detect a cassette jam, defective cassette sensor, or

other malfunction, it will indicate the cassette is bad by sending a recycling
cassette full status and a count of zero.

CASSETTE
Code
3FH

Controller Data
1 byte: Y1

(Dyyy yyyy)
If Y1 = 1yyy yyyy; yyyy yyy = Number of bills to return to customer.
If Y1 = 0; Unload one bill to recycling cassette of appropriate bill type or drop cassette
Command for routing bills from recycling cassette. This command allows returning
customer bills in case of cancelling.

NOTE: The total number of bills must not exceed 20 bills.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 22 of 60

SET
RECYCLING
CASSETTE TYPE
Controller Command
Code
SET RECYCLING CASSETTE TYPE

40H

Controller Data
2 bytes: Y1-Y2

Command for assigning recycling cassette bill type. If the cassette is not empty, the command forces
complete unloading of the cassette.
Y1
Y2

Number cassette code

(abc zzzzz)
If a = 1 Cassette is present.
If b = 1 Lets Cassette type NULL.
If c = 1 Lets Cassette type ESCROW.
Only one of this bit can be set. zzzzz - Type of bill. This bits is valid if bits b,c = 0
and a = 1 only

Notes: It is strongly recommended to send RECYCLING CASSETTE STATUS command before sending
SET RECYCLING CASSETTE STATUS TYPE command to assure proper cassette type assignment.

GET BILL TABLE

Controller Command
GET BILL TABLE

Code
41H

Bill-to-Bill unit Response Data

120 bytes: Z1-Z120

Command for request bill type description.

Z1-Z120

The 120 - byte string consists of 24 five-byte words.

Byte 1 of word most significant digit of the denomination.
Bytes 2-4 of word country code in ASCII characters.
Byte 5 of word decimal placement or proceeding zeros. If bit D7 is 0, the bits D0-D6
indicate the number of proceeding zeros. If bit D7 is 1, the bits D0-D6 indicates the decimal point position
starting from the right and moving to the left.
A five-byte position in the 120-bytes string indicates bill type description for the particular bill type. For
example, first five bytes correspond to bill type=0, second five bytes correspond to bill type=1 and so on.
Example:
Bill Type

0
1
2
3
4
5
6
7
8
9

Denomination
Code
First Byte
0x1
0x2
0x5
0x5
0x19
0x19
0x19
0x19
0x1
0x5

Country
Code
3 bytes
ITL
ITL
ITL
NLC
NLC
NLC
NLC
NLC
USA
USA

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Denomination
Code
Second Byte
0x3
0x3
0x3
0x82
0x82
0x81
0x0
0x2
0x0
0x0

Denomination
1,000
2,000
5,000
.05
.25
2.5
25
2500
1
5

Page 23 of 60

Lira
Lira
Lira
Crown
Crown
Crown
Crown
Crown
Dollar
Dollar

10
0x1
USA
0x1
11
0x2
USA
0x1
Unsent bytes are assumed to be zero.

10
20

Dollar
Dollar

DOWNLOAD
Controller Command
DOWNLOAD

Code
50H

Controller Data
1 byte: Y1

Y1 subcommand byte.

This command is not implemented in current Bill-to-Bill unit software releases and will always return an
INV response.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 24 of 60

4
4.1

CONTROLLER/COIN CHANGER Communication Specification

Introduction.

This section defines the communication bytes sent and received by a Coin Changer. The Coin Changers
address is 02H. Unless stated otherwise, all information is assumed to be in hexadecimal format.
The coin changer must be compatible with Controller that is designed according to the operational rules
defined earlier in this document.

4.2

Command Protocol

The commands IDENTIFICATION, GET COIN TABLE, and DOWNLOAD should be sent by the Controller,
when Coin Changer is in the following states: Power up, Initialize or Unit Disabled.
If the Coin Changer, which is not executable in its present state, receives a Controller command Coin
Changer issues ILLEGAL COMMAND message.

4.3

Controller Commands

Command
RESET
GET STATUS
TUBE STATUS
POLL

HEX Code
08H
09H
0AH
0BH

ENABLE COIN TYPES

0CH

DISPENSE

0DH

IDENTIFICATION

0FH

GET COIN TABLE

DOWNLOAD

10H
50H

4.4

Description
Command for Coin Changer to self-reset
Request for Coin Changer set-up status
Request for Coin Changer tube status.
Request for Coin Changer activity Status
Indicates Coin Type enable or disable. Command is
followed by set-up data. See command format
Command to dispense a coin type. Command is followed
by set-up data. See command format
Request for Model, Serial Number, Software Version of
Coin Changer, Country ISO code
Request for coin type description
Command for transition to download mode

Controller Command Format

RESET
Controller Command
RESET

Code
08H

Controller Data
No data bytes

This command is used to tell the Coin Changer that it must return to its default-operating mode. It must
abort all communication and disable all acceptance until otherwise instructed by the Controller.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 25 of 60

GET STATUS
Controller Command
GET STATUS
Z1-Z3

Code
0CH

Coin Type, 3 bytes. Indicates the coin enables for coin types 0 to 23.
Coin Type Routing, 3 bytes. Indicates what coin types can be routed to the Coin
Changers tubes. Valid coin types are 0 to 23.

Z4-Z6

Coin Type
Byte Z1 bits
7 6 5 4 3 2

2
3

1
8

1
7

1
6

Coin Type Routing

Byte Z4 bits
7 6 5 4 3 2

2
3

1
7

2
2

2
2

Coin Changer Response Data

6 bytes: Z1 Z6

2
1

2
1

2
0

2
0

1
9

1
9

1
8

Byte Z2 bits
7 6 5 4 3 2 1 0
Coin types enabled if bits set
1 1 1 1 1 1 9 8
5 4 3 2 1 0

Byte Z5 bits
7 6 5 4 3 2 1 0 7
Coin types can be routed if bits set
1 1 1 1 1 1 1 9 8 7
6 5 4 3 2 1 0

Byte Z3 bits
4 3 2

Byte Z6 bits
4 3 2

NOTE: Coin type credits sent as FFH are assumed to be Free Vend tokens and their value is assumed to
be worth one vend.

TUBE STATUS
Controller Command
TUBE STATUS
Z1-Z3

Code
0AH

Coin Changer Response Data

18 byte: Z1-Z27

Tube Full Status - 3 bytes.

Indicates status of coin tube for coin types 0 to 23.

A bit is set to indicate a full tube.
7

Byte Z1 bits
5 4 3 2

2
3

2
2

2
1

1
7

2
0

1
9

1
8

Byte Z2 bits
0 7 6 5 4 3 2 1 0 7
Tube for Coin types is full if bits set
1 1 1 1 1 1 1 9 8 7
6 5 4 3 2 1 0

Byte Z3
4 3 2
4

Z3-Z27Tube Status 24 bytes.

Indicates the greatest number of coins that the changer knows reliably can be paid
out. A bytes position in the 24-byte string indicates the number of coins in a tube for a
particular coin type. For example, the first byte sent indicates the number of coins in a
tube for coin type 0. Bytes not sent are assumed to be zero.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 26 of 60

NOTE: If a Coin Changer can detect a tube jam, defective tube sensor, or other malfunction, it will
indicate the tube is bad by sending a tube full status and a count of zero for the malfunctioning coin
type.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 27 of 60

POLL
Controller Command
POLL

Code
0BH

Bill-to-Bill unit Response Data

1 or 2 bytes: Z1 or Z1- Z2

Indicates state of the Coin Changer and its activity. The Coin Changer may send 1or 2 of the following
data bytes:
Response data
bytes
Z1
Z2
10H

Description
Power Up

11H

Initialize

12H

Idling

13H

Accepting

14H

Unit Disable

14H

Changer Busy

16H
17H

Changer Pay Out Busy

Escrow request

18H

Double Arrival

19H

No Credit

13H

Coin Routing Error

13H

Generic Acceptor Error

13H

Defective Tube Sensor

13H

Coin Jam

13H

Tube Jam

40 - 4FH
(0100xxxx)

Coin accepted to cash

box

50 - 5FH
(0101xxxx)

Coin accepted to tube

60 - 6FH

Not used

70 - 7FH
(0111xxxx)

Coin was rejected

80 FFH

Coin dispensed

The state of Coin Changer after power up

The state, in which Coin Changer executes
initialization on the RESET command of the Controller.
In this state Coin Changer waits for an inserting of coin
into its front bezel.
In this state Coin Changer validates a coin and
determines its denomination.
The Coin Changer has been disabled by the Controller
and also the state in which Coin Changer is after
initialization
The Coin Changer is busy and cannot answer a
detailed command right now.
The Coin Changer is busy activating Pay Out devices.
An escrow lever activation has been detected.
Two coins were detected too close together to validate
either one.
A coin was validated but did not get to the place in the
system when credit is given.
A coin has been validated, but did not follow the
intended routing.
The Coin Changer has detected that the validator has
been removed or not responding.
The Coin Changer has detected one of the tube
sensors behaving abnormally.
A coin(s) has jammed in the acceptance path.
A tube Pay Out attempt has resulted in jammed
condition.
xxxx = coin type deposited (0 to 15).
Z = number of coins in the tube for the coin type
accepted.
xxxx = coin type deposited (0 to 15).
Z = number of coins in the tube for the coin type
accepted.
xxxx = coin type deposited (0 to 15).
Z = number of coins in the tube for the coin type
accepted.
yyy = number of coins dispensed.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 28 of 60

(1yyyxxxx)

manually

xxxx = coin type dispensed (0 to 15)

Z = number of coins in the tube for the coin type
accepted.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 29 of 60

ENABLE COIN TYPES

Controller Command
ENABLE COIN TYPES
Y1 Y3

Code
0CH

Controller Data
4 bytes: Y1 Y6

Coin enable 3 bytes

Byte Y1 bits
5 4 3 2

2
3

2
2

2
1

1
7

1
6

2
0

1
9

1
8

Byte Y2 bits
7 6 5 4 3 2 1 0
Coin types enabled if bits set
1 1 1 1 1 1 9 8
5 4 3 2 1 0

Byte Y3 bits
4 3 2
4

A bit is set to indicate a coin type is accepted. For example, bit 6 is set to indicate coin type 6, bit 15 is set
to indicate coin type 15, and so on. To disable the changer, disable all coin types by sending a data block
containing 000000H. All coins are automatically disabled upon reset.
Y6 Y6

Manual Dispense enable 3 bytes

Byte Y4 bits
5 4 3 2

2
3

2
2

2
1

1
7

1
6

2
0

1
9

1
8

Byte Y5 bits
6 5 4 3 2 1 0
Dispense enabled if bits set
1 1 1 1 1 1 9 8
5 4 3 2 1 0
7

Byte Y6 bits
4 3 2
4

A bit is set to indicate dispense enable. For example, bit 2 is set to enable dispensing of coin type 2. This
command enables/disables manual dispensing using optional inventory switches. All manual dispensing
must be disabled while in the sales mode.

DISPENSE
Controller Command
DISPENSE

Code
0DH

Y1 =

Indicates coin types 0 to 23 to be dispensed.

Y2 =

Indicates number of coins to be dispensed.

Controller Data
2 bytes: Y1-Y2

If two coin types have the same value, the highest coin type must be paid out first.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 30 of 60

IDENTIFICATION
Controller Command
IDENTIFICATION
Bytes
Z1-Z5
Z6-Z12
Z13-Z16
Z17-Z19

Code
0FH

Acceptor Response Data

19 bytes:
Z1 Z19

Description
Model No. & Model Code 5 bytes
Serial Number 7 bytes Factory assigned serial number
Version 4 bytes Current software version
Country 3 bytes ISO code

Bytes Z1-Z19 must be sent as ASCII Characters zero (30H) and blanks (20H) are acceptable.

GET COIN TABLE

Controller Command
GET COIN TABLE

Code
10H

Acceptor Response Data

80 bytes: Z1-Z80

Command for request coin type description.

Z1-Z80

The 80 - byte string consists from 24 five-byte words.

Byte 1 of word hex representation most significant digit of the denomination.
Bytes 2-4 of word country code in ASCII characters.
Byte 5 of word this byte used to determine decimal placement or proceeding zeros. If bit
D7 is 0, the bits D0-D6 indicate the number of proceeding zeros. If bit D7 is 1, the bits D0D6 indicates the decimal point position starting from the right and moving to the left.
A five-byte position in the 80-bytes string indicates coin type description for the particular coin type. For
example, first five byte correspond bill type=0, second five byte correspond bill type=1 and so on.
Example of coin type description for 25-cent USA: 0x19USD, 0x82;
Unsent bytes are assumed to be zero.

DOWNLOAD
Controller Command

Code

Controller Data

DOWNLOAD

50H

NONE

This command is not implemented in current Coin Changer software releases and will always return an
INV response.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 31 of 60

CONTROLLER/BILL VALIDATOR Communication Specification

4.5

Introduction.

This section defines the communication bytes sent and received between the Bill Validator and the
Controller. Unless stated otherwise, all information is assumed to be in a hexadecimal format. The Bill
Validators address is 03H.

4.6

Command Protocol

If a Controller command is received by the Bill Validator, which is not executable in its present state, the
Bill Validator issues ILLEGAL COMMAND message.

4.7

Controller Commands
Command

RESET
GET STATUS

HEX Code
30H
31H

SET SECURITY

32H

POLL

33H

ENABLE BILL TYPES

34H

STACK

35H

RETURN

36H

IDENTIFICATION

37H

HOLD
SET BARCODE
PARAMETERS

38H

EXTRACT BARCODE
DATA
GET BILL TABLE
GET CRC32 OF THE
CODE
DOWNLOAD
(see details for subcommands)

REQUEST STATISTICS

41H

Description
Command for Bill Validator to self-reset
Request for Bill Validator set-up status
Sets Bill Validator Security Mode. Command is followed
by set-up data. See command format
Request for Bill Validator activity Status
Indicates Bill Type enable or disable. Command is
followed by set-up data. See command format
Sent by Controller to send a bill in escrow to the drop
cassette
Sent by Controller to return a bill in escrow
Request for Software Part Number, Serial Number,
Asset Number
Command for holding of Bill Validator in Escrow state
Command for settings the barcode format and number
of characters
Command for retrieving barcode data if barcode
coupon is found. If this command is sent when barcode
coupon is not found the Bill Validator returns ILLEGAL
COMMAND response.
Request for bill type description

51H

Request for Bill Validators firmware CRC32.

50H

Command for transition to download mode.

60H

Command for retrieving full information about

acceptance performance.

39H
3AH

The IDENTIFICATION, GET BILL TABLE, DOWNLOAD and REQUEST STATISTICS commands should
be sent by the Controller when Bill Validator is in the following states: Power up, Initialize, one of the
Failure states (41H-47H) or Unit Disabled. Otherwise an ILLEGAL COMMAND response will be returned.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 32 of 60

4.8

Controller Command Format

RESET
Controller Command
RESET

Code
30H

Controller Data
No data bytes

This command is used to tell the Bill Validator that it must return to its default operating mode. It must
abort all communication, reject any bills in the validation process, return any bills in the escrow position,
and disable all other activity until otherwise instructed by the Controller.

GET STATUS
Controller Command
GET STATUS
Z1-Z3
Z4-Z6

Code
31H

Validator Response Data

6 bytes: Z1 Z6

Bill Type, 3 bytes. Indicates the bill enables for bill types 0 to 23.
Bill Security Levels, 3 bytes. Indicates the security level for bill types 0 to 23.

Bill Type
Byte Z1 bits
Byte Z2 bits
Byte Z3 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
Bill Security Levels
Byte Z4 bits
Byte Z5 bits
Byte Z6 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0

SET SECURITY
Controller Command
SET SECURITY

Code
32H

Controller Data
3 Bytes: Y1 Y3

Byte Y1 bits
Byte Y2 bits
Byte Y3 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0

A bit is set to indicate the type of bill(s), which are set to a high security level.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 33 of 60

POLL
Controller Command
POLL

Code
33H

Bill Validator Response Data

1 or 2 bytes: Z1 or Z1- Z2

Indicates state of the Bill Validator and its activity. The Bill Validator may send 1or 2 of the following data
bytes:
Response data
bytes
Z1
Z2
10H

Power Up

11H

Power Up with Bill in

Validator

12H

Power Up with Bill in

Stacker

13H

Initialize

14H

Idling

15H

Accepting

17H

Stacking

18H
19H
1AH

1BH
1CH
1CH
1CH
1CH
1CH
1CH

Description
The state of the Bill Validator after power up
Power up with bill in the Bill Validator. After a RESET
command from the Controller Bill Validator returns the
bill and continues initializing.
Power up with bill in Stacker (Bill was transported too
far to be returned). After the Bill Validator is reset and
INITIALIZING is complete, status will immediately
change to STACKED(81H) (Credit Recovery feature).
Bill Validator executes initialization after the RESET
command from Controller.
Bill Validator waits for an inserting of bill into its bill
path.
Bill Validator executes scanning of a bill and
determines its denomination.
Bill Validator transports a bill from Escrow position to
drop cassette and remains in this state until the bill is
stacked or jammed.

Bill Validator transports a bill from Escrow position back

to customer and remains in this state until customer
removes the bill or the bill is jammed.
Bill Validator has been disabled by the Controller or just
Unit Disabled
came out of initialization
The state, in which the bill is held in Escrow position
Holding
after the HOLD command of the Controller.
Bill Validator cannot answer with a full-length message
right now.
YH Device Busy
On expiration of time YH, peripheral is accessible to
polling. YH is expressed in multiple of 100
milliseconds.
Generic rejecting code. Always followed by rejection reason byte (see below).
Rejecting due to
60H
Insertion error
Insertion
Rejecting due to
61H
Dielectric error
Magnetic
Rejecting due to
62H
Previously inserted bill remains in head
Remained bill in head
Rejecting due to
63H
Compensation error/multiplying factor error
Multiplying
64H Rejecting due to
Bill transport error
Returning

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 34 of 60

1CH

65H

1CH

66H

1CH
1CH

67H
68H

1CH

69H

1CH

6AH

1CH
41H

6CH

42H
43H
44H
45H
46H
47H
47H
47H
47H
47H
47H
47H
47H
47H

80H
81H
82H

Conveying
Rejecting due to
Identification1
Rejecting due to
Verification
Rejecting due to Optic
Rejecting due to Inhibit
Rejecting due to
Capacity
Rejecting due to
Operation
Rejecting due to Length
Drop Cassette Full
Drop Cassette out of
position
Validator Jammed
Drop Cassette Jammed

Identification error
Verification error
Optic Sensor error
Return by inhibit denomination error
Capacitance error
Operation error

Length error
Drop Cassette full condition
The Bill Validator has detected the drop cassette to be
open or removed.
A bill(s) has jammed in the acceptance path.
A bill has jammed in drop cassette.
Bill Validator sends this event if the intentions of the
Cheated
user to deceive the Bill Validator are detected.
When the user tries to insert a second bill when the
previous bill is in the Bill Validator but has not been
Pause
stacked. Thus Bill Validator stops motion of the second
bill until the previous bill is stacked.
Generic Failure codes. Always followed by failure description byte (see below).
50H Stack Motor Failure
Drop Cassette Motor failure
Transport Motor Speed
51H
Transport Motor Speed failure
Failure
52H Transport Motor Failure
Transport Motor failure
53H Aligning Motor Failure
Aligning Motor failure
Initial Cassette Status
54H
Initial Cassette Status failure
Failure
One of the optic sensors has failed to provide its
55H Optic Canal Failure
response.
56H Magnetic Canal Failure
Inductive sensor failed to respond
Capacitance Canal
5FH
Capacitance sensor failed to respond
Failure
Events with credit.
Y = bill type (0 to 23).
If bill type is enabled with escrow the Bill Validator
YH Escrow position
waits command from Controller to stack or to return bill.
If during 10 sec command will not be sent bill will be
returned.
YH Bill stacked
Y = bill type (0 to 23)
YH Bill returned
Y = bill type (0 to 23)

YH =17H(2310) corresponds to a barcode coupon.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 35 of 60

ENABLE BILL TYPES

Controller Command
ENABLE BILL TYPES

Code
34H

Controller Data
6 bytes: Y1 Y6

Byte Y1 bits
Byte Y2 bits
Byte Y3 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
NOTE: Sending 000000H disables the Bill Validator.
Byte Y4 bits
Byte Y5 bits
Byte Y6 bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types with escrow enabled if bits set
2 2 2 2 1 1 1 1 1 1 1 1 1 1 9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
NOTE: On power-up or reset all bill acceptance and escrow are disabled.

STACK
Controller Command
STACK

Code
35H

Controller Data
No data bytes

This command causes the Bill Validator to send the bill in escrow position to the drop cassette.
NOTE: After a STACK command the Bill Validator should respond to a POLL command with the BILL
STACKED message within 30 seconds. If this command is sent when the Bill Validator is not in ESCROW
state the ILLEGAL COMMAND message is returned.

RETURN
Controller Command
RETURN

Code
36H

Controller Data
No data bytes

This command causes the Bill Validator to return bill in escrow position to the customer.

NOTE: After a RETURN command the Bill Validator should respond to a POLL command with the BILL
RETURNED message within 30 seconds. If this command is sent when the Bill Validator is not in
ESCROW state the ILLEGAL COMMAND message is returned.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 36 of 60

IDENTIFICATION
Controller Command
IDENTIFICATION
Bytes
Z1-Z15
Z16-Z27
Z28-Z34

Code
37H

Bill-to-Bill unit Response Data

34 bytes:
Z1 Z34

Description
Part Number 15 bytes, ASCII characters
Serial Number 12 bytes Factory assigned serial number, ASCII characters
Asset Number 7 bytes, unique to every Bill Validator, binary data

Bytes Z1-Z27 must be sent as ASCII Characters. Zero (30H) and Blank (20H) are acceptable. Asset
Number must be sent as binary code.
15 bytes

FL-US1701

7 bytes

12 bytes

00K038AS3419 Binary code

Asset Number

Serial Number
Model

This command is valid in the following states only: Power up, Initialize, one of the Failure states (41H47H) or Unit Disabled.

HOLD
Controller Command
HOLD

Code
38H

Controller Data
No data bytes

This command allows the controller to hold Bill Validator in Escrow during 10 s. After this time the
Controller should send the STACK or RETURN command. For continued holding in an Escrow state it is
necessary to resend this command. Otherwise the Bill Validator will execute return of a bill.

SET BARCODE PARAMETERS

Controller Command
SET BARCODE PARAMETERS

Code
39H

Controller Data
2 bytes: Y1-Y2

Used to set the barcode format and number of characters.

Y1 - bar code format. 01H = interleaved 2 of 5.
Y2 - number of characters (min 6, max 18).

EXTRACT BARCODE DATA

CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 37 of 60

Controller Command
EXTRACT BARCODE DATA

Code
3AH

Bill Validator Response Data

n bytes: Z1-Zn

Z1-Zn - n bytes ASCII of barcode data, n is equal min 6 bytes, max 18 bytes. Data is sent most
significant byte first. Parameter n is assigned by command SET BARCODE PARAMETERS.
This command may be sent at any time after the Bill Validator responds to the Poll command by event
80H, 81H or 82H and the bill type indicates barcode token presence (23). Barcode data of a successful
reading is preserved until next bill will be inserted. Otherwise an ILLEGAL COMMAND response will be
returned.

GET BILL TABLE

Controller Command
GET BILL TABLE

Code
41H

Bill Validator Response Data

120 bytes: Z1-Z120

Command for request bill type description.

Z1-Z120

The 120 - byte string consists from 24 five-byte words.

Byte 1 of word hex representation most significant digit of the denomination.
Bytes 2-4 of word country code in ASCII characters.
Byte 5 of word this byte used to determine decimal placement or proceeding zeros. If bit
D7 is 0, the bits D0-D6 indicate the number of proceeding zeros. If bit D7 is 1, the bits D0D6 indicate the decimal point position starting from the right and moving left.
A five-byte position in the 120-bytes string indicates bill type description for the particular bill type. For
example, first five byte correspond bill type=0, second five byte correspond bill type=1 and so on.
Example:

Bill Type
0
1
2
3
4
5
6
7
8
9
10
11

Denomination
Code
First Byte
0x1
0x2
0x5
0x5
0x19
0x19
0x19
0x19
0x1
0x5
0x1
0x2

Country
Code
3 bytes
ITL
ITL
ITL
NLC
NLC
NLC
NLC
NLC
USA
USA
USA
USA

Denomination
Code
Second Byte
0x3
0x3
0x3
0x82
0x82
0x81
0x0
0x2
0x0
0x0
0x1
0x1

Denomination
1,000
2,000
5,000
.05
.25
2.5
25
2500
1
5
10
20

Lira
Lira
Lira
Crown
Crown
Crown
Crown
Crown
Dollar
Dollar
Dollar
Dollar

Unsent bytes are assumed to be zero.

This command is valid in the following states only: Power up, Initialize, one of the Failure
states (41H-47H) or Unit Disabled.

GET CRC32 OF THE CODE

CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 38 of 60

Controller Command
GET CRC32 OF THE CODE

Code
51H

Bill Validator Response Data

4 bytes: Z1-Z4

Z1-Z4 - 4 bytes of CRC, MSB first.

This command is valid in the following states: Power up, Initialize, one of the Failure states (41H-47H) or
Unit Disabled.

DOWNLOAD
Controller Command
DOWNLOAD

Code
50H

Controller Data
NONE

Command for transition Bill Validator to download mode.

Upon receipt of this command and issuing of confirmation ACK the Bill Validator transits to download
mode. In this mode the Bill Validator receives DOWNLOAD command with sub-commands only. All other
commands will be ignored.
Issuing of confirmation ACK by Bill Validator to the DOWNLOAD command is delayed for up to the time
of command execution (200 ms).
This command is valid in the following states: Power up, Initialize, one of the Failure states (41H-47H) or
Unit Disabled.
Controller Command
Code
DOWNLOAD
50H
(Switch to DOWNLOAD/Request Status)

Sub-Command
00H

Bill Validator Response Data

1 byte: Z1

Command for polling boot loader program status. This command should be send for transition to
download mode and after issuing operation command.
Z1
If Z1= 00H boot loader program is ready to execute download commands;
If Z1= E0H boot loader program has executed previous operation command successfully;
If Z1= E1H boot loader program has executed previous operation command with error.
Controller Command
DOWNLOAD
(Request block size)

Code
50H

Sub-Command
01H

Bill Validator Response Data

1 byte: Z1

Request for memory block size. Further programming with DOWNLOAD Write To Memory must be
performed with blocks of this size. No defaults are defined for data block size, and no assumptions
should be made valid response to block size request is the only way of evaluating the actual block size
for the session given.
Z1
DATA block size index. Actual block size is 2^Z1.
Ex: if DATA block size is 512 bytes then size index is 9 (512=2^9).

Controller Command
DOWNLOAD

Code
50H

Sub-Command
Controller Data
Bill Validator Data
02H
(n+5) bytes: Y1-Y(n+5)
1byte:Z1

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 39 of 60

(Write to memory)
Command for writing data to memory.
Y1-Y2
Length of message;
Y3-Y5
AdrLow, AdrMid, AdrHigh are the address first byte of n Data bytes;
Y6-Y(n+5)
n Data bytes (following requested block size).
Z1
if Z1=E0H data received successfully
If Z1=E1H data received with error
Controller Command
DOWNLOAD
(Exit)

Code
50H

Sub-Command
03H

Bill Validator Response Data

1 byte: Z1

Command for exiting to normal operation.

Z1

If Z1= E0H - CRC of freshly written code matched the one supplied with code itself;
If Z1= E2H - CRC of freshly written code did not match the one supplied with code itself;

REQUEST STATISTICS
Controller Command
REQUEST STATISTICS

Code
60H

Bill Validator Response Data

4358bytes: Y1-Y4358

Command for retrieving statistical data

To describe the Bill Validator performance characteristics more meaningfully all cumulative data are
grouped into three aggregates of counters. The first aggregate is formed by 16 sets of 96 counters each.
The second aggregate is formed by 20 sets of 46 counters each. The third aggregate is formed by 20
sets of one counter each. Each aggregate keeps track of Bill Validator events on a different statistical
basis.
In the first aggregate sets are averaged by 10000 inserted bills, in the second aggregate sets are
averaged by 500 inserted bills, and in the third aggregate by 50 inserted bills.
The first aggregate counters are populated after insertion of every 10000 bills is completed, second after insertion of 500 bills, third - after insertion of 50 bills. Aggregates contain circular buffers, i.e. one set
of counters in every aggregate always contains current results. For every aggregate counter sets are
output the most recent set last, therefore if circular buffer is not full zeroes will precede normal statistic
data.
Such organization of the statistical data allows analyzing change of the characteristics of Bill Validator
depending on number of the inserted bills for various scales with points 10000 bills, 500 bills and 50 bills.
Below as an example the diagrams of change of some characteristics for these three scales are given.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 40 of 60

Rate of acceptance
98%
97%
96%
95%
94%
93%

n=10000
n

2n 3n 4n 5n 6n 7n 8n 9n 10n 11n 12n 13n 14n 15n 16n

Diagram 1

Number of
inserted bills

Number of Returned bills

by capacitance criteria
10
9
8
7
6
5

n=500
n

2n 3n 4n 5n 6n 7n

Total number of
jams

13n 14n 15n 16n 17n 18n 19n 20n

n
Diagram
2

Number of
inserted bills

6
5
4
3
2

n=50

1
n 2n 3n

4n

5n 6n 7n

13n 14n 15n 16n 17n 18n 19n 20n

n

Diagram 3
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 41 of 60

Number of
inserted bills

In response to a REQUEST STATISTICS command Bill Validator sends Y1-Y4358 bytes. Y1-Y2 is length
of message (see 2.3). Y3-Y4358 corresponds to the following table.
1.
2.
3.
4.
5.
6.

Type of Data
Identification data
16 sets of first aggregate
20 sets of second aggregate
20 sets of third aggregate
Table of denominations
Currency names block

Numbers of bytes
32
(Y3-Y34)
16x179=2864 (Y35-Y2898)
20x66=1320 (Y2899-Y4218)
20x1=20
(Y4219-Y4238)
100
(Y4239-Y4338)
20
(Y4339-Y4358)

Format of identification data block:

Bytes
Z1-Z3
Z4
Z5

Z6-Z12

Z13
Z14-Z25
Z26-Z32

Description
Country Code 3 bytes, ASCII characters
Denomination count 1 byte (number of denominations accepted), binary
Data format version 1 byte, RESERVED FOR FACTORY USE
Last statistics reset Date and Time 8 bytes, format shown below:
- LSB of year (ex: for year 2002, its 210 decimal), 1 byte (Z6);
- MSB of year (ex. for year 2002, its 7 decimal), 1 byte (Z7);
- Month, 1 byte (Z8);
- Day, 1 byte (Z9);
- Hour (24-hour based), 1 byte (Z10);
- Minutes, 1 byte (Z11);
Seconds, 1 byte (Z12).
Reserved
Serial Number 12 bytes, ASCII
Reserved

Format of statistical data for one set of 1/10000 aggregate:

Z1-Z2
Z3-Z4
Z5-Z6

Z41-Z42
Z43-Z44
Z45-Z46

Z81-Z82
Z83-Z84
Z85-Z86

Z121-Z122
Z123-Z124
Z125_Z126

Z161-Z162
Z163-Z164
Z165-Z166
Z167

Number
Number
Number

Number
Number
Number

Number
Number
Number

Number
Number
Number

Number
Number
Number
Number

Inserted bills
of Accepted bills for 1 st denomination
of Accepted bills for 2 nd denomination
of Accepted bills for 20 th denomination
of Returned bills by optical criteria for 1st denomination
of Returned bills by optical criteria for 2nd denomination
of Returned bills by optical criteria for 20 th denomination
of Returned bills by magnetic criteria for 1 st denomination
of Returned bills by magnetic criteria for 2 nd denomination
of Returned bills by magnetic criteria for 20 th denomination
of Returned bills by capacitance criteria for 1 st denomination
of Returned bills by capacitance criteria for 2 nd denomination
of
of
of
of

Returned bills by capacitance criteria for 20 th denomination

Unrecognized bills
Returned bills by length
Failures by magnetic

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 42 of 60

Z168
Z169
Z170
Z171
Z172
Z173
Z174
Z175
Z176
Z177
Z178
Z179

Number
Number
Number
Number
Number
Number
Number
Number
Number
Number
Number
Number

of
of
of
of
of
of
of
of
of
of
of
of

Failures by optics
Failures of transport mechanism
Failures of stacking mechanism
Failures of aligning mechanism
Jams in drop cassette
Jams at entrance sensor
Jams at both entrance and aligning sensors
Jams at aligning sensor
Jams at aligning and optical sensors
Jams at optical sensor
Jams at optical and exit sensors
Jams at exit sensor

* - Number of denominations accepted includes both old and new denominations, if theyre present. Order
of denominations is listed in table of denominations

Format of statistical data for one set of 1/500 aggregate:

Z1-Z2
Z3-Z4

Z39-Z40
Z41
Z42

Z60
Z61
Z62
Z63
Z64
Z65
Z66

Number of Accepted bills for 1 st denomination

Number of Accepted bills for 2 nd denomination

Number of Accepted bills for 20 th denomination

Number of Returned bills by verification for 1 st denomination
Number of Returned bills by verification for 2 nd denomination

Number of Returned bills by verification for 20 th denomination

Number of Returned bills by optical criteria
Number of Returned bills by magnetic criteria
Number of Returned bills by capacitance criteria
Number of Jams at bezel
Number of Jams at transport path
Total number of Jams

Format of statistical data for one set of 1/50 aggregate:

Z1

Total number of Jams

Format of denominations table:

Z1-Z100

The 100 byte string consisting of 20 five-byte words.

Two most significant bits of first byte in every word denomination type (old or new).
Coding of a denomination type:
7th bit 6th bit
denomination type
0
0
Old denomination
0
1
New denomination
Other bits of first byte hex representation of the most significant digit of the

denomination.

Bytes 2-4 of word country code in ASCII characters.

Byte 5 of word used to determine decimal placement or proceeding zeros. If bit D7 is 0,
the bits D0-D6 indicate the number of proceeding zeros. If bit D7 is 1, the bits D0-D6
indicate the decimal point position starting from the right and moving left.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 43 of 60

Example:
Denomination
Code
First Byte
0x1
0x5
0x1
0x41
0x2
0x42
0x5
0x45
0x1
0x41
0x1
0x2
0x42
0x5
0x45
0x1
0x2
0x5

Country
Code
3 bytes
USA
USA
USA
USA
USA
USA
USA
USA
USA
USA
MXN
MXN
MXN
MXN
MXN
MXN
MXN
MXN

Denomination
Code
Second Byte
0x0
0x0
0x1
0x1
0x1
0x1
0x1
0x1
0x2
0x2
0x1
0x1
0x1
0x1
0x1
0x2
0x2
0x2

Denomination
1 Dollar
5 Dollars
10 Old Dollars
10 New Dollars
20 Old Dollars
20 New Dollars
50 Old Dollars
50 New Dollars
100 Old Dollars
100 New Dollars
10 Pesos
20 Old Pesos
20 New Pesos
50 Old Pesos
50 New Pesos
100 Pesos
200 Pesos
500 Pesos

Format of currency names block:

Names of currencies comprise a formatted ASCII data string where currency names appear in a
sequence corresponding to the table of denominations. Currency names are separated by slash. String is
terminated with dot.
Example:

Dollar/Peso.
Command REQUEST STATISTICS is valid in the following states: Power up, Initialize, one of the Failure
states (41H-47H) or Unit Disabled.

If statistic data is not correct Bill Validator sends an error response with data field set to 31H (INVALID
STATISTIC DATA).

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 44 of 60

5
5.1

CONTROLLER/ Card Reader Communication Specification

Introduction

This section defines the communications bytes sent and received between Card Reader and the
Controller. The Card Reader s address is 04H.
Unless stated otherwise, all information is assumed to be in hexadecimal format. The numbers will be
sent most significant byte first.

5.2

Card Reader States

Card Readers may be viewed as state machines. These states are as follows:
1) Inactive
2) Disabled
3) Idling
4) Ready for Transaction
5) Vending
6) Busy
7) Vend OK/Vend Failed
5.2.1 Inactive
This is the state of the card reader at power up or after a reset. All cards except for stored value cards
(for balance inquiry after internal initialization completes) will not be accepted. The card reader cannot
leave this state until all SETUP information is received from the Controller.
5.2.2 Disabled
The card reader automatically enters this state from the Inactive state when it has received all SETUP
information from the Controller and completes its internal initialization. It will also enter the Disabled state
from the Idling state when it receives the READER/DISABLE command. While in the Disabled state,
stored value cards will be accepted (for balance inquiries), but no vending requests will be granted.
5.2.3 Idling
In this state, cards may be used for transactions. The card reader will remain in this state until a valid card
is read (when it will enter the Ready for Transaction state), a READER/DISABLE command is received
(when it will return to the Disabled state) or a RESET is received (when it will enter the Inactive state).
5.2.4 Ready for Transaction
In the Idling state, when a valid card is processed, the card reader will enter the Ready for Transaction
state. This indicates that the card reader is available for vending activities. The only structured exits from
the Ready for Transaction state are:
- Through the VEND/SESSION COMPLETE subcommand from the Controller (for a no-value cards,
ex. debit and credit cards; for stored value cards this command makes no sense but will not
generate an error);
- Through card removal (for stored value cards only).

Other VEND subcommands will cause the card reader to leave the Ready for Transaction state and enter
the Vending state when products are purchased.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 45 of 60

5.2.5 Vending
This state is entered from the Ready for Transaction state upon reception of a VEND/VEND REQUEST
command from the Controller.

5.2.6 Busy
This state is entered when Card Reader starts performing internal operations and exited upon completion
of internal operations. Exit is done to the state present before entering Busy, except for error conditions
appeared while in Busy.

5.2.7 Vend OK/Vend Failed

This state is entered after processing Vend Request command. When all transactions with card and/or
bank are finalized this state is returned to POLL command and cleared upon successful readout or kept
until successful readout in case of communication errors.

5.3

Command Protocol

The card reader will provide an informational response immediately with the requested data.

5.4

Controller Commands

COMMAND
RESET
SETUP
POLL
VEND
ENABLE/DISABLE
IDENTIFICATION
DOWNLOAD

5.5

HEX CODE
30H
11H
33H
13H
14H
15H
50H

DESCRIPTION
Command for Card Reader to self-reset.
Send/Request Card Reader setup status.
Request for Card Reader activity status.
Vend state control.
Disabled/Enabled state control.
Request for Model, Serial Number, Software Version,
Localization ISO code.
Command for transition to download mode.

Controller Command Format

RESET
Controller Command
RESET

Code
30H

Controller Data
No data bytes

This command is the vehicle that the Controller must use to tell the Card Reader that it must return to the
Inactive state. With the exception of the ACK response, it must abort all communication, terminate any
ongoing transaction (with a refund, if appropriate), eject the card (if applicable), and go to the Inactive
state until otherwise instructed by the Controller.

The Controller must follow the RESET command with the SETUP and ENABLE/DISABLE commands to
enable vending transactions. RESET command is not valid for Vending, Busy and Vend OK/Vend Failed
states. If received with any of these states active, a COMMAND INVALID response is issued.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 46 of 60

SETUP
Controller Command
SETUP
Y1 =

Code/Subcommand
11H

Controller Data
Y1

Response Data
Z1 Z2

Controller Capabilities Level

Indicates the highest capabilities level the Controller supports. Currently, this byte is set
to 01.
RESPONSE - CARD READER CONFIGURATION:
Indicates the Card Reader is responding to a SETUP request from the Controller. This
response includes the following data:
Z1 =

Z2 =

Card Reader capabilities level

Capabilities level of the Card Reader. Currently the highest
capabilities level is 01.
Miscellaneous options
b0 Fund Restoring capable
0=
the card reader is NOT capable of restoring funds to
the users card or account. Do not request refunds.
1=
the card reader is capable of restoring funds to the
users card or account. Refunds may be requested.
b1 Continuous Payment capable
0=
the card reader is NOT capable of collecting funds
from multiple cards for single payment. Money
withdraw request will be denied if funds are
insufficient in authorized card.
1=
the card reader is capable of collecting funds from
multiple cards for single payment. Money withdraw
request will be approved even if funds are insufficient
in authorized card
Other bits are ignored (under card reader capabilities level 01) and may be
set to any value.

POLL
Controller Command
POLL

Code
33H

Controller Data
No data

Response Data
Z1 up to Z2

The POLL command is used by the Controller to obtain information from the Card Reader. This
information may include user actions, hardware malfunctions, software malfunctions or information
explicitly requested by the controller.
Controller may receive the following POLL responses from the Card Reader:

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 47 of 60

Response data
bytes

Z1
01H
05H

Description

Z2
Inactive
Disabled

06H

Idling

07H

Ready for Transaction

08H

Vending

12H
13H

Vend OK
Vend Failed

09H
10H

Z2

11H

Malfunction/Error
Delayed
Busy

Indicates the Card Reader has been reset/re-powered.

Indicates the Card Reader has received all SETUP
information from the Controller. Card Reader will also
enter the Disabled state from the Enabled state when it
receives the ENABLE/DISABLE command.
In this state cards may be used for transactions. Card
Reader will enter the Enabled state from the Disabled
state when it receives the ENABLE/DISABLE
command.
Indicates the Card Reader is available for vending
activity.
This state is entered from the Idling state upon
reception of a VEND REQUEST command from the
Controller.
Transaction successfully completed.
Transaction failed for a reason not relevant to the
Controller.
The Card Reader is reporting a malfunction or error.
Indicates that a full response to a command is not
available right now. This may occur, for example, while
card reader is dialing out to the bank.
Card Reader is busy with internal operations

INACTIVE:
Indicates the Card Reader has been reset, due to either an external RESET or an
internally detected condition.

Z1 = 05H

DISABLED:
Indicates the Card Reader has received all SETUP information from the Controller and
completed its internal initialization. Card Reader will also enter the Disabled state from
the Idling state when it receives the ENABLE/DISABLE command.

Z1 = 06H

IDLING:
In this state cards may be used for transactions. Card Reader will enter the Idling state
from the Disabled state when it receives the ENABLE/DISABLE command.

Z1 = 07H

READY FOR TRANSACTION:

Indicates the Card Reader is available for vending activity.

Z1 = 08H

VENDING:
This state is entered from the Idling state upon reception of a VEND REQUEST
command from the Controller.

Z1 = 12/13H

VEND OK/VEND FAILED:

This state is entered from the Vending state upon completion of a transaction.

Z1 = 01H

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 48 of 60

Z1 = 09H

MALFUNCTION/ERROR:
The Card Reader is reporting a malfunction or error. This response includes the
following information:
Z2 =

Error Code = xxxxyyyy

xxxx =
0010: Card Error (e.g. stored value card removed while transaction is in progress,
or a no-value card read incomplete) 1 or 2
0100: Communications Error (checksum error/data frame inconsistent) 2
1000: Reader Failure3

Other values not defined under card reader capabilities level 01.
1Transient error Reported once.
2Non-transient error reported every POLL until cleared. Card Reader
functional after error cleared.
3Non-transient error reported every POLL until cleared. Card Reader not
presently functional.
yyyy = Manufacturer defined sub-code

VEND/BEGIN SESSION
Controller Command
Code/Subcommand
Controller Data
Response Data
VEND/BEGIN SESSION 13H
Y1
none
Y1 = 10H
VEND BEGIN SESSION - subcommand.
Indicates that VMC is requesting card authentication from the Card Reader. This
command may only be issued in Idling state, otherwise a COMMAND INVALID will be
returned. If a stored value card is already authenticated, the Ready for Transactions
state will be entered immediately. For the no stored value card an invitation is issued
for the user to insert/swipe a card, and after completed, Ready for Transactions state is
entered. Its at Controllers discretion to terminate this condition if a time-out occurs
without a card being authenticated, as this state is never left on Card Readers initiative
for no stored value cards and left on Card Readers initiative when card is removed for
stored-value cards.

VEND/GET FUNDS

Controller Command
Code/Subcommand
Controller Data
Response Data
VEND/GET FUNDS
13H
Y1
Z1-Zn
Y1 = 00H
VEND GET FUNDS - subcommand.
Indicates that VMC is requesting a balance from the card. This command may only be
issued in Ready for Transactions state, otherwise a COMMAND INVALID will be
returned.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 49 of 60

Z1 =

Flag indicating that a card contains stored value:

E0HE7H the card is a stored value card;
E8HEFH - the card is not a stored value card;

All subsequent data exists for stored value cards only and consists of N 8-byte blocks, one block
per each wallet with different currency in the card. Wallets are numbered sequentially as they
arrive in response to VEND/GET FUNDS, starting from 0.
Z2-Z4 =

Currency code, three ASCII characters, following ISO 4217;

Z5-Z8 =

Wallet balance in composite format, i.e. binary unsigned integer value; Z9 least
significant bits compose the fractional part to obtain the exact value Z5Z8 should
be treated as a 32-bit binary value, then divided by 10^Z9; the division result is the
integer part of funds value, the remainder stays for the fractional part.
Number of decimal places.

Z9

VEND/VEND REQUEST
Controller Command
Code/Subcommand
Controller Data
Response Data
VEND/
VEND REQUEST
13H
Y1 Y10
none
Y1 = 01H
VEND REQUEST - subcommand.
Indicates the customer has made a selection. The Controller is requesting vend
approval from the Card Reader before dispensing the product. The Card Reader enters
state Vending after reception of this command and keeps it until transaction is finalized
(state Vend OK is entered) or error occurs (state Vend Fail is entered). The state is
preserved until successful read-out.
Y1 = 02H
VEND REQUEST REFUND - subcommand.
Indicates the controller is requesting a refund for the given wallet with amount given.
The Card Reader enters state Vending after reception of this command and keeps it
until transaction is finalized (state Vend OK is entered) or error occurs (state Vend Fail
is entered). The state is preserved until successful read-out.
VEND REQUEST and VEND REQUEST REFUND commands are valid only in Ready
For Transaction state, otherwise COMMAND INVALID is issued.
Wallet number. Wallets are numbered serially starting from 0 as returned by
VEND/GET FUNDS command. If card is not a stored value card Y2 may be assigned
any value.

Y3 Y6 =
Y7 Y10 =

Amount to draw in composite format, same as for VEND/GET FUNDS command.

Accumulated amount in composite format, same as for VEND/GET FUNDS
command. This field represents amount, accumulated for the given card session (i.e. it
is set 0 prior to issuing VEND/BEGIN SESSION and incremented prior to sending
every VEND/VEND REQUEST with requested value). This value is used by Card
Reader to trace retransmissions of VEND/VEND REQUEST issued by Controller.
Separate accumulated amounts are maintained for every wallet reported by the Card
Reader.

Y2 =

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 50 of 60

VEND/VEND CANCEL
Controller Command
Code/Subcommand
Controller Data
Response Data
VEND/
13H
Y1
Z1
VEND CANCEL
Y1 = 03H
VEND CANCEL - subcommand.
This command can be issued by the Controller to cancel a VEND REQUEST command
before the Card Reader has sent a VEND APPROVED/DENIED. The Card Reader will
respond to VEND CANCEL with a VEND DENIED or VEND CANCEL FAILED and
return to the Idling state. State preserved until successful read-out. This command is
valid only in Vending state, otherwise COMMAND INVALID response is issued.
Z1 = 06H
Z1 = 07H

VEND DENIED:
Approval denied for the customers selection. Do not dispense any products/credit
services.
VEND CANCEL FAILED:
Funds are already withdrawn and may not be returned. Products/services should be
dispensed.

VEND/SESSION COMPLETE
Controller Command
Code/Subcommand
Controller Data
VEND/
SESSION COMPLETE
13H/04H
Y1
Y1 = 04H
SESSION COMPLETE subcommand.
This tells the Card Reader that the session is complete and to return to Idling state.

ENABLE/DISABLE
Controller Command
READER/DISABLE

Code/Subcommand
14H

Controller Data
Y1

Any transaction in progress will not be affected and must continue to its normal completion.
Y1 = 00H

DISABLE - subcommand.

Y1 = 01H

This informs the Card Reader that it has been disabled, i.e. it must no longer accept a
customers card for the purpose of vending. Vending activities may be re-enabled using
the READER ENABLE command. The Card Reader must retain all SETUP information.
ENABLE - subcommand.
This informs the Card Reader that it has been enabled, i.e. it must be ready for
accepting cards.

Reader may be enabled from Disabled state only and disabled from Idling state only,
otherwise a COMMAND INVALID response will be issued.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 51 of 60

IDENTIFICATION
Controller Command
IDENTIFICATION
Bytes
Z1-Z15
Z16-Z27
Z28-Z34

Code
15H

Card Reader Response Data

Z1 Z34

Description
Part Number 15 bytes, ASCII characters
Serial Number 12 bytes Factory assigned serial number, ASCII characters
Asset Number 7 bytes, unique to every Card Reader, binary data

Bytes Z1-Z27 must be sent as ASCII Characters. Zero (30H) and Blank (20H) are acceptable. Asset
Number must be sent as binary code.
15 bytes

FL-US1701

12 bytes

7 bytes

00K038AS3419 Binary code

Asset Number

Serial Number
Model

DOWNLOAD
Controller Command
DOWNLOAD

Code
50H

Controller Data
No data bytes

Command for transition Card Reader to download mode. Currently not defined and returns COMMAND
INVALID response.

5.6

Non-Response Time

The maximum non-response time for a Card Reader is 5 seconds. This is the maximum time for which a
Card Reader will not respond to a command with ACK, NAK or a data message.

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 52 of 60

APPENDIX

Example CCNET Message Sequences

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 53 of 60

6.1

Power Up & Reset sequence

Controller
POLL
ACK
RESET
POLL
ACK
GET STATUS
ACK
SET SECURITY
IDENTIFICATION
ACK
POLL
ACK
POLL
ACK

6.2

ACK

------>
<----------->
------>
<------

POWER UP

Power is switched on
Reset peripheral

ACK

------>
<----------->

INITIALIZE

------>
<----------->

BILL-TO-BILL UNIT CONFIG.

------>
<------

Comments

Bill-to-Bill unit is initializing

Collect operational parameters

Update bill security levels

ACK

------>
<----------->

BILL-TO-BILL UNIT ID

Collect asset inf.

------>
<----------->

INITIALIZE

Bill-to-Bill unit is initializing

------>
<----------->

UNIT DISABLE

All bill types are disabled

Enable sequence

Controller
ENABLE BILL TYPES
POLL

Power Up & Reset sequence

Bill-to-Bill unit

Enable sequence
Bill-to-Bill unit
------>
<----------->
<------

Comments
Enable appropriate bill types

ACK
IDLING

Bill-to-Bill unit is waiting accepting of

bill

------>

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 54 of 60

6.3

Disable sequence

Controller
ENABLE BILL TYPES

6.4

Disable sequence
Bill-to-Bill unit
------>
<------

ACK

Bill Accept sequence (Bill stacked).

Bill Accept sequence
- Bill stacked Bill-to-Bill unit

Controller
POLL
ACK
POLL
ACK

------>
<----------->
------>
<------

ACK

------>
.
.
.
------>
<----------->

STACK

------>

POLL

<-----POLL
ACK

POLL
ACK
CASSETTE STATUS

------>
<----------->
.
.
.
------>
<----------->
------>
<------

Bill is accepting

ESCROW POSITION

Bill type in escrow position

ESCROW POSITION

Bill type in escrow position

Send bill to drop cassette or one of
the recycling cassette

ACK
STACKING

Bill is stacking

BILL STACKED

Bill has been stacked

Collect operational parameters

BILL-TO-BILL UNIT
CASSETTE STATUS

------>

ENABLE BILL TYPES

------>
<------

ACK

------>
<------

IDLING

ACK

Comments

ACCEPTING

ACK

POLL

Comments
Disable all bill types

Enable appropriate bill types

Bill-to-Bill unit is waiting accepting of

bill

------>

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 55 of 60

6.5

Bill Accept sequence (Bill returned)

Bill Accept sequence
- Bill returned Bill-to-Bill unit

Controller
POLL
POLL

POLL
ACK
RETURN
POLL
ACK

POLL
ACK
ENABLE BILL TYPES
POLL
ACK

Comments

------>
<------

ACCEPTING

Bill is accepting

------>
<------

ESCROW POSITION

Bill type in escrow position

ESCROW POSITION

Bill type in escrow position

.
.
.
------>
<----------->
------>
<----------->
<----------->
.
.
.
------>
<----------->

Return bill to consumer

ACK
RETURNING

Bill is returning

BILL RETURNED

Bill has been returned

------>
<------

ACK

Enable appropriate bill types

------>
<------

IDLING

Bill-to-Bill unit is waiting acceptance of

bill

------>

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 56 of 60

6.6

Bill Dispense sequence (Bill dispensed).

Controller
DISPENSE

POLL

ACK

POLL

Bill Dispense sequence

- Bill returned Bill-to-Bill unit

------>
<------

ACK

------>
<------

BILL DISPENSING

Bill transporting to dispenser

------>
.
.
.
------>
<------

BILL DISPENSED

Dispense is completed. Bills pay to

customer.

ACK

------>

CASSETTE STATUS

------>
<------

ACK

------>

POLL

------>
<------

ACK

Comments
Dispensed bills to customer

Collect operational parameters

BILL-TO-BILL UNIT
CASSETTE STATUS

IDLING

Bill-to-Bill unit is waiting accepting of

bill

------>

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 57 of 60

6.7

Bill Unload sequence (Bill unloaded).

Controller
UNLOAD

POLL

ACK

POLL

Bill Unload sequence

- Bill unloaded Bill-to-Bill unit

------>
<------

ACK

------>
<------

BILL UNLOADING

Bill transporting to drop cassette.

------>
.
.
.
------>
<------

BILL UNLOADED

Unload is completed. All Recycling

Cassettes are empty. (All banknotes
stacked in drop cassette.

ACK

------>

CASSETTE STATUS

------>
<------

ACK

------>

POLL

------>
<------

ACK

Comments
Stacking all bills from Recycling
Cassettes to drop cassette. (Unload
Bill-to-Bill unit)

Collect operational parameters

BILL-TO-BILL UNIT
CASSETTE STATUS

IDLING

Bill-to-Bill unit is waiting acceptance

of bill

------>

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 58 of 60

6.8

Set cassette type sequence

Set cassette type sequence
Bill-to-Bill unit

Controller
CASSETTE STATUS

------>
<------

BILL-TO-BILL UNIT
CASSETTE STATUS

ACK

------>

SET CASSETTE TYPE

------>
<------

Assigning cassette to bill type

------>
.
.
.
------>
<------

ACK

POLL

ACK

------>

CASSETTE STATUS

------>
<------

ACK

------>

POLL

------>
<------

Bills transporting to drop cassette.

SET CASSETTE
TYPE

Setting recycling cassette type is

completed.

BILL-TO-BILL UNIT
CASSETTE STATUS

Collect operational parameters

Necessary recycling cassette is
empty. It is assigned to new bill type.

IDLING

Bill-to-Bill unit is waiting acceptance

of bill

Power Up with Bill in Stacker sequence for Bill Validator

Controller
POLL

ACK

SETTING
CASSETTE TYPE

------>

ACK

6.9

Collect operational parameters

Cassette necessary for setting is not
empty.

ACK

------>
<------

POLL

Comments

Power Up & Reset sequence

Bill Validator
------>
<------

POWER UP WITH BILL IN

STACKER

Comments

On the Power up the validator will

check if the bill was in the process of
being stacked during the last power
down. The bill being stacked is
defined as time between the bill
clears the exit sensor and before the
response to a poll command with the
Bill Stacked event is sent.

------>

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 59 of 60

RESET
POLL
ACK
GET STATUS
ACK
SET SECURITY
IDENTIFICATION
ACK
POLL
ACK
POLL
ACK
POLL
ACK

------>
<------

Reset peripheral
ACK

------>
<----------->

INITIALIZE

------>
<----------->

BILL VALIDATOR CONFIG.

------>
<----------->
<----------->
------>
<----------->
------>
<----------->
------>
<----------->

Bill Validator is initializing

Collect operational parameters

Update bill security levels

ACK
Collect asset inf.
BILL VALIDATOR ID

INITIALIZE

Bill Validator is initializing

BILL STACKED

Bill Validator confirmation signal

UNIT DISABLE

All bill types are disabled

CashCode Company Inc

PT# MAN_CCNET Rev.2.3.1 NOV 2002

Page 60 of 60