What Is a Cyberdeck Actually For?
This project is my first cyberdeck build in close to five years. The last time I was actively building was around my departure from The Cyberdeck Cafe, and stepping away from that space gave me enough distance to rethink what I actually want out of these builds. Back then, momentum mattered. You built fast, finished strong, documented everything, and moved on. What did not always happen was long term use.
One comment from the M3TAL article on Hackaday has stuck with me ever since. “What are these cyberdecks used for exactly?” At the time it felt dismissive. Looking back, it feels fair. Yamato and M3TAL both worked. They both looked the way I wanted them to look. But once the excitement of finishing them wore off, one was eventually parted out and absorbed into other projects, and the other mostly sat on a shelf. They were objects, not tools.
That question is the foundation of this project.
Modularity as the Entire Point
This deck is being built as a platform rather than a finished artifact. Modularity is not a feature I am adding later. It is the core design principle from the start. Every major subsystem is designed with the assumption that it may change, be upgraded, or be removed entirely at some point in the future.
All external modules connect to the main unit through a 44 pin JAMMA style edge connector. I chose this format because it is mechanically robust, simple, and well understood. The connector provides shared power rails, multiple ground references, USB connectivity, and low speed buses like I2C and SPI. That gives each module enough flexibility to be genuinely useful without forcing it to duplicate infrastructure that already exists in the main unit.
Using an edge connector instead of loose cables also changes how the deck feels. Modules seat positively. They are easy to remove and reinstall. Troubleshooting becomes more straightforward because each module can be treated as its own system. If something fails, it does not take the rest of the deck down with it. If a module becomes obsolete, it can be replaced without regret.
This is how I plan to avoid the shelf problem.
Core System and Compute
At the heart of the deck is a Raspberry Pi 5. I am using it not because it is trendy, but because it finally feels capable enough to serve as a real core system rather than a novelty computer. The performance jump over earlier generations is significant, especially when it comes to general responsiveness, peripheral bandwidth, and multitasking.
The Pi 5 lives in the main unit and handles compute, display output, storage management, and the operating system. It is intentionally boring. That is not a criticism. It is a design goal. The core should be stable and predictable so everything else around it can be experimental. If I want to push boundaries, that happens in the modules, not in the heart of the system.
Power is handled by a dedicated UPS style power board that supports safe shutdown and stable voltage regulation. I am treating power, grounding, and noise control as first class concerns rather than things to clean up at the end. This deck is expected to host radios, displays, and other electrically noisy components, so clean power matters if it is going to be reliable.
Communications as a Modular System
One of the primary modules for this deck is the communications module. It is designed to house two software defined radios, a dedicated WiFi board, and a LoRa module. Putting all of this into a single removable module keeps RF related complexity contained. Grounding, shielding, filtering, and layout decisions can all be handled in one place instead of leaking into the rest of the system.
This module is meant to be used, experimented with, and potentially replaced entirely. If better radios become available or my interests shift, the module changes. The deck stays.
Future modules are already part of the plan. Additional storage modules, alternate communications stacks, sensor focused modules, or even task specific processing boards are all possible. I am not trying to predict every future use case. I am trying to make sure the system can adapt when new ones appear.
Input and the Part I Always Enjoy
The keyboard is fully hand wired, which has always been one of my favorite parts of building cyberdecks. There is something grounding about routing every wire yourself and knowing exactly how the matrix is laid out. It is slower than dropping in a prebuilt solution, but it makes the deck feel personal in a way nothing else does.
Input is handled by a dedicated microcontroller that manages both the keyboard and a TrackPoint style pointing device. This keeps latency low, firmware flexible, and input behavior isolated from the main operating system. It also fits the broader philosophy of the build. Each subsystem should do one job well and not interfere with the others.
Why This Time Is Different
This project is not about proving that I can build another cyberdeck. I already know I can do that. It is about answering that old question honestly. What are these cyberdecks used for exactly?
This one is meant to be used. It is meant to change. It is meant to survive past the build phase without being dismantled or forgotten. Modularity is how I am trying to make that happen. If this deck evolves instead of ending up as spare parts or shelf art, then for the first time, I will feel like I built a cyberdeck that actually understands its purpose.