Innovative NV9 Manual

SSP SMILEY®
SECURE
PROTOCOL
INTELLIGENCE IN VALID
A
SSP SMILEY®
SECURE
PROTOCOL
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol 2
CHANGE HISTORY
Innovative Technology Ltd
Title: SSP Gaming Protocol
Drawing No: GA138 Project:
Author: P. Dunlop Date: 26/05/98
Format: MS Word 2000
Issue Protocol Ver.
Release Date
Mod By
Comments
Issue 1 1 26/05/98 PD
Issue 2 1 03/02/99 TB
Issue 3 1 11/06/99 AK
Issue 4 2 4/02/00 PD
Issue 5 2 20/06/00 PD
Issue 6 2 26/10/00 PD
Issue 7 2 20/11/00 PD
Issue 8 2 20/01/01 TB
Issue 9 2 4/10/01 TB
Issue 10 2 21/01/02 AK
Issue 11 2 23/03/04 PK General Revision
Issue 12 3 05/08/04 TB Protocol Version 3
Issue 13 3 02/01/06 TB Protocol Version 3 events
Issue 14 4 16/11/07 TB BNV Barcode commands
Issue 14G4 PD Encryption, Smart Range
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol
3
Issue 4. – Peter Dunlop 13/01/2000
Introduction of generic commands. Introduction of commands/ responses for coin readers
and coin hoppers. Introduction of addressing structure. Introduction of encrypted packets.
Upgrade “Protocol Version’ to 2.
Issue 5. – Peter Dunlop 20/06/2000
Clarification of remote download specification – addition of example sequences. Correction
of command conflict – SYNC and LAST REJECT CODE specified with same code, LAST
REJECT CODE has been changed to 0x17. Addition of notes to identify function not currently
implemented on NV4 / NV4X.
Issue 6. – Peter Dunlop 26/10/00
Block size missing from header description in version 5 – fixed. Rewording of description of
remote downloading protocol. Addition of maximum block size. No code changes required
in product firmware or demo code. Changed example CRC code from assembler example to
C example. Addition of simplified remote programming flow chart.
Issue 7. – Peter Dunlop 20/11/00
Introduction of basic card reader commands. Addition of FAIL as a generic response.
Addition of manufacturers extension generic command for use internally.
Issue 8. – Tim Beswick 20/01/01
Change SLAVE_RESET form generic response to an event response to reflect correct
behaviour. Addition of euro county code to appendix.
Issue 9. – Tim Beswick 04/10/01
Addition of HOLD command to allow escrow implementation on BNV
Issue 10. – Andrew Kennerley 21/01/02
Addition of slave address for a Audit Collection Device.
Issue 11. – Peter King 23/03/04
General Revision Correction of Slave ID Reference in section 3.1
Addition of extra address allocation for note validators
Issue 12. – Tim Beswick 05/08/04
Addition of SHOW_RESET_EVENTS BNV commands and note cleared at reset events.
Protocol taken to Version 3
Issue 13. – Tim Beswick 02/01/06
Addition of Cash box removed and replaced events. Explanation of Note start-up events in
expanded protocol.
Issue 14. – Tim Beswick 16/11/07
The addition of Bar code ticket commands and events for Banknote validator. Updated
reject reason codes.
Issue 14G. – Peter Dunlop 5/1/09
Revision of Encryption layer to propose a more secure system & interface for smart payout.
Commands that must be encrypted on encryption-enabled products are highlighted in red.
Copyright Innovative Technology GA138 –14G

