Close
0%
0%

The Open Book

An open hardware reading device that's easy to build, easy to manufacture, and easy to make your own.

Similar projects worth following
This is a complete reimagining of the Open Book Project, but the original mission remains:

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

The Open Book aims to be a simple device that anyone can build for themselves. 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. It should be extensible, so that a reader with different needs can write code and add accessories that make the book work for them. It should be global, supporting readers of books in all the languages of the world. 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.

This is an open hardware e-book reader designed around the ESP32-S3. It grew out of an old design for a Feather-oriented board that I designed before the pandemic. With the benefit of four years learning the ins and outs of design, manufacturing and community development, I designed this new version over the summer specifically to submit for the Hackaday Prize. 

The Open Book stakes out an alternate vision for developing personal computing devices, 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. 

To that end, the Open Book embraces a radically open design, outlining the functional groups of parts on printed circuit board in the same way they're grouped on the schematic. It prints a list of pin functions on the board itself, opening the device up to being hacked on and extended. It offers two analog-capable GPIO pins and an I²C bus using common, standard connectors. And it supports the entire Unicode basic multilingual plane, ensuring that readers of books in all the world's languages will find a home in the Open Book.

Moreover its focus on affordability and design for manufacturability make this a piece of hardware that could be built by anyone, either in a makerspace with basic soldering tools or in the context of a small manufacturing line. The open source enclosure is 3D printable on a basic FDM printer; the open source board design can be fabricated by just about any PCB house, and the parts are large enough to be pick and placeable by hand or with an open source pick and place machine. 

The Open Book's community has, over the course of years, enthusiastically embraced previous iterations of the Open Book: building and sharing alternative enclosure designs, forking the firmware to add functionality, and even helping each other to source circuit boards and trade parts so that they could build their own devices. 

I believe that I can turn this version of the Open Book into an open hardware product that continues to fulfill the promise of the Open Book while putting this vision and this object into the hands of a larger community of readers. 

License Info

The Open Book's hardware is released under a Creative Commons BY-SA 4.0 license. [link]

The Open Book's firmware is released under the MIT license. [link]

OSO-BOOK-B1.pdf

PDF of the Open Book schematic, as submitted for the Hackaday Prize.

Adobe Portable Document Format - 652.29 kB - 10/08/2023 at 04:28

Preview
Download

OSO-BOOK-B1-01.zip

Gerber files for rev 01 of the Open Book, as submitted for the Hackaday Prize.

Zip Archive - 3.95 MB - 10/08/2023 at 03:47

Download

OSO-BOOK-B1.csv

BOM for rev 01 of the Open Book, as submitted for the Hackaday Prize. Specific part numbers are mentioned in the “Value” column; generic passives include just the component value and spec since the specific part I used doesn't really matter. Check the “Footprint” and “Notes” column to make sure you're getting the right stuff.

Comma-Separated Values - 2.90 kB - 10/08/2023 at 05:18

Download

Open Book - Sprint 5.scad

OpenSCAD sources for the Open Book enclosure as of the Hackaday Prize submission. Designed for FDM printing. Some options may not be fully implemented. NOTE: This design requires that you use either metal M2.5 screws (to bite into the plastic) or an M2.5 tap wrench if you plan to use nylon screws.

scad - 11.47 kB - 10/08/2023 at 04:31

Download

Open Book - Sprint 5 Frontplate.stl

STL file for the WIP frontplate, generated from the OpenSCAD sources above. Designed for FDM printing; the fit may not be as good with other fabrication processes.

Standard Tesselated Geometry - 155.16 kB - 10/08/2023 at 04:43

Download

View all 6 files

  • The Hackaday Prize Video

    joey castillo10/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 castillo10/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 castillo09/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 castillo09/07/2023 at 23:31 1 comment

    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 castillo09/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 castillo09/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 castillo09/07/2023 at 21:47 2 comments

    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 castillo09/07/2023 at 21:45 0 comments

    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 castillo09/07/2023 at 21:44 4 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 castillo09/07/2023 at 21:42 4 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

  • 1
    Procure parts for the Open Book

    You'll need parts from a few suppliers to build your Open Book: 

    • You can get printed circuit boards from a PCB fabrication service like PCBWay. Just upload the zipped gerbers provided in the Files section.
    • Next, procure components for the build; follow the BOM provided in the Files section, and you should be able to get almost all the components from Digi-Key.
    • The e-paper display, you'll have to source from Good Display.
    • The battery is available on Aliexpress.
    • Finally, if you plan to 3D print a case for your Open Book, you can get the metal M2.5 screws from McMaster-Carr.
  • 2
    Assemble the Open Book PCB

    I'll admit that this step has “draw the rest of the owl” vibes to it, but the truth is, there are so many ways to assemble a circuit board that I don't want to be prescriptive. You may want to order a stencil with your board, apply paste, pick and place and bake. On the other hand you may, like me, prefer to use a fine-tipped soldering iron and put the parts down one by one. Maybe you're a whiz with the hot air station and you want to assemble it with that. 

    However you're most comfortable, assemble all the surface mount and through-hole parts on the circuit board. 

  • 3
    Mount the e-paper display and battery

    Once you've assembled the board, CAREFULLY insert the display's flex cable into the flex connector, and fold it over the edge of the board so that the display covers the documentation on the front of the PCB. You can secure it along the edges with Scotch tape or plain blue painter's tape.

    Plug the battery into the Molex Picoblade connector, and tape the battery into place on top of the pin assignments block on the back of the Open Book. 

