ccTalk
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 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.
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 Microchip microcontrollers with 512 bytes of ROM to powerful ARM7 32-bit processors.
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.
An Example ccTalk Message Packet
TX data = 002 000 001 245 008 _____
- 002 = destination address
- 000 = zero data bytes
- 001 = source address
- 245 = command header ‘Request equipment category id’
- 008 = checksum ( 002 + 000 + 001 + 245 + 008 = 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 = 001 013 002 000 067 111 105 110 032 065 099 099 101 112 116 111 114 022
- 001 = destination address
- 013 = 13 data bytes
- 002 = source address
- 000 = reply header
- 067…114 = ASCII for ‘Coin Acceptor’
- 022 = checksum ( sum of all packet bytes is zero )
The reply from address 2 back to address 1 identifies it as a coin acceptor.
Coin and Note Naming
A number of associated standards have emerged over the years from within the ccTalk specification. For example, the global tags to identify the world’s forever changing coins and notes.
In ccTalk a coin has a 6 character identifier of the format <2-letter country code><3-digit value><1-letter issue code>
The country code conforms to ISO 3166. The issue code is assigned to different issue dates or special mint variations of the same coin.
e.g.
- US025A United States 25c
- GB010B Great Britain 10p
- EU200A Euro €2
Bank notes follow the same pattern but 4 characters are allocated to the value and there is an associated scaling factor, usually x100, with the country.
e.g.
- US0001A United States $1
- GB0020A Great Britain £20
- EU0005A Euro €5