menu_fooldal
menu_bemutat
menu_arlista
menu_termekek
menu mark IMD (Integrated
monitoring device)
menu mark Multiplay cabinet
GSM data transfer
device
Database manage-
ment system
menu_bemutat
Converting kits
Reseller activity
Gambling machine resurrection
NOM standardization
Services
Knowledge base
Consultancy
menu_bemutat
menu_bemutat

TECHNICAL REQUIREMENTS FOR CONFIGURATION OF A UNIFORM DATA COMMUNICATION SURFACE OF INTEGRATED CONTROL UNIT (ICU) OF GAMBLING MACHINES

The elaboration of the requirements is based on the authorisation as per §V. of Annex No. 2. of the regulation issued by the PM (Ministry of Finance) under No. 21/2000 (V.18) and the law 4. § (1)  XLV. 1991 relating to the regulation of measurements.

CONTENTS

1.1. SUMMARY, DEFINITIONS
2.1. DATA TRANSMISSION STANDARD
2.2.  CIRCUIT CONNENCTIONS
2.3.  ELECTRIC PARAMETERS OF DATA TRANSMISSION SIGNALS
2.4.  BAUD RATE
2.5.  HARDWARE KEY, CONNECTION POINT SETUP, DATA TRANSMISSION PROTOCOL
3.1. DATA ACQUISITION, DATA RECORDING
3.2.  CONFIGURATION DATA
3.3  DATA READOUT/ENTRY
3.4  CHECKSUM
3.5   ACCESS RIGHT, USAGE OF HARDWARE KEY
3.6  DESCRIPTION OF CONTROL COMMANDS, CODING

1       Summary, definitions

The integrated control unit (ICU) is a hardware equipment freely designed and produced by the manufacturer built in the sealed AWP central unit box, having a data communication contact with the control unit and functioning as a separate systems engineering unit.

It is designed to collect, record and store specific data of the gambling machine for the time stipulated by the valid laws and regulations and to assure configuration data input and reading of stored data on a standard interface.

The ICU has to store accumulated annual, quarterly and monthly values for 5 years. In addition, it has to be able to store data of the last month in a daily breakdown.

The ICU has to store the following data in HUF:

  1. Accumulated value paid in .............................................. (IN)
  2. Accumulated value paid out ........................................... (OUT)
  3. Accumulated value of credit gambled away ................. (BET)
  4. Accumulated value of wins ............................................. (WIN)
  5. Value of the biggest win of the day ................................ (WINMAX)
  6. Number of plays .............................................................. (GAME NR)

The amounts (IN, OUT, BET) out of the above listed values must also be recorded by electromechanical counters of min. 7 digits controlled by AWP.

Wins are counted between two subsequent starts (i.e. one play). Accumulated value of wins (WIN) is calculated by adding the won amount by each play.

The biggest win of the day (WINMAX) is the highest amount won during plays. This must be recorded (value and min/hr).

The play counter (GAME NR) shows the accumulated value of the plays gambled, i.e. when starting a new game the number will be increased by 1.

Different amounts can be calculated by derivation of data recorded by the ICU, e.g. percentage to be paid out to the player according to the laws.

The amounts are to be calculated and displayed by the reader device.

2.1       DATA TRANSMISSION STANDARD

As to data transmission, standard parameters are given for ICU data communication  with the reader and the configuration unit.

Data transmission standard .....................

:

EIA RS232C (CCITT V. 24, DIN 66020)

Data transmission protocol .....................

:

asynchronous serial transmission

Baud rate (bit/s) .....................................

:

1200, 2400, 4800, 9600, 19200, 38400

Start bit (pc)

:

1

Data bit (pc)

:

8

Stop bit (pc)

 

1

Parity bit (pc)

 

none

Connection type

:

DTE - DTE duplex

Connection mode

:

3-phase zero modem

Connection type of reader/configuration equipment

:

9-pole Sub D male

ICU connection type

:

9-pole Sub D male

Connection cable

:

9-pole Sub D female-female

2.2       CIRCUIT CONNECTIONS

The ICU is connected by three cables to the communication device. Their connection and function is standardised. The signalling lines are named as follows:

Y RxD (Receive Data)

Y TxD (Transmit Data)

Y GND (Ground)

9-pole Sub D adapter layout:

1

DCD

(Data Carrier Detect)                                                                            blank

2

RxD

(Receive Data) --------------------------------------------------------------------->

3

TxD

(Transmit Data) -------------------------------------------------------------------->

4

DTR

(Data Terminal Ready)                                                                         blank

5

GND

Ground ------------------------------------------------------------------------------>

6

DSR

(Data Set Ready)                                                                                  blank

7

TRS

