It's me, and I'm back working on the Zorchpad. This is the brainchild of one Kragen. We have somewhat different, but related ideas for where to take the project. The idea is to make a computer that will continue to work as long as the human using it.

It's been a while (9 months) since I've posted about the Zorchpad. Basically, I developed an ugh field* around the case. I had been designing it in CAD and trying to print 3D versions of it, for approaching 2 or 3 months, and I just got sick of it. I kept getting stuck, and delayed, and etc. The problem was that I was just emotionally burnt out on the whole subject, and unwilling to look at the case, let alone try to make it yet again. (Even though there are probably some pretty easy ways to do it, like cardboard or clay.)

Adam Simonyi to the rescue! I sat down with Adam and woefully begged him to take care of the case for me. And he did!

Blame any aesthetic shortcomings on me -- I pushed him pretty hard on "we're just testing electronics! It should look like shit!

Now I am feeling much better and mostly unstuck. I'm ready to start work on the pad again. <3 Thanks Adam!

Even though no big milestones have been accomplished recently, this seems like a good time to summarize the state of the project.

tl;dr: The power budget is 1 milli-watt. As a bit of context, Kragen's approach to making a computer that lasts a long time is to avoid parts that fail. In his experience (he walks around with pocket computers a lot), this seems to include dead batteries. They're out of charge, or need replaced, or there's no power outlet, or he forgot his charger. So his design does not include a battery. Instead, the whole thing is designed to run on solar cells indoors, and hide any power failures from the user. Think an old-school pocket calculator. So, because we want to run on indoor solar, we have a REALLY small power budget (1 milli-watt). Personally, I think even if you have to run on battery, low power use will still be cool.

This heavily influences our hardware choices. We're experimenting and seeing how it works in practice!

Okay, on to the prototype. Where is it at? Get ready for a dump of how my brain works.

v0.1 Roadmap

• CPU:
  • Priority: (Done)
  • Design notes: Apollo3 system-on-a-chip (on an Adafruit breakout board)
  • Hardware State: Working.
  • Software State: Working.
  • Power: Not tested.
• Keyboard:
  • Priority: Blocking
  • Design notes: We need a low-power keyboard. I'm making a "matrix" keyboard (zero power usage, needs outside electronics). You can buy these premade up to numpad size.
  • Hardware State: Not working. I have a 12x5 plate to put keyswitches into, I have switches, and I have keycaps. I should be able to assemble the hardware. Then I will hand-solder them, following instructions from the custom mechanical keyboard community.
  • Software State: Partially working. Tested with 4x4 keyboard.
  • Power: Not tested.
  • Next step: 3D Print
• Video (Screen):
  • Priority: (Done)
  • Design notes: We need a low-power screen. We selected the SHARP memory-in-pixel display.
  • Hardware State: Working.
  • Software State: Working.
  • Power: Not tested.
  • Next step blocker: Power measurement
• Audio Out:
  • Priority: (Done for v0.1)
  • Design notes: Audio is low-power enough that we can do it for headphones. We are adding an audio jack. This also has the advantage that earbuds are easier to replace than speakers.
  • Hardware State: Working.
  • Software State: Beeps only (with PWM)
  • Power: Not tested.
  • Next step blocker: Power measurement
• Persistent Storage:
  • Priority: High
  • Hardware State: Working (built-in to apollo3)
  • Software State: Working.
  • Power: Not tested.
  • Next step blocker: Power measurement
• Power Switch:
  • Priority: Blocking
  • Hardware State: Trivial
  • Next step: Do it
• Wire reduction:
  • Priority: Blocking
  • Design notes: A 12x5 matrix keyboard needs not (12+5) wires, but 9 wires. Combined with all the other peripherals, that's too many, so we need something like a shift register to reduce the wire count.
  • Hardware State: Not working. Have not found a low-power shift register or alternative.
  • Software State: (Blocked on hardware)
  • Next step: Order parts OR Do it with high-power shifter for v0.1
• Wiring, General:
  • Priority: Blocking
  • Hardware State: Not working. (Plan is jumpers or connectors, with wire ends soldered to boards)
  • Next step: Draw wiring diagram, Order parts
• Power Supply:
  • Priority: Blocking
  • Design notes: The first version will probably just be a AA battery (not solar)
  • Hardware State: Not working
  • Next step: Order parts (AA holder), Check required voltages for all parts, Design schematic

v0.2 Roadmap

