Devlog #4: Iterating CAD for component assembly and adding necessary detail

With the hardware flow open, I received feedback on my hardware project. A reviewer returned my funding request and advised me to work on adding more detail to my CAD model, since it’s important for actually putting the hardware together and makes CAD your best wingman.

Detailed Assembly

The detailed assembly would be close to the concept from Devlog #2, but:

• Instead of blocks for every hardware component, I’ll use open-source .step files as 1:1 reference models. If the model accurately represents the real part and tolerances are accounted for, Onshape fits should represent reality. (Attribution is given in docs/ATTRIBUTIONS.md in my GitHub repository.)
• Fasteners mattered now, so there was no more pairing of generic screws with generic nuts and calling it a day.
• The clearance holes from before weren’t as reliable as threaded bosses for mounting purposes, so I had to make replacements where necessary.

Hardware Modeling and Fit

Raspberry Pi 4B

Importing the model for the Raspberry Pi 4B revealed an incorrect assumption. I assumed its 4 mounting holes sat near the corners of the board, but they were actually positioned differently. I adjusted the gap between the mounting rails to allow the Pi to rest and moved the mounting holes to where the Pi could line up on top of them, resulting in a mounting-aware pair of rails that I fastened shortly after.

Elecrow RC070 7-inch Touchscreen Display

I took the given file from its product page and merged its individual parts into one composite part. After composing, I added mounting holes matching those of the real component. The screen’s width fit perfectly into the top enclosure’s cutout (same width dimension), and with that, I added 0.5mm clearance to all sides of the top enclosure half’s screen cutout in case tolerance reality decides to strike my hardware.

Anker Portable Charger/Power Bank

This was where it got tricky. There was no available CAD model for the battery pack online, so I had to reverse engineer it myself. Our more realistic battery model had a length of ~153mm, while our placeholder had a length of ~115mm. Since our battery tray was initially modeled to fit snugly around the placeholder model (back when we just needed everything to fit together), our actual battery wasn’t going to fit. Our much more realistic model won over, and I reworked the battery tray with a looser but not as risky fit, centered closer to the side opposite the mounting rails of the inner enclosure’s bottom half.

MicroCenter Flash Drive

This part required some more of the same principle - reverse engineering - and having the flash drive with me made it easier to create a reference model. Dimensions that are reasonably close to the real thing in Onshape allow us to achieve the same purpose: testing the spacing and enclosure considerations of Stardeck.

Challenges

Reverse engineering the battery and flash drive was where I learned the most during this revision. I implemented the dimensions that were most relevant to each part’s size and connectivity (since I didn’t need 10/10 looks here) to concoct replicas that came pretty close to the real thing. I also had to design holes that would work with a custom Featurescript for threading. I tried to increase the thickness of certain sides with mounting holes for ThreadCreator’s sake, but what ended up working was switching to a similar Featurescript called BoazThread.

What’s complete:

• Refined key details of the component assembly
• Related my enclosure hardware to 1:1 hardware models
• Reverse engineered parts without publicly available CAD models

Next up:

• Refine design further (if required for funding)
• Receive physical parts
• Assemble Stardeck IRL
• Get Stardeck to boot

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