View all 6 instructions

Enjoy this project?

Share

Discussions

Lari wrote 02/16/2024 at 13:57 point

do you think u will try to make a revised version with the new display or u are u done with the project?

  Are you sure? yes | no

SaraForestergd wrote 02/12/2024 at 13:40 point

Homeworkprovider is your ultimate Assignment Homework Helper! With dedicated Assignment Doers, this platform ensures quick and reliable assistance for high school and university assignments and quizzes. Its user-friendly interface and prompt service make it the top choice for academic support. Highly recommend for those seeking a trustworthy Homework Helper!

Read More: https://homeworkprovider.com/

  Are you sure? yes | no

smkj312 wrote 12/01/2023 at 00:32 point

I tried changing gpio35, 36, and 37 to other non-psrom spi ports, but still failed, and the screen still stuck on burning the babel.bin file.

  Are you sure? yes | no

Kaeso wrote 11/12/2023 at 15:27 point

Hi, does the bottom of the ESP32-S3 need to be soldered to the PCB? I am having a hard time getting it to flow.

  Are you sure? yes | no

drtonis wrote 10/27/2023 at 06:00 point

Hi, could you share the Pick and place file for PCB production? Gerber files are available and the BOM too, but without the last file I cannot order a PCBA. PCBA is to cheap nowadays that it's not worth to do it manually.

  Are you sure? yes | no

Brian Almaguer wrote 10/23/2023 at 15:46 point

Seems the GDEW042T2 used in this project is now out of production and hard to find online. I just purchased the GDEY042T81 as a replacement on recommendation of the eink retailer I am working with. The GDEY042T81 on paper looks like it should work but I am waiting for my parts to come in for me to build and validate. I am looking forward to making this device.

  Are you sure? yes | no

jamesdl250 wrote 12/11/2023 at 07:03 point

Any update on the GDEY042T81?

  Are you sure? yes | no

Joeseph Rodrigues wrote 10/22/2023 at 07:46 point

Epub support and a backlight, and this thing would KILL

  Are you sure? yes | no

James wrote 10/20/2023 at 13:39 point

Is there a plan to support epub format?

  Are you sure? yes | no

sergpank wrote 10/25/2023 at 09:43 point

epub is basically zipped json so it should be easy to implement

If I could assemble my own open book on esp32 I would definitely join to firmware development, but github of this project looks abandoned - https://github.com/joeycastillo/The-Open-Book

don't quite undersrtand the current state of this project and if it has any future ...

  Are you sure? yes | no

Griguoli09 wrote 10/19/2023 at 22:30 point

Are you planning to implement a backlight? Btw thanks very much for this project. Congratulations for you work!

  Are you sure? yes | no

Would Christ Be a Geek? wrote 10/17/2023 at 18:19 point

While looking at the BOM and sourcing for the materials, I got stuck in the item L1 (Inductor_SMD:L_Taiyo-Yuden_MD-4040). Could not find the correct part number because there are a couple of options within this specs. Look the list: TAIYO YUDEN MD Series 10 uH 1616 (4040 metric) Power Inductors - SMD – Mouser

  Are you sure? yes | no

meierrom wrote 10/24/2023 at 12:34 point

I'll try with this: Digikey: 587-LCXND4040KKL100MDGCT-ND

  Are you sure? yes | no

Emily wrote 10/16/2023 at 21:25 point

I see discussion on which displays are available. Would this 4.2" B/W display from waveshare work, or is it a different chip? https://www.waveshare.com/4.2inch-e-paper.htm It happens to be the one I have on hand.

  Are you sure? yes | no

rtw0 wrote 10/20/2023 at 18:31 point

