Node pcb

Digital Kinetic Art Clock

This project is the digital successor to my ClockClock24 Project, a replica of the kinetic art piece by Humans Since 1982. The original features physical clock hands driven by stepper motors, which brings challenges around power supply and makes scaling difficult.

This version replaces the clock hands with round LCD displays, which opens up new possibilities beyond just showing the time: animations, a snake game across all displays, or custom widgets.

Table of contents

• Vision
• Key decisions
• How it works
• Repository layout & component status
• Roadmap
• Open questions

🌅 Vision

The goal is to build a wall mounted array of round LCD displays that act together as one big synchronized screen. Each display sits in its own spot in a grid, similar to the clocks in the predecessor, but instead of physical hands every spot now has its own small screen.

At first, the array will simply show the time. But since every spot is now a real screen and not just a pair of clock hands, I plan to add more features over time. This includes smooth animations where the hands ease in and out instead of jumping, geometric patterns that move across the whole grid, a snake game that can be played across all displays at once, and small widgets like weather or notifications.

One central computer (likely a Raspberry Pi) will control the whole array and decide what should be shown. It sends this information to every display, and each display takes care of showing its own part of the picture.

🧩 Concept

⚙️ How it works

To make the vision above work, the project splits the thinking and the drawing onto different controllers. One controller calculates the global image/animation and broadcasts these to the nodes. Each node controller then renders its individual pixels and displays them.

        ┌───────────────────────────────────────────────┐
        │  MASTER (Raspberry Pi 3)                      │
        │  • Headless Linux, C#                         │
        │  • Time sync, global vector math, game logic  │
        │  • Web UI for control/config                  │ 
        └───────────────────────┬───────────────────────┘
                                │  RS485 bus (broadcast)
                                │  tiny state packets @ 60 FPS
        ┌───────────┬───────────┼───────────┬───────────┐
        ▼           ▼           ▼           ▼           ▼
     ┌──────┐    ┌──────┐    ┌──────┐    ┌──────┐    ┌──────┐
     │ NODE │    │ NODE │    │ NODE │    │ NODE │    │ NODE │  
     │RP2040│    │  +   │    │  +   │    │  +   │    │  +   │
     │GC9A01│    │ LCD  │    │ LCD  │    │ LCD  │    │ LCD  │
     └──────┘    └──────┘    └──────┘    └──────┘    └──────┘
   Each node renders its own pixels locally from the shared global state.

The master and the slave nodes

One computer, the master controller, runs the whole logic. It keeps track of time, decides what the array should be displaying, and runs a simple web page so it can be controlled. Every screen has its own slave controller, together they make up a node. Each node holds the picture for its own screen and draws it fast enough to keep up with all the others. It also knows its own position in the grid, so it only draws its own little piece of the bigger picture. The work is split this way because one controller can think for the whole array, but it cannot draw fast enough on dozens of screens by itself. And a tiny slave controller is fast enough to draw one screen, but it is too small to run all the planning logic. Splitting the work lets both sides do what they are good at. There is also a hard numeric reason the nodes have to render locally. One screen is 240×240 pixels at 16-bit color (RGB565), so one full frame is 240 × 240 × 2 bytes ≈ 112.5 KiB. The RP2040 on each node has 264 KiB of SRAM, so it comfortably fits a double buffer for its own screen (≈225 KiB) with room to spare.

Read more about the master controller in master/README.md, about the nodes in slave/README.md, and about the hardware behind them in pcb/README.md.

How the data is sent to the nodes

Here is the idea that makes the whole array possible. The master does not send a full picture to every screen, sixty times a second. That would be far too much data. Instead, it sends a tiny instruction, something like "the hand should now point at 45 degrees" or "the snake is now at position 12, 2." Every node controller receives the exact same tiny instruction at the exact same moment, and draws its own piece of the picture from it. Streaming one full frame to one screen at 60 FPS is 112.5 KiB × 60 ≈ 6.6 MB/s, for a single screen alone. For 9 nodes that is already ≈ 60 MB/s, at the full 72-node array it is ≈ 475 MB/s. A wired RS485 bus, the kind of connection this project uses, realistically carries somewhere in the low single-digit Mbit/s over a long daisy chain, several hundred times too little. A state instruction, on the other hand, is a handful of bytes sent once, at 60 Hz, no matter how many screens are listening. That gap is the entire reason the master only ever sends instructions, never pixels. This has three nice side effects. It needs very little data, since an instruction is just a handful of bytes instead of a full image. It keeps everything in sync automatically, since every screen hears the same instruction at the same time. And it scales easily, since adding more screens does not change how much data the brain has to send.

To reliably send state instruction a Data Protocol needs to be defined. Read more about this in master/README.md and slave/README.md.

What actually will be displayed

This instruction can describe anything, which is what makes the project exciting. So far the plan includes:

• Time: the original purpose, digits and clock faces drawn across the grid.
• Geometric and animated patterns: motion across the whole grid, with easing animations instead of sudden jumps.
• A snake game: one game played across the entire array at once.
• Small widgets: controlled from the brain's simple web page.
• Gifs

📦 Repository layout & component status

Digital Clock 72/
├── 3D files/
│   ├── final/
│   └── test/
├── docs/
│   ├── datasheets/
│   └── images/
├── master/
│   └── README.md
├── slave/
│   └── README.md
├── pcb/
│   ├── node-pcb/
│   └── README.md
├── tests/
│   ├── phase-1.1-display-performance/
│   └── README.md
└── README.md

🗺️ Roadmap

This roadmap tracks the project progress. The approach is to test cheap, risky parts first before committing to PCB production. The prototype is a 2×2 (4-node) array, large enough to validate the bus, addressing, and power distribution without high cost. Notes for each phase are listed in tests/.

❓ Open questions

• Power at scale. See node_pcb's
• Broadcast protocol definition. Exact protocol definition. Needs to be implemented in master and slave.
• Addressing scheme (firmware). Daisy-chain auto-addressing to be implemented in firmware.
• Syncing How to make sure all displays run in sync