# Matemat The Matemat is a vending machine for carbonated soft drinks. It is based on an old vending machine with all its electronics replaced by new custom-build circuit boards. All hardware and software was designed by members of [CCC Basel](http://www.ccc-basel.ch) and released in the form of circuit diagrams, printed circuit board layouts and source code for anyone to use and modify. Refer to the LICENSE file for details. The name "Matemat" is a portmanteau of "mate" (as in [yerba mate](https://en.wikipedia.org/wiki/Mate_%28drink%29) and "automat" (the German word for vending machine). The device is mainly intended to dispense mate tea based soft drinks, but may be used for other types of beverages too. ## Structure The heart of the vending machine is a Raspberry Pi model 3 or zero or later, with a custom CAN interface board on its GPIO header. See [CAN Hat](https://github.com/onitake/canhat) for more information. ## Firmware Some of the modules require firmware. There is a makefile in each module's firmware directory to build and flash the firmware to the integrated microcontroller Before building, you need to check out the CAN driver source code, which is referenced as a Git submodule. Run the following commands in the checked out repository: ```shell git submodule init git submodule update ``` ## Modules The Matemat components are highly modular. Individual circuits are connected by CAN bus, and can be extended as needed. ### drive Single-motor driver. Attached directly to each bottle release mechanism. Requires only power supply wires for the motor and the CAN bus line. ### power Motor driver board and power supply. Alternative to the drive board. Uses the existing machine wiring instead of power + CAN. ### control Old central control board. Obsolete. ### feedback End switch feedback interface. Senses the status of the end switches and sends CAN bus messages on changes. This module requires firmware. Connect an Atmel programmer to the ISP header of the feedback board, make sure the programming jumper is shorted and run: ```shell cd feedback/firmware/ make flash ``` ### poweriface Interface between CAN bus and power board. This module requires firmware. Connect an Atmel programmer to the ISP header of the poweriface board, make sure the programming jumper is shorted and run: ```shell cd poweriface/firmware/ make flash ``` ### sensor Environment sensor interface. ### wiring Wring schema of the old vending machine. ### uncanny Central controller software. Has a simple HTTP API for controlling output and checking the current fill status of each slot. Written in Go, must be compiled before use: ```shell cd uncanny/ go build ./cmd/uncanny ``` The resulting `uncanny` executable should be running on the controlling Raspberry Pi. An example SystemD unit is provided in `server/uncanny.service`. Copy `uncanny` to `/usr/bin`, install the service file to `/lib/systemd/system/uncanny.service` and enable it with: ```shell cd uncanny/ cp uncanny /usr/bin/ cp uncanny.service /lib/systemd/system/ systemctl daemon-reload systemctl enable uncanny.service ``` A working CAN bus is required to run `uncanny`. You need to make sure the bus is initialized at boot. On RaspberryOS/Raspbian/Debian, this can be achieved with the following lines in `/etc/network/interfaces`: ``` auto can0 iface can0 inet manual pre-up /sbin/ip link set $IFACE type can bitrate 125000 loopback off sample-point 0.75 up /sbin/ip link set $IFACE up down /sbin/ip link set $IFACE down ``` ## Bus ### Topology All modules are connected via a CAN bus. It is highly recommended to wire them by means of shielded twisted-pair cable with a nominal impedance of 120Ω. At the very least, you need a cable with three wires to ensure a good ground connection between all modules. To allow for easy wiring, six-pole screw terminals are mounted to the PCBs. Two poles are intended for the positive CAN bus line, two for the negative line and two for the shield. They are internally connected together. ### Wiring To achieve a continuous bus topology, connect only two cables to each module. Make sure CAN H is connected to CAN H and CAN L to CAN L. Crossover is not supported on the CAN bus. When wiring is complete, you should end up with a continuous bus that is tapped at each module. Attach 120Ω resistors (preferably 1% or better) to the ends of the bus. The final wiring should look like this: ``` ┌───────────┐ ┌───────────┐ ┌───────────┐ │ module1 │ │ module2 │ │ module3 │ │ │ │ │ │ │ │H L ⏚ H L ⏚│ │H L ⏚ H L ⏚│ │H L ⏚ H L ⏚│ └╥─╥─╥─╥─╥─╥┘ └╥─╥─╥─╥─╥─╥┘ └╥─╥─╥─╥─╥─╥┘ ╰━╯ └╥┘╱ └╥┘╱ └╥┘╱ └╥┘╱ ╰━╯ 120Ω ║╱ ║╱ ║╱ ║╱ 120Ω ╚═════════╝ ╚═════════╝ ``` ### Protocol Bus communication only makes use of basic CAN features. No higher-level protocols such as CiA, EtherCAN, VSCP or similar are required. Normal 11-bit CAN adressing mode is used. For messages that support RTR, any module can send a remote transmission request and the addressed module will respond with the described message. A module may also send the message without being probed. This is the list of supported message IDs: | Message ID | Sender | Receiver | RTR Support? |Data Length | Data Format | Description | |------------|------------|------------|--------------|------------|-------------------------|-------------| | 0x10 | feedback | any | yes | 2 | 0b00000KJI 0bHGFEDCBA | Feedback module status report (A..E = end switch D..H, F..J = empty switch D..H, K = reset switch, 0 = off, 1 = on) | | 0x11 | poweriface | any | yes | 2 | 0bHHHHHHHH 0bLLLLLLLL | Power module status report (0xHHLL are the contents of the 16-bit shift register) | | 0x21 | controller | poweriface | no | 1 | 0b00000MMM | Start dispensing from slot M (1-5) or stop all dispensers (M = 0) | | 0x4f | any | any | no | 1 | 0b0000000E | Enable (E = 1) or disable (E = 0) automatic status updates on all modules |