Wires i2c

ktane

keep talkin and nobody goes poof :D

this is a physical recreation of the... briefcase, from KEEP TALKING AND NOBODY <REDACTED>. the intention of this project is to be as faithful as possible to the original, so some modules might not be included or otherwise altered so that they can exist within the fabric of reality :]

at its core, the game might seem like a challenging engineering task, as the game's mechanics are governed by a large amount of arbitrary rules that would conceivably allude to the existence of a complex rats nest of circuits and logic. the idea that the serial number would make it so that the 4th wire should be cut instead of the 3rd wire? that must imply that the serial number is somehow mysteriously connected to the wiring of the wires?!? making a system that obeys those rules would be... impossible!

however, this is, in fact, a game. one specific wire isn't a safe wire because a specific quirk of the circuitry allows it to failsafe to prevent detonation, like it is in real... defusal situations. it's a safe wire because, well, "we said so". so, rather than thinking of the rules as implying its internals, we can instead implement it more simply: it is, at its core, a control panel. each module is a uniquely crafted box of buttons, dials, switches, lights, and other doodads that have no real significance other than that they make for a really fun game. the logic that one of those buttons is a good button and a bad button, is, as it is, all logic! and, rather than a control panel that controls, say, a vehicle, or a nuclear reactor, our briefcase is a control panel that plays a game.

as such, the meat of this project can be designated into a handful of sections:

1. circuit design
   connecting all of our switches and blinkers to a brain that can accurately recognise its current status, and how it changes over time.

2. logic programming
   writing the rules of the game into that brain: that a bad switch flick causes mistakes, and a good switch flick causes lights to turn on.

3. product design
   wrapping all of the boilerplate setup into a housing, and then exposing the game's "interface" (the switches and blinkers)

gameplay loop

as reality is often disappointing, specifically, that it cannot be procedurally generated, the briefcase must be set up at a designated time before the game is considered "active", where every physical element can be assembled manually.

as such, the briefcase will have the following states:

enum Phase {
  SETUP, ACTIVE, SOLVED
};

1. setup (if applicable):
   puzzle is inactive, time is frozen at starting time (e.g. 5:00)
   modules can be inserted or disconnected
   modules cannot cause strikes or be completed

2. active: puzzle is active, time will start ticking down, and modules can be completed/cause strikes

3. solved (win/loss): puzzle is inactive, time is at 0:00
   modules should not be connected or disconnected at this time
   modules cannot cause strikes or be completed

modules

as the original game is grouped into modules, it'd be an absolute shame not to engineer the recreation as modular, as each physical "module" can roughly correspond to one virtual module.

generic module implementation

each of these modules will be designed as a standalone ATMega328p (IC from an Arduino R3), as this is a lot more cost-effective than dedicating an entire dev board to a module.

as the modules must stay in sync and send/receive information, they must be connected through communication. we're using a simple 2-wire I²C communication bus (for details, see "Communication")

all modules will have four pinouts to connect to a bus, aside from the exposed interfaces needed for the module:

• 5v (red)
• gnd (black)
• scl (white)
• sda (yellow)

further circuit schematics can be found in the kicad/ folder.

controller "module"

this isn't an actual module, but it has the same footprint and effectively acts as a normal module, so we're counting it here. this is the designated main hub for all of the briefcase's unique properties, including:

• battery count
• indicators
• serial number
• strikes
• timer

this controller will also include a handful of interactive elements, such as a speaker for sound effects and buttons to configure and advance state.

wires module (finally, the good stuff)

during setup phase, this module will accept any number of pin connections between the 6 left and 6 right terminals. these connections must be made with custom wires with a specific resistance to identify their colour, as follows:

• yellow: 100 Ω
• red: 220 Ω
• blue: 470 Ω
• black: 680 Ω
• white: 1k Ω

once setup phase is complete, the module will commit the final configuration of the wires as the "starting state", and any disconnections will cause either a strike or a completion.

any CONNECTIONS... i mean, idk man don't do that lol

communication

communication across the puzzle is handled through an I²C multi-master (different addresses can choose to initiate communication) bus. currently, there is no plan to implement arbitration, so a simple protocol must be created to prevent crosstalk. the general idea is that for any given "state change" event (e.g. user interacting with a module, module/controller connecting, needy module reactivating), only one address should be initiating communication, though this can include any number or combination of send/receives.

controller

always on address 8

possible initiations

• request state from module
• send reset signal to module
• send activate signal to module

format for <briefcase data>

first byte is header, second byte is data:

• header: 0
  data: serial#
  0/1: mod of last digit

• header: 1
  data: batteries

  0	less than 2 batteries
  2	2 batteries
  3	more than 2 batteries

• header: 2
  data: timer
  8 bits: [wwxxyyzz], each packet of 2 is based on each of the 4 digits:

  if digit is	then
  not special	00
  1	01
  4	10
  5	11

• header: 3
  data: number of strikes

module

allocated 56 addresses, could be between 9-64
there are 14 total modules, but addresses must be unique, so each module type can assign as one of 4 addresses:

possible initiations

• request data from controller
• send status to controller (-1/255 for "caused strike")