• E-ink Screen:
  • Priority: Mid
  • Design notes: I'm testing adding an e-ink display as well, because the memory-in-pixel display goes up to around 3-4 inches diagonal only.
  • Hardware State: Not spec'ed. I have two around the house.
  • Software State: Large screen working on RPi but not apollo3, small screen not working.
  • Power: Probably uses too much power. Looking around for different screens that use less.
  • Next step: Research
• PC Communicator:
  • Priority: High.
  • Design notes: How do we talk to the apollo3 from a normal computer? With the larger apollo3 breakout board, we get a UBS programmer, which solves this for early versions. But we can't measure power usage with USB plugged in, it uses some GPIO pins, and it won't work for the final prototypes with the small breakout board. The main goal is to reprogram the software, not to "talk" and send internet traffic.
  • Power: Not tested (could be net power gain!)
  • Next step blocker: GPIO pins
• Audio In:
  • Priority: Very Low
  • Design notes: (none)
  • Hardware State: The apollo3 may have an integrated microphone, I wasn't clear.
  • Software State: Not working.
  • Power: Not tested.
  • Next step: Research
• Hard Disk:
  • Priority: Low
  • Design notes: First version will use a microsd.
  • Hardware: Not working. If we want a slot (as opposed to soldering to the pads), also not ordered.
  • Software: Not working.
  • Power: Not tested.
  • Next step: Buy parts
• Audio Out:
  • Priority: Mid
  • Design notes: Improve to support voices
  • Hardware State: ?
  • Software State: No voice/music yet. Unclear whether that will need a hardware upgrade.
  • Power: Not tested.
  • Next step: Programming, Testing
• GPIO:
  • Priority: Mid
  • Design notes: To let us hook up new peripherals and/or talk to a computer
  • Hardware State: Not working
  • Software State: Not working
  • Next step blocker: Wire reduction
• Power supply v2: Capacitor buffer:
  • Priority: Low
  • Design notes: The actual power source is solar power or a battery. We want a buffer so that when the power dies, we have enough time to hibernate.
  • Next step: Ask for help
• Power supply v3: Solar power:
  • Priority: Low
  • Design notes: Testing solar panels is high priority to make sure they can supply the right amounts of power, but not actually using them.
  • Next step: Buy panels, Test panels
• Power Use Measurement:
  • Priority: Mid
  • Next step: Ask for help (in progress)
• Battery Level Measurement:
  • Priority: Mid
  • Design notes: Monitor the current battery %/runtime, capacitor %/runtime. Optional: trigger an alert when the battery/solar panel is removed, so we can know to hibernate.
  • Next step: Ask for help
• Clock:
  • Priority: Very Low
  • Design notes: Is this needed for power monitors? If so becomes a high priority.
  • Next step: Research
• Connectors + Sockets:
  • Priority: Low
  • Design notes: I'd like to learn how to make sockets. This enables to use better connectors than jumper wires, slot in more expensive chips like the apollo3 to re-use them across builds, and use displays with flex ribbon cables. It also allows end-user servicability.
  • Next step: Requirements, Research, Order parts
• Circuitboarding:
  • Priority: Low
  • Design notes: We're wiring together a bunch of floating parts with hot glue and jumper wires. Switch to having circuitboards instead at some point. Could be perfboard or traditional printed circuits. Printed circuits could be done with a service or at home.
  • Next step: Design in KiCAD, Print
  • Next step blocker: Connectors + Sockets
• Persistence on Power Loss:
  • Design notes: We're planning to run on solar (maybe also battery). If it's dark, you shouldn't lose state. We should just "pause" until the light comes back.
  • Hardware notes: Blocked
  • Software notes: Difficult. This is an OS-level software problem.
  • Next step blockers: Capacitor buffer, Battery level measurement
• OS / VM:
  • Design notes: We want an OS that stops badly-written software from locking up your machine in unfixable ways.
  • Software notes: Not designed
  • Next step: Write software
• Software:
  • Design notes: We need some test software! Text editor, text reader, software editor/compiler.
  • Software notes: Not written
  • Next step: Write software

I’ve been designing a keyboard and case for the zorchpad.

There are four pieces in the first iteration.

A top bottom base, to enclose the keyboard electronics.

A keyboard plate. The keys fit into the holes here. You type on the top, electronics go in the bottom.

A top plate. You see the screens, and switches through the cutouts. Otherwise, it keeps the behind-the-scenes wiring out of sight.

And finally, the top piece.

