My take on a Psion bluetooth keyboard has been in the works since 2018. It’s one of my first hardware projects and, if I’m honest with myself, was a litte beyond my abilities at the time. There were just too many new things all at once: microcontrollers, 3D printing, and PCB design.

The PsiBoard, while working, has never felt complete

Now that I’ve a little more experience behind me, I’m going to have a go at finishing it—I receive a constant trickle of emails from folks intereted in building their own, and I’d love to be able to offer a complete set of parts and instructions.

Shifting Sands and a New Direction

The world of custom keyboards has moved on significantly since 2018, with devices like the Pro Micro and it’s cousin the nice!nano becoming the go-to microcontrolers, supported by a wide range of off-the-shelf customizable firmware.

Moving forwards, I’m going to use ZMK and a nice!nano. This is a combination I’ve experience with from my work on the Little Luggable, and it should allow me to foucs on the electronics and the industrial design, rather than spending my days working around already-solved firmware issues.

Electronics

The Psion Series 5/5mx keyboard connects using a 20-pin ribbon cable

When I last worked on the PsiBoard, my understanding of the keyboard matrix was as follows (ribbon cable pin numbering given in parentheses):

This has 12 columns, and 8 rows, requiring 20 I/O pins—too many for most microcontrollers (the nice!nano has only 18). Previously, to work around this, I tied the modifier keys to a single column, leading to issues identifying multiple modifier keys¹.

With the benefit of experience, I’ve realized that these modifier keys are intentionally broken-out to allow diodes to be introduced on each of the modifer lines to avoid exactly this problem—Psion skipped putting diodes on the flexible PCB itself, but made it possible to add them where it really matters.

Taking this into account, here’s my updated understanding of what the Series 5 keyboard matrix should look really look like:

Our new row 6 is created by tying pins 1-6 from the ribbon cable to a single pin, by means of a diode on each wire. This prevents loops in the keyboard matrix by ensuring current can only flow in a single direction through the circuit. Happily, this also only requires 15 I/O pins, leaving 3 spare pins on the nice!nano.

Using a breadboard to test the new modifier row and diodes

Returning to a breadboard for prototyping, I was able to confirm this all works correctly and give myself a testbed for my customized ZMK firmware.

Next Steps

With the wiring in place, the next step is to convince myself I can get all the functionality I want with the ZMK firmware, especially around power management.

For the last 4 years, I’ve been working on Bookmarks, a Pinboard client for iOS, macOS, and iPadOS. Bookmarks was my attempt at bringing a Pinboard-like visual experience to private bookmarking. It’s been in public TestFlight beta for the last couple of years and has picked up a fair number of users. After much consideration, I’ve decided to stop working on it.

Bookmarks focuses on offering a more visual experience

Before getting into the details, I’d like to say thank you to everyone who’s been helping me test Bookmarks, and has provided feedback and suggestions during development. It makes a huge difference to know that what I’m building helps others and is very much why I started writing software in the first place. Thank you!

While I’m really proud of what I’ve created with Bookmarks (it’s an app I’ve used almost daily for the last few years), I want to invest my time elsewhere. Maintaining indie software represents a huge amount of work and, of all the software I write and maintain, Bookmarks deviates most from the product I’d design if I started again today¹, and is the one with the most alternatives in the market².

Bookmarks is open source (under the MIT license), so if you’re interested in taking over the project, I encourage you to do so and am happy to help you get up to speed.

Over the past couple of months, I’ve been working on-and-off on Reporter, a new command line utility to make it easier to keep track of changes to your files.

Reporter generates email reports letting you know about changes over time. It’s intended to fill in one of the missing pieces from services like Dropbox for folks who choose to self-host their files using network shares, or tools like Syncthing¹, providing both a quick sanity check that file changes match expectations and an easy way to discover edits in files shared with others.

Reporter generates clean email reports showing file changes

Reporter works by scanning your files and generating a snapshot containing paths, modification times, sizes, and shasums. It then compares this snapshot to the previous one and sends an email summary if there have been any changes. It includes a built in SMTP client (using Swift-SMTP from the Kitura project) to avoid the need to rely on platform-provided mailers and, while it’s written in Swift, compiles and runs happily on Linux (I run it primarily on my Raspberry Pi based home Syncthing mirror).

There’s not much more to say. Reporter is a simple tool with a single purpose. I find it incredibly useful and maybe you will too. Right now, you’ll need to build it from source (and there are some known issues), but if there’s interest, I’ll look into packaging for various platforms. You can find it on GitHub. I’d love to hear how you get on.