Good morning everyone.
As said, my name is Joey Castillo and I'm here to give a brief talk on, I guess,
comprehensible open hardware, which for the record, I'm not a maker of open
hardware tools. I'm just a humble user of them. But yeah, this talk comes from the
perspective of someone using the tools made by the folks in this room to learn
from open hardware designs and make some of my own. So one of the first things that
I wanted to build when I got into open hardware was called the open book. This is
an open hardware e-reader, more or less. And I wanted to make this for a long time,
way back in like 2018, 2019, when I really wanted to make something like this. I
didn't actually have the skills to make something like this. So to get there, I
went online to steal as much as I could from folks like Adafruit, who make open
source hardware. In opening up their designs for things like this e-paper
driver board, they let me copy a lot of what they did for their gadget into my
gadget. But getting ahead of myself here. The open book is the thing that I wanted
to make, and I had some goals for the device. Those goals were pretty simple, or
simply stated. I wanted to use it to read books. As I pitch it to new
acquaintances, it's like a kindle that you build from scratch. I wanted it to
support reading text in all the languages of the world. And I also wanted it to be
affordable, accessible, and for lack of a better term kind of DIY-able. So just to
give you an idea of what the device is and what it does, here is a short video of
it in use. Here's a listing of books and short stories on the device. And I can
launch this short story by Leo Tolstoy, which of course renders in Russian. The
center button goes back home, where we can select a different work, like here the
Tao Te Ching, rendered in Chinese. So I think it's pretty fun as projects go, but
the fact is that's only half of it. The other half is I wanted the open book to
be comprehensible to the person who builds and uses it. Like, it's through open
hardware that I learned to build open hardware, and I really want to pay that
forward to the people who have their own open book. To explain some of how I tried
to do that, I have to flip it over to the back side. So there are a lot of issues
with this first revision of the open book, but I'm showing it first because of this
sort of dense silkscreen text that kind of became my trademark. Back when people
were on Twitter, multiple folks at various times called me the Dr. Bronner's of
PCB design. For this habit of filling every millimeter of my board with text.
Up here, I'm narrating the entire soap opera of an ideal diode circuit giving
five volts to a regulator, which is interesting, I guess. But why? Why should I pack
my board silkscreen full of this kind of stuff? To answer that, I need to briefly
do my ideology of why I got into open hardware. The problem, as I see it, is
closed tech, especially as shipped by these big tech companies, fails to serve
users of the technology. I tend to look at technology through the lens of power.
Like, take this Kindle, for example. Who is this technology designed to empower?
And while, yes, it does allow you to read books, I'd argue it is designed to empower
Amazon. It's designed to push you into dark patterns that make you spend more money
with Amazon. It's designed to surveil your taps and profile your habits for
Amazon. It's designed to steal your attention and monetize it by selling ads
for makeup or toasters. Meanwhile, the end user just wants to use the device on
their terms without ads for toasters and is prevented from doing so by the platform
owner. The big question for me, why does the tech get away with this? And the
answer that keeps coming back to me is the technology is fundamentally
incomprehensible to the end user. A device like this arrives fully formed as a slab
of glass and plastic and it's meant to be used in the ways the platform owner
sets forth. It's not meant to be understood or hacked or made to better serve the
user. So what can we do about it? Well, I don't have all the answers, but in my
practice at least, my goal is to make tech that folks can understand. My theory is
if we can design well-documented open hardware that people can build on their
own and understand, at least in the broad strokes, we can teach them that they don't
have to accept technology that wasn't made with their best interests at heart.
There is this fantastic quote from Bunny Wong in a blog post about hacking his
Garmin smartwatch. He writes, the point of open hardware is not the ritual of
compiling our stuff from source. It's the awareness that technology is not magic,
that there's a trail of breadcrumbs that any of us could follow to liberate our
digital lives. So with that in mind, what are the breadcrumbs? What trail am I
laying down for users of my objects to follow? Over the course of a few years,
I've had the opportunity to design several different versions of the open book and
I think I've found three different sets of breadcrumbs for three different
contexts. The first one has to do with helping the user understand how the
gadget works, the second helping them understand how to build the gadget
themselves, and third, explaining how to make use of the gadget. Let's take the
first one first. This is one of the earliest open book prototypes and my vision
back then was to use the silkscreen to narrate what each component on the board
does. This has some benefits, I think. Like on the plus side, this could
demystify the tech for someone who sat down and actually read the silkscreen.
On the downside, I have to say, space is limited and I honestly left wondering
if this is the most useful information to give the user. Like, I want to
demystify the tech, I want them to feel like this is something they can understand,
but is understanding how a MOSFET works the best way to do that? The best answer
I can come up with is maybe. Still, there were a couple of bigger issues with this
version of the open book. The parts are kind of small. These are 805 passives,
which are pretty small for the average folk. They're fine-pitched parts. There's
also parts like this microSD slot, which has its solderable connections hidden
underneath a shield. I borrowed that footprint from Adafruit, which is open
hardware and great, but they design for manufacturing, not hand-building. They're
also honestly just way too many parts on this board. It's trying to do too many
things and it's overwhelming to someone trying to build and understand it. So,
yeah, this realization led to a new design that I called the abridged edition. This
version cut the part count down considerably and tried to make it as simple as
possible for people to build themselves. I used bigger passive components, 1206,
and I picked parts with pins that are easily accessible like this new microSD slot.
Instead of making folks solder down a fine-pitched microcontroller, I used the
Raspberry Pi Pico module, which has a super-friendly 0.1-inch pitch. Yeah, some
parts like this flex connector I could not buy on a module, but then I realized I
can make my own module and have it preassembled. This little cast-related
module, the green part, includes the e-paper connector as well as the whole
supporting boost circuit. I ordered dozens of these for a few bucks a piece and I
offered them alongside my main PCB. This meant that DIY makers only had to
plop down one module to get the display working instead of a dozen densely packed
fine-pitched parts. I also decided rather than using the silk screen to explain
things, I could use it to explain how to build the thing. Adding step-by-step
instructions alongside each of the parts on the board is a different trail of
dreadcrumbs, but the upshot was you could follow the instructions, literally
counter-clockwise around the board, and if you followed them all correctly, you
would end up with a working device. Okay, so things I like about this set of
dreadcrumbs, well, it is super effective. Since releasing this design, dozens of
people around the world have assembled their own open book boards without any
of my involvement. Like these photos are community builds that I never touched.
I didn't even send them a board. These are people going in on group buys and part
swaps and having enough success with the build that they've moved on to hacking
on the firmware, which is exactly what I wanted to see. I'll also say we did a
workshop at Hackaday Supercon in 2022, very ad hoc, not a formal workshop. We just
sat on the floor of Supply Frame HQ and I guided a dozen people through building
their own open books, and every single one walked away with a working device.
Like, the plan worked. Still, after the abridged edition and doing these
workshops kind of hands on, I realized to make the project scale to more people, I
couldn't rely on everyone soldering it together themselves. I would have to have
most of the thing done for them. This means I'm no longer using the silk screen to
tell folks how to solder the thing together. Still, I did want to use it to do
something useful. I still wanted to encourage that comprehensibility that we
were talking about earlier. In this case, I kept something from the original open
book, arranging the components in functional blocks, even if I can't fit room for
narrative text to describe what they do. These blocks match what's in my schematic
and how the components are grouped over there. This still gives people an
overview of how the device works. You can see this is not a pile of parts arranged
haphazardly. These parts work together in ways the user can understand. This is the
battery charger. This is the power supply. Still, there is the question of what to do
with the rest of the board space, and I can't leave it blank, so.
The trail I'm finding most useful these days is the trail that leads to making use
of the device. For this latest version of the open book, I'm including pin
assignments as well as notes on how to develop firmware for the device right there
on the circuit board itself. So, I'm going to be honest with you. I use this a
ton when I'm writing my own firmware. Like, I am lazy, really. Sometimes I don't
want to search my own documentation. Sometimes I didn't even write the
documentation. If I don't want to open my schematic to try to decode what I was
thinking when I designed this thing six months ago, what are the odds a user is
going to go to all that effort themselves? Having the docs right there on the board
is an affordance for people making use of my device, and as I found out, I am one
of them. This also works on boards of many shapes and sizes. This is the circuit
board for SensorWatch, the Casio wristwatch mod that I'm wearing on my wrist.
Also, a shout out to Lucas, who is just up here. I learned everything about making
a Casio board swap from your open hardware Pluto watch, so thank you for that.
SensorWatch owes its existence to your project. Anyway, you can see here we're on
the backside. This board is less than one inch in diameter, but we're still able to
include notes about which pins are which, the capabilities, and even which on-chip
peripherals I expect you to call on to make use of those pins. Self-documenting
circuit boards like these attach relevant information to the hardware you already
have physically in hand. This board doesn't just have pin labels. It has a narrative
of how you wire it up. It doesn't just have component designators. It tells you
what they mean for the device configuration. Oops. It creates a self-contained artifact.
This is a prototype of a new version of SensorWatch. I'm still working on the pin
assignments, and they may change before it's final, but even if I put this down and
pick it up in six months, I don't have to cross-check a revision number with a
schematic and a datasheet to get hacking. All the relevant information is literally
in hand. Moreover, that information becomes available to the end user as well.
Unlike closed-source objects, you have to painstakingly reverse engineer. Putting this
information on the board itself makes the object hackable by default. We're throwing
the doors open to the end user without forcing them to do so much as a web search,
much less a deep dive into my repo. Also, just as a side note, this technique pairs
very nicely with code that makes use of the same names. If your silkscreen says
you named a pin button alarm, and the headers for your board support package also
name that pin button alarm, you've made everyone's life easier, including,
actually, maybe even especially your own. Once again, I am not someone who invents
open hardware tools. I am just a humble user of them. And I don't have all the answers
for when it comes to making or helping folks to rock the stuff that we make. Still,
these are some of the ways that I have tried to make some of my stuff more transparent.
And I just want to close with some questions that I can ask myself and we can
ask ourselves as we finalize our designs and send them out into the world. Questions
like, how would I imagine someone using this device? Am I offering affordances
that make it likely they'll achieve what I hope that they'll achieve? What kind of
information would I want to give a user of the device, both at a basic level and
at a more advanced level? And also, I didn't put it on the slide, but what would I
want to know if I'm picking this up after six months and I've forgotten most of my
design choices? Most of all, can I tell the story that I'm trying to tell, the
story of the device in a way that makes sense? Because if I can figure that out
and print it right there on the board, both the artifact and its back story will
live together forever. Anyway, that is what I wanted to share today. So I'm going
to put up my info and I would love to take questions if we had any.
Thank you. So first of all, I love the product and I love your philosophy in
open source. So those open books support EPUB files right now?
It does not. So the open book uses a ESP32 microcontroller. It's a very kind of
resource constrained platform. At this time, I'm supporting plain UTF-8 text.
That is my file format of choice. That might also be a bit of an ideological
choice. I like the idea that a plain text file can represent a literary work.
Plain text feels powerful. I think if space aliens come and see the ruins of
our civilization in a millennium, they'd probably be able to figure out the
UTF-8. I'm not sure if they'd be able to figure out the plethora of things that
go into... EPUB is just a zip. Yeah, having said that, folks ask this
question a lot and now that people are hacking on the firmware, I think it's
entirely possible that I think the ESP32 is a capable microcontroller and I'd
be curious to see what folks come up with in this space. So while it's not
something I'm working on myself, this is the ethos of open source, right?
Throwing the doors open to folks. Awesome, thank you. Thank you.
Yes, but for me the problem is microvision in the sense, so because there
is a lot of SMD, surface-mountain device, and for me it's not practical. You
need an installation of a big house to have a fire and this precision
soldering and so it's not for everybody, this kind of thing. So I know hardware,
but hardware is now in the past, it was easy. Now it's very difficult. So if
you can do a book format, it's little also. I prefer a large format and to
chance to make a chance to come annotation and so on. So what do you
say about that? I think you're absolutely right and I think this is the reason
that I'm starting to move toward getting it PCBA assembled and maybe people just...
maybe the experience of building your own book is like taking a circuit board
that's assembled and putting it into a case of your choosing or 3D printing a
case and maybe that's the larger things that you're putting together, but I
totally understand not everyone is going to be able to solder these fine-pitched
parts and yeah, I think maybe my appetite for DIY got ahead of my understanding
of everyone's capability or desire to DIY. So I think you're totally right and
yeah, I'm probably moving toward more PCBA in the future.
Can you pass the microphone back to Andy?
Hi, thanks. It's really great. A couple of questions. So the
sales screen can mess up your board now if you make a mistake in the documentation.
That is correct. I think it makes me very diligent about triple checking things
before I send it off, but no, I will not lie, that has happened to me before.
No way of automating that?
I'm very curious and maybe some of the folks in this room have ideas, but I do
like the idea of if I know I want to annotate, for example, a line on my
microcontroller symbol, I want that to be on my sales screen. That would be very
interesting to see if there are ways to link those things together. I haven't yet
run across ways to do that, but if anyone in this room knows tools that can help
me with that, I would love to do more of that.
Can you do field substitution in KeyCAD in the sales screen?
Okay, cool. I've been told I can do field substitution in KeyCAD in sales screen,
so that is awesome. As a user of KeyCAD, I will check that out.
Any plans for having a camera on the book that you can scan the board and show
the schematics and the documentation on the ebook itself?
Interestingly, not only in the ebook itself, but I have a colleague who's
working on using kind of QR style codes to get a better sense of the assembly
of various devices. I think there's a lot of possibilities there.
I also had a slide about the idea of, I like the idea of putting things like
QR codes that contain text, not URLs, but if I could put a basic readme in a
QR code and you scan it and you get the full text of a pinout or a description,
that would be very interesting. But yeah, possibilities.
I see one more in the back.
There's a question on the line on the ETA.
So, yeah, the question is, am I planning to offer the open book online or is there
an ETA? And I hope to do a crowd supply campaign at some point this year.
I'm just, yeah, it's hard to find the time to do all the things I want to do,
but hopefully by the end of the year, hopefully in the next few months I'll
have a pre-launch page up and we'll be able to, yeah, put something out there.
Okay, so thank you, Joey.
Thank you. Thank you all.