(Request to Send)                                                                                 blank

8

CTS

(Clear to Send)                                                                                     blank

9

RI

(Ring Indicator)                                                                                   blank

Forming the connection cable (zero modem):

 

2.3            ELECTRIC PARAMETERS OF DATA TRANSMISSION SIGNALS

The 9-pole Sub D adapter receives bipolar line signals which are coded according to the standard as  logical 0 (SPACE) and logical 1 (MARK).

SPACE (0) = + 3 V ...... + 25 V

MARK (1) = - 3 V ...... + 25 V

(In most cases, approximately +/- 12 V of voltage level is used.)

 

In ideal cases, line signals are square. The pulse generators must be as close as possible to square form. In general, square signal distortion occurs due to the scattered capacity of the wire, therefore data transmission will be of differentiating or integrating type. In such cases, the oscilloscope displays overshoots, negative tilts and deadbeats. This error has a negative effect on the data transmission quality. To sum up: the cable is designed and produced for data transmission, its type should fit the data transfer rate (baud rate) requirements.

2.4       BAUD RATE

Different standard baud rates are applicable to the ICU. The table hereunder lists the values of data transfer rates together with times necessary for transmission of 1 bit and 1 byte.

bit/s

transmission time of 1 bit

(msec)

transmission time of 1 byte

(msec)

(1 start bit, 8 data bits, 1 stop bit)

1200

833,3

8,33

2400

416,7

41,7

4800

203,3

2,08

9600

104,2

1,04

19200

52,1

0,52

38400

26,1

0,26

Recommended rate: 9600 bit/s.

The following table gives the signal shape for transmission of number 53H, as an example:

 

D7

D6

D5

D4

D3

D2

D1

D0

   

53H=

0

1

0

1

0

0

1

1

   
 

msb

           

lsb

------->

First to be transmitted

     

5

       

3

   
 

2.5            HARDWARE KEY, CONNECTION POINT SETUP, DATA TRANSMISSION PROTOCOL

Access levels of ICU are available by hardware key. The hardware key is an electric circuit that enables individual identification of a specific circuit. This means that every circuit has a code number the single occurrence of which is guaranteed by the manufacturer. The ICU must be prepared for reception and identification of hardware keys containing the DS 2401 circuit of Dallas Semiconductor Co. The hardware key circuit is to be connected to the system by a mono jack plug of 6,3 mm in diameter.

The plug connection is a standard mono jack female jack of 6,3 mm in diameter. The connector should be placed on the box terminal in an accessible way. A standard GND terminal of the female plug is connected to the DS 2401 GND, while data flows through the other terminal (data line) (DQ).

Data transmission is through DS 2401 as per one-wire™ single-conductor cable protocol circuit detailed in the manufacturer catalogue. The technical parameters described in the catalogue must be observed! The electronic parts of hardware key must be designed in a way that in case of a failure of the ICU, neither should it damage the circuit of the hardware key due to the failure, nor should it go wrong in case of a short circuit of the connector.

3.1       DATA ACQUISITION, DATA RECORDING

The ICU is to handle logical management of different data groups. These groups are as follows:

  • The values of the previously mentioned data (IN, OUT, CREDIT, WIN, WINMAX, GAME NR)  continuously generated during the game change from time to time. Therefore, the actual value must be available at any time.
  • Closing data related to different calendar dates are to be stored as accounted data for the period stipulated by the law. Therefore the IEK should be suitable to record 31 pieces of daily, 60 pieces of monthly, 21 pieces of quarterly and 6 pieces of yearly groups.
  • During approval procedure of AWP, National Office of Measures (NOM) records various configuration data, therefore entry and readout of these data must be ensured.
  • Data logging is time dependent, therefore the actual correct time must be produced by a real time clock and readout of time must be constantly ensured. Accuracy of the real time clock must be within +/- 1 min/month. Setting and resetting of the real time clock is to be given a particular attention. Setting and resetting of the ICU real time clock is an exclusive right of NOM laboratories.
  • For the input of configuration data and setting of the real time clock write commands must be given. An event log must follow the command. For these purposes, a non-destructive readout memory field must be assured to enable polling and monitoring of all configuration and real time clock data recorded previous to changes and containing information for the whole operational life specified by the law.
  • It is an exclusive right of the NOM expert configuring the system to give such write commands. Therefore, manufacturers and operators can only have operation software that does not contain write commands for configuration and real time clock. Operations within the scope of Gambling Board (GB) and NOM (e.g.: configuration, real time clock setting, reading of audit trail, etc.) can be initiated only after checking of access right, i.e. after entry of the code name. These code names of primary importance must be securely stored on a long-term basis assuring the exclusion of access by any unauthorised third persons.

