Background

For a while, I had been interested in learning more about PCB design and 3d printing. I also had been playing around with the idea of building a modular electronic catan board.

The goals for the project was to

I also set some limitations to make the project more feasible. In the past, I've done some fairly simple THT soldering, but I wasn't confident in my ability to manually do SMD soldering and I did not plan on getting a reflow oven, so al the parts needed to be THT. I also had limited experience with arduino language, so I decided to stick with that instead of learning AVR C.

To possibly add some longevity to the project, I decided to split the project into two separate circuits: the catan tile and a generic, reusable network tile. The network tile would be responsible for routing messages between tiles and the game tile. The catan tile would represent a single tile of catan, handle user input, and communicate with other tiles via the network tile layer. Because of my restrictions to use arduino + THT, I settled on using the ATMEGA328P, the same MCU as an Arduino UNO, for both boards.

Network Tile

Each tile needs to communicate with its 6 neighbors and the attached game tile. I wanted to use the hardware serial port for logging/debugging, so I needed some other way of communicating between boards. I had to rule out I2C and SPI because I needed to know the topology of the board in order to set up a valid board. Just having a tile as an address on a bus wasn't enough. I finally settled on the built in SoftwareSerial library for this.

After creating a few arduino-on-a-breadboards, I experimented with using multiple software serial ports to communicate. Once done, I created a protocol that could be implemented to send arbitrary messages over a network of such tiles.

   0                   1                   2                   3  
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Start Code  | Source Address|Destination Ad.| Payload Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               | System Option | System Command|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Start Code:  8 bits
     Used to indicate start of message
   Source Address:  8 bits
     The source address
   Destination Address: 8 bits
     The destination address
   Payload Length: 16 bits
     Size of the a pyload after the header in bytes
   System Option: 8 bits
     Specifies system options to use
   
   System Command: 8 bits
     Specifies network commands to perform

 One caveat of using SoftwareSerial is that it can only listen on one port at a time. To handle networking, I would need the tile to constantly round-robin the ports listening for an incomming message. I created a common library that could ping a destination until acknoledged and then read/write messages.

With several more breadboarded tiles assembled, I began working on network discovery. This would work by having a designated tile attempt to discover the network by attempting a breadth first traversal to discover new nodes. The network is fairly dumb, so the coordinator also needs to distribute updates whenever it receives information about a new node so that the others can also route messages to it.

I quickly ran into an issue, however. It seemed that the single MCU did not have enough memory/power to handle both routing messages using the 7 soft serial ports and coordinating network discovery. Instead of trying a more robust MCU, I decided to offload netowrk topology, discovery coordination, and shortest path calculation to a second MCU on the same circuit. This Pathfinder would be a separate device that the router could communicate with using I2C.

Catan Tile

The game tile needed to display the role value, support placing roads and settlements, changing the robber location, changing the currently active player, and setup a random and valid board.

The roads, settlements, and land type would be represented using neopixels so that I could easily control the different colors without using a ton of pins that a single UNO does not have. Each tile would need 6 LEDS along the edges to represent roads and harbors. For the settlements, only 2 corners per tile would have 2 LEDs each (1 for settlement, 2 for city), and one in the center for the resource type. I chose to only have LEDs on 2 corners and represent the other corners using neighboring tiles. This has the downside of requiring a complete ring of tiles around the board for the ocean.

For the roll value and robber, O originally thought of using a stepper motor with a wheel with labels, but that not going to work out. Instead, I settled on using a double digit 16 segment display. The inputs would require 6 edge buttons, 2 corner buttons, a center button for changing between game and test modes, and a final button to place the robber/change player color.


The buttons and 16 segment display would need far more IO pins than available, so I used switch registers to save pins. The catan tile was then able to be split into 4 modules that I could test on 4 separate breadboards:

Tile Design

Since I wanted to be able to reconfigure the tile, the final circuit and case needed to not be physically attached. The network tile needed to use pogo pin headers to connect, with at least 5 pins. I could not find any affordable 5 pin headers, so I went with 6 (VCC, TX, GND, GND, RX, VCC). To keep the boards close together,

I designed the case with 6 wells around the edges to hold a rare earth block magnet. I also wanted to create a lid out of a translucent material. After several iterations, I found that the case also needed small guides to prevent tiles from slipping and causing shorts when pins no longer lined up correctly. The lit also had to be abandonded because the pressure deformed the case sufficiently to make lining up the pins inconsistent. Instead, I printed a thin sheet that could be screwed on.

The network PCB is very simple. The catan PCB has all the IO components (LEDs, buttons...) on one side and theothers on the back. The two boards are connected by a 4 pin connection for power and data.


How to Play

Putting it all together

With how slow things like validation and player color change is, actually playing catan is very slow and not terribly practical, but the goal of this project. I just wanted to make something I thought was cool.


Fairly late into the project, I ran into several issues. The first was that the network graph was that network communication seemed unreliable. Random lockups would occur, requiring a power cycle to reset everything. This meant loosing the game board. My initial solution was to save as much long-term state to EEPROM. this had the added benefit of being able to resume a game after power cycling.

The network hiccups persisted, however. I had seen this earlier on in development when I was using an insufficient power supply. With a variable bench powersupply, I was able to supply the board with as much power as it needed. Issues were less common, but still occurred. I found that slowing the baud rate of the software serial ports finally worked.

The remaining issue is network discovery speed and to a lesser extent, reliability. The process to discover and distribute the network for all 52 tiles os O(n^2) and takes ~25 minutes. This is die to the time wasted waiting for the software port to come around when trying to send messages, time wasted pinging empty ports to see if they exist, and then all this is compounded having to send updates to every node for every node. The board can be reset without rediscovery, but if the board is reconfigured, discovery is mandatory.

Reliability wise, I have not had issues so far since slowing its speed, but it certainly isn't resilient. If a node goes dead, the network can't see that and will try to pass messages through it indefinitely, locking up more nodes.