Copyright Innovative Technology GA138 –14G
TABLE OF CONTENTS
Change History
2
1 Introduction 5
2 General description 6
3 Hardware Layer 7
4 Transport Layer 8
4.1 Packet Format 8
4.2 Packet Sequencing 8
5 Encryption Layer (currently not implemented) 9
5.1 Packet Format 9
5.2 Encryption Keys 10
5.3 Encryption Algorithm 11
6 Control Layer 12
6.1 Introduction 12
6.2 Addressing 12
6.3 Peripheral Validation 12
6.4 Generic Commands and Responses 13
6.4.1 Generic Commands 13
6.4.2 Generic Responses 14
6.4.3 Remote Programming (version 2.65 and later) 14
6.4.4 Example Programming File Formats (ITL NV4 Validator) 16
6.4.5 Simplified Remote Programming Flow Chart 17
6.5 Banknote Validator 18
6.5.1 BNV Operations 18
6.5.2 BNV Commands 18
6.5.3 BNV Response to Polls 22
6.6 Coin Acceptor 23
6.6.1 perationCoin Acceptor O 23
6.6.2 Coin Acceptor Commands 23
6.6.3 Coin Acceptor Responses to Polls 25
6.7 Single Coin Hopper 25
6.7.1 perationsSingle Coin Hopper O 25
6.7.2 Single Coin Hopper Commands 25
6.7.3 Single Coin Hopper Responses to Polls 26
6.8 Basic Card Reader 27
6.9 Smart Hopper – provisional, subject to change 27
6.9.1 Smart Hopper Operation 27
6.9.2 Smart Hopper Commands 27
6.9.3 Smart Hopper Responses to Polls 29
6.10 Smart Payout – provisional, subject to change 30
6.10.1 Smart Payout Operation 30
6.10.2 Smart Payout Commands 30
6.10.2.1
SMART Mode Commands 31
6.10.2.2
DUMB Mode Commands – Not recommended 31
6.10.3 Smart Payout Responses to Polls 32
Appendix A – Country Codes 33
Appendix B – Block Encryption Routines 34
Appendix C – CRC Calculation Routines 35
SSP® Smiley Secure Protocol 4

Copyright Innovative Technology GA138 –14G
1 INTRODUCTION
This manual describes the operation of the Smiley®Secure Protocol - SSP as fitted with
manual as there are many new features permitting
anual please contact the ITL for assistance. In
sted by contacting: support@innovative-
miley® and the ITL Logo are international registered trademarks and they are the
ean and International Patents and Patents
novative Technology is not responsible for any loss, harm, or damage caused by the
Firmware Version 1.10 or greater.
L recommend that you study thisIT
new uses and more secure applications.
you do not understand any part of this mIf
this way we may continue to improve our product. Alternatively visit our web site at
www.innovative-technology.co.uk
nhancements of SSP can be requeE
technology.co.uk
S
property of Innovative Technology Limited.
nnovative Technology has a number of EuropI
Pending protecting this product. If you require further details please contact ITL®.
In
installation and use of this product. This does not affect your local statutory rights. If in
doubt please contact Innovative Technology for details of any changes
MAIN HEADQUARTERS
Innovative Technology Ltd
Derker Street – Oldham – England - OL1 4EQ
Tel: [phone] Fax: [phone]
E-mail: [email protected]
Web site: www.innovative-technology.co.uk
SSP® Smiley Secure Protocol 5

Copyright Innovative Technology GA138 –14G
2 GENERAL DESCRIPTION
a secure interface specifically designed by ITL®to
e all
he interface uses a master slave model, the host machine is the master and the
ata transfer is over a multi-drop bus using clock asynchronous serial transmission with
ach SSP device of a particular type has a unique serial number; this number is used to
.
mmands are currently provided for coin acceptors, note acceptors and coin hoppers. All
EATURES:
• Serial control of Note / Coin Validators and Hoppers
er
iation
BENEFITS:
• Proven in the field
t interfacing of transaction peripherals.
nes.
o help in the software implementation of the SSP, ITL can provide C Code, DLL controls
Smiley®Secure Protocol - SSP is
address the problems experienced by cash handling systems in gaming machines.
Problems such as acceptor swapping, reprogramming acceptors and line tapping ar
addressed.
T
peripherals (note acceptor, coin acceptor or coin hopper) are the slaves.
D
simple open collector drivers. The integrity of data transfers is ensured through the use of
16 bit CRC checksums on all packets.
E
validate each device in the direction of credit transfer before transactions can take place
It is recommended that the encryption system be used to prevent fraud through bus
monitoring and tapping. This is compulsory for all payout devices.
Co
current features of these devices are supported.
F
• 4 wire (Tx, Rx, +V, Gnd) system
• RS232 (like) - open collector driv
• High Speed 9600 Baud Rate
• 16 bit CRC error checking
• Data Transfer Mode
• Encryption key negot
• 128 Bit AES Encrypted Mode
• Simple and low cos
• High security control of payout peripherals.
• Defence against surrogate validator fraud.
• Straightforward integration into host machi
• Remote programming of transaction peripherals
• Open standard for universal use.
T
and Visual Basic applications on request. Please contact support@innovative-
technology.co.uk.
SSP®Smiley Secure Protocol 6