Here are the pieces in correct position. In the top will be the screens and battery. The bottom is a keyboard you type on. The whole things is meant to fold on a hinge, much like a laptop.

The same pieces, spread out.

There were many, many problems with the first design and the first print. I’ll talk about them (and my fixes) in my next post.

The Zorchpad needs a custom keyboard. Its power budget is only 1mW, and there’s just nothing available in that range. So, I need to make a custom keyboard. I started reading up on how to make your own–especially the electronics.

I don’t know how to make a PCB:

Or how to attach headers to the inside of an existing keyboard, which looks like this–:

But I found a project called GOLEM with an excellent guide to making your own keyboard. Here is their wiring:

I can do that! They got me out of a major rut.

Their advice walks you through how to do a small keyboard in a cardboard plate. I did a few keys, gauged the effort, and decided to use my 3D printer. Cutting out 50-60 keys precisely by hand doesn’t sound easy. Worse, if you mess up, you have to start over. In plastic, I can’t mess up halfway, and the spacers to support the keyboard can be part of the print.

Above, I’m designing a “sampler” keyboard in CAD (OpenSCAD). I want to iron out problems in my process before I try a full-size keyboard. Below, Prusa-Slic3r is slicing the finished model for my 3D printer to print.

Here’s the finished sampler keyboard:

Currently I’m waiting on keycaps and switches ordered from China, and then I’ll put together my finished keyboard. But I have been making some progress in the meantime. Here’s the layout I’m going to try.

And I’ve started streaming some development of a case and keyboard on Twitch (Tue/Thu 12pm noon, EDT). Feel free to join! Anyone can watch, but you need an account to chat.

I’ve gotten to the point in Zorchpad development where I’d like to see how the whole thing fits together and if there will be any insurmountable problems. We’re still trying to figure out some things like–will it have one screen or two? What form factor will it be? Will the keyboard fold in half? So I put together a cardboard model.

This model has:

• A power switch. I’m assuming the very first prototype will run on battery, not solar like the final one.
• Two memory-in-pixel screens (total power usage: 0.001 W)
• One e-ink display (total power usage: variable/unknown)
• An apollo3 artemis board, which includes RAM, CPU, microphone, and BTLE (not pictured, total power usage about 0.0005 W)
• One flash chip (not pictured, power usage variable)
• A battery slot. I’m using AAA for my convenience (Holds: 3000 joules = ~20 days power)
• An audio jack for headphones
• A microSD slot
• A custom keyboard (total power usage: variable/unknown)
  The keyboard is closely modeled off a standard one, for now.

Immediately, a few problems pop out:

• It’s fairly long. This will stick out of my pocket. This is with very closely spaced keys on a somewhat reduced keyboard.
• There’s not really a great place to put solar panels. It’s has almost zero free space, plus there’s going to be a lot of wiring. Are we going to drill holes through the solar panel to let wires pass through? Also, I really haven’t been able to figure out how many cm2 of solar we need.
• It’s hard to get the screen to stay propped up on my cardboard model. I’d like a solution that doesn’t use hinges, since those tend to loosen over time.

My next step will probably be to make a custom working keyboard. Then, I’ll make an entire working zorchpad. Both will be either cardboard or 3d-printed (whichever is easier).

Another update on the zorchpad. We now have a working 16-button keyboard (sadly no QWERTY yet). Here you can see a simple typing program that shows what you type on screen.

As mentioned in a previous post, the reason we’re using a custom keyboard is to stay to low power usage–much lower than a standard keyboard.

So far we have:

• Screen display — both pixels and letters
• Sound output (simple beeps for now)
• Keyboard input

I’ve been pondering simple input methods for microcontrollers. One obvious idea is, a keyboard! But for some reason, my USB keyboards use a staggering amount of power compared to my microcontrollers–1W of power for my mechanical keyboards, maybe 0.1W for the regular ones.

Let’s look inside a commercial keyboard, and see if we can hook up to it:

Yikes. What’s going on? Well, let’s make our own little keyboard, and explore what’s going on. We’ll build it in three layers, or “index cards”:

The bottom layer has 6 vertical stripes. The top layer has 3 horizontal stripes. Each place they cross will be a “key” you can press.

In between them, we add a spacer layer (punched holes) so they keys are “up” by default, and you have to press them to make them connect.

This picture might help explain how they will go together:

Now we assemble:

The final keyboard has 6 x 3 = 18 “keys”. We write the hex digits plus a couple extra keys with marker.

