ccTalk (pronounced see-see-talk) is a serial protocol in widespread use throughout the money transaction and point-of-sale industry. Peripherals such as the currency detectors for coins and banknotes found in a diverse range of automatic payment equipment such as transportation, ticketing, payphones, amusement machines, and retail cash management use ccTalk to talk to the host controller.
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). MDB interface protocol. ccTalk. Extended Interface / USA Serial (NIS. 4 NV9 USER INTERFACE. The user interface with the NV DIPswitches and a RED LED, G Th. Operational status of the NV9. Figure 2 - User Display and DIPswitch Settings. NV9 Operations Manual 7. CcTalk tutorial, free serial port sniffing tool March 3, 2020 ccTalk tutorial, ccTalk on Arduino nano part 5 bill acceptor example March 13, 2018 ccTalk tutorial, ccTalk on Arduino nano part 4, more about coin ID values November 24, 2017.
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).[1]:20
The protocol was developed at a company called Coin Controls (hence coin-controls-talk, later called Money Controls and from 2010 Crane Payment Solutions) on the outskirts of Manchester in north-west England mainly by Engineer Andrew William Barson. The first release of the protocol was in 1996.[2]
The ccTalk protocol is an open standard.[1]:13
The protocol uses an asynchronous transfer of character frames in a similar manner to RS232. The main difference is that it uses a single two-way communication data line for half-duplex communication rather than separate transmit and receives lines. It operates at TTL voltages and is ‘multi-drop’ i.e. peripherals can be connected to a common bus and are logically separated by a device address. Each peripheral on the ccTalk bus must have a unique address.
The original protocol operated at 4800 baud with subsequent releases standardising on 9600 baud. Low cost bridge chips are now available from a number of manufacturers to allow ccTalk to run over USB at baud rates of at least 1 Mbit/s.
ccTalk protocol stacks have been implemented on a range of devices from tiny Microchipmicrocontrollers with 512 bytes of ROM to powerful ARM7 32-bit processors.[1]:12–13
The protocol supports all standard operations for electronic devices such as flash upgrading of firmware, secure transfer of data and detailed diagnostic information.
Advantages of ccTalk include low cost UART technology, a simple-to-understand packet structure, an easily expandable command interface and no licensing requirements. The latter affords the protocol a good deal of popularity in a crowded and highly competitive field similar to open-source software.
In 2010, DES encryption was added to certain commands so that it could be made more resilient against attacks on the bus.[2]Each peripheral has its own unique DES key.[3][4]
An Example ccTalk Message Packet[edit]
TX data = 2 0 1 245 8
- 2 = destination address
- 0 = zero data bytes
- 1 = source address
- 245 = command header ‘Request equipment category id’
- 8 = checksum ( 2 + 0 + 1 + 245 + 8 = 256 = 0 mod 256 )
This is a message from address 1 ( the host ) to peripheral address 2 to find out what it is.
RX data = 1 13 2 0 67 111 105 110 32 65 99 99 101 112 116 111 114 22
- 1 = destination address
- 13 = 13 data bytes
- 2 = source address
- 0 = reply header
- 67…114 = ASCII for ‘Coin Acceptor’
- 22 = checksum ( sum of all packet bytes is zero )
The reply from address 2 back to address 1 identifies it as a coin acceptor.
Details[edit]
The ccTalk protocol is a byte-oriented protocol. The series of bytes in a message -- represented above as a series of decimal numbers -- is transmitted as 8-N-1.
Many devices have single electrical connector that carries both power (typically +12 V or +24 V) and the ccTalk data over a total of 4 wires.
To reduce cost, for short interconnection distances CPI recommends sending ccTalk data over an unbalanced multi-drop open-collector interface: both transmit and receive messages occur on the same bi-directional serial DATA line at TTL level, driven through an open-collector NPN transistor.The pull-up resistor at the host pulls the DATA line to +5 V, so logical 1 (and idle) is nominally +5 V, and logical 0 (and start bit) is nominally 0 V.[1]:15,17For longer distances, CPI recommends sending ccTalk data over a balanced multi-drop RS-485 driver interface, also nominally +5 V and 0 V.[1]:17
Secure peripherals require all bytes of a message to be encrypted, except for the first two bytes -- the destination address byte and theArchived 2017-10-16 at the Wayback Machine.Issue 4.7
External links[edit]
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.
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.
Cctalk Serial Interface Software
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
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 :
Send a request with header 229
Get the response data
- Check the counter value.
If the value is greater than the previous one, check the corresponding number of results
Depending on the error code returned, process the coin ID that has been accepted
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 :
Teensy implementation
Cctalk Serial Interface Example
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
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.