Copyright Innovative Technology GA138 –14G
3 HARDWARE LAYER
cter transmission based on standard 8-bit asynchronous data
.
e data format is as follows:
Encoding:NRZ
AUTION: Power to peripheral devices would normally be via the serial bus however
e
ECOMMENDED CONNECTORS
mmended the first is a 15 pin 0.1” pitch header (Molex
ote Acceptor Conne
e second is a 10-pin 0.1” dual row shrouded header with polarized slot. This is primarily
Communication is by chara
transfer. Only four wires are required TxD, RxD, +V and ground. The transmit line of the
host is open collector, the receive line of each peripheral has a 10Kohm pull-up to 5 volts
The transmit output of each slave is open collector, the receive input of the host has a
single 3k3 ohm pull-up to 5 volts.
Th
Baud Rate: 9600
Duplex: FullDuplex
Startbits:1
DataBits:8
Parity: none
Stopbits:2
C
devices that require a high current supply in excess of 1.5 Amps e.g. hoppers would b
expected to be supplied via a separate connector.
R
Two types of connectors are reco
22-01-2155), this is primarily for use on bank note acceptors (see table 1).
Table 1 – Bank N ctor Details
Th
for use with coin acceptors. The pin out is shown below (see table 2).
Table 2 – Coin Acceptor Connector Details
Pin Signal
Pin 1 TxD
Pin 5 TxD
Pin 6 Address 0 (currently not implemented)
Pin 12 GND
Pin 11 +12V
Link Pin 3 to Pin 8 ENABLE
Pin Signal
Pin
Signal
1 TxD 2 Reserved
3 RxD 4 Reserved
5 Address 0 6 Address 1
7 +12V 8 Ground
9 Address 2 Address 410
SSP® Smiley Secure Protocol
7

SSP® Smiley Secure Protocol 8
4 TRANSPORT LAYER
4.1 PACKET FORMAT
Data and commands are transported between the host and the slave(s) using a packet
format as shown below.
STD SEQ/Slave ID LENGTH
DATA
CRCL
CRCH
STX: Single byte indicating the start of a message - 0x7F hex.
SEQ/Slave ID: Bit 7 is the sequence flag of the packet, bits 6-0 represent the address of
the slave the packet is intended for, the highest allowable slave ID is 0x7D
LENGTH: The length of the data included in the packet - this does not include STX, the CRC
or the slave ID.
Slave ID: Single byte used to identify the address of the slave the packet is intended for.
DATA: Commands or data to be transferred.
CRCL, CRCH: Low and high byte of a forward CRC-16 algorithm using the Polynomial (X16
+ X15 + X2+1) calculated on all bytes, Except STX. It is initialised using the seed 0xFFFF.
The CRC is calculated before byte stuffing.
4.2 PACKET SEQUENCING
Byte stuffing is used to encode any STX bytes that are included in the data to be
transmitted. If 0x7F (STX) appears in the data to be transmitted then it should be
replaced by 0x7F, 0x7F.
Byte stuffing is done after the CRC is calculated, the CRC its self can be byte stuffed. The
maximum length of data is 0xFF bytes. The sequence flag is used to allow the slave to
determine whether a packet is a re-transmission due to its last reply being lost.
Each time the master sends a new packet to a slave it alternates the sequence flag. If a
slave receives a packet with the same sequence flag as the last one, it does not execute
the command but simply repeats its last reply.
In a reply packet the address and sequence flag match the command packet. This
ensures that no other slaves interpret the reply as a command and informs the master
that the correct slave replied.
After the master has sent a command to one of the slaves, it will wait for 1 second for a
reply. After that, it will assume the slave did not receive the command intact so it will re-
transmit it with the same sequence flag.
The host should also record the fact that a gap in transmission has occurred and prepare
to poll the slave for its serial number identity following the current message. In this way,
the replacement of the host’s validator by a fraudulent unit can be detected.
The frequency of polling should be selected to minimise the possibility of swapping a
validator between polls. If the slave has not received the original transmission, it will see
the re-transmission as a new command so it will execute it and reply. If the slave had seen
the original command but its reply had been corrupted then the slave will ignore the
command but repeat its reply. After twenty retries, the master will assume that the slave
has crashed.
A slave has no time-out or retry limit. If it receives a lone sync byte part way through
receiving a packet it will discard the packet received so far and treat the next byte as an
address byte.
Copyright Innovative Technology GA138 –14G

