Project Logs

Collapse

• The Hackaday Prize Video

  joey castillo • 10/10/2023 at 12:22 • 1 comment

  I’m going to be honest: I had a whole long post I wanted to write this week about ideas for working with writers, a whole “Open Book Quarterly” where, if this thing took off, we could use royalties from the book to commission short stories, and pay writers to publish new works for the Open Book and the world.

  Alas, making this video completely took it out of me. 

  It was a crazy weekend of soldering and screenshotting, building a second prototype with a camera in front of my face and enlisting the help of so many of my colleagues to film me even as I begged to film them. I contended with cursed text encodings (the Windows-1251 Cyrillic text file from a previous post came back to haunt me). I even managed, in the space of a half an hour, to design, mill out, assemble and demonstrate the first Open Book add-on board: a simple external input device with a pair of buttons that demonstrates how an accessibility add-on might be made. 

  
  

  I want to thank several of my colleagues for making this video possible: Amrit Kwatra and Ilan Mandel for helping to shoot video, Evan Kahn for his advice and notes, and Zaq Landsberg for offering to be my hand model and ending up with a starring role as one of the readers of the Open Book. (I'm the other one)

  Featured works in this video include the Odyssey by Homer, How Much Land does a Man Need by Leo Tolstoy, The Art of War by Sun Tzu, and the opening poem from Langston Hughes’ collection of poetry, The Weary Blues. 

  The Odyssey I’ve loved ever since my high school hosted a weekend-long recitation of the work; we read the Fagles translation, but I’ve heard good things about Emily Wilson’s new version. How Much Land does a Man Need is a gut punch of a short story that feels incredibly relevant to our time. The Art of War requires no introduction. And Langston Hughes’ first book of poetry is as powerful today as it was when it was published in 1926. 

• A working prototype!

  joey castillo • 10/01/2023 at 20:32 • 0 comments

  It's funny: while I knew the new Open Book with ESP32 was working — it booted up as far as the boot screen, and our Focus UI framework was working well though to throw an error message about the SD card — I had not actually gotten the Libros firmware fully functioning on the new prototype. 

  To be clear, I knew what needed doing — the TODO list was short, just two items long — but up until this morning, I hadn't made time to do them, and the prototype only made it this far: 

  Yes, if you look closely, there IS a MicroSD card in the card slot at the right; I just hadn't written the code to, y'know, deal with it yet. I also hadn't yet dealt with the bigger issue: getting the reams of language data to work not from an external SPI flash chip, but from the ESP32-S3's own Flash memory, in a dedicated partition set aside for global language support. 

  TL;DR: I checked off both items on the TODO list this afternoon, and now the Open Book with ESP32-S3 is a fully functioning prototype, with all the same functionality of the Abridged Edition crammed into a svelte profile with a slim, rechargeable LiPo.

  Item 1: get sd card working

  This ended up being a super simple two-line fix. Essentially, the Open Book has two SPI buses, one for the SD card and another for the E-Paper display, and I just needed to coax the SDFat library into accepting the desired SPI bus as a parameter. 

  With one tweak to an #ifdef in the library's configuration, and a one line change to specify the SPI bus passed into the configureSD function, the SD card was working, and we were able to make it to the next error screen: 

  Item 2: get babel working from a partition on ESP32-S3's flash

  This one ended up being trickier. First we had to add a partition table to the project, which tells the ESP32-S3 which parts of the Flash to use for our app, and which parts to use for our data. 

  Then, instead of configuring the Babel universal language library to look for language data on a chip on the SPI bus, we point it at the partition we just created, called "babel".

  There's some boilerplate around four-year-old implementations of the Babel abstraction and the typesetter, but the cruxy bit is that we more or less only have to implement one function to make this work: 

  void BabelESP32S3::read(uint32_t addr, void *data, uint32_t len) {
      esp_partition_read(this->babel_partition, addr, data, len);
  }

  This is just the generic read method that the Babel language library uses to read language data. In the BabelSPIFlash class, this would manipulate a chip select pin and read data over hardware SPI. In the case of the ESP32-S3, we just read data from the partition. Easy peasy.  

  With these two changes, the Open Book with ESP32-S3 — the Hackaday Prize entry Open Book — is able to read books from an SD card and display them on the screen. 

  Which, like, I always knew that it would! I just needed one clear Sunday afternoon to make it happen.

• Transparency in Gadget Design

  joey castillo • 09/27/2023 at 19:56 • 0 comments

  On a lark a few weeks ago, I took my existing Open Book enclosure designs and sent them to PCBWay to try out their 3D printing service. For the record, this was not a PCBWay sponsorship thing; although they have sponsored runs of the circuit boards for workshops in the past, this was just me forking over some cash to try out a new process, as sometimes I do. Anyway, on seeing that they offered an option for printing in completely transparent resin, I leaped at the opportunity to check it out. 

  I know it's hard to see something whose entire purpose is to be transparent, so here's a close-up of one of the corners, showing how the black metal M2.5 screw connects the front of the enclosure to the backplate: 

  Anyway, for the record, I don't think you should order this just yet; I can see where I'd like to change the design to implant standoffs for the screws, and the backplate isn't as rigid as I'd like, which is something I think I need to iterate on. 

  Still, it does look extremely cool, and I think it's rad especially for a project like this that aims to demystify the object inside the enclosure. 
  

• How the Open Book Saves the World

  joey castillo • 09/07/2023 at 23:31 • 2 comments

  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....

  Read more »

• You’ll Never Make It On Your Own: Community and The Open Book

  joey castillo • 09/07/2023 at 21:51 • 1 comment

  NOTE: This project log was originally posted on 08/30/2023 at 23:11 EDT, but due to a misunderstanding, it had to be deleted and remade. 
  

  My work on the Open Book spans a whole four years now, from the first idle thoughts of “We should have a DIY e-book” to now, when I think we have a prototype that’s worthy of that claim.
  

  In between then and now, I’ve put three versions of the book forward, not counting the fourth one that I’m submitting here for the Hackaday Prize. Each of these concepts represents a refinement of the idea, from a FeatherWing accessory board, to a standalone object that was hard to build, to a standalone object that was easier to build.

  Still, even as I put these versions of the book forward, I never actually put them forward as fully assembled objects. I put them forward as an open source hardware project, with full schematics, Gerbers and BOMs. Sometimes I sold boards or parts; in other cases I even led workshops. But the premise of the Open Book was always this: you participated in making it.

  Supercon 2022: Joey’s Ad-Hoc Build-a-Book Workshop

  Late last year, when the Abridged Edition design was trending toward done, I decided to bring some of the kits along to my first Hackaday Supercon. I didn’t really have a plan for them, other than to say that I was hoping that they wouldn’t come home with me. The kits, at this point, consisted of a printed circuit board, a display, and a little castellated e-paper driver module (plus a whole mess of cut tape strips in my canvas Hackaday bag). 

  This wasn’t an official workshop. It didn’t appear on the schedule, because I didn’t even know that I was going to do it until I got to Supercon. But while hanging out with some friends and colleagues that Friday, the conversation just drifted there: “Do y’all want to build a book? Let’s do it.”

  “Let’s do it now.”

  So, there, on the floor of Supplyframe HQ, armed with whatever Pinecils and battery packs we had on hand, a dozen folks started soldering. Not everyone in the group had surface mount soldering experience; at least one worried that they wouldn’t be able to build it. The BOM wasn’t kitted at all; rather, the instructions I'd printed on the circuit board said to solder parts in order, and I ran around like the parts fairy — “Anyone need a 10K resistor? Who needs MOSFETS?”
  

  The hour was a chaotic scene, but by the end of it, all the books were assembled. We discovered that a couple of folks’ devices didn’t work completely. But I helped some members of the group, and other members of the group helped each other. By the end, with just a bit of rework, 100% of the people on that floor walked away with their very own working Open Book.

  The experience of running that ad-hoc workshop taught me a couple of things. For one thing, I learned that this version of the design was in fact something that folks could DIY. Of course it also helped me to recognize that I couldn’t be everyone’s personal parts fairy; to make this thing make more sense, I would have to get organized.
  

  A short phase two: selling kits

  After the workshop, I gathered what remaining parts I had on hand, and I assembled a few kits. The Open Book Abridged Edition Kit is essentially the same design as the one in the workshop, but with a component card to keep the parts organized, and with a lot of very carefully placed bubble wrap (not pictured) to protect it when I sent it out, in the mail, to folks who ordered it on the Oddly Specific Shop.

  Here’s the truth though: I never sold that many kits. They were time consuming to put together, and it was really hard to keep them in stock; I’d order ten sets of parts, make ten kits, and then use the proceeds from those ten kits to buy parts for the next ten. I found myself treading water, never quite operating at the volume that I needed to really churn these objects out.
  

  But in the end, it didn’t really matter. Because when you...

  Read more »

• A Book for Every Language, Part II (plus: proportional-width fonts!)

  joey castillo • 09/07/2023 at 21:50 • 2 comments

  NOTE: This project log was originally posted on 08/13/2023 at 21:28 EDT, but due to a misunderstanding, it had to be deleted and remade. 

  OK, right: languages. Where we last left this topic I was introducing Babel, the Open Book’s solution for displaying texts in all the languages of the world. I mentioned that it was a bit like an old school character ROM in a computer from the DOS era, except that instead of a few kilobytes, the Open Book has (up to now) used a two-megabyte SPI Flash chip, packed to the gills with well over 60,000 bitmap glyphs for every language on earth. 

  GNU Unifont, our bitmap font of choice, is mostly an 8x16 bitmap font, which makes it easy to store glyphs: each 8x16 character is sixteen bytes long, with each byte representing the state of one line of pixels. So, for example, the ASCII letter A has a byte representation like this: 
  

  00 00 00 00 18 24 24 42 42 7E 42 42 42 42 00 00 

  …and it looks like this. You can almost visualize how the 00’s correspond to empty lines without pixels, the 7E represents the crossbar with nearly all pixels set, and the repeated 42’s represent the sturdy legs that keep the letter from tipping over: 

  The point though is that this glyph fits in 16 bytes, and if our goal is to support the whole Basic Multilingual Plane — which has code points that range from U+0000 to U+FFFF — you get the sense that naïvely, we could create a lookup table where each character occupies 16 bytes. Then we could look up a character by multiplying its code point by 16: for code point U+0041 (ASCII 65, the letter ‘A’), we could multiply 65 by 16 and expect to find 16 bytes of bitmap data right there. 
  

  Alas, it’s not quite that simple. Remember, I said that Unifont was only mostly 8x16. The reality is, some languages' glyphs don’t fit into a tall skinny 8x16 bitmap. Some characters need more room to breathe. So GNU Unifont also includes a lot of double-width characters that are 16x16, like this Devanagari letter A:

  This glyph is wider, and it requires 32 bytes to represent it. Needless to say, you can’t have a constant time lookup table when some entries are 16 bytes long and others are 32. 
  

  What to do? 

  I suppose we could make our lookup table 32 bytes wide, and just accept that some characters only use the first half of that. The Devanagari ‘A’ could occupy its 32 bytes, and we’d just have to pad out the ASCII ‘A’ with 16 bytes of zeroes. Technically, this would work! It involves a lot of wasted space, but 32 bytes × 65,535 code points = 2,097,120 bytes — just barely small enough to fit into our 2 megabyte Flash chip, with 31 bytes to spare.

  And if we have all the glyphs, we have all the languages, right? 

  …right? 

  Alas — once again — it’s not quite that simple. When it comes to language, nothing is simple. 

  Code points and characters, nonspacing marks, text direction and connected scripts (oh my!)

  As it turns out, there’s a lot more to rendering text than having all the glyphs. For one thing, not only is not every code point assigned, not every code point even represents a character. Some code points represent accent marks or diacritics. Others might be control codes that do things like override the direction of a run of text. 

  Wait: text direction? Yes, as it turns out, not every language reads from left to right. Hebrew and Arabic in particular render from right to left — and Unicode specifies that when a character with right-to-left affinity appears in a run of text — משהו כזה — the direction of the text run needs to switch until a character with a left-to-right affinity appears. 

  Not only that, some scripts like Arabic require connected forms to display correctly: a run of letters (م ث ل   ه ذ ه) need to be connected (مثل هذه) not just to appear legible, but because it’s simply incorrect to render them disconnected. It’s not how the...

  Read more »

• A Book for Every Language: Part I

  joey castillo • 09/07/2023 at 21:47 • 1 comment

  NOTE: This project log was originally posted on 08/05/2023 at 19:00 EDT, but due to a misunderstanding, it had to be deleted and remade. 

  There’s a note in my notepad, under the broad subject area of retrocomputing: “Fundamental tension: understanding the past vs inventing the future.” Today’s notions of computing are the result of decades of choices, conscious and unconscious, by people in the past who invented the future. Some of those choices were the result of deep discussions of technical merit; others were based on expediency or commercial considerations. Either way, these choices ended up written into specifications and protocols, many of them coded in software, but many also implemented in in hardware, creating a built world of objects that represents the past’s implementation of the future. 
  

  Sometimes, the past got it right. Sometimes, it got it wrong. I think it’s important to understand what the past got wrong so that we can invent a better future. 

  One big area where the past intersects with the Open Book is in the encoding of languages. I’ve long felt strongly that the Open Book should support readers of books in all the languages of the world. That means it needs to have some way to store texts in all the world’s languages, and display them on an e-paper display — all on a tiny, low-power microcontroller with the RAM of a computer from the late 1980s and the compute power of a computer from the mid 1990s. 

  Let’s take a trip back in time: what did this era of computing look like? 

  Well, in the late 1980s, you had ASCII, which is lines 2, 3 and 4 of this graphic, and includes glyphs for English letters, numbers and punctuation marks. Many computers also supported “Extended ASCII,” which the first line and the bottom half of this graphic. With this extension, you got characters for several more Western European languages, as well as some symbols for math and engineering. The way this worked was this: your graphics card would have stored bitmap representations of each of these glyphs on a little ROM chip (probably 8 kilobytes), and when displaying text, it would look up the bitmap for each character and copy it into display RAM, so it could render on your monitor. 
  

  This worked fine if you were an English-speaking writer (or a Spanish-speaking mathematician). But if you were interested in transcribing works in a rare or endangered language (like, say, the Cherokee language), your computer wouldn’t be able to do that out of the box. In a world of 8 kilobyte character ROMs, those well-intentioned folks in the past couldn’t fit every language into your computer and make it commercially viable. Moreover, ASCII only has 128 code points (256 if you really stretch it). 

  Those folks in the past had painted themselves into a corner: there was literally no room left to encode more languages. 

  Unicode: Solving the Encoding Problem

  If you’re not familiar with Unicode, here’s the one sentence pitch: it’s an attempt to unify all the world’s writing systems — ancient and modern, past, present and future — into a single universal character encoding. Under Unicode, every glyph for every character that is or ever has been is assigned a unique code point. There are 1.1 million of them available, and we haven’t yet hit 10% utilization. 

  Technically, Unicode was invented in 1991, and computers were getting more capable and powerful throughout the 1990s. Seeing as we had solved this problem from a technical perspective, surely operating systems and users all adopted this new universal character encoding quickly, ushering in a golden age of interoperability, peace and prosperity. 

  Of course, I’m only joking! In reality a patchwork of mutually incompatible code pages dominated the early days of personal computing, remapping the 256 ASCII code points to different languages in a manner that all but guaranteed that any attempt to open a non-Western file...

  Read more »

• Enclosure design and the new Open Book

  joey castillo • 09/07/2023 at 21:45 • 1 comment

  NOTE: This project log was originally posted on 07/27/2023 at 18:51 EDT, but due to a misunderstanding, it had to be deleted and remade. 

  One key requirement for the Open Book has never changed: I want it to be portable. I mean, it has to be, right? You want to toss it in your purse to read on the subway, and that means that it has to be battery-powered and self-contained. As this requirement goes, the original Open Book actually looked OK at a glance: 
  

  But if you look just a little closer, it becomes clear how it failed on both of these metrics. 
  

  Let’s take battery power first: when I was laying out that manic Dr. Bronner’s style circuit board, I wasn’t thinking about where a battery would fit. As a result, we were limited to placing a battery in the one spot without any components on it: the area between the Feather headers. Luckily there is a 400 mAh battery that fits there. But let’s face it: 400 mAh is not a lot of juice. Also, putting the battery on top made the device feel a bit top heavy, which is not a great hand feel.
  

  Then there’s the issue of an enclosure, and the fact that the fit and finish wasn’t great. You can see big holes for the USB port and the lock button, as well as holes for plugging in a FeatherWing — not a ton of ingress protection. The enclosure also wasn’t as thin as I’d hoped it could be: that 400 mAh battery only manages to pack as much power as it does by being 8 millimeters tall, which makes it the thickest object on the board, and all but ensures that the device will be more than a centimeter thick when placed in its housing.

  Later I moved on to the Abridged Edition, which was designed to be easier to hand-solder. Here’s one of the assembled boards — generously sponsored by PCBWay when I wanted to try out their white silkscreen: 

  This part worked! Folks had a lot more success assembling this one. But how does it score on the portability factor? Let’s examine those same two metrics: battery power and enclosure design. 

  To keep the part count low and the hand-soldering easy, this version did away with the entire lithium polymer charging circuit. Instead, it’s powered by a pair of AAA cells, which gives the device something like 1,000 mAh of capacity! 
  

  Alas, it’s a tradeoff when it comes to enclosure design: the device has a chunky “backpack” sticking out. It also lacks a front plate, largely because industrial design hasn’t traditionally been my strong suit: for a long time, I had designer’s block on how to make a “good” 3D printable enclosure. 

  This begs the question, as I work toward a final version of the Open Book: what would a no-compromises version of this design look like? 

  The new Open Book

  First off, I think the circuit board looks something like this. The Lipo charging circuit is back, along with a slim Molex Picoblade connector. You can find batteries with this connector on Aliexpress, and boy did we find one: that huge gray rectangle is a 1,500 mAh battery that’s just three millimeters thin. I was careful to keep a 50 by 70 millimeter area completely devoid of parts, which means the battery can safely fit there, flush with the 1.0 millimeter circuit board. 
  

  This gives the Open Book a much bigger power budget, while keeping the device slim in the extreme. And placing the heavy battery toward the bottom of the board puts its center of gravity in the bottom center of the device — just where we want it for the object to have a satisfying feel in the hand. 
  

  As far as an enclosure design? Well, ideally I’d like to enclose it entirely, save for slim openings for the MicroSD card and USB port. To be clear, I haven’t designed a final version of this yet — I just assembled the first of the new prototypes late last night — but I have been experimenting with an old Abridged Edition with its battery holder pried off and a Lipo shoved inside. As of now, I’m able to enclose that device in a 3D printed...

  Read more »

• The Quest for a Sub-$100, DIY E-Book Reader

  joey castillo • 09/07/2023 at 21:44 • 2 comments

  NOTE: This project log was originally posted on 07/20/2023 at 18:38 EDT, but due to a misunderstanding, it had to be deleted and remade. 

  The other night I was jotting down some notes about the Open Book, trying to figure out how to write about what we did right and what we did wrong, about how we got to where we are from where we came from. In broad strokes, I imagined two parallel tracks to understanding: there’s the engineering of the gadget, the set of choices that make the thing what it is, and then there’s the economics of the gadget, the set of choices that make the thing a viable product. 

  Of course, one of the key lessons learned from this project is that those things are so deeply intertwined that there’s no way to talk about them in isolation. 

  The original Open Book design got a few things right on the engineering side. It got almost nothing right on the economics side. Over the course of this project, I’ve made several revisions of the concept that got closer to threading the needle and getting both right. I think I’m finally close with this latest design, the design I intend to submit for the Hackaday prize. 

  But before we get into that, a quick aside on how these two sides of the equation relate. 

  The Economics of the Gadget, or: What does it cost?

  When I was first designing the Open Book, I imagined that I’d buy a circuit board and a pile of parts, and that would add up to the cost of the gadget. This is one of the reasons I threw the kitchen sink at that board; it had everything from a display and buttons to a headphone jack and a microphone preamplifier for voice commands. I felt okay with it because (in my recollection) the cost of all the parts added up to something like $70 — still less than a Kindle! 

  But here’s the thing: that’s not what the gadget costs. First off, you have to pay someone to assemble the board, and with dozens of lines on the bill of materials (BOM) and more than 130 individual part placements, that would add up to quite a lot. Let’s pencil in $15 for assembly costs, just as a rough guesstimate. Now the board costs $85. (There are other costs like packaging and testing and eventually an enclosure, but for the moment let’s keep it simple.)
  

  If I sold the board for $85, I would in theory break even. But that doesn’t pay me for any of the work I’ve done on the gadget. It also doesn’t help recoup the money I spent on prototypes, fund development of the software that runs on the gadget, or plan ahead for costs associated with designing a future version of the gadget. This $85 is just the cost of goods sold, or COGS, and selling a gadget at cost means you’re losing money. 

  If I want to make the Open Book a sustainable thing, I need to add margin to this number — money I get to keep to run the business (and maybe pay myself a little bit if there’s anything leftover). In my experience running Oddly Specific Objects, I need a minimum of 40 points of margin for the business to even remotely make sense. So how do we add that margin? The math on it looks something like this: 

  sale_price = cost / (1 - margin)

  Or
  

  $85 / (1 - 0.4) = $141.67

  So the gadget costs $142, right? Well, not so fast. My core competency is in designing and making gadgets. It’s not in logistics or marketing. Which is all to say, I don’t want to be in the business of shipping these things individually. I’d much prefer to do something like a Crowd Supply campaign, where we make 1,000 of them, and then we ship them all at once to a distribution partner. 

  In essence, this $142 is my wholesale price, what I’d charge for selling 1,000 of them to a reseller. But that reseller also needs to make money, and a reasonable number might be 30 points of margin for them. Luckily we already know the math for this; we just need to change our perspective. From the reseller’s perspective, my sale price is their cost of goods sold, and we can add their margin on top like this: ...

  Read more »

• The Open Book at Four: Graduation Day

  joey castillo • 09/07/2023 at 21:42 • 3 comments

  NOTE: This project log was originally posted on 07/13/2023 at 18:10 EDT, but due to a misunderstanding, it had to be deleted and remade. 
  

  Hi y’all. It’s been a long time.

  In case you’ve forgotten why you followed this project in the first place, a brief recap: the Open Book is an open hardware e-book reader, designed to be built from parts and understood by the reader who uses it. I searched today for the earliest references I could find to this project, and came up with this tweet from August 9th, 2019: 

  Looking back, it’s wild to think how little I knew back then — or perhaps more optimistically, it’s wild to think of how much I’ve learned since then. I didn’t have a background in electrical engineering when I set out to build this gadget; I wanted to build an e-book, and along the way, I taught myself what I thought I needed to know. To be clear: I’ve made mistakes along the way. In many ways, the early version gracing the cover of the Hackaday project page embodies a lot of those mistakes. But I’ve been working on it on and off ever since, learning more and refining the concept. 
  

  Several times over the years, I’ve commented to friends that this project has been my education in engineering and product design; I built my own curriculum, and taught myself what it takes to ship a product and build a business; I learned accounting and parts sourcing at the same time I learned low power design and firmware development. But if this were a four year program, now would be the time for it to come to a close, and that means a final project. 

  The Open Book is that project, and over the next nine weeks, I intend to get it into shape and submit it for the Hackaday prize.

  There’s a lot to do between now and then, and a lot to update y’all on. For my part, I’m finalizing the circuit board design in the next 48 hours, and I have a new enclosure design printing even as we speak. I hope to be able to share some images and details of those things as soon as next week, with weekly updates to follow in advance of the September 12th “Save the World Wildcard” deadline. 

  Do I think the Open Book is meant to save the world? In a way, yes; it stakes out an alternate vision for technology, using the humble e-book reader as its ideological canvas: 

  • It posits that technology should be understood by the user, not act like a black box. 
  • It posits that technology should serve the user, not the platform owner that created the technology. 
  • It posits that technology should be extensible, offering expansion points for accessibility features that make it work for differently abled users. 
  • It posits that technology should aim to support users around the globe as equals, supporting all the world’s languages by default instead of leaving some behind. 
  • Most of all, it posits technology as a thing that you make out in the open, not a thing that you buy that is closed. I will admit, the exact level of “makiness” may vary a bit from where we started. But the core vision remains as strong as ever.

  Anyway. All will be revealed soon. Until then, thank you so much for your interest in Open Book, and your patience with me as I’ve drawn this vision into the world over the last four years.

View all 10 project logs