The followings  are valid for the stored data:

  • Each values of the counter are represented as 4-byte, hexadecimal numbers. The conversion from hexa into decimal values is carried out by the reading unit. During configuration decimal to hexa conversion necessary for set-up of the counter starting value and calculation of derived amounts (e.g.: payout percentage = total wins / total credits) are also carried out by the reader unit.
  • Recorded amount are shown on the counters in 1 HUF units. (The values equal the amount of HUF)
  • Data of the real time clock (date, time) are represented as binary-coded decimal (BCD) numbers, in a standard form: year, month, day, hour, minute (yy, mm, dd, hh, min).
  • Most of the configuration data are constant, i.e. the character string is mixed (consisting numbers and/or letters) and as such, it is stored in ASCII format.
  • The key code represents an 8-byte hexadecimal number (details on DS 2401 data sheet)

Before presentation of data transmission control commands, data groups containing "read only" or "write and read" data commands entered on a uniform serial pad  will be revised in details.

1.                  Actual counter values:

data reading:                     with authority

data writing:                       NOM for start-up values (additional data are to be entered only by AWP)

IN……………………………………………………………..            = 4 bytes

OUT…………………………………………………………..            = 4 bytes

BET......………………………………………………………            = 4 bytes

WIN…………………………………………………………...            = 4 bytes

WINMAX, HR, MIN…………………………………………         = 4 + 1 + 1 + 6 = 4 bytes

GAME NR…………………………………………………    = 4 bytes

2.                  Daily data (31 pcs):

data reading:                        with authority

data writing:                          NOM for start-up values (additional data to be entered only by AWP)

YEAR, MONTH, DAY, IN, OUT, CREDIT, WIN, WINMAX, HR, MIN

1……..1………...1.…....4….4.......4………...4…...4.................1…..1……. = 25 bytes

3.                  Monthly data (61 pcs):

data reading             with authority

data writing:             NOM for start-up values (additional data to be entered only by AWP)

YEAR, MONTH, IN, OUT, CREDIT, WIN

1……..1………...4…..4……4……….4……………………………………. = 18 bytes

4.                  Quarterly data (21 pcs):

data reading             with authority

data writing:             NOM for start-up values (additional data to be entered only by AWP)

YEAR, QUARTERY, IN, OUT, CREDIT, WIN

1……..1……….…….4…..4……4……….4………………………………. = 18 bytes

(QUARTERY: 01m=first, 02m=second, 03m=third, 04m=fourth)

5.                  Annual data (5pcs):

data reading            with authority

data writing:             with authority

YEAR, IN, OUT, CREDIT, WIN

1……..4…..4……4……….4……………………………………. = 17 bytes

6.                  NOM configuration data (18 pcs):

data reading             with authority

data writing:             at configuration by NOM

Data 1 – 13:         Characters defined in ASCII format

Data 14 – 17:       Characters defined in HEXADECIMAL format

Data 18:               Characters defined in ASCII format

7.                  Real time clock data:

data reading             with authority

data writing:             at configuration by NOM

YEAR, MONTH, DAY, HR, MIN

1……..1………...1……1…..1……………………………………………….. = 5 bytes

8.                  Data of real time clock set/reset event log (60 pcs):

data reading             with access right

data writing:             not possible for external user (automatically executed by ICU)

YEAR, MONTH, DAY, HR, MIN, YEAR, MONTH, DAY, HR, MIN

1……..1…….1……1…..1……1……..1………...1……1…..1.. = 10 bytes reset time 
time before resetting

9.         NOM configuration event log data (20 pcs):

data reading                with access right (GB, NOM)

data writing:                 not possible for external user (automatically executed by ICU)

Data 1 – 13:                 Characters defined in ASCII format

Data14 – 17:                Characters defined in HEXADECIMAL format

Data18:                        Characters defined in ASCII format

Data 19– 23:                Characters defined in HEXADECIMAL format

                                    (actual values of counters)

                                    ----------------------------------------------------------total: 366 bytes

 Data 24:                   Save date, time data….................……………………………:     5 bytes

=  307 bytes

10.       Key code data (192 pcs):

Readout of data:           ICD reads, uses, can be read only with authority Data writing: only with authority

(64 GB key + 64 NOM key + 32 Checking lab key + 32 Operator key)
In all: 192 pcs key codes 192 x 8 bytes key codes = 1536 bytes

11.       GB key code usage event log (20 pcs):

Data reading:            with authority (GB, NOM)

Data writing:             not available for external users, automatic function of ICU

KEYCODE, YEAR, MONTH, DAY, HR, MIN, YEAR, MONTH, DAY, HR, MIN

8………....1…….1……….1…...1…1…..1….....1………1…..1….1….….. = 18 bytes

                                    start of key code usage               end of key code usage

