Published on 19 August 2013

Coin acceptor

A coin acceptor is a device that can recognize various types of coins based onits weight, shape, size and more (all depends on the device and themanufacturer). Usually, all the different coins it can recognize are separatedin what are called validation channels, which means one coin type is assignedan ID.

Coin acceptors usually can recognize up to 16 different coin values, andeach of them is assigned one of those validation channels. These devices alsohave at least two sorter paths, which define the path the coin will take basedon the fact that the coin has been recognized or not. The two main paths are the'good coin' path (generally inside the machine) and the 'error' path, whichnormally gives the coin back to the customer.

Combining a fully featured e2c CashBus (CCTalk + MDB M+S) interface with dual serial ports, CC200 is suitable for demanding payment applications of cash and cashless payment. E2c CC300 smart device hub is a fully-features device hub combining 4 serial ports with extensive GPIO. ‘Circuit 1 - ccTalk Standard Interface’ 4.2 05-10-01 Addition of connector type 9 for serial universal hopper Serial Protocol - Voltage Levels. Allowable ranges now defined. See Tables 2 & 3. 1 USB interface for cctalk The USB interface for ccTalk permits to connect a device which operates according to the ccTalk protocol to the USB port of a Personal Computer. Warning: before connecting the interface to the Personal Computer, it is necessary to download the suitable drivers, which are available on Azkoyen website page. ¾ Standard PCI slot interface. ¾ Low Cost High Performance Solution. ¾ Multiple Device support ¾ Parallel coin acceptor ¾ ccTalk coin acceptors (SR3, SR5, SR5i) ¾ ccTalk note acceptors (Lumina) ¾ Auxiliary Device support ¾ Up to 16 LED’s / low power lamps / relays or Industry-standard switches ¾ Serial Electronic Meter. The ccTalk protocol is one of 2 protocols specified by BACTA for use in all AWP machines with serial coin acceptors. (The other is the Host Intelligent Interface protocol developed by Mars Electronics International ).

Data request

To actually get the data from the coin acceptor, the controller must issue arequest with header 229 - Read buffered credit or error codes. The coinacceptor will respond with eleven bytes, containing the following information :

• Counter is an event counter. Each event will increase this value.
• Result is stored in two bytes. Usually, the first byte contains thevalidation channel and the second contains the error code (OK, bad coin,mechanical error, ...) I said usually, because some acceptors invert the tworesult bytes, resulting in many errors when trying to figure out what happenson those devices. When in doubt, refer to the product documentation.

Since the coin acceptor will return the validation channel value, thecontroller will need to know which coin type is associated with each ID. It isthen mandatory to know this association to be able to process different coinsproperly.

Interfacing with a coin acceptor

In the previous article, we saw how to create ccTalkpackets and requests. Now, let's interface a coin acceptor, handle its returned dataand process it !

Initialization

Cctalk Serial Interface Software

First of all, You have to make sure that the coin acceptor is online bysending a sample poll packet and get the response.

Coin acceptor setup

The coin acceptors need to be initialized prior accepting coins. The two mainthings to do are to set the inhibit status, which define which validationchannels are enabled on the coin acceptor. This can be done using the header 231- Modify inhibit status with two bytes of data. Each bit in the bytes representa validation channel (little-endian).

The second thing is to enable the coin acceptor, which is often not done bydefault. To do this, we need to send a request with header 228 - Modify masterinhibit status and 0x01 as the data byte - which means enabled.

Data request and processing

Now that the coin acceptor is ready, it needs to be polled regularly (specs sayevery 200 milliseconds, but it can be more) and the returned data needs to beparsed and processed.

The counter starts at zero on initialization, and increments up to 255. It willthen loop from 1 to 255 and so on. Processing the data is quite simple once youknow which coin is what :

1. Send a request with header 229

2. Get the response data

3. Check the counter value.

   If the value is greater than the previous one, check the corresponding number of results

4. Depending on the error code returned, process the coin ID that has been accepted

5. GOTO 1

Example code

The following Python code uses the ccTalk library presented in last post It shows a basic coin acceptor initialization andpolling, and can be enhanced to support other functionalities :

Cctalk Serial Interface Download

Teensy implementation

I also created a simple ccTalk controller that can be used on an Arduino or aTeensy device. The code available here polls a coin acceptor and willsend the corresponding amount of keystrokes to the host computer. The purpose ofthis was to add a coin acceptor on my MAMEcab to add a more realistic feelingwhen playing.

Here is a (crappy) demo of it in action. You can actually see the credits changewhen I insert a new coin :

Cctalk Serial Interface Example

In the next post, we'll start messing with a ccTalk bus by injecting data andsee what can be done once you have a physical access to the bus.