The dimensions of the Waveshare display are the same. Electrically, the pins are all the same except pin 5 (VSH2 on GoodDisplay, VGH on Waveshare). No idea whether it's even necessary, there is a VSH1 pin already, after all. 

I don't know about the drivers, it's a different controller, there might be a need to write another driver - they're not compatible from what I've gathered.

The outlook is good, but I wouldn't use it just yet - it isn't perfectly compatible. Maybe when we hear back from the creator.

  Are you sure? yes | no

meierrom wrote 10/23/2023 at 11:25 point

Hard to say. You need GDEW042T2. I found it here:

https://buy-lcd.com/products/42inch-e-inkanel-spi-interface-buy-eaper-display

  Are you sure? yes | no

handcookedtortilla wrote 10/16/2023 at 03:39 point

Excited to make this once I can get my hand on the display  Thanks for all the hard work!

  Are you sure? yes | no

Kinurr Barlow wrote 10/15/2023 at 21:19 point

This is an amazing project. I've been looking for something like this for a long time. :)

  Are you sure? yes | no

Ramon Moorlag wrote 10/15/2023 at 19:59 point

This would be a great work session for a CS Teacher's conference. Build your own book.  And we already have an open book; openbook.ieni.org about everything about open and teaching. 

  Are you sure? yes | no

raymondday wrote 10/14/2023 at 23:23 point

I see it only has a miceSD card slot. Can it be made to take a SATA SSD or M.2 drive?

  Are you sure? yes | no

Brian Wyld wrote 10/11/2023 at 15:02 point

Do you have a feel for the total BOM cost for the project (including PCB/battery/screen)? I see you talk in the  project log about the problem of 1$ on BOM = 2$+ on retail price...

  Are you sure? yes | no

joey castillo wrote 10/12/2023 at 13:16 point

That project log (this one https://hackaday.io/project/192688-the-open-book/log/222901-the-quest-for-a-sub-100-diy-e-book-reader) is the best sense of the numbers that I have. Unit cost is listed in the spreadsheet at the bottom, but it makes a couple of assumptions, namely the enclosure and manufacturing costs are very rough estimates, and it assumes I figure out a solution to get rid of the through-hole buttons.

  Are you sure? yes | no

Brian Wyld wrote 10/13/2023 at 15:14 point

thanks, very useful!

  Are you sure? yes | no

Brian Wyld wrote 10/11/2023 at 14:04 point

Good display don't seem to have the 4.2" panel in stock, and don't recommend for new designs... they propose the GDEY042T81 instead - any idea on compatibility? Seems to be spi also, but maybe a different controller chip?

  Are you sure? yes | no

joey castillo wrote 10/11/2023 at 14:23 point

Alas, it is a different controller chip. For the purposes of making the Hackaday Prize deadline, I used old displays I had on hand, but I think the final version is going to have to use the GDEY042T81 just for availability reasons. The board design should be compatible with both, though there may be a change in inductor value for the boost circuit, and I have a couple of the new displays on hand so I should be able to write a driver for the new display soon.

  Are you sure? yes | no

Brian Wyld wrote 10/11/2023 at 14:57 point

Well, there is also the B/W/R one 

GDEQ042Z21

that looks mechanically compatible and has the UC8276 controller (not the UC8176 but maybe an easier port). And red highlighting would be cool...

***EDIT : ah, didn't see your reply about the tri-color display below before this message ***

  Are you sure? yes | no

meierrom wrote 10/23/2023 at 11:27 point

Good display has multiple sites. It's weird. Try this: https://buy-lcd.com/products/42inch-e-inkanel-spi-interface-buy-eaper-display

  Are you sure? yes | no

peter.robinson.ch wrote 10/05/2023 at 08:45 point

Great project. Suggestions: Move the screw heads to the rear for a cleaner finish. Also, check out the video "Improve your prints with acetone smoothing" on YT for improving the case finish. It's an easy method to implement.

  Are you sure? yes | no

smkj312 wrote 10/05/2023 at 02:19 point

it would be great  if it can use the tri-color version e-paper display .because the tri-color display is very cheap in my country .its only $5 from electory price tag

  Are you sure? yes | no

joey castillo wrote 10/11/2023 at 14:28 point

Unfortunately in my experience the tri-color displays don't work as well; the ink formulation in those screens doesn't lend itself to the fast refresh required to make for a good page turning experience. Having said that it's been a few years since I tried it, and it's at least electrically compatible with the tri-color displays, so you can totally try it!

  Are you sure? yes | no

smkj312 wrote 10/24/2023 at 02:56 point

thank you for your reply

  Are you sure? yes | no

Saulohp wrote 09/11/2023 at 13:08 point

This is a awesome project!!!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates