Mechanical Terminal Update 2
If you haven't listened to their discography yet, I highly recommend checking out Crystal Castles, specifically their songs Vietnam
and Empathy
.
This post is a high-level overview touching on mechanical and product design facets for the mechanical pixel/terminal. All technical specifications and calculations will be included in a TDS which will take a couple weeks to write.
Motors
Previously the last couple days I have been designing a motor for a pixel.
Last Design
I made a previous prototype which did not completely work but convinced me that a working mechanical pixel was possible. It used electromagnets to spin magnets around on a track, pulling the faces in with an oval-shaped cam track and flipping them.
Next Design
This design will have magnets on the pixel faces pulled inwards and spun around on bearings by a single electromagnet that alternates current.
Cost Limitations
- CNC machine time
- Different gauges of wires
- Bearings
- Different springs according to different specifications
Cam Mechanism
No matter how thin you pull in the pixel faces, there will still be some lateral protrusion when spinning. The spinning profile needs to be as small as possible so all the pixels can spin in sync without colliding into eachother. The above diagram shows the minimum the faces need to be pulled in so that when medial motion up and down is introduced in a sinusoidal shape, there will be no protrusions.
From the diagram, we are left with just under .6 of the width of the pixel. That is ample space to put an electromagnet on probably any scale, and is close enough so that magnets on the faces can be pulled inwards.
The medial motion will have to be introduced with an oval cam mechanism moving in tandem with the main electromagnets.
Product Design
The final terminal will likely not be cheap, due to the prices of the components (wire, iron housings, circuitry) - not at all competing with LCDs on price compatibility. So a different market must be sought - making an upper end computer interface.
A key advantage my terminal has is that it is not backlit, and does not require any light at all.
The converse of that is allowing light to go through your screen. OLEDs do that.
Layering OLEDs with other OLEDs or regular LEDs looks terrible. Leads to unwanted Moire Patterns. But you could put a lightless display behind a transparent OLED screen and it would look great.
Accessing the terminal is usually done through terminal emulators on graphic interface systems, which is not truly accessing the terminal because of all the extra layers of software required for a window system. Alternatively, on Linux, you could hit Ctrl + Alt + F1-F6 for TTYs 1-6, but these are extra steps (requires just that many extra keys to press!), make different user sessions on the same machine (overhead), and have user interface problems like not being able to copy and paste, either with the build in GNU commands or the keyboard shortcuts (the way around this is to save your text to a file in one session and use the file in another session). If a dual-layer screen could be made between layering and OLED display and mechanical display, it would immediately become the best way to go between the the terminal and the graphical system.
Having a dual layer screen would be optimal for information density - in the same amount of space, you get around double the informational density (corresponding with pixel density on the mechanical terminal, which will be lower). To see from one to the other, all that is required is readjusting the focus on your eyes - no need for a second monitor or swapping between windows that keep covering eachother up.
I want to distribute the terminal with a custom Linux distro (probably Debian with some special software for controlling the terminal).