1 When the coinmech is idle, it sends 0x31 which is ack'd by replying
2 to it with 0x00. Without this, the coin mech will not accept coins
3 (and they fall through to the return slot).
5 Every time the balance changes (or maybe when an 0xff is sent to the
6 mech), the coin mech sends a packet:
8 (columns are byte number, date, hex, ascii, binary)
9 004a [Fri Aug 8 18:37:19 2003] | 38 8 00111000
10 004b [Fri Aug 8 18:37:19 2003] | 24 $ 00100100
11 004c [Fri Aug 8 18:37:19 2003] | 20 . 00100000
12 004d [Fri Aug 8 18:37:19 2003] | 20 . 00100000
13 004e [Fri Aug 8 18:37:19 2003] | 20 . 00100000
14 004f [Fri Aug 8 18:37:19 2003] | 25 % 00100101
15 0050 [Fri Aug 8 18:37:19 2003] | 20 . 00100000
16 0051 [Fri Aug 8 18:37:19 2003] | 24 $ 00100100
17 0052 [Fri Aug 8 18:37:19 2003] | 20 . 00100000
18 0053 [Fri Aug 8 18:37:19 2003] | 39 9 00111001
20 The first 3 bits are always 001, saying this comes from the coin
21 mech. The 4th bit is 1 for a control byte, and 0 for a data byte.
23 Hence the first 0x38, is a "start of packet" byte. The next 8 bytes
24 are data bytes, so you only look at the lower nibble for data. The
25 next four bytes, and the following two after that denote two numbers
26 which you multiply together to get the value in the mechanism.
28 The second is an 8-bit number which I assume is the smallest
29 possible denomination (in all cases we have, 5c). The first number
30 is a 16-bit number which is the number of the above denominations.
32 eg, above we have (reading most-significant-nibbles last),
33 0000000000000100 = 4. and 00000101 = 5. 4*5 = 20 - so there was 20c
34 in the mech (a 20c coin namely, but the logic doesn't know that).
36 The next byte (0x24 here) seems to be the mantissa of the number to
37 convert to dollars. The firmware uses it to decide where to stick a
38 decimal point on the display. So here 0100 (read in binary) means
39 the decimal point is two places in.
41 The last data byte (0x20 here) is for whether there are coins in the
42 machine. Firmware only looks at the last bit - if it is set, it
43 displays "EXACT COINS ONLY".
45 Finally there's the "end of packet" byte, 0x39.
48 A packet is sent every time the balance of the machine changes, (and
49 possibly when an 0xff is sent - need to test this).
52 When change is given, what occurs is the controller board sends to
53 the machine a byte which is the number of "smallest denominations"
54 that the item cost. Eg, a $1.10 packet of chips is 22x5c. So the
55 logic board sends decimal 22 to the coin mech, and out pops 90c
56 change (assuming a $2 coin was put in).
58 Which means unless there's more to the protocol which doesn't occur
59 in normal conversations, there's no real way we can just "drop out
60 change". Even if we hook into the buttons on the side of the coin
61 mech that dispense money, we don't really have any reliable way to
62 know if there really is money in there or not to drop out.
66 The other problem noticed, is that the coin mechanism will respond
67 to any character written on the serial line, so the idea of using
68 the serial bus is somewhat defeated. (The manual says that using a
69 coin mechanism excludes other devices such as a bill changer or card
70 reader, and I presume this might be why). Which means we may resort
71 to putting a UART on a daughterboard after all.