Sometime in the late 1990s, after extensive salvaging of all available electronic scrap that I could beg, buy, borrow, or garbage-dive for convinced me that hardware dev without funding was functionally impossible for someone that people still perceived as being a child.
This led to the assembly of functional requirements & a parts list for modular augmented reality heads-up-display(s) using off-the-shelf parts.
The total cost was around $1k, and that system never saw the light of day.
The far-far-away inspired helmet used as a salvaged-parts HUD testbed, however, is one of my more treasured childhood relics.
Freshman year at university, we acquired the responsibility of refactoring an HRM that was proof-of-concept built by a group of senior students the year before.
We spent almost a thousand hours rebuilding 80-90 percent of the codebase, focused on one very specific problem: the ability to submit time-off requests inside a human resources management system for use where the internet, when available at all, operates at or below the 5kbps range.
The entire codebase was, when I finally abandoned the project almost three years later, less than 5MB on disk, and individual pages would load nearly instantly over a connection of 10kbps or more.
In 2012, having seen some shyte, we registered the domain and started trying to actually make a hardware device that would be useable not only off the grid, but effective if the grid were completely, irrevocably gone.
The original concept:~ jakimfett, circa 2012
A Raspberry Pi inside a weather-resistant enclosure
with battery and renewable energy recharging options,
an aggressive power efficiency controller,
and a long range wifi antenna.
Add an intrusion detection system,
and configure the system to connect
with any in-range open wireless hotspot.
Then connect and safely interact with the internet
using the DarkPi as a bridge.
The hardware concept was relatively simple, from a parts perspective, especially compared to the previous HUD design. The Raspberry Pi single-board computer had been released that spring, and computing devices made not simply possible, but accessible to someone with marginal technical ability, were just starting to hit the mainstream.
Nobody had made a magic mirror yet, and the days of multiple form factors that could be booted from a single SDHC datacard were still in the future, but very much expected.
Frisbee: v0.0.x, circa 2012-2014
- Raspberry Pi 1 SBC (2011 mfg stamp).
- Network file server (sftp) and game dev (Minecraft).
- Retrofitted into the Trio (software lost in transit).
- 3x RasPi (Original Pi, Pi2, Pi Zero) in a psuedo-cluster.
- Meshed, but couldn’t connect out (no bridging to the internet).
- Too large for casual portability,
- (especially with the weight of batteries and charging hardware).
- Performance issues due to:
- near-obsessive levels of security cross-checking.
- original Pi designated as primary interface.
(SDCard form factor prevented easy forwards compatibility & swapping)
- Airgapped updates created significant workflow lag.
- Almost briefly ran FreeBSD (which may be more possible now).
- Overheated easily, due to three Pis running at high load constantly.
- Failed the badlands dogfooding test, design deprecated.
Nomad: v0.4.x, 2019 Q1-Q3
- Raspberry Pi Zero W v1.1 (Adafruit)
- Portable, 4-5 hour battery life.
- First Pi running functions.sh
- USB hub, SD adapter, 3.5mm audio I/O, ethernet (RJ45).
- Built and tested while traveling 4500 km from home and back.
- First successful use of a darkpi unit to make more darkpi units.
- Relatively fragile, dies if dropped.
- Required per-HDMI-output configuration
- Boot now hangs about 5 seconds in (after storage for a month).
Five: v0.5.x, 2019.Q4
- Raspberry Pi Zero W v1.1, cold-swappable to 3B+
- Constructed entirely to enable development of the Shard/Swarm.
- Portable: 8.5 hour battery life, 5″ display.
- Fragile, but very modular.
- More of a testbed/prototype console than a darkpi.
Shard: v0.6.x (2020)
- Raspberry Pi Zero W v1.1 (possibly cold-pluggable, untested)
- Distributed build system for the Assorted Tech office.
- First immutable architecture iteration.
- Deploying infrastructure-as-code proof-of-concept.
- Hub-and-spoke design scales poorly.
Swarm: v0.7.x, 2021-2022
- differentiated by homelab / household need, offline-tolerant
- bridge (network & orchestration gateway)
- flits (portable workstation)
- stem / 5laps (lora & sensor platform)
Beam: v0.8.x, 2022-ongoing
- return to BEAM principles for interface paradigms
- decade-scale durability focus, permacomputing aspirations
- v7 as the dev platform
Hardware commissions will open in early 2019.
Comments are disabled on this post