12. NOM key code usage event log (20 pcs):

Data reading:           with authority (GB, NOM)

Data writing:             not available for external users, automatic function of ICU

KEYCODE, YEAR, MONTH, DAY, HR, MIN, YEAR, MONTH, DAY, HR, MIN

8………....1…….1……….1…...1…1…..1….....1………1…..1….1….….. = 18 bytes

                                    start of key code usage               end of key code usage

3.2                                          NOM CONFIGURATION DATA
Total: 48 + 76 + 144 + 14 + 64 = 346 bytes


manufacturing data

1.    AWP type                                      : 16 bytes

2.    AWP product number__                           : 16 bytes

3.    AWP manufacturing date                        : 16 bytes


NOM data

4.    AWP serial number of calibration certificate ______            : 16 bytes

5.    AWP validity of calibration certificate_                 : 16 bytes

6.    serial number of program card             : 16 bytes

7.    NOM identification number                      :   8 bytes

8.    code of NOM expert_______                     :   2 bytes

9.    checking date ___                             : 16 bytes

10.  checking lab (CL) code__                        :   2 bytes


operator data

11.  GB certificate number                        : 16 bytes

12.  name of operator                             : 64 bytes

13.  address of operator                             : 64 bytes


counter starting data

14.  Counter step value (HUF)……………….………………..       :   2 bytes

15.  IN counter start value (HUF)………………….…………  :   4 bytes

16.  OUT counter start value (HUF)…………………………       :   4 bytes

17.  BET counter start value (HUF)….…………….……       :   4 bytes

NOM data

18. Notes:_______________________________: 64 bytes

Automatically displayed actual values

19.  IN counter actual value (HUF)....……………………       :   4 bytes

20.  OUT counter actual value (HUF)..…………………  :   4 bytes

21.  BET counter actual value (HUF)...……………………       :   4 bytes

22.  WIN counter actual value (HUF)...………………       :   4 bytes

23.  GAMENR counter actual value...………………       :   4 bytes

3.3       DATA READOUT/ENTRY

ICU data of the gambling machine must be always available when machine is ON. It means that unconfigured ICU must also be in a ready-for-communication status. When switched on, the system should function in this mode as a default.

The ICU should be designed in a way that further data modification changing data representing counter values stored through the previously described uniform serial pad should not occur. This means that no command, hardware or software solution executing changes or modifications to counter values is to be built in the ICU.

Data communication between ICU and AWP must be assured in a way that new game can only be started after all data of the previous game are recorded. AWP must shut down in case of:

  • ICU circuit doesn't work
  • The communication breaks
  • Error is occurred during working

The above requirements are to be observed by the manufacturers.

3.4            CHECKSUM

It has a primary importance to avoid from data getting damaged during transmission. Naturally, it can be assured only in an ideal case because data damage is always a real danger. Therefore, detection of faulty data is to be ensured. This can be easily and effectively achieved by application of a 2-byte-checksum connected to the data flow. If the client detects any difference during control of the checksum, he can reject the received data and ask for repeated transmission. This method is a modulo-checksum addition procedure.

The longest data destined for transmission out of the above described data groups has 64 bytes. This means that the checksum is less than 0FFFFH (65535), i.e. the checksum can be calculated by simple addition. However, if the transmitted character string consists only 0-s, the checksum will be also 0, which excludes the possibility of checking. This problem can be eliminated by adding entered commands to the checksum (which are never 0 due to coding), and consider the 2-byte checksum as the negative of the character sum transmitted by the command. This procedure assures a high level security of data control.

CHECKSUM = NOT (SUM (D1....Dx)

3.5            ENTRY AUTHORITY, USING HARDWARE KEY

The development of ICU should be solved on the way that to fulfil the reading and writing orders can be done only after checking the entry authority. Four levels must be made on the entry authority. These are:

  1. NOM authority
  2. GB authority
  3. Checking lab authority
  4. Operator authority

For the safety storing of the entry codes four non-volatile, programmable memory spaces must be made. ICU must be able to identify 64 pcs NOM codes, 64 pcs GB codes, 32 pcs Checking lab codes and 32 pcs Operator codes. So in all 192 pcs hardware codes must be programmable.

NOM should be able to carry out every reading and writing orders

GB should be able to carry out every reading orders but it can be able to write only onto the GB key code memory space

Checking lab won't get writing authority, even for its own key code memory space. The Checking lab can read only the turnover data that can be read by the

Operator can write only the 32 pcs operator codes, nothing else; it can get only partly reading authority! (Operator key code writing: CDh, 01h…20h orders) The Operator can read out only that part of the accumulated data that happened during his operation time. ICU must ensure that term. (It is practical if the prohibition is bound to the changing of the "GB certificate number" data that can be found in the 11th row of the configuration data).

The values can be read by the Operator:

  • Temporary positions of counters (C0h, … C5h, CEh orders)
  • Daily, monthly, quarterly and yearly total data (C6h, … C9h orders)
  • Configuration data (CAh orders)
  • The memory block of the operator key codes (CBh, 01h…20h orders)
  • The code of the inserted key (CBh, 00h orders)
  • Date and time data (D1h order)

Only the previously authorized hardware key plugged into ICU can access the GB, NOM and Checking lab functions. The organizer can give his identity code with hardware key, too, or with sending the key code - given by the PC - on serial line when using the reading program (CDh, 00h order).

Without giving the identifying code key ICU replies an error message. (sending back the order code + the negal of identifier).

After manufacturing all code spaces must contain 00h bytes. It is very important to keep this condition, because to provide the free programming of any key code into ICU can be solved only in this way. During the first configuration the NOM writes key codes into three spaces (Exception is the Operator sector). After that (immediately after the writing) ICU can operate only if using these codes. It is possible to change any key-code of a given code space. But anyway only those key codes can be changed that are on the authorized sector of the entering key code. The key codes of the other code spaces cannot be modified. (Exception is only the NOM key: you can write into any code sector with it.)

The events of the last 20 pcs NOM and GB key using must be logged. The content of the log: the key code, the date-time of the start of the key using, the date-time of the finish of the key using. The key using start by giving the first order with the entering key and finish when:

  • plugged any key but the entered key or
  • there is no any entered key present when initiated an order on the serial port or
  • there is no order given out on the serial port but after passing 5 seconds no entered key is present.

If the store is full, every time the oldest event will be overwritten.

Key code programming rules

In case there is no programmed key code in a specific sector (NOM, GB, operator), i.e. the code area is blank then 1 key code can be entered freely. All other operations need authorised key and code.

The code sector of Checking lab can be accessed with a hardware key only after the NOM key code is programmed

The expert of NOM enters the key codes of NOM, GB, Checking lab during the first checking from floppy disk.

If a specific code area is not blank, all operations need authorised key and code. Entering of a new key code and cancelling of the previous key is possible only with an authorised key. New key code can only be entered in a blank area in order to avoid data loss caused by incorrect overwriting of data.

With authorised NOM key all code sectors are available for writing.

The operator is can send his identification code through serial port as well (Cdh,00h, ... command), but its validity is limited to the end of execution time of the command.

For backup purposes, the code of a plugged key can be read out by giving command through the serial port. Cbh,00h ... command).

3.6            DESCRIPTION OF CONTROL COMMANDS, ENCODING

For communication with the ICU uniform control commands must be applied. The commands are executed only if execution method is exactly defined. These methods are detailed in the following paragraphs:

  • During the game and depending on the player performance, the actual values of IN, OUT, BET, WIN, GAME NR counters continuously increases, while the stored WINMAX value will be overwritten if win is equal or bigger than the stored value. WINMAX value must be recorded together with the time of the actual WIN (hr, min).

            Each start increases the game number by 1.

            Capacity needed: 26 bytes.

  • Daily data mean information of the actual counter values for a specific day. Capacity needed for daily data storage: 25 bytes. Storage of data must be ensured for max. 31 days, therefore 31 numbered (1 ....31) storing areas are needed.

            Necessary data storage area: 31 Χ 25 = 775 bytes

  • Monthly data mean information of the actual counter values for a specific month. Capacity needed for monthly data storage: 18 bytes. Storage of data must be ensured for max. 61 months, therefore 61 numbered (1 ....61) storing areas are needed.

             Necessary data storage area: 61 Χ 18 = 1098 bytes

  • Quarterly data mean information of the actual counter values for the actual three-month period of the year. Capacity needed for quarterly data storage: 18 bytes. Storage of data must be ensured for max. 21 quarters, therefore 21 numbered (1 ....21) storing areas are needed.

    Necessary data storage area: 20 Χ 18 = 378 bytes
  • Annual data mean information of the actual counter values for a specific year. Capacity needed for daily data storage: 17 bytes. Storage of data must be ensured for max. 6 years, therefore 6 numbered (1 ....6) storing areas are needed.

                Necessary data storage area: 6 Χ 17= 102 bytes

The counters that record the temporary, the daily, the monthly, the quarterly and yearly data operate in the same time. It means, that the time when the data given by the instructions arrive, all the counters must record them. When a day has passed, the new data should be written into the new serial number's daily space together with the new date (year, month, day = 3 bytes). When a month has passed, the new data should be written into the new serial number's monthly space together with the new date (year, month, day = 3 bytes). The quarterly and yearly data should be fixed on the same way like above, too. According the fact above, the counter values are continuously increasing during operation. After passing the different periods (day, month, quarter year and year) the counting is going on onto a store space with a new serial number. So the older data can't be changed.