5 ENCRYPTION LAYER
5.1 PACKET FORMAT
Encryption is mandatory for all payout devices and optional for pay in devices. Encrypted
data and commands are transported between the host and the slave(s) using the
transport mechanism described above, the encrypted information is stored in the data
field in the format shown below (see figure 1).
STX SEQ/Slave ID LENGTH
DATA
CRCL
CRCH
STEX Encrypted Data
LENGTH DATA PACKING CRCL CRCH
Figure 1 – Encrypted Data Format
STEX: Single byte indicating the start of an encrypted data block - 0x7E hex.
LENGTH: The length of the data included in the packet - this does not include STEX, the
next key or the CRC.
PACKING: Random data to make the length of the length +data +packing +CRCL +CRCH
to be a multiple of 16 bytes. There must be at least one random packing byte in each
pocket.
CRCL, CRCH: Low and high byte of a forward CRC-16 algorithm using the polynomial (X16 +
X15 + X2+1) calculated on all bytes, except STEX. It is initialised using the seed 0xFFFF.
After power up and reset the slave will stay disabled and will respond to all commands
with the generic response Key_Not_Set, without actioning the command, until the key
has been negotiated.
There are two classes of command and response, general commands and commands
involved in credit transfer. General commands may be sent with or without using the
encryption layer. The slave will reply using the same method, unless the response
contains credit information, in this case the reply will always be encrypted. Credit
transfer commands, a hopper payout for example, will only be accepted by the slave if
received encrypted. Commands that must be encrypted on an encryption-enabled
product are highlighted in red throughout this document. The STEX byte is used to
determine the packet type. Ideally all communications will be encrypted.
After the data has been decrypted the CRC algorithm is preformed on all bytes including
DATA, CRCL and CRCH. The result of this calculation will be zero if the data has been
decrypted with the correct key. If the result of this calculation is non-zero then the
peripheral should assume that the host did not encrypt the data (transmission errors are
detected by the transport layer). The slave should go out of service until it is reset.
SSP® Smiley Secure Protocol
9
Copyright Innovative Technology GA138 –14G

5.2 ENCRYPTION KEYS
The encryption key is 128 bits long, however this is divided into two parts. The lower 64
bits are fixed and specified by the machine manufacturer, this allows the manufacturer
control which devices are used in their machines. The higher 64 bits are securely
negotiated by the slave and host at power up, this ensures each machine and each
session are using different keys. The key is negotiated by the Diffie-Hellman key
exchange method. See: http://en.wikipedia.org/wiki/Diffie-Hellman. The exchange
method is summarised in the table below. C code for the exchange algorithm is
available from ITL.
Host Slave
1 Generate prime number GENERATOR
2 Use command ‘Set Generator to
send to slave
3 Check GENERATOR is prime and store
4 Generate prime number MODULUS
5 Use command ‘Set Modulus’ to send
slave
6 Check MODULUS is prime and store
7 Generate Random Number
HOST_RND
8 Calculate HostInterKey: =
GENERATOR ^ HOST_RND mod
MODULUS
9 Use command ‘Request Key
Exchange’ to send slave
10 Generate Random Number SLAVE_RND
11 Calculate SlaveInterKey: = GENERATOR
^ SLAVE_RND mod MODULUS
12 Send to host as reply to ‘Request Key
Exchange’
13 Calculate Key: = SlaveInterKey ^
HOST_RND mod MODULUS
Calculate Key: = HostInterKey ^
SLAVE_RND mod MODULUS
Note: ^ represents ‘to the power of’
Action Command Code (HEX)
Set Generator 0x4A, Generator
Set Modulus 0x4B, Modulus
Request Key Exchange 0x4C, HostInterKey
Table 1 – Encryption Control Commands
SSP® Smiley Secure Protocol 10
Copyright Innovative Technology GA138 –14G

Set Generator: The Nine byte command, the first byte is the command –0x4A. The next
eight bytes are a 64 bit number representing the Generator this must be a 64bit prime
number. The slave will reply with OK or ‘Parameter out of range’ if the number is not
prime.
Set Modulus: The Nine byte command, the first byte is the command –0x4B. The next
eight bytes are a 64 bit number representing the modulus this must be a 64bit prime
number. The slave will reply with OK or ‘Parameter out of range’ if the number is not
prime.
Request Key Exchange: Nine byte command, the first byte is the command –0x4C. The
next eight bytes are a 64 bit number representing the Host intermediate key. If the
Generator and Modulus have been set the slave will calculate then reply with the generic
response and eight data bytes representing the slave intermediate key. The host and
slave will then calculate the key. If Generator and Modulus are not set then the slave will
reply FAIL.
5.3 ENCRYPTION ALGORITHM
The encryption algorithm used is AES with a 128-bit key; this provides a very high level of
security. Data is encrypted in blocks of 16 bytes any unused bytes in a block should be
packed with random bytes. AES is used in electronic codebook mode (ECB). Please
contact ITL for an implementation of key exchange and AES encryption, this is provided as
C source code. See: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard.
The encryption functions included in issue 14 and earlier of this document are redundant.
SSP® Smiley Secure Protocol 11
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol
12
6.0 CONTROL LAYER
6.1 INTRODUCTON
The slave can only respond to requests from the master with an address byte that matches
the slaves address, at no time will the slave transmit any data that is not requested by the
host. Any data that is received with an address that does not match the slave’s address will
be discarded.
The master will poll each slave at least every 5 seconds. The slave will deem the host to
be inactive, if the time between polls is greater than 5 seconds. If the slave does not
receive a poll within 5 seconds it should change to its disabled state. The minimum time
between polls is specified for individual peripherals. Only one command can be sent in any
one poll sequence.
6.2 ADDRESSING
The address of a peripheral consists of two parts, the fixed part that determines the type
of device and the variable part. The variable part is used if there is a number of the same
type of peripheral in the same machine, for example hoppers (see table 4).
The variable part of the address can be set in one of two ways. Firstly it can be
programmed to a fixed number using a PC tool, or the peripheral can be programmed to
take the rest of the address from external pins on the interface connector (Currently not
implemented).
SLAVE ID (Hex)
Peripheral
0x00 Note validator 0
0x01 Note validator 1
0x02 Coin Validator 0
0x03 Coin Validator 1
0x04 Card Reader 0
0x05 Card Reader 1
0x07 Audit Device
0x08 Handheld Audit Collection Device
0x09 – 0x0F Reserved
0x10 – 0x1F Coin Hoppers 0 – 15
0x20 – 0x2F Note Dispensers 0 – 15
0x30 – 0x3F Card Dispensers 0 – 15
0x40 – 0x4F Ticket Dispensers 0 – 15
0x50 – 0x5F Extra Note Validators
0x60 – 0x7E Unallocated
Table 4 – Peripheral Addressing
6.3 PERIPHERAL VALIDATION
To ensure that credit transfers are only received from or sent to genuine devices, the
device receiving the credit must first request the serial number from the sending device
and only accept if the serial number matches a pre-programmed number.
The serial number should be requested after each reset and also after each break in
communications. For example a host machine should request a coin acceptors serial
number at reset or if a poll sequence is unanswered, before enabling the device. Also, a
coin hopper should not process any dispense commands until the host machine has sent
its serial number.
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol 13
6.4 GENERIC COMMANDS AND RESPONSES
Generic commands are a set of commands that every peripheral must
understand and act on (see table 5).
6.4.1 GENERIC COMMANDS
Action Command code (HEX)
Reset 0x01
Host Protocol Version 0x06
Poll 0x07
Get Serial Number 0x0C
Synchronisation command 0x11
Disable 0x09
Enable 0x0A
Program Firmware / currency 0x0B, Programming Type
Manufactures Extension 0x30, Command, Data
Table 5 – Generic Commands
Reset: Single byte command, causes the slave to reset.
Host Protocol Version: Dual byte command, the first byte is the command, the second byte
is the version of the protocol that is implemented on the host, current version is 02.
Poll: Single byte command, no action taken except to report latest events.
Get Serial Number: Single byte command, used to request the slave serial number.
Returns 4-byte long integer.
Most significant byte first e.g.
Serial number = 01873452 = 0x1C962C
So response data would be 0x00 0x1C 0x96 0x2C
Sync: Single byte command, which will reset the validator to expect the next sequence ID
to be 0.
Disable: Single byte command, the peripheral will switch to its disabled state, it will not
execute any more commands or perform any actions until enabled, any poll commands
will report disabled.
Enable: Single byte command, the peripheral will return to service.
Program Firmware / currency:See section 6.4.3 – Remote Programming.
Manufactures Extension: This command allows the manufacturer of a peripheral to send
commands specific to their unit. The intention is that the manufacturer only uses the
extension command internally; it should not when operating in a host machine. The
specific command and any data for that command should follow the Extension command.
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol 14
6.4.2 GENERIC RESPONSES
Table 6 - Generic Responses
Generic Response Response code
OK 0xFO
Command not known 0xF2
Wrong number of parameters 0xF3
Parameter out of range 0xF4
Command cannot be processed 0xF5
Software Error 0xF6
FAIL 0xF8
Key Not Set 0xFA
OK: Returned when a command from the host is understood and has been, or is in the
process of, being executed.
Command Not Known: Returned when an invalid command is received by a peripheral.
Wrong Number Of Parameters: A command was received by a peripheral, but an incorrect
number of parameters were received.
Parameter Out Of Range: One of the parameters sent with a command is out of range.
E.g. trying to change the route map for channel 34 on a coin acceptor.
Command Cannot Be Processed: A command sent could not be processed at that time.
E.g. sending a dispense command before the last dispense operation has completed.
Software Error: Reported for errors in the execution of software e.g. Divide by zero. This
may also be reported if there is a problem resulting from a failed remote firmware
upgrade, in this case the firmware upgrade should be redone.
Key Not Set: The slave is in encrypted communication mode but the encryption keys have
not been negotiated.
6.4.3 REMOTE PROGRAMMING
Table 7 - Remote Programming Code Summary
Code Description
0x0B, Type Start Programming, type (00 – firmware, 01 - currency)
0x16 Programming Status
Using the command 0x0B followed by a parameter that indicates the type of
programming required performs remote programming (see table 7). Send 0x00 for
firmware programming and 0x01 for currency data programming.
The peripheral will respond with a generic reply. If the reply is OK, the host should send the
first block of the data file (the file header). The header has the format shown below (see
table 8). The block size depends on the peripheral used but must be a minimum of 10
bytes to contain the header data.
When the block size for a peripheral is greater than the header length (11 bytes) then the
header is padded out with 0’s to the length of a block. The maximum length of a block is
236 bytes.
Copyright Innovative Technology GA138 –14G