If I attach alligator clips to the second horizontal screw terminal, and fourth vertical screw terminals, and wire a battery and buzzer with the terminals, I get a connection beep only when I press the key “A”:

In a real computer, we obviously can’t just move alligator clips around. Instead, we attach wires to all 9 posts–three outputs wires for the horizontal lines, and six inputs for the vertical lines. We output a signal on the first horizontal line, and see if we can read it from any of the six vertical lines inputs. Then we output a signal on the second horizontal line, and see if we can read it, and so on for the third. Assuming only one key is pressed (or none), we can identify the key. This “scanning” process could be done thousands of times a second, rapidly enough that it can’t miss our slowpoke human fingers.

And this is how most keyboards work. There are some special keys–Shift, Ctrl, Alt, etc might be on their very own line, since we want to detect key combos. And better keyboards can detect multiple keys being pressed at once (N-key rollover), which I think they do by having a completely separate wire to each key which multiple people tell me they do with a diode next to each key.

For the above project, I used:

• Three index cards
• A hole punch
• Scissors
• A ruler
• A pen (NOT a pencil, since graphite is conductive)
• 9 screws, 9 nuts, and 18 washes. I selected #6 American Wire Gauge, which is about 4mm thickness
• Copper tape

Did this work perfectly? Definitely not.

• On some keyboards I’ve made, you have to press quite hard.
• My multimeter takes a while to register a press. I think a microcontroller would be better.
• You have to attach the terminals carefully. I think what’s going on is that you can actually put the screw exactly through the center of the washer which is actually making contact with the strips, so that only the washer is attached, and the screw doesn’t rub against the washer.
• It’s of course fairly easy to mis-align anything. This is pretty easy to fix with care. I used the “spacer” grid to draw the centerpoint of the printed letters.
• The screw heads are a bit thick, so it’s hard to press the keys in the column/row next to the screws. A piece of backing cardboard might fix this.

This was my third attempt. Here’s the second, using aluminium foil. It worked at least as well, maybe better, but it was harder to make. I just taped the foil down, taking care not to cover the contact points. I am told the aluminium will gradually oxidize, making it non-conductive.

And here’s one using graphite from drawing hard with a #2 pencil.. Graphite, it turns out, works terribly, and I couldn’t read a signal halfway down the index card. Despite what people have told me, I’m not yet convinced you can make a conductive wire out of it.

A friend of mine, Kragen Javier Sitaker has been designing something he calls the zorzpad (see link below). I can never remember the name, so as a joke my version became the “zorch pad”. We live on opposite sides of the globe, but we’ve picked up the same or similar hardware, and have been having fun developing the hardware and software together.

The basic idea of the Zorchpad is to have one computer, indefinitely. It should keep working until you die. That means no battery that runs out, and no parts that go bad (and of course, no requirements to “phone home” for the latest update via wifi!). This is not your standard computer, and we’ve been trying a lot of experimental things. One of the main requirements is that everything be very low-power. He picked out the excellent apollo3 processor, which theoretically runs at around 1mW. In general, the zorchpad is made of closed-source hardware.

Since I’ve realized this will be a long project, I’m going to post it piece-by-piece as I make progress. Below is a demo of the display.

The graphics demo shows, in order:

• a title screen
• a flashing screen (to show graphics-mode framerate)
• a demo of font rendering. we’re using the fixed-width font tamsyn.
• a munching squares animation
• a demo of how fast “text-mode” updates would be

We’re using a memory-in-pixel LCD. The only manufacturer is Sharp LCD. You have have seen these before in things like the Pebble watch–they’ve very low-power except when you’re updating. This particular screen is quite tiny–240x400px display (which is fine with me), but only 1.39×2.31 inches (35x59mm). The only bigger screen available in this technology is 67x89mm, a bit lower resolution, and out of stock. As soon as it’s in stock I plan to switch to it.

According to the datasheet, the screen consumes 0.05-0.25mW without an update, and perhaps 0.175-0.35mW updating once per second. We haven’t yet measured the real power consumption for any of the components.

The most obvious alternative is e-ink. E-ink has a muuuch slower refresh rate (maybe 1Hz if you hack it), and uses no power when not updating. Unfortunately it uses orders of magnitude more power for an update. Also, you can get much larger e-ink screens. The final zorchpad might have one, both or something else entirely! We’re in an experimentation phase.

Datasheets, a bill of materials, and all source code can be found in my zorchpad repo. Also check out Kragen’s zorzpad repo.