Because of the requirements of the continuity and safety one must solve, that the configuration data written by NOM cannot be changeable by anybody not authorized. To avoid that the present configuration data and the above mentioned temporary counter positions (IN, OUT, BET, WIN, GAMENR) must be saved by date and time when any configuration data have to be changed. This data space have to be formed on the way that it must not be written by any outer order, it can only be read. In all 20 pcs configuration data table's data should be stored, so it needs 20 pcs space (1 … 20) with serial numbers. The necessary store space: 20 x 371 = 7420 bytes.

If the memory spaces that are reserved for the logging data (configuration data, clock setting data) are filled out and new logging is necessary then the oldest logging data should be overwritten.

The writing and reading entry authorities are coded with hardware key. The earlier explained hardware key contains 8 bytes code-information. Store space is necessary for in all 192 pcs hardware key-codes, so 192 pcs (1 … 192) spaces are necessary with serial numbers. The necessary store space: 192 x 8 = 1536 bytes.

Using of GB and NOM keys must be logged. The logging contains the code of entry, the date-time of entry, and the date-time of out. For that it needs 18 bytes memory. In all 2 x 20 pcs = 40 pcs key using should be logged, so 2 x 20 pcs (1 … 20) spaces are necessary. The necessary store space: 2 x 20 x 18 = 720 bytes.

To write the configuration data in is possible only with NOM authority key. To write the all configuration data in the PC must be given 18 pcs different writing orders (CCh, 01h…12h orders). The configuration must be ready only after the orders executed correctly. The PC operating program of ICU should be made on the way that it must operate the configuration table as a unit during making the operations (writing, reading). If the execution of all the order that are necessary for the whole configuration or for reading in the configuration data was not made, the program must give alarm about it for the operator.

The event-logged data of the configuration table must be operated as a unit, too. The data of those are relating, too, so they can be understood only after reading out of the whole saved configuration table. (E1h…F4h, 01h…18h orders)

The memory areas must be numbered to be able to use them as a reference during readouts. At the same time, this number is used as a frame code in order to be to check which data have been transmitted correctly or incorrectly. This way, data transmission will not have to be repeated from the very beginning, just incorrectly transmitted parts are to be sent again.

Readout command structure:

(sent by reading unit to ICU)

CONTROL CODE, IDENTIFICATION CODE ------> transmission

(2 bytes)

......................................................................................................................................

(Sent by ICU to reading unit)

reception<------ COMMAND CODE, IDENTIFICATION CODE, DATA, CHECKSUM

(data returned)

This means, that the equipment initiating reading (PC, printer, etc.) contacts transmitter by a 2-byte readout command (command code + identification code) If contact is successfully made, ICU will produce the character string and a 2-byte checksum will be added to it. The reader checks the received data. The command code and identification code sent back are for the reader to check whether ICU produced the required data, at the same time the reader controls the accuracy of the received data as well.

Writing command structure:

(sent by reading unit to ICU)

COMMAND CODE, IDENTIFICATION CODE DATA, CHECKSUM ------> transmission

(2 bytes)


(Stored and sent by ICU to reading unit, if checksum is accepted)

reception<------ COMMAND CODE, IDENTIFICATION CODE, DATA, CHECKSUM

(data returned)

(ICU sends back the data to the reader if checksum is not accepted)

reception <------ NEGATIVE (COMMAND CODE, IDENTIFICATION CODE) (data returned)

According to the above, the equipment (PC, Notebook, etc.) initiating readout by making contact with the appropriate series of commands (command code + identification code + data + checksum). If contact is successfully made, ICU will store the character string and controls it with a 2-byte checksum. If the checksum is found correct, ICU logs the received data and sends back the whole character string to the equipment initiating  reading. If transmitted data are incorrect after checking by ICU, then ICU will send back the negative of the command code + identification code. Then, the reader will compare transmitted and sent back data. In case of data discrepancy, it will repeat the reading command.

Important!!!

  1. By reading the saved daily, monthly, quarterly and yearly data the answer given by the operator for the non-readable spaces all data-byte (date, time, counter value) should be FFh value. The reading device must recognize from the FFh characters, which content of the read store can't be displayed in that case. To provide those the reading software must implement the followings: During changing the configuration data - for which the saving connects - the actual date-relating blocks of the daily, monthly, quarterly and yearly blocks will be overwritten by the starting counter positions (the actual earlier blocks do not change). In this way it can be assured that nobody could reach the earlier data in the case of changing the operator. The configuration data change-related, saved configuration logs do not allow to lose data.
  2. For reading and writing functions, there may be multi-byte hexadecimal numbers as well. The transmission of these data must always be started by LSBs (less significant byte) and be ended by MSBs (most significant byte).
  3. Real time clock is in BCD format. For the transmission of these data, keep an order of year as the first and minute as the last one. (i.e.: transmission order: year, month, day, hour, minute)
  4. For clock data event logging, first previous data are to be transmitted, then the newly recorded ones.
  5. For ASCII data transmission, the first character wrote in must be transmitted the first, and logically the last character must be the last one to be sent.
  6. Transmission of key codes has the following byte order: first - family code byte, last - CRC byte. The key codes can be saved on discs, and can be read from it. The saved key file has max 512 pcs hexadecimal characters, on the way that the first 8 bytes are the code of the first key, the next 8 bytes are the code of the second key and so on, the last 8 bytes code are the code of the latest, i.e. the 64th key.
  7. Processing the asynchronous data given during transmission can be started at least 200 ms after transmitted the last character. At the same time it means that it is not allowed to be longer interval than mentioned among the continuously transmitted characters.

The reading commands of the counter values:

 

Command code,

Identification code,

Response data

IN (act.):

OUT (act.):

BET (act.):

WIN (act.):

WINMAX (act.):

GAMENR (act.):

ALL (act.):

C0h,

C1h,

C2h,

C3h,

C4h,

C5h,

CEh,

xx h,

xx h,

xx h,

xx h,

xx h,

xx h,

xx h,

C0h, xx h,   4-byte data, 2-byte check,

C1h, xx h,   4-byte data, 2-byte check,

C2h, xx h,   4-byte data, 2-byte check,

C3h, xx h,   4-byte data, 2-byte check,

C4h, xx h,   6-byte data, 2-byte check,

C5h, xx h,   4-byte data, 2-byte check,

CEh, xx h, 26-byte data, 2-byte check,

ALL means (IN, OUT, BET, WIN, WINMAX, HOUR, MINUTE, GAMENR) read simultaneously. This means that sending the CEh ordercode the answer arrives in the sequence of: IN, OUT, BET, WIN, WINMAX, HOUR, MINUTE, GAMENR.Identifier: xx signed character can be anything.

 

DAILY (1.)

DAILY (2.)

.

.

DAILY (31.)

C6h,

C6h,

.

.

C6h,

01h,

02h,

.

.

1Fh,

C6h, 01h,  25-byte data, 2-byte check,

C6h, 02h,  25-byte data, 2-byte check,

.

.

C6h, 1Fh,  25-byte data, 2-byte check,

MONTHLY (1.)

MONTHLY (2.)

.

.

MONTHLY (61.)

C7h,

C7h,

.

.

C7h,

01h,

02h,

.

.

3Dh,

C7h, 01h,  18-byte data, 2-byte check,

C7h, 02h,  18-byte data, 2-byte check,

.

.

C7h, 3Dh,  18-byte data, 2-byte check,

QUARTERLY (1.)

QUARTERLY (2.)

.

.

QUARTERLY (21.)

C8h,

C8h,

.

.

C8h,

01h,

02h,

.

.

15h,

C8h, 01h,  18-byte data, 2-byte check,

C8h, 02h,  18-byte data, 2-byte check,

.

.

C8h, 15h,  18-byte data, 2-byte check,

ANNUAL (1.)

ANNUAL (2.)

.

.

ANNUAL (6.)

C9h,

C9h,

.

.

C9h,

01h,

02h,

.

.

06h,

C9h, 01h,  17-byte data, 2-byte check,

C9h, 02h,  17-byte data, 2-byte check,

.

.

C9h, 06h,  17-byte data, 2-byte check,

Configuration data readout and writing commands:

Readout:                      with CAh command

Writing:                        with CCh command

 

Command code,

Identifier

Answer


manufacturing data

 

AWP type

AWP serial nr.

AWP prod. date

CAh,

CAh,

CAh,

01h,

02h,

03h,

: CAh, 01h, 16-byte data, 2-byte check,

: CAh, 02h, 16-byte data, 2-byte check,

: CAh, 03h, 16-byte data, 2-byte check,


NOM  data

 

AWP certificate serial nr.

AWP certificate validity

CPU serial nr.

NOM identifying nr.

NOM expert's id.

Date of checking

Checking lab id.

CAh,

CAh,

CAh,

CAh,

CAh,

CAh,

CAh,

04h,

05h,

06h,

07h,

08h,

09h,

0Ah,

: CAh, 04h, 16-byte data, 2-byte check,

