This is my submission for the Hackaday Prize: the ESP32-S3 based Open Book, an open hardware e-book reader that traces its origin to an ancient (or at least pre-pandemic) contest on this very web site. I designed the circuit board from scratch in KiCad in June, after the Hackaday Prize brunch at Teardown inspired me to enter. I prototyped in July, hand-soldering and bodging even as I coded proportional width fonts into the typesetter and worked on new enclosure designs. I wrote project logs in August, describing details about the journey and diving deep into the code and the vision. And I submit it now in September. 

This is the first version of this object that meets my high standards, the first version that I consider worthy of consideration for the Hackaday Prize. It is, in just about every way except form factor, very different from the device that I was hacking on in 2019. It’s benefitted from years of lessons learned about what it takes to ship a real object: 

• It’s physically slimmed down to a centimeter thin, thanks to a dramatic redesign that also slimmed down the part count, and added a wireless MCU that can do more with less. 
• The software’s been rewritten from the ground up, moving from a world of fragile Arduino sketches to a PlatformIO project with a house-built GUI framework, Focus, that’s allowed for massive community involvement. 
• And, for what it's worth, the form factor has a ton of subtle changes, accumulated over years of learning about the ergonomics of the object by using it.

ANYWAY. The reason I bring up the differences is that one thing hasn’t changed since the very first commit: the statement of the problem, and the proposed solution. They’re both in the project description above, but I’ll quote the problem statement here:

As a society, we need an open source device for reading. Books are among the most important documents of our culture, yet the most popular and widespread devices we have for reading are closed objects, operating as small moving parts in a set of giant closed platforms whose owners' interests are not always aligned with readers'.

That was true in 2019, and it’s true today.

It is true that we have more and better open source software for e-books now. The KOReader project has matured greatly, and offers an alternative operating system for many e-readers (at least the ones you can jailbreak). Inkbox has also emerged as a promising alternative OS for Kobo. And the reMarkable tablet has spawned a whole ecosystem of community projects.

Still, these are all options for running open source software on closed source hardware. The problems remain — especially the problem that platform owners’s interests are not aligned with readers’. Amazon in particular has made recent versions of their Kindle more resistant to jailbreaking, because they make more money by showing you ads and reading your reading habits. 

It also remains a problem that all of these objects are complex and opaque, resisting efforts that would help the user of the object understand how it’s made and how it works. That matters. If the companies making hacker-friendly devices decided to get out of the e-book business, squeezed out by the Amazons of the world — this sort of thing has happened before — we’d have no hardware on which to run the open source software.

For most hardware companies, the incomprehensibility of the object is a feature. It’s the moat that keeps competitors from copying them, and the gate that keeps users locked into their platform. The Open Book proposes a different model for making a personal computing device, one outlined in its solution statement (which also hasn’t changed since 2019). In this final post before submitting for the Save the World Wildcard, I figured I’d step through each clause, section by section.

The Open Book aims to be a simple device that anyone can build for themselves.

The simplicity of the Open Book is maybe the biggest departure from the current crop of e-book readers, in that it's built around a microcontroller rather than a full-featured, Linux-capable SoC. This makes it low-power by default, and helps us to avoid many of the complexities like power management that come with designing a single-board computer. The ESP32-S3 gives us a CPU, Flash memory for program storage and font data and enough RAM to buffer a two-bit grayscale display, plus WiFi and Bluetooth (which we don’t even make use of yet) — all in one package whose external component requirements boil down to a pull-up resistor and some 10µF capacitors.

It’s very simple.

The second clause, “that anyone can build for themselves”, has taken on different meanings over the course of the project. At first I thought it meant that one person, alone with a soldering iron, should have the capacity to build this object. Over the years I’ve learned that not everyone wants that. It’s still possible, of course; I hand-solder every Open Book prototype myself. But the ESP32-S3 Open Book is designed for manufacturability, and it’s designed for manufacturability by even the most home-brew setup possible:

• It’s a two-layer board with design rules that any PCB house can fabricate cheaply.
• All passives are 0805 or 1206, which means you can place them with tweezers or an open source pick and place.
• Assembly is single-sided, except for some through-hole buttons that we may be able to get rid of.
• All pads are exposed, which makes rework easy.
• The part count is low: on the order of 45 surface mount parts in a minimal configuration, and 55 with all features included.
• Finally, the enclosure is 3D-printable on even the most basic 3D printers, and it’s held together with nothing more than four M2.5 screws.

I think this object is simple enough to build now that anyone with a membership at a hacker space could spin up a little Open Book manufacturing side hustle.

The Open Book should be comprehensible: the reader should be able to look at it and understand, at least in broad strokes, how it works.

While it doesn’t have quite the same “Dr. Bronner’s” energy as the 2019 Open Book, which strove to explain every aspect of its operation, this ESP32-S3 Open Book still leans in to comprehensibility. 

All parts are placed in groups, with their purpose clearly marked. I may not have the room to explain just how the e-paper boost circuit works, but at least it’s clear that that cluster of parts relates to that aspect of the object — and if you want to go to the schematic, you’ll find the same grouping of components there too.

Down below, I've used the battery keepout area to offer something that I’ve realized is even more useful than a narrative explanation: the Open Book includes a technical description of all the pins and functions of the microcontroller, along with a short narrative that describes some of the subtler aspects of the design.

I’m going to be honest: this is partly to make the object comprehensible to me; I can’t count the number of times I’ve referred back to this guide when hacking on the new firmware build for this version of the hardware.

It should be extensible, so that a reader with different needs can write code and add accessories that make the book work for them.

At the end of that narrative description, you’ll notice the bit about the I²C port and GPIO’s A and B. This is a feature of the Open Book that’s been there since the beginning, and that I still think remains important and valuable. Not everyone has the same physical abilities or even wants to use the device in the same way; some people have trouble hand-holding a device; others may struggle with pressing the physical buttons on a gadget like this.

The two GPIO ports could allow for the addition of alternative input methods like a foot pedal or analog dial (both IO’s are on ADC pins). The I²C port could be used to add a variety of digital sensors, such as a gesture sensor or a GPIO expander that would allow for more and more complex types of input.

The I²C port uses Adafruit’s STEMMA-QT standard, which makes use of a very common JST-SH 4-pin cable. GPIO’s A and B use a JST-SH 3-pin cable, which is becoming more common ever since Raspberry Pi decided to use it as the debug connector on their new Pi Pico H series of boards. (The 2019 Open Book used the chunkier JST-PH standard; moving to SH slims down the case design and leaves more room for a bigger battery.)

It should be global, supporting readers of books in all the languages of the world.

We’ve already talked about this in a profound degree of detail, but just to recap: where the original Open Book from 2019 was able to support the entire Unicode Basic Multilingual Plane, I believe this new version of the Open Book could also support the Supplemental Multilingual Plane, which would open the doors to displaying works in ancient languages, add support for more obscure and historical CJK glyphs (and of course let us read books written with emoji).

I want to be clear: this isn’t done yet; right now we still only — ”only” — have the Basic Multilingual Plane. But the 8 MB of Flash capacity on the ESP32-S3 makes this a reasonable and achievable goal with some software work in the months to come.

Most of all, it should be open, so that anyone can take this design as a starting point and use it to build a better book.

We also talked about this a bit last week, but the bottom line is the openness of the Open Book has already inspired folks to build a better book. Right now it’s mostly taking the form of new enclosure designs, and software forks that make the book do the things that folks want it to do. But I’m also seeing folks designing their own e-book readers these days, including one that’s submitted for this very same Hackaday prize.

Folks also reach out to me and open GitHub issues asking if it’s possible to make one with a bigger screen, or a touchscreen, or a screen from a recycled Kindle. I sense these folks may just be a few steps away from deciding to build it themselves. Personally I’d love for a well-designed, highly manufacturable open source e-book reader to kick off a Cambrian explosion of form factors and functionality for portable reading, a reimagining of this sector that’s so far been largely a closed source world.

Conclusions

A few months back, a colleague interviewed me for a paper she was working on. In that conversation, the question came up of, y’know, my “deal”, and I found myself describing my sense of resentment toward technology as we’ve built it. A Kindle comes into your life fully formed: a gray slab of glass and silicon. You’re invited to use it; you’re invited to consume with it; but you’re not invited to understand it. You’re not invited to customize it or change it, at least outside the narrow lines drawn for you. 

The device is not “yours”.

I contrast that with the kind of computing I grew up with, that Windows 3.1 era, when you could build your own computer with your own accessories, and then go into display settings and change every color of every window to make garish color schemes that would make designers in Redmond cringe. The thing is, that was okay! It empowered the user; it showed them that the computing device was something that they had power over. It showed the user that they could make this technology serve them. Whereas now, it feels like companies make technologies that don’t serve the user; if anything, these technologies make the user the servant of some other vision, a vision that none of us really signed up for.

When I say I want to build comprehensible open source objects, what I’m trying to say is I want to show people another way. I want to say, “No, you built this thing. You can understand this thing. You don’t serve it; it serves you.” This object represents a vision for an alternative way of designing objects: in the open, shared and forkable, in a manner meant to empower the user instead of the platform owner. 

Plus you can read books on it.