I've been using my Raspberry Pi Rack design from 2015 since its inception, but it wasn't compatible with the new Raspberry Pi model 4. This new model has a different ethernet and usb port layout and higher power requirements. So, I'm designing a new enclosure.
The reason I started this project was that the new Raspberry Pi 4 is incompatible with my previous Pi Rack. The ports are in a different arrangement and it requires far more power than the connectors I used are able to handle.
All of that additional power needs somewhere to go too. Since the older generation of Pis sip power and don't produce much heat, I made no accommodations for active or even passive cooling in my previous rack. Even so, the Pis stayed cool enough.
Luckily enough, adding accommodations for cooling won't require a large design change. In the rack, the Pis are stood on edge and sandwiched next to each other. This is actually a good arrangement for passive cooling - air warmed by the Pis, if unobstructed, would rise and be replaced with cool air from below. That is, if it wasn't for the solid top and bottom plate holding them in place.
So, without further ado, here's the next set of teasers! First, the "base" plate:
This piece would sit under the row of Pis. The 6 parallel slots are rails for each sled containing a Pi to slide into. The vent grill allows cool air to enter the space between Pis; it will exit out a matching grill on the top plate above. The other holes and slots are a mix of mounting and wire routing; you'll see what they're each used for soon enough. Here's an image of the same part from the previous rack.
Next teaser: the updated sled!
Here we have the hot-swappable Raspberry Pi holding trays. The Pi above is a model 2B, but the PCB mount hole footprint is identical to newer Pis. You can see the vented sides that align with the baseplate.
There's still a few things missing - I'm planning to add some kind of locking mechanism that can keep the tray snugly in the enclosure. The wiring between the dsub connector and Pi needs to be done too.
I've also been playing with the idea of adding additional hardware to the sleds. They're already approximately the size of a 2.5" SSD - I'd have to add a few millimeters to their height. I could probably fit 2 or 3 SSDs if I made a double-wide sled. I'm not sure if I'll pursue this.
The white print in the background is an earlier iteration. I tweaked a few dimensions and thicknesses as well as adding the vented sides between the two prints.
Funnily enough, the black filament I used to 3d print this prototype is the exact same reel my original rack was printed from. It's scrap material now - 4 years of sun and humidity is not kind to PLA - it turned extremely brittle. Prototype prints like this are great way to dispose of your excess filament.
On another topic - I've received the components I'm planning to use for the backplane. I have an ethernet controller, some mux/demuxers, and some relays. I'm planning to design some of the electronics next. In the meantime, check out the previous project log entry if you're curious what these parts will be used for.
I've been playing with the idea of making the Raspberry Pi enclosure smart - that is, giving it features beyond being a dumb power distribution plane. Specifically, adding some degree of out-of-band management. This kind of system management - also called lights-out or sometimes ipkvm, allows you to manage the device as if you were physically interacting with it. For this project, this would translate to something like power management and remote serial.
A frequent problem for servers is the administrator making some change that locks out all users, including themselves. Common causes of this are breaking ssh, the network configuration, or network login related things. But another cause can be a crash or freeze of the system. In this situation, you need physical access to the server to either cycle power to reboot it from the crash, or log in using a physical keyboard and monitor. This is an obvious problem if you are not nearby the device.
Out-of-band management solves this problem. It allows you to access the console and control server power over an internet connection.
The Raspberry Pi has a lesser-known feature called the Serial Console. This kind of interface is extremely common in computing devices - almost every motherboard has this feature, sometimes coupled with serial-over-ip. Other electronics, such as wireless routers, use them as a debug port. Enabling this feature turns 2 pins on the raspi's GPIO header into serial rx/tx pins that the operating system can read or write. While you can technically do anything using this port within the OS, the most common use is, again, the serial console. Linux is able to present a login and command prompt that keystrokes, transmitted over serial, interact with. It ends up being very similar to a normal ssh console. There's more info about how to set up and use this feature over here.
So what does all this mean for this project? Initially, nothing. It's an add-on idea I may pursue afterwards. But here's how it would go:
The tray holding each pi would gain 2 more connections that route through the connector into the backplane. On the backplane there would be serial connections for however many Pis you have. Dealing with this many serial ports would be inconvenient, so I need to design some multiplexing circuitry. Some brief research and queries in the Freenode #arduino chatroom suggests that CMOS logic 'and' gates will do the trick here. ANDing the serial signal with a control signal effectively lets you multiplex a serial line.
The backplane is where this multiplexing circuitry would reside. There would be some kind of microcontroller that can operate the serial multiplexer and read/write data. This microcontroller could also control relays to control power to each individual Pi.
The last question is how the user will operate this system. It should be over an IP connection, so an ethernet interface is probably the best option. Another option would be the classic esp8266, but I want to avoid using wifi. Hard-wired connections are simply more stable. I've seen ethernet shields for arduino. Once the microcontroller has an IP connection, it should be possible to build a simple telnet interface
So, to summarize - I think it would be a really interesting project to add a control plane to this rack. It would provide a telnet over IP connection that could be used to access individual pi's serial console and power on/off individual Pis.
Also, for a quick update - I'm about half done modeling the rack. I still need to add cuts to separate it into easily 3d printable parts and add various mounts for assembly and circuitry and the like.
The d-sub connectors I've been planning to use in this project came in the mail today. They'll be used to send power and data to each removable tray holding a raspberry pi. You may recognize it as a vga connector - it's a very common part picked specifically for an easy to reproduce build.
I also did a quick test print to check if my mounting points were accurate. The print looks minimal but it's actually a part of the larger rack model that has been chopped out.
Even with the plastic mounted, the connectors are a bit difficult to separate. Hopefully these connectors will loosen up - I recall VGA cables being generally pretty easy to disconnect. I'm planning to add a locking mechanism to keep each pi tray snugly in place, perhaps the same mechanism can pry the tray out if operated differently. I haven't designed a locking mechanism before, so it will be a fun experiment. Regardless, the mounts pictured above were a success - with M3 screws (socket-cap ftw!), the clearance is perfect.
- Power supply - my build of the old design uses a computer power supply (and later, a barrel-jack). A computer PSU is a bit unsightly. The design will be modular, but I'll use one of the popular pre-made power supply units, common in 3d printers.
- Hotswap connection - the old design cannibalized ethernet connectors for network and male/female dupont jumper connectors glued into the chassis. While this works, it's fragile and very easy to break. I don't think it would handle the 2.5A power requirement of the model 4 either. The new design will use a d-sub connector that both power and ethernet is routed through. This will add an inch or two of depth to case, but will make it possible to use other single-board computers later.
- Pi chassis - the old design depended on only the friction of the power and ethernet connectors to keep the pi in the chassis. The new design will use a 3d-printed locking mechanism to keep the Pi securely in place.
- Ease of editing the model - I was naive to 3d printing when making the old design, and manually drew it out in Sketchup. The new design will be done using parametric cad - OpenSCAD specifically. It was also drawn at a single configuration, holding exactly 6 of the Pi. Parametric cad being parametric cad, I want it to be very easy to make new configurations of the design.
I'm also only getting started! Here's a teaser for now: