Bottom Line Up Front

ccTalk is an open specification for communication between hosts like vending machines, your PC or perhaps even my pinball machine (someday!) AND coin acceptors and bill validators. Connect a data line between the ccTalk port and your serial port and talk to your coin acceptor. There's a command to completely disable a coin acceptor. How cool is that! But darn, it's not the answer I'm looking for.

TL;DR

Now I am getting frustrated. My coin acceptor doesn’t work (Actually, I don’t know how to make it work.) When I spot a faded “ccTalk” on left corner of my coin acceptor. The image has been enhanced for greater clarification:

What the heck is that. A Google moment later: I discover it’s a protocol. Remember, I’m a beginner. So, ccTalk is an (open) specification for communication with my coin mech. It’s based on RS-232. The command structure (data bytes) are meant to be easy: a destination, data length, source, command byte, the data (of specified data-length, if applicable), and a checksum byte. Simply, send a command. Get a response back. For example, the five byte sequence:

Represents a “poll” command. If you are familiar with TCP/IP, this poll command is like “ping”, but much simpler; if sent, the coin acceptor will only acknowledge (ACK) back. Here’s the response:

Simply, if you send: 0x02 0x00 0x01 0xFE 0xFF then you will get back: 0x01 0x00 0x02 0x00 0xFD.

Note, when sending the first 0x02, it is the destination address (the coin acceptor) for the poll command. The pollis from you (ok, your PC) with source address, 0x01. The response message, sent by the coin acceptor, flips those addresses. Note that neither message sent any data; the data column is empty and the data-length is zero.

As for the checksum, it computed as the inverted sum  of your bytes Modulo 255. I like using the Python’s shell. I can type my equation and press return. To calculate the checksum of the poll command, that is… figure out its 0xFF (255 in decimal). Below, I add 2+0+1+254, invert, and then take the mod 256. Easy peasy:

So time to grab a USB serial adaptor. Not so fast. Caveat Emptor, please know what you’re doing before actually hooking up your Tx and Rx lines… The story continues.

The ccTalk specification is divided into four parts. And readily available on-line. Most of the commands set a parameter within a coin acceptor or get the current setting (again, mostly). I do not wish to re-iterate commands here. Instead, let me refer you to a very good tutorial the [ccTalk Tutorial]

That said, I discover a command, number 228. The command enables or disables the coin acceptor. Holly cow this has got to be my answer (!):

And another command, 231 that inhibits individual coins:

Clearly that’s may answer!!! It’s got to be it. Some casino operator clearly “inhibited” its operation before surplus’ing the thing, right?   Spoiler alert… the commands are not the answer. I'll explain why shortly as The story continues.

Bottom Line Up Front

The Microcoin QL uses pin 6 for an inhibit function. Their tech note says ground the pin, still no joy. 

TL;DR

The company’s tech note describes pin 6, V_inhibit.  See below. By default, the pin is floating, the default way most of us would connect the acceptor and get it enabled. But no luck. So I tried Ground, still no joy. I even tried positive voltage, but certainly did not believe at this point. Here's the excerpt for pin 6:

Spoiler alert: There’s more to the story and use of pin 6. The acceptor activates when pin 6 is grounded and the acceptor is constantly polled. And for that to happen, the adventure transitions to ccTalk and commands sent over its data line.

Bottom Line Up Front

Plug it in, turn it on, Darn it, my coin acceptor does nothing. OK, so what’s this orange (amber) LED all about? 

TL;DR

I got such a deal. So, I saw an auction for a dozen Microcoin QLs, about $100 + shipping. That’s a great price; half-off! To get a new QL, I’d need to add a zero at the end.  The lot had various years: 2013, 2015, two from 2019. What could go wrong? I should have known better. A sucker is born every minute. BTW, There’s no evidence that PT Barnum actually said that [wiki]. Anyway, if they just-worked, I wouldn’t be on this adventure.

I’m impatient so I Just wanted to plug it in. We don’t need [to worry about] no magic smoke. That’s what protective diodes are for, right?  Well, I’m not that reckless! I did a little research before plugging it in. Williams pinball machines from the late eighties use the Williams Pinball Controller [WPC89], the architecture, its schematics are readily available [Xmission]. Within a WMS pinball, there’s a coin door interface, just a PCB with several connectors, typically a Molex 0.1” or 0.156” (3.96mm) header. Well ops, the coin door interface is actually found in the game specific operator’s manual, not the architecture / schematic. My bad. The image below is from the [Safe Cracker] manual; I show the connector for a coin-acceptor:

The coin door schematic denotes an “NRI Interface”. Cool. Oh, NRI refers to National Rejectors Inc. (NRI) GmbH, and is / was renowned for its “G-13 market leading 3.5 inch electronic coin validator that set the standards with its unique Multi-Frequency Technology (MFT) validation”. Yeah, that’s the marketing hype from the Google top entry. The G-13 has been around for more than a decade. And I believe NRI is now owned by Crane (?) Like the QL, the G-13 is programmable (via dip switches) and has an A & B memory block of learned coins. I may need to correct / edit that prior sentence, bear with me.

Here, I was excited to see that the pinout matched what I saw in the pinball and from the NRI manual. Here’s a link to the G-13 manual off the [Suzo Happ] website:

So what about the connector for the Microcoin QL? This is where standards are good, expected. Here’s the figure from Microcoin’s QL Technical Data [Microcoin]. A match; GND and +12VDC are on the same pins:

Both ends use a female 2.54 mm pitch, 10 pin 2×5 connector (2 rows of 5 pins) at the pinball coin-door interface and on the QL coin acceptor. For me, pin 1 (ground) had a red wire.  Gosh, it’s size and appearance seemed so ubiquitous / familiar, like the old IDE disk drive and floppy drive connectors of yore, but smaller (only ten pins.) In fact, the same pitch is used for the ribbon cables used within the WMS pinball machines.  I’ll note that the coin-acceptor’s connector had a directional tab; you could only insert the connector into the male housing in a single direction, and unlike the cables used in pinball. I have had many a yikes moment there! Aren’t standards great.

Let’s wire this puppy up.

  Ugh, the LED is orange (amber) Ain’t it supposed to be green? 

Note, discerning the difference between an orange (amber) LED and a red LED was subtle. I will write about that test shortly. Spoiler alert, it involves jamming cardboard across the optos 

If you don’t succeeded, repeat the same process over and over again. Yeah, I tried every one of my newly acquired coin acceptors. The LED was orange on everyone. 

Back to the orange LED. Strictly, RFTM. Microcoin’s quick reference guide tells you that if the LED is amber (some manuals say orange), then the acceptor is “disabled”:

At this point, all kinds of questions are going through my mind: Permanently disabled? I spent $100 on junk? Was the acceptor used at a Las Vegas casino for a decade; a billion coins passing through it, wearing it out? Perhaps it has a built in shutdown at a prescribed End of Life, it self-destructs.  Amazing how the brain can runaway with crazy ideas.

Speaking of coin paths. I mention the reject path above. The NRI manual had a nice visualization of a coin’s successful and failed pathway. Pretty cool:

Ok, I know all you owner operators of vending equipment and Gaming devices might be chuckling at my over simplifications.  but the story continues. The devil is in the real detail. I’m getting there.

Bottom Line Up Front

Selecting a coin acceptor was straight forward. I wanted to program new coins and a token, be inexpensive, and physically fit inside a pinball. Let’s hack the Microcoin QL.

TL;DR

“All this has happened before” –BSG

There is a bounty of coin acceptors to choose from. The NRI G-13 series, Money Control SR3, even one from Sparkfun (link below), no doubt there are dozens more. Well, I did not have many requirements. Others will likely have a much longer list / more stringent needs. For example, data encryption and Diffie-Hellman key exchange are things I do not need. For me, the Microcoin QL is easy to program (no dip switches), decade old examples are cheap ($20), they use +12 VDC which is readily available inside my pinball and fit in a coin-door. OK, the size of coin mechs and acceptors are standardized. Here, the coin drop is from the top. And the accept pathway is towards the back. Again, pretty standard. That 12 coins can be learned, is also a relatively standard feature (I won’t mention A & B coin banks in this post.) Speaking of programming: Just press a button three times, pick your coin channel/category/storage position, drop some coins, teach your acceptor, select the coin-line, and press the button to finish.  The faceplate has a nice how-to program; cool pictograph:

What’s not to like; what could go wrong?

The devil is in the detail.

YouTube Programming a Microcoin QL

YouTube Programming a Sparkfun Coin Acceptor

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/