File offset
Table 8 - Remote Programming / Header and Block Size
Description
Size
0 Number of blocks to send (low byte, high byte),
including header block
2 bytes
2 Manufacture code (of file) e.g. ‘ITL’ 3 bytes
5 File type – 0x00 firmware, 0x01 currency 1 byte
6 Unit subtype 1 byte
7 Unit version 1 byte
8 Block length (BL) 1 byte
9 Checksum (CRC of data section of file) CRC low byte 1 byte
A Checksum (CRC of data section of file) CRC high byte 1 byte
B Padded 0’s to block size BL-11 bytes
The peripheral will then respond with OK or HEADER_FAIL depending on the acceptability
of this file (see table 9).
Table 9 – Peripheral Response
Response Code
OK 0xF0
HEADER_FAIL 0xF9
The host will then send the required number of data blocks. The peripheral will respond
with a generic response when each packet has been processed (see table 10).
If the host receives any response other than an OK then that packet is retried three times
before aborting the programming (the peripheral should then be reset). After the last data
packet has been sent and a response received, the host will send a programming status
command 0x16. The peripheral will respond with one of the following codes:
Table 10 - Peripheral Response Codes
Response Code
OK 0xF0
Checksum Error 0xF7
FAIL 0xF8
After a successful programming cycle, the peripheral should be reset. If the programming
cycle does not complete successfully, then the peripheral should be disabled until it can
be programmed successfully.
In the case of an unsuccessful firmware programming cycle, the new firmware will either
be discarded or partly programmed. If the firmware has been partly programmed, then
the peripheral will respond to all Polls with the generic response ‘Software Error’.
The peripheral will not allow the host to enable it until it receives a complete and valid
firmware file.
SSP® Smiley Secure Protocol 15
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol 16
6.4.4 EXAMPLE PROGRAMMING FILE FORMATS (ITL NV4 Validator).
Programming files supplied by Innovative Technology Ltd for NV4 BNV are formatted as
follows (see tables 11 and 12): Variable number of blocks depending on currency, fixed
block length (128 bytes).
Table 11 - Currency File Example
Header block
92, 01, 49, 54, 4C, 01, 01, 01, 80, 8D, 2C
Padded to block length with 0’s
1st data block F0, 34, C0, 21, D3, 00, 00, 5F, 5F, 80h data bytes
2nd data block
FF, 24, D3, 21, 45, 01, 00, 3F, 5F, 80h data bytes
.
.
257th data
block
FF, 24, D3, 21, 45, 01, 00, 3F, 5F, 80h data bytes
Table 12 - Firmware File Example
Header block 01, 01, 49, 54, 4C, 00, 01, 01, 80, FD, 22 Padded to block length with 0’s
1st data block FF, 24, D3, 21, 45, 01, 00, 3F, 5F, 80h data bytes
2nd data block F0, 34, C0, D1, D3, 00, 00, 5F, 5F 80h data bytes
.
.
257th data
block FF, 24, D3, 21, 45, 01, 00, 3F, 5F, 80h data bytes
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol
17
6.4.5 SIMPLIFIED REMOTE PROGRAMMING FLOW CHART
Read Header
Determine: download TYPE, block size and
number of blocks
Send:
START PROGRAMMING, TYPE
OK?
FAIL
Send next data block
(next BLbytes of file)
Last Data Block?
Send:
PROG_STATUS
FAIL Send: RESET
DONE
OK
(First BLbytes of file)
Send: HEADER
Open File
Figure 2 - Programming Flow Chart
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol 18
6.5 BANKNOTE VALIDATOR
6.5.1 BNV OPERATION
When the validator has recognised a note, it will not start to stack it until it receives the
next valid poll command after the read n (n<>0) has been sent. The note will be rejected
if the host responds with a REJECT.
6.5.2 BNV COMMANDS
Action Command code (HEX)
Set inhibits 0x02
Display on 0x03
Display Off 0x04
Set-up Request 0x05
Reject 0x08
Unit data 0x0D
Channel Value data 0x0E
Channel Security data 0x0F
Channel Re-teach data 0x10
Last Reject Code 0x17
Hold 0x18
Enable Protocol Version Events 0x19
Get Bar Code Reader Configuration 0x23
Set Bar Code Reader Configuration 0x24
Get Bar Code Inhibit 0x25
Set Bar Code Inhibit 0x26
Get Bar Code Data 0x27
Table 13 – Bank Note Validator Commands
Set Inhibits: Variable length command, used to control which channels are enabled. The
command byte is followed by 2 data bytes, these bytes are combined to create the
INHIBIT_REGISTER, each bit represents the state of a channel (LSB= channel 1,
1=enabled, 0=disabled). At power up all channels are inhibited and the validator is
disabled.
Display On: Single Byte command, turns on the display illumination bulb.
Display Off: Single Byte command, turns off the display illumination bulb.
Reject: Single byte command causing the validator to reject the current note.
Set-up Request: Single byte command, used to request information about a slave. Slave
will return the following data: Unit Type, Firmware version, Country Code, Value multiplier,
Number of channels, (if number of channels is 0 then 0 is returned and next two
parameters are not returned) Value per channel, security of channel, Reteach count,
Version of Protocol (see table 14).
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol
19
Table 14 - Response to Set-up request
Data Size/type Notes
Unit Type 1 byte, integer 0x00 Note Validator
Firmware Version 4 bytes, string XX.XX (can include space)
Country Code 3 bytes, string See Country Code Table
Value Multiplier 3 bytes, integer 24 bit value
Number of channels 1 byte, integer Highest used channel
Channel Value 15 bytes, integer bytes 1 – 15 values
Security of Channel 15 bytes, integer bytes 1 – 15 security
Reteach count 3 byte, integer Byte 1 - reteach count.
Byte 2, 3 flag register
indicating which channels
have been modified. All set to
zero at factory.
Protocol version 1 byte, integer
Unit Data Request: Single byte command which returns, Unit type (1 Byte integer),
Firmware Version (4 bytes ASCII string), Country Code (3 Bytes ASCII string), Value
Multiplier (3 bytes integer), Protocol Version (1 Byte, integer)
Channel Value Request: Single byte command which returns a number of channels byte
(the highest channel used) and then 1 to n bytes which give the value of each channel up
to the highest one, a zero indicates that the channel is not implemented.
e.g. A validator has notes in Channels 1,2,4,6,7 so this command would return
07,01,02,00,04,00,06,07. (The values are just examples and would depend on the
currency of the unit). The actual value of a note is calculated by multiplying the value
multiplier by channel value. If the number of channels is 0 then only one 0 will be
returned.
Channel Security Data: Single byte command which returns a number of channels byte
(the highest channel used) and then 1 to n bytes which give the security of each channel
up to the highest one, a zero indicates that the channel is not implemented.
(1 = low, 2 = std, 3 = high, 4 = inhibited).
E.g. A validator has notes in Channels 1,2,4,6,7 channel 1 is low security,
channel 6 is high security, all the rest are standard security.
The return bytes would be
07,01,02,00,02,00,02,03
If the number of channels is 0 then only one 0 will be returned.
Channel Reteach Data: Single byte command, which returns 3 bytes.
First byte - the number of times the unit has been manually taught. (1 for each face).
Second byte - Channels 1 to 8 flag register bit 0 = channel 1 to bit 7 = channel 8 if set
shows that the indicated channel has been altered.
Third byte is as second but the channels shown are bit 1 = channel 9 to bit 6 = channel
15.
Last Reject Code: Single byte command, which will return a single byte that indicates the
reason for the last reject. The codes are shown below (see table 15). Specifics of note
validation not shown to protect integrity of manufacturers security.
Copyright Innovative Technology GA138 –14G

