January 25, 2010
Coinco 9300-CL Reverse Engineering Part 1
The coin changer is a coinco 9300-CL which from what I can tell is the same as the 9300-L model, but with it requiring 117 instead of a lower voltage. Both seem to have the option of a 15 pin or 12 pin plus, the CL has a 12 pin plug. Using the service manual found here. It explains the pinout and basic operation of the coin changer. However the image for any details of the communication is rather blurry and almost impossible to understand, so I had to do some poking to figure out what was what. To start out the 12 pin plug has 6 vertical pins and then 6 more pins that alternate vertical and horizontal. Pin 1 is the first vertical pin of the all vertical group, starting on the left and then 2 in the middle and finally pin 3 on the right. The rest of the pins follow suit in numbering from left to right on each row. Luckily I had a connector that came from the vending device, so I simple had to use my multimeter to find the connected point on the female connector for the main board. Which was nice as it had the two 117 volt pins removed so I could not accidentally destroy anything!
Using the service manual I have compiled a much easier to read version for the pinout as it was on the female header end of the plug. You will notice pin 10 and 12 are missing as there is no need for them because another pair of separate wires run to my power supply for those pins. For basic use it looks like you simple need pin 1 and 2 hooked up to +5 and ground on the arduino and then 3 to a digital output pin and 4 and 5 to digital input pins. Pin 3 is your TX pin for the serial communication where pin 5 is the RX. However pin 4 is used as an interrupt that signals when data is going to be sent. Sadly the service manual only covers a single example of when a coin is used. This states that when a coin is entered it will send an interrupt to the controller via pin 4 and then wait for a signal on pin 3, which after receiving it will finally send a message with information on the coin and other states. This is nice, but what I needed is how to connect to it at startup as well. It looks like when the coin changer is first turned on it sends a status request to the controller and will not fully activate until the request is answered. This is preventing me from actually using it in any way.
So to get around this I hooked everything up to the controller board I already have, that came with the parts, and started intercepting the communication between the coin changer and the controller, using my simple oscilloscope and the arduino to read the serial communication. For the most part the serial communication is simple enough, however I have yet to figure out the actual protocol used. From what I have seen online I believe the 9300-CL uses some form of the MDB protocol however I have not been able to quite narrow it down to the 9 bits it should be using if that is the case. I have tried many different timing setups in order to catch the correct bits, 2400 and 3300 microsecond delays between bits seem to get the best results so far, which I would happily use, if not for the fact that I also need to talk to the coin changer, not just read what it spits out. So I am now waiting for a reply from coinco tech support to see if they can shed some light on the matter, otherwise it will be a slow process of trial and error till I get the right timing and figure out the correct protocol.
January 18, 2010
SSH Messenger
This was an interesting project, not so much on the Objective C side, which I am getting quite good at, instead the shell scripting was a challenge this time. In order to have the SSH command work without setting up key pairs, I needed to delve into the world of Expect. Expect is a handy command set that allows you to set up automation of terminal entry. In short you can have it "expect" some input and then after finding it, send some output to the terminal, which in my case was the password entry for ssh. The ssh command does not have a password argument, so it needed expect to look for the password prompt and then enter a password for the user. It also led to a nice way to do some general result checking in the case of a prompt with two or more button options.
Expect while a little strange at first was not that hard to figure out and only took about an hour and a half to have down pat and working the way I wanted it to. Sadly as it is based out of /usr/bin/expect you cannot use echo command, which made it slightly harder to learn when something was not working.
Check out the base script I came up with below...
#!/usr/bin/expect -f #log_user 0 set addr [lindex $argv 0] set usr [lindex $argv 1] set pas [lindex $argv 2] set message [lindex $argv 3] set from [lindex $argv 4] # now connect to remote UNIX box (addr) with given script to execute spawn ssh $usr@$addr -o StrictHostKeyChecking=no match_max 100000 # Look for any ssh issue that needs exit set timeout 4 expect "ssh:" {exit 2} # Look for password prompt(s) expect "*?assword:*" {send "$pas\r"} # Look for password rejection and exit expect "*?assword:*" {exit 1} set timeout 10 # send osascript commands for popup send "osascript -e 'tell application \"Finder\" to activate'\r" #send "osascript -e 'tell application \"Finder\" to display dialog \"$message\"'\r" send "osascript -e 'tell app \"Finder\" to display dialog \"$message\" buttons \"Ok\" default button 1 with title \"Message From $from\" with icon caution'\r" # Look for reply expect "button returned:Ok" { send "logout\r" exit 0 } send "logout\r" exit;
Another important thing to note is that I was rather annoyed to find out it required the curly braces to be placed how they are, due to it being based on Tcl. However it was only a minor inconvenience until I realized that is why if kept having errors. The script above takes 5 arguments Address, User, Password, Message and From, and is the general Alert script used in the SSH Messenger.
This makes the first Objective C and Shell combo app that I have done, which is a nice change from the Java Shell combo I am more used to working with. That and it was a good refresher in shell scripting.
January 1, 2010
A look back before a step forward...
With the passing of Dec 31, it is now 2010 and I have been think back on the past year. All and all it was not too bad a year, although not exactly perfect either. Looking back...
GOOD...
Graduated from College (with, in my opinion, flying colors)
Caught up on some good reading
Spent time with family
Had fun with friends
Could actually enjoy the full Christmas Season
Finished some very cool projects
BAD...
Still no full time job, (but part time is better than nothing)
No personal car (not huge, but annoying at times)
Paying back school loans (easy to do, but I hate seeing the money leave)
As you can see, the good easily outweighed the bad, which hopefully in this next year will be finish off completely. Because, all and all, other than the lack of full time job, life is not too bad. Thus, I do not think I have much of a right to complain.
After looking at the past year, I got to thinking back on the fact that ten years have passed from the year 2000, and all the changes that have happened in the last ten years. Some of the things I realized where quite amusing.
10 Years ago...
I was happy using dial up (3.5 Kb/s!)
Had never formally programed (but was used to html!)
Used a black & white powerbook duo (system 6.5)
Listened to all my music on cd/cassette player
Never put up a halloween display
Had only hiked one mountain
Lived in a different house
Had a small messy room
Watched way more tv
Could not drive
However a few things have not changed even after ten years...
Still put up a Christmas tree in my room each year
Still chase and poke crabs each summer
Still working with circuits (but much better at it)
Still get along well with my parents
Still fixing things
Still use a Mac
Looking at just these changes over a decade of my life, I have to wonder what will the next ten years bring!