Bottom Line Up Front (BLUF)

It’s alive, oh crap it does not work, ok let’s ‘hack’ it, look mom it works, kinda. Let me tell you what I did.

TL;DR

The adventure began with an expectation that a modern coin acceptor could be mounted, (electrically) connected, and operated in an 80's pinball machine. The coin acceptor could be programmed for additional coins, if desired. The initial connection powered the device but coins were not accepted. My acceptor was in-operable; let me coin the phrase in-op, here. Did you like that pun? After a few hours of research, reading, building, rummaging through my parts bin and tinkering, I got my coin acceptor, a Microcoin QL to work on the bench. Getting it to work in a pinball will take more effort; more to follow. The adventure included re-learning about serial communication (aka, RS-232), voltage levels, seeing those serial bits on-the-wire, reading the ccTalk specification, simulating the ccTalk interface circuit, building that circuit, connecting a serial USB and the circuit to the acceptor’s ccTalk interface, working with RealTerm (a terminal application for engineering), sending raw ccTalk commands (i.e., specific bytes), and polling the acceptor to “keep it enabled”. This last facet, polling was not mentioned in the protocol specification, product literature, Internet searches, or various forums. Polling was discovered by pure accident. Now, those involved in vending and the Gaming industry most likely know everything mentioned here. The ideas are innate for them. Not so for us mere mortals. In retrospect, constantly polling a coin acceptor makes complete operational sense: a device should not take your coin, if it ain’t ready. Thus, the coin acceptor should power-on in a disabled state; it should self-inhibit until the vending-device is ready. This is a product design choice and not something to be dictated in a protocol specification. Such hindsight seems so simple. Perhaps I operated under too simple an assumption formulated by what I have already seen within a pinball machine: A good-old-fashion coin mech took your coin, flicked a switch, and the pinball machine gave you a credit. A person would never insert a coin into a pinball that wasn’t powered-on, right? Whereas, you might not be able to tell that a sprayer in a car wash was working. And it’s likely that a video poker console or some other Gambling device has a greater security requirement (government scrutiny). The coin acceptor must thus, protect you from doing something stupid; putting your coin in when not supposed too. Seems like common sense to me. Well anyway, I got to use my oscilloscope, lab bench power supply, (old) breadboard, and discrete components that had been sitting in bins, waiting for a day like this! Please follow along as I describe the various steps, sources, and insights that helped me on my path to adventure.

 I would especially like to thank the person who wrote the ccTalk tutorial, a blog that’s been running for ten years. Now that’s dedication. Crane Payment Industry for producing an open standard (industrial protocols and their IP can be tightly controlled.) The four part ccTalk specification is freely available and a must read. Lastly, the author who wrote Falstad, such an amazing circuit simulator.

https://cctalktutorial.wordpress.com/about/

http://falstad.com/circuit/