|
Title: Trying to design a coinless system Post by: SLOTMAN on January 01, 2010, 05:42:35 PM In my venture to make playing with my machines more exciting I am trying to devise a "coinless" system. I am pretty well versed in microcontrollers and C programming. Since my days of using a scope are long gone and I dont have access to one anymore I am calling to the NLG community to help me with some stuff on the coin comparitors.
What I want to devise is a computer controlled cashless system. As far fetched as this sounds it isnt that hard. What I need to know is the data from the comparitor and the optics or even the bill acceptor. What protocol does the DBV use to register the machine that a bill has been accepted and what value. Is it Pulse Width Modulation? Is it Hex? Is it ASCII? Even if I take the easier route and go toward bypassing the coin mech on the same machine lets assume there is a CC-16. About as basic as you get. I know on a 5500 the CC-16 sends a signal first then a specific time the coin optics register. If I knew what type of signal I could emulate it with a microcontroller. I would be able to build a simple Java applet to add credits to machines. If there is somone out there who can help me I promise to make all my progress and finding public to the whole community. If this works as planned the cost per machine shouldnt be much more than around $10.00 so it is very cost effective. Any information or feedback would be greatly appreciated. Title: Re: Trying to design a coinless system Post by: reho33 on January 01, 2010, 10:58:45 PM Slotsdirect.com has Bally "free play" machines. You just push a button to add credits and cashout works with nothing dispensed from the machine at all. If you are trying to do something like that, you might like to know that a seperate board was added to these machines to make them act that way. How they did it is a secret that they might not be willing to give up. I know that there have been threads on it so do a search and look around.
Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 01, 2010, 11:15:22 PM The seperate board will be a microcontroller that I program in C. I just need to know exactly what the pulse is from the acceptor or optics and I can emulate that with a microcontroller. Short of having a scope I just have to go off what others may know.
Title: Re: Trying to design a coinless system Post by: stayouttadabunker on January 02, 2010, 01:08:23 AM Quote[I would be able to build a simple Java applet to add credits to machines.]End Quote
Where on a machine would this be installed to? Have you ever opened up an SP chip on a S+ board to see what was in it? You might see some programming in there that might interest you very much! :89- Title: Re: Trying to design a coinless system Post by: a69mopar on January 02, 2010, 05:01:34 PM If you manage to fake out the BV then it should work on other machines with the same protocol. For an S6000, it's ID003, the same as Sigma, Atronic, and others. The concept is great, press a button and it thinks it accepted a $100 bill.
Thanks, Wayne Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 02, 2010, 08:50:25 PM Faking out the validator is going to be very complicated, I admit that. Faking out a simple set of optics will be a easy task. The only problem would having to make sure the machine will accept over the max bet amount or you may throw it in to tilt because it would look like a coin is going through even though the coin mech should be diverting.
If anyone has tested the optics I just need to know how many milisecond pulse it is and I can go from there. I have all machines to work with so machine type isnt a problem. Title: Re: Trying to design a coinless system Post by: StatFreak on January 02, 2010, 11:55:40 PM For the S-Plus you can use an SP chip with Montana credits to allow the machine to accept coins beyond the max bet. For other platforms, YMMV.
The timing of the pulse was discussed to some degree here (http://newlifegames.net/nlg/index.php?topic=5771.msg51665#msg51665). Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 03, 2010, 02:40:29 PM StatFreak, thanks for your reply. You have answered one piece of the puzzle which is a big help. What I have gathered is the coin mech puts out a 16ms pulse +/- 4ms. That is great. My microcontroller can do that without any problem. I will setup a test station and test the theory.
The next step will be the time delay pause before the coin optics actually see the coin and then the pulse that the coin optics put out. When I have those two variables I can program the microcontroller to emulate it. Ultimately I would like to know what the bill validator puts out as emulating that would be a lot more exciting. Title: Re: Trying to design a coinless system Post by: SAT (aka GANDHI) on January 03, 2010, 04:24:32 PM Hi
Looks like fun what you're trying to do... I see you have already the delays info, so all I can add is a piece of code I wrote some time ago to perform the task of adding credits to slots machines working with CC-62 and CC-16 acceptors. You are free to use it as reference. As you said, the goal of adding credits through the coin signals can be achieved easily with any of the low-range micro-controllers out there... The code below was the first try I made using the good-old PIC16F84, later for the final version I adapted it for the smaller PIC12F508/509 in order to use the built in oscillator instead of a cristal and capacitors arrange. Some notes of my project: - Since I made my board to work for both CC-62 and CC-16 comparitors I had to add two sense outputs in my code to emulate successfully the CC-62 behavior. Remember the CC-62 works by sending two open-collector pulses to the slot machine in a sequence. The COIL pulse first, followed by the SENSE pulse with a gap between both that represents the time when the coin is traveling from the coils to the led sensor. If that sequence isn't respected the machine will go into TILT (coin jam) state. The CC-16 is simpler because it only sends the SENSE pulse, so in that connector I routed only one of my outputs. - For some reason when I programmed the micro to work with the delays of the data-sheets I had the slot machine falling into Coin-JAM state. I fixed it reducing the gap between delays to a minimum, even less than what the papers said. Not sure if it was a matter related to the machine I was working with or something else... I just tell you how I solved it. - At the end I unified my three delays because I saw they worked being the same one (Coil-Travel-Sense) . It was easier in the code and I was also looking to add credits as fast as possible only to find out at the end that the credits signals in the Aristocrats are buffered, so it doesn't matter how fast I programmed my micro, the credits will add at the machine's speed :200- - The final delay I used in the 508/509 version was 3 milliseconds. It worked lovely :31- It isn't written in C, but hope it's of help for your work. Code:
BTW: Happy new year !!!! Title: Re: Trying to design a coinless system Post by: StatFreak on January 03, 2010, 04:35:38 PM Nice SAT. :3-
Just a thought: I would have given the sub code in routine X1 a name and called it ten times from routine "repeat" with a simple loop instead of duplicating the X1 code in routine "repeat". :79- Or modify "repeat" so that it can be called from X1 and X10 and delete the extra code in X1... Title: Re: Trying to design a coinless system Post by: SAT (aka GANDHI) on January 03, 2010, 04:52:05 PM Nice SAT. :3- Just a thought: I would have called routine X1 ten times from routine "repeat" with a simple loop instead of duplicating the X1 code in routine "repeat". :79- That's right Stat !!! Just wanted to time and see who was the first to point that out !!! My watch reads 11:06:5342 ..... Too long but you won the prize anyways :72- Now seriously: Even when I've been reading about these things for a while I consider myself a TOTAL NEWBIE regarding microcontrollers and its programming. The true is that when I was developing this little thing I was reading a book called "PIC in Practice - Project Based approach" by D.W. Smith. I recommend it for anyone trying to get into the beautiful world of micros cause the explanations are extremely simple and well done in this book. In fact, for this project I was putting in practice the things I was reading and that's why you see that kind of (dumb) routines in my code... I would call this book PIC for Dummies hehehehe.... For me is the best, I really like how the author make all his points. Thanks for the advice and best regards. ----> ADDed You know... recalling a little bit I remember I tried to do that (simplifying the frigging code) when finishing the project on the 508/509 but I couldn't because the 508/509 has a stack of two levels and the way I was coding (calling subroutines every time I wanted to do something) didn't appear to work with such a small stack... [any suggestions/inputs regarding this subject will be appreciated] The fact is that I needed the board up and running quickly so I preferred to expend some more lines of code instead of wasting time testing more options..... Ohhhhh.... god helps those like me slaves of TIME :25- Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 03, 2010, 05:50:19 PM Sat, Kudos to you. This is exactly what I am looking for. The language is a little different but in the microcontroller world I am sure I can make it work.
Now, part one of the puzzle is mostly solved. I will bench test soon. The next step is to take a value and program it to a simple magnetic strip card. All it needs to be is a number and nothing else. Pretty simple but here is the ultimate goal. Card has a value which can either be preloaded or come from a hopper pulse (step 3). That value is read and signals the controller to amount whatever amount is on the card in to credits (erasing it off the card is a different story) since the cards would be passive in a sense. If this works I will share everything with the NLG community. Title: Re: Trying to design a coinless system Post by: jay on January 03, 2010, 07:17:30 PM I would think that the main stream approach might be to use the SAS interface and put credits on the machine through ETF.
I have heard that there is a SAS manual floating around. We could then use this either with a swipe card system you suggested or through the voucher system on the DBVs Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 03, 2010, 08:20:10 PM I would have to assume that the EFT system is as heavily encrypted and guarded as much as bank EFT's. I may be wrong but I would assume if someone was able to tap in to the network they could credit themselves a whole bunch of money.
Sat: Would you happen to remember which pins you used for the coin mech and the coin optic? I have attached a picture of the 16X84 Title: Re: Trying to design a coinless system Post by: SAT (aka GANDHI) on January 04, 2010, 03:04:09 AM I would have to assume that the EFT system is as heavily encrypted and guarded as much as bank EFT's. I may be wrong but I would assume if someone was able to tap in to the network they could credit themselves a whole bunch of money. Sat: Would you happen to remember which pins you used for the coin mech and the coin optic? I have attached a picture of the 16X84 Not sure if the EFT is heavily encrypted as you suggest... I believe that knowing which SAS commands to send and having the proper interface with a SAS enabled machine that can be done as Jay pointed [Of course: It's easier to say it than to DO IT !!] However, I'm interested in what you suggested previously: adding credits through the bills line instead of the coins like I did.... I tell you that because the problem of adding credits through the coin line is that they have to be added serially... If the adding signal is buffered like it's in Aristocrats the adding process is painfully slow. Using the bills line would be better but my knowledge about programming micros doesn't go so far (yet ;)) Are you able to build an emulator of a bill acceptor based on a PIC? Regarding your questions: I used RB0 as "First Pulse" (coils) and RB1 as "Second Pulse" (optics). Remember that both pulses are required in CC-62 or later models alike. Title: Re: Trying to design a coinless system Post by: jay on January 04, 2010, 04:42:53 AM The reason I suggested SAS is that it works universally across all of the major platforms.
I know coin comparitors are pretty universal but the optics may be a bit more proprietary for each platform and as such bypassing the interface may involve a bit more interfacing. We know that the bill validators use different IDs 22/23 for the S+, 24 for S2000 and I suspect it has a bunch to do with timing and possibly sequencing. I am sure once you figure them out it would be easy enough to switch between them however it is still machine specific. From what I know about SAS is that it appears to be a RS422 interface to each slot. EFT being a command does not appear to be any more encypted than the rest of the SAS protocol. I think its a 2 or 3 wire interface. Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 04, 2010, 11:03:37 AM Figuring out what the protocol is for each item is the hard part. If I had my scope still I would narrow it down.
SAT: Good point on the buffering, unless the machines were set for tokenization it could be a painfull time for all the credits to add up. Tokenization being unrealistic since it is machine dependent and not always possible. JAY: The RS422 protocol is sometimes used in a QUASI form which is 4 wires. I have to admit that as far as EFT and SAS I am totally lost. So where that leads me is to emulating the bill acceptor as to make the credits a quicker process (Thanks SAT for the input). I will try to figure out if it is just a pulse sequence. The problem there is it isnt just putting the acceptor on the bench and checking. The machine has to communicate with the acceptor to tell it that it is ready to accept. So that is the first attack. If there is any other insight I would love to hear it. Title: Re: Trying to design a coinless system Post by: SAT (aka GANDHI) on January 04, 2010, 12:32:52 PM If I had my scope still I would narrow it down. I think using a scope (oscilloscope right?) would be the hard way to understand any protocol lol... So where that leads me is to emulating the bill acceptor as to make the credits a quicker process (Thanks SAT for the input). I will try to figure out if it is just a pulse sequence. The problem there is it isnt just putting the acceptor on the bench and checking. The machine has to communicate with the acceptor to tell it that it is ready to accept. So that is the first attack. If there is any other insight I would love to hear it. I'll tell you what I would do if I would have time enough, because believe me: this is a time-consuming task!!! : Through lots of readings, explanations of OP-Bell and other savvy friends I've understood that the bill acceptors are in constant communication with slot machines, something known as "Polling" in electronic communications. The machine is constantly polling (asking) the BV to know its state.... Op-Bell said the other day the frequency was about 200ms, so each 200ms the machine sends a row of serial pulses that means "what are you up to now". At that point the BV has to respond with other row of serial pulses what could mean some of the possible states: "Idle" (nobody has put a bill in the BV yet), or "accepting", "stacking", "rejecting" etc, etc, etc... Each question made by the machine is followed by an acknowledge and answer of the BV. All the words enclosed in "" in this message represents commands that belongs to the serial protocol used by bill acceptors. Those messages are expressed electronically in form of serial pulses, and digitally in form of hex numbers. Those messages has a format, a way to check if messages are OK, and they follow a sequence. For me that is a protocol. The monster I would try to beat. Instead of connecting the BV to a slot machine, I would connect it to my laptop using the harness and software for that and then I would use any of the sniffers (serial port monitors) available in the internet to check "WHAT THE HECK" is my computer talking to my BV and vice-versa lol...... Some suggestions: http://www.serial-port-monitor.com/ (http://www.serial-port-monitor.com/) http://www.kmint21.com/serial-port-monitor/ (http://www.kmint21.com/serial-port-monitor/) http://www.freedownloadmanager.org/downloads/serial_port_sniffer_software/ (http://www.freedownloadmanager.org/downloads/serial_port_sniffer_software/) I'm talking you about understanding the protocol starting from the end. A task comparable to reading a book written in a language you don't know, starting from the last page to the first one, and the book being upside down Some people call it reverse engineering. Are you sure you want to do that? Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 04, 2010, 12:45:19 PM SAT: Its cold, I am house bound until about March so I have a lot of time on my hands. I have found that some protocols use pulse data
which is a good begining. Is there any post on here that shows a homemade cable to talk to the DBV as I do have the software (thank you JCM website). I assume it is a DB-9?? I have a stash of cables that I would like to cut up and use to talk to the dbv. Believe me, I know this is a MAJOR TASK but the only thing lost would be time. 001 DBV/EBA/IBA Parallel Code Interface IGCA 002 WBA/DBV Pulse Interface Various 002/003 WBA/DBV Pulse / Serial Various 003 WBA JCM Standard; bi-directional serial interface All 003B WBA Standard ID-003 with enhanced "B" interface for barcode instruments. Bally Systems. Harrah's Corporate 003WS WBA ***For WMS Games Only*** WMS 004/Bar DBV ID-004 with a few extra codes included for barcode ticket data passage. CDS, Amtote 011 DBV Bill acceptor must be reset in order to intialize Sigma 015 DBV Bi-directional serial interface, includes bar code messaging Sigma 022 DBV Measured pulse interface; defined by IGT IGT only 022/023 WBA/DBV Measured pulse interface; defined by IGT IGT only 023 DBV Similar to ID-022 IGT only 024 WBA/DBV Bi-directional interface designed by IGT; also known as "netplex" IGT only 033 TSP-02 SII compatible printer protocol Bally, Konami etc. 042 DBV Pulse mode only Leisure Entertainment 044 DBV Includes both pulse and 1-direction serial Bally (pre-2K), Williams, and others 044P DBV Interface designed to be backwards compatible with Bally Games Bally 044P/045P DBV Bally 045 DBV Contains a stack signal and messaging included to support barcoding Bally (pre 2K) 045P DBV Same as ID-045 with additional messaging Bally 045W DBV Requires stack signal for coupons only Williams 0C3 WBA Bi-directional serial interface designed several years ago Aristocrat 0D3 DBV-301 MDB Vending customers Enhanced AD-02 AD-02 Enhanced Interface. Source Technology, others MDB DBV-301 MDB (Not designated ID-0D3 because this is not manufactured by JCM) Vending customers Standard AD-02 Standard AD-02 interface EMN8 Title: Re: Trying to design a coinless system Post by: SAT (aka GANDHI) on January 04, 2010, 01:03:43 PM Don't have the harness nor the schematics, but there you can download the DBV-200 manual with all the part numbers and the equipment needed to link the laptop to your BV.
http://www.jcmglobal.com/Libraries/Product_Manuals/DBV-200.sflb.ashx (http://www.jcmglobal.com/Libraries/Product_Manuals/DBV-200.sflb.ashx) Hope it helps. Title: Re: Trying to design a coinless system Post by: SLOTMAN on January 05, 2010, 01:14:38 PM SAT and JAY, thank you very much for the input. Now I need to get working on it. I will keep everyone posted on the progress. I am starting with the coin mech bypass first. That is a simple pulse timing so it will be very easy to do.
There again, I believe in sharing so I will keep everyone posted. Title: Re: Trying to design a coinless system Post by: SAT (aka GANDHI) on January 05, 2010, 02:09:54 PM :172-
:79- Keep us posted |