Devlog #3 - Printing the Physical Enclosure

Good news! This week, I managed to get my 3D printer up and running. Weeks of CAD work finally culminated in a pair of printed enclosure halves. Since I was going for a clamshell design for the first print, I printed both the top and bottom halves to see how they would go together. I knew I was technically doing this to test out tolerances and whatever, but I was secretly excited to be building something outside of Onshape for a change.

Settings

I mostly used my printer’s default profile, adding tree supports for the floating cantilever sections in the internal mounting rails. They printed cleanly and snapped away easily after fabrication. (Detailed slicer settings are documented separately in docs/printer_settings.md.) The only supports needed were for those mounting rails in the bottom half and the alignment lip on the top half. The results, as you’re about to see, went smoothly.

Print Results

Fresh off the 3D printer, I had both enclosure halves. The clamshell enclosure worked exactly how I’d hoped, and it seems like it will make disassembly easy enough to fill the internals with electronics (once I have them) and assembly easy enough to not irritate users. The alignment lips kept both halves aligned, and the lip mounting holes worked as a visual aid that told you whether or not each enclosure half was level or not - a perfect circle meant aligned, sliding semicircles meant you had to nudge it a bit.

The other visible features - the display mounting area, port cutout, and battery tray - also turned out great. I was surprised to see the top half fit like a glove onto the bottom half first-try. After all, I’ve heard scary stories around an imaginary campfire where one tolerance requires reprinting everything (spooky). Luckily, no such thing happened here.

And the mounting holes? They all came out exactly as modeled. The M3 holes on the alignment lips and the M2.5 holes on the display mounts and Pi rails matched the dimensions I designed. Considering how much I’d heard about tolerance problems, seeing everything line up on the first print felt like a small victory.

When I Thought I Messed Up

So…something happened. I noticed fringing filament that was sticking out of certain surfaces. I thought this would compromise the design’s integrity, and so I searched up the problem. After looking online, I found that this event was known as stringing, where melted filament can ooze from the nozzle during travel and solidify on top of whatever it lands on. I was relieved to figure out that this wasn’t a structural problem, but rather an aesthetic one, which I solved by clipping off any excess filament similar to the tree supports.

Summary

Printing the enclosure completely changed how the project felt. Up until this point, Stardeck had only existed inside Onshape. Holding both halves in my hands made it feel less like an idea and more like something I was actually going to finish. I don’t have my electronics just yet, but I believe that Hack Club’s funding process will give me the parts that I need to turn my idea into a reality.

Speaking of the funding process, I’ve also spent a great deal of time in consecutive work sessions just documenting. I’ve been preparing my JOURNAL.md to showcase day-to-day summaries of progress, screenshotting my Onshape designs, and sharing my fabrication workflow. Steps like these are what allow a project to be considered for hardware grants later, which I need to receive the electronics that’ll make Stardeck a real cyberdeck.

The enclosure may only be plastic for now, but it’s the first physical piece of Stardeck. Next comes the stage I’ve been designing around from the beginning: bringing it to life with actual hardware.

Next Up:

• Finish up documentation/design tweaks
• Submit design for hardware funding
• Assemble components into the enclosure
• Craft a booting prototype?

Devlog #2 - Component Assembly and Design Tuning

This week, I was tuning my Stardeck designs to reach feasibility before submitting my design to Stardance for review. I started to test my initial design decisions using Onshape to model the spacing that each part would need, and I used that to finish up a component assembly that reflected how my parts would fit together in the real world.

CAD Assembly

Space was a critical factor in my cyberdeck because it was what everything inside of my enclosure lived on. Furthermore, my enclosure design evolved often to account for unanticipated constraints. A few of my enclosure features for Stardeck surprised me as I never even knew that I needed them at first.

• Clamshell Design: Remember how in the first devlog, I was considering using a rectangular prism with a carved-out back to house all the internal components? I found out very quickly that this would still make for a hard assembly once more than two parts came in. A clamshell design - top half, bottom half - would allow me to make the most of the space given because it would allow me to actually reach many parts of the internals.

• Alignment Lips: This took me a long time to conceptualize after hearing about these for the first time, but it became easy once I thought of a shoebox. The top of any shoebox fits on the bottom half and rests there - not because it’s screwed in place, but because the top half sort of wraps around the bottom half. These made the clamshell more robust as the “shoebox method” promised a safer screwdriver assembly as well.

• Mounting Rails: Placing the Raspberry Pi, which would be the basis of Stardeck’s computing subsystem, in the exact middle of the enclosure meant that other components - battery, screen, flash drive, etc - could reach it easily. However, it can’t just levitate, so it uses mounting rails to keep it up. The rails also come with holes for the Pi to be mounted onto for added security.