SSP® Smiley Secure Protocol 20
Code Reject Reason
0x00 Note Accepted
0x01 Note length incorrect
0x02 Reject reason 2
0x03 Reject reason 3
0x04 Reject reason 4
0x05 Reject reason 5
0x06 Channel Inhibited
0x07 Second Note Inserted
0x08 Reject reason 8
0x09 Note recognised in more than one channel
0x0A Reject reason 10
0x0B Note too long
0x0C Reject reason 12
0x0D Mechanism Slow / Stalled
0x0E Strimming Attempt
0x0F Fraud Channel Reject
0x10 No Notes Inserted
0x11 Peak Detect Fail
0x12 Twisted note detected
0x13 Escrow time-out
0x14 Bar code scan fail
0x15 Rear sensor 2 Fail
0x16 Slot Fail 1
0x17 Slot Fail 2
0x18 Lens Over Sample
0x19 Width Detect Fail
0x1A Short Note Detected
Table 15 – Reject Code Reasons
Hold: This command may be sent to BNV when Note Read has changed from 0 to >0
(valid note seen) if the user does not wish to accept or reject the note with the next
command. This command will also reset the 10 second time-out period after which a note
held would be rejected automatically, so it should be sent before this time-out if an escrow
function is required.
Enable higher protocol version events: Single byte command to enable events
implemented in protocol version >=3. Send this command directly as part of the start-up
routine before any POLLS are sent to ensure any new events are seen. If Command is not
known (F2h) is returned, this feature is not implemented in the firmware. Otherwise a two-
byte response will return: OK, and then the current protocol version of the validator being
addressed.
Copyright Innovative Technology GA138 –14G