: CAh, 05h, 16-byte data, 2-byte check,

: CAh, 06h, 16-byte data, 2-byte check,

: CAh, 07h,   8-byte data, 2-byte check,

: CAh, 08h,   2-byte data, 2-byte check,

: CAh, 09h, 16-byte data, 2-byte check,

: CAh, 0Ah,   2-byte data, 2-byte check,


operator data

 

 

CAh,

CAh,

CAh,

0Bh,

0Ch,

0Dh,

: CAh, 0Bh, 16-byte data, 2-byte check,

: CAh, 0Ch, 64-byte data, 2-byte check,

: CAh, 0Dh, 64-byte data, 2-byte check,

----------------------------------------------------------------------------- counter start-up data---------

 

Counter step value

IN counter start value

OUT counter start value

BET counter start value

CAh,

CAh,

CAh,

CAh,

0Eh,

0Fh,

10h,

11h,

: CAh, 0Eh,   2-byte data, 2-byte check,

: CAh, 0Fh,   4-byte data, 2-byte check,

: CAh, 10h,   4-byte data, 2-byte check,

: CAh, 11h,   4-byte data, 2-byte check,

After configuration, WIN, WINMAX, GAME NR counter values are automatically erased, i.e. starts from 0 value at new configuration.

For readout, CCh command code is to be used.

Key code character readout and writing commands:

 

Command code,

Identification
code

Answer


NOM CODE READOUT

NOM CODE ENTRY

CBh,

CDh,

81h..C0h,

81h..C0h,

CBh, 81h..C0h, 8-byte data, 2-byte ch,

CDh, 81h..C0h, 8-byte data, 2-byte ch,


GB CODE READOUT

GB CODE ENTRY

CBh,

CDh,

41h..80h,

41h..80h,

CBh, 41h..80h, 8-byte data, 2-byte ch,

CDh, 41h..80h, 8-byte data, 2-byte ch,


C. LAB CODE REDOUT

C. LAB CODE ENTRY

CBh,

CDh,

01h..40h,

01h..40h,

CBh, 01h..40h, 8-byte data, 2-byte ch,

CDh, 01h..40h, 8-byte data, 2-byte ch,


OPER. CODE READOUT

OPER. CODE ENTRY

CBh,

CDh,

01h..20h,

01h..20h,

CBh, 01h..20h, 8-byte data, 2-byte ch,

CDh, 01h..20h, 8-byte data, 2-byte ch,


PLUGGED IN KEY
CODE READING

OPERATOR ID.
MEMORY WRITING

CBh,


CDh,

 00h,

 
00h,

CBh, 00h, 8-byte data, 2-byte ch,


CDh, 00h, 8-byte data, 2-byte ch,


Real time clock date/time data reading and writing commands:

 

Command code,

Identification
code,

Answer

DATE, TIME READING

DATE, TIME WTRITING

D1h,

D2h,

xx h,

xx h,

D1h, xx h, 5-byte data, 2-byte check,

D2h, xx h, 5-byte data, 2-byte check,

Clock setting/resetting configuration event logging readout commands:

 

Command code,

Identification
code,

Answer

CLOCK SET (1.):

CLOCK SET (2.):

CLOCK SET (60.):

E0h,

E0h,

E0h,

01h,

02h,

3Ch,

E0h, 01h, 10-byte data, 2-byte check,

E0h, 02h, 10-byte data, 2-byte check,

E0h, 3Ch, 10-byte data, 2-byte check,


CONFIG (1.):

CONFIG (2.):

.

.

CONFIG (20.)

E1h,

E2h,

.

.

F4h,

01h…18h,

01h…18h,

.

.

01h…18h,

1. config table

2. config table

.

.

20. config table


Reading orders of GB, NOM key-using logs:

 

Command code,

Identification
code,

Answer

GB KEY USAGE (1.)

GB KEY USAGE (2.)

.

.

GB KEY USAGE (20.)

F5h,

F5h,

.

.

F5h,

01h,

02h,

.

.

14h,

F5h, 01h, 18-byte data, 2-byte check,

F5h, 02h, 18-byte data, 2-byte check,

.

.

F5h, 14h, 18-byte data, 2-byte check,

 


NOM KEY USAGE (1.)

NOM KEY USAGE (2.)

.

.

NOM KEY USAGE (20.)

F6h,

F6h,

.

.

F6h,

01h,

02h,

.

.

14h,

F6h, 01h, 18-byte data, 2-byte check,

F6h, 02h, 18-byte data, 2-byte check,

.

.

F6h, 14h, 18-byte data, 2-byte check,

 


Attention! During developing, introducing ICU, questions can be asked! For information, please, call NOM Gambling Research Department.

Related downloads