• Port Cutout: I felt so relieved after realizing that I needed this before shipping off all my CAD files to display on GitHub. The reason why was because it’s the hole in the enclosure that allows external cables to access the Pi’s USB ports. This makes essential functions such as swapping flash drives and connecting keyboards much easier. Overall, it’s a small design feature that makes assembly and maintenance much easier.

System Architecture

From the last devlog, we already knew how each component would connect to one another in practice. However, I found that for this iteration, the system could be modeled effectively at the subsystem level without a full PCB design or detailed electrical schematic. To follow, I created a System Architecture diagram to demonstrate how the parts of Stardeck interact with each other. After solving the electrical problem, I managed - with several days of me modeling components to depict and assemble - to solve the mechanical problem instead. Both were closely related to each other, which made for a lot of work when planning port maps, looking at diagrams of the port locations on a Raspberry Pi, finding components for the BOM that I want for my build, and so on.

Summary

I learned a lot about hardware selection, using Onshape to work around physical constraints, and building prototypes with future me in mind. I’m confident this design is ready to be submitted at its current state to Stardance. It’s simple and has just enough functionality without going overboard for a minimal viable product. With funding help from them, I’ll have the parts necessary to go from designing a prototype to fabricating a prototype.

Exploded View Part Numbers

1. Top Enclosure
2. Bottom Enclosure
3. Raspberry Pi
4. Battery Pack
5. Screen
6. Flash Drive
7. Alignment Lip
8. Battery Tray
9. Mounting Rails

Next up:

• Print enclosure
• Assemble real-world components
• Iterate on the design (if met with an obstacle during fabrication)

Devlog #1 — Initial Architecture and Packaging Study

🎉What I did this week:

• Defined system architecture for the cyberdeck (power, computer, input, output)
• Selected Raspberry Pi 4B as the main controller
• Created an initial system schematic/diagram to model subsystem interactions
• Performed a first packaging study in Onshape
• Verified that all core components fit within the proposed enclosure concept

🎚️Initial Schematic

Note: This is a system-level schematic used to understand how components in the cyberdeck interact with each other, paired with a packaging study to estimate spatial requirements. This is an early-stage design exploration.

The goal of this stage was to answer the question:

What parts will Stardeck consist of, and how do they interact with one another?

System Overview

The cyberdeck is composed of four primary subsystems:

• Power
• Computer
• Input
• Output

System Description

Power subsystem:

Provides energy to all other subsystems. This is the foundation of the system.

Computer subsystem:

The Raspberry Pi acts as the central controller, managing both input and output operations.

Input subsystem:

The keyboard is the primary input method. Additional input devices may be added later through USB expansion.

Output subsystem:

The display serves as the primary output device, showing system activity and user interface.

🪛Design Direction

After reviewing publicly available cyberdeck designs, I decided on a compact tablet-like form factor.

The current design consists of:

• A front-mounted display embedded into the case
• A Raspberry Pi and power bank mounted inside the enclosure behind the screen

This configuration is chosen to prioritize reaching a functional MVP quickly. Future iterations may introduce improvements such as a rotating or laptop-style hinged display.

🔬Packaging Study Findings

All dimensions are approximate and based on early-stage placeholder modeling. Units are in millimeters (length x width x height).

• Case:
  230 x 160 x 40
  Includes a cutout on the front face for the embedded display.

• Screen (initial placeholder):
  200 x 120 x 15

• Screen (final target, 7 inch):
  155 x 87 x 15

• Raspberry Pi 4B:
  90 x 60 x 25
  Slightly oversized in the model to account for cables, connectors, and mounting tolerance.

• Power bank:
  110 x 70 x 20
  Based on a typical 10,000 mAh USB battery. Final dimensions may change depending on selected model.

Key Finding:

The initial screen model was too large. The original estimate produced a diagonal of approximately 233 mm (about 9.2 inches), which did not match the intended 7 inch display size.

After correction, the 155 x 87 mm screen model aligns with a 7 inch diagonal and is now used as the baseline for enclosure design.

Current Conclusion

The current enclosure design appears sufficient to house all core components based on the current placeholder assembly in Onshape.

Remaining uncertainties primarily involve final battery selection and cable routing.

👣Next Steps

• Finalize selection of power bank
• Choose exact display model
• Begin KiCad schematic for wiring and power design
• Refine enclosure geometry in Onshape based on finalized components

God bless you,
Yodahe