So, you want to attach a payment device to your embedded or PC based machine and don’t know a thing about which device and protocol to use. These are the most common protocols used, I have tested more or less all of them: Serial pulse protocolMostly used on vending or kiddie ride machines where there is no big amounts of money involved. A common configuration is with one data output that sends one pulse per major / minor currency unit and one input to disable the acceptance. Some have individual inputs to enable each coin or bill channel.
On coin hoppers there is an input that runs the hopper motor and an output that send a pulse for each coin paid. The host knows how many coins/bills were paid or accepted by counting the pulses. This can be problematic on higher value bills or coins, for a 100 Eur bill 100 pulses must be sent, the probability that an error occur is pretty high. There is no error recovery, some security can be reached by tightening the acceptable pulses width error accepted. Most low price coin and bill acceptors have this protocol available by firmware or dip-switch or other settings. At a minimum only one data input is needed on the host machine. Parallel pulse protocolOnly for coin and bill acceptors.
Is the same as the the pulse protocol but each coin have it’s own output, this way the time to read a 5 Eur bill is the same as for a 100 Eur bill. The down side of this is that the host machine will need one input for each bill / coin channel. If you use also the individual enable inputs you will have a large data bus, with large connectors. The security is somehow higher due the redundancy in the data received by the host machine. Binary serialUses a RS232 or TTL levels RS232 to send a byte for each bill accepted. For simplicity can be the bill/coin value like 0x05 for 5 Eur 0x0A for 10 Eur, 0x32 for 50 Eur and so on or the bill / coin channel like 0x01 for 5 Eur, 0x02 for 10 Eur and so on.
The security is still pretty low but it’s fast and at a minimum needs only one data wire. Binary parallelIs a variant of parallel pulse protocol where a the outputs are valid only on the edge of a clock line, this allow using combinations to represent the bill channel so 16 bills can be signaled using 4 data outputs and a clock line. MDB serial protocolIs a serial protocol designed for vending machines, the security is pretty high with error recovery, many kind of devices can be driven including cashless audit and age verification devices. It uses optically insulated RX and TX which is good for the noise protection RS232 like 9600, 9 bits no parity 1 stop bit. It uses a simple checksum to check the integrity of the data packets A drawback is that it uses 9’th bit signalling that isn’t supported by most PC operating systems.
As a workaround the serial port must be reset at the runtime or some kind of translation hardware interface must be used. In exchange most micro controllers have special features to easily detect and use the 9’th bit signaling.
The voltage supplied by the MDB connector must be around 34 V or the peripheral must have it’s own power supply.There is also support in the protocol for power management. The protocol specifications are freely available from NAMA ID003 serial protocolIs a proprietary protocol owned by JCM used only for bill acceptors and bill changers. Is widely spread in the gaming industry. It also uses optically insulated RX and TX lines at 9600 bauds 8 bit data 1 even parity bit and an optional hardware reset line. Can be run over serial to USB converters. The integrity of data packets is protected with a CRC16 check-sum.
There is no recommended connector or power supply voltage, each producer uses it’s own version. The specifications can only be obtained from JCM after signing a non disclosure agreement. The use for host machines is free as far as I know, for slaves a per unit fee must be paid.
Even it’s not a free to use protocol many bill acceptor producers have ID003 versions of their products due it’s large use in the gaming industry. As an oddity, the machines that use ID003 bill acceptors are also using ccTalk for the coin acceptor and coin hopper. CcTalk protocolIt’s widely spread in the gaming and vending industry, can drive coin and bill acceptors, changers and coin hoppers, can run multiple devices of the same kind, the security can be as high as you need, there are options for simple checksum, CRC16, ccTalk or DES encryption. The interface is simple just one bidirectional data wire,PC friendly and easy to implement even on a low resources micro controller. CcTalk is free to use for slaves and host to and any producer has ccTalk version of their products. The software you will make will be reusable on cheap or expensive devices as you need.
Other serial protocolsThere are many vendor specific serial protocols but unless you have a good reason you wouldn’t want to design a host machine for them. With the noticeable exception of JCM’s ID003 for which you will find devices from many producers (not as many as ccTalk though) you will be stuck with a single or at most two suppliers and if some reason the product will not be available you will have to write a new software. Why not USB protocol?Yes and no. There isn’t a true USB protocol accepted as a standard in the industry and that will include them in the “Other serial protocols” category.
What is accepted as a standard is ID003 or ccTalk over USB which is only a matter of interface, some devices have a built in USB to serial/ccTalk cable. I’m sorry, ID003 is proprietary and you need to contact JCM for the specifications. You also must sign a non disclosure agreement. It’s not clear to me if the acceptor side is cctalk/spp or ID003.
If your board must act as a ID003 slave you will have to pay a fee to JCM for that, even so I doubt that they will let you. Still, even for personal use I cannot help you for the same non disclosure reason.
There are some ready made boards on the market more or less legal that do that but I cannot give you any advice. Thank you for visiting my blog.Like. Search for: Recent Posts. March 13, 2018. November 24, 2017.
November 23, 2017. February 17, 2017.
July 28, 2016. January 8, 2016. January 4, 2016. December 24, 2015. December 15, 2015. December 11, 2015.
November 16, 2015. November 13, 2015. October 26, 2015. October 16, 2015.
October 13, 2015. October 9, 2015. October 8, 2015. September 22, 2015. September 16, 2015. September 10, 2015.
August 25, 2015. August 12, 2015. August 12, 2015. August 11, 2015.
August 11, 2015Recent CommentsonDave onondawid ononArchives.Categories.Meta.
The logic levels for the ccTalk line are 3.5 to 5V for mark state (idle ) and 0 to 1V for space state (active). This allows a low cost interface width 5V microcontrollers. Some dedicated gaming PC based platforms like have one or more built in ccTalk ports. Simple 5V microcontroller interfaceA normal switching diode can be used but the noise margin could be to low. The resistor can be in 1Kohm to 10Kohm range.
If the Tx output is open colector you can connect together TX RX and data line without the diode. Also the resistor is not required if the slave has a pull up. Simple 3V microcontroller interfaceYou can skip the diode if the microcontroller has internal protection diode.I know that the levels are not exactly by the book, the input low level for Pic microcontrollers is guaranteed at 0.15 VDD for CMOS inputs. 1V means 0.3VDD for 3.3 V and 0.2VDD for 5V but this worked for me flawlesslyFor PC there are many USB to RS232 TTL adapters available that can be used with the schematics above, search Google, they have 5V and 3.3V outputs. If you want a ready made ccTalk cable has one (pl2303 based) or you can find some more in “Usefull ccTalk links” page.There is also on youtube a video where is simply connecting TX and RX and data together, I doubt that the TX output is open collector the slave just force zero the output that acts also as a pull up when idle. This might reset your USB to serial chip if the output is stronger.Of course do not forget the official schematics from the ccTalk documentation, I don’t have their agreement to show them here but you can find them in page 82 to 85. (Continues from last post)Looking completely to my questions in my last post and the “this guy” video in Youtube, what I understand is that: Attaching the only 1 data line of ccTalk device to a USB to TTL cable’s DATA IN (receieved) and DATA OUT (transmittted) cables is enough.
But there appear two new questions:1-The equipment in the video is a ccTalk coin acceptor which needs12 V to work. So the guy takes the energy from the PC’s board. But for a hopper which needs 24 V, 1 A minimum, it is impossible. OK, the answer my friend is blowing in the wind, it is easy, just use an external 24 V power supply.
But the guy atttaches the USB-TTL cable’s ground (black) to the PC board’s ground (black) cable. In that case should I attach the USB-TTL cable’s ground to the 24V external power supply’s ground? Or what?2-It seems it is possible to work by connecting the only 1 data line of ccTalk equipment to a desktop PC’s 9 pin RS232 pins (both) 2nd (tranmission) and 3rd (receiver) and using an external 24 V power supply WITHOUT A USB TO TTL CABLE. (In that case there is no ‘where to connect the ground of USBtoTTL cable’ question, there is no USB cable or port in this scenerio)Like. Hi.I’m having trouble communicating with a Microcoin SP1.
I used to use a PL2303HX USB to RS232 TTL converter very successfully (by using the simple connect TX and RX together approach), but this converter does not support windows 8 and above and I’ve been forced to upgrade to windows 10. Instead I’ve purchased the PL2303TA which does support windows 10 and to use this I’ve used your ‘Simple 5V microcontroller interface’. This works really well for transmitting, but I could not get a reply (strictly I got a garbled reply). Connecting up an oscilloscope, I found that in the the reply from the coin acceptor, the level is only being pulled down to 2v, not 0v. My electronics knowledge is very rusty (ie I’ve not done any for 25 years!), but I was kind of thinking that I need some sort of circuit to bring down the level at the coin acceptor end.Any suggestions at all?Many thanks in advance,RichardLike.
I see that PL232TA is using 3V not 5. I had this issue when I burned the USB to serial TTL converter but this happened only when I did something very wrong, I forgot a ground wire or I had a short to 12 V on the data line. Are you having loopback answer without connecting the coin acceptor?
If not then change the converter. The issue with using 3v converter was mostly for the TX side because the “1” level might be to low for some devices, most of them are having a similar input inside and translate levels over 2.5V as “1”. The chance to burn the RX due the 5v pull-up is very low, never happened to me. Nothing on google worked for PL2303HX? I switched to windows 10 recently and I found drivers for all my cables even no name ones( not official ones but working well)Like. Use the transistor schematic.
I really don’t see where is the trouble with the mirrored message on RX. It works the same with the interrupts or polled, first check the consistency of the received message with the sent message then receive the answer.
It is useful to diagnose a ccTalk line shorted to ground. There is a hardware option to suppress the echo but it’s buggy, you can find it on page 13 of this document: but take into account that if your ccTalk line is shorted to ground this circuit will send data back to RX, you must handle that somehow. Also some unexpected spikes can occur on RX due the line capacitance. I don’t know any ready made chip solution.Like. Search for: Recent Posts. March 13, 2018.
November 24, 2017. November 23, 2017. February 17, 2017. July 28, 2016. January 8, 2016. January 4, 2016.
December 24, 2015. December 15, 2015. December 11, 2015. November 16, 2015.
November 13, 2015. October 26, 2015. October 16, 2015. October 13, 2015. October 9, 2015. October 8, 2015.
September 22, 2015. September 16, 2015. September 10, 2015.
Cctalk Serial Port
August 25, 2015. August 12, 2015. August 12, 2015. August 11, 2015. August 11, 2015Recent CommentsonDave onondawid ononArchives.Categories.Meta.