Oh, hi all! I didn't my project to show up here today! This was just my private notes-to-self I'm using to organize a group to create this thing.
These notes haven't been cleaned up to be public yet (near the end it gets particularly messy and the memory map has changed from the state shown on this page), but oh well, it's been found!
I will answer any questions you may have.
And if you want to help make this, my email address is in my profile. Programmers, electrical engineers, testers, documentation... whatever skills you have, I'm sure you can help!
What are you going to do about the actual cost of the device? You've already got an e-paper display, but you're also adding a 'laptop' style enclosure, real keyboard, and if you're storing SSH keys, you're really close to running a cut-down Linux system. That's basically a laptop, and you could get the same thing with, you know, a laptop. Have you thought about scaling down the display, keyboard, and enclosure to something palm-top sized?
That is very cool! Have you built a physical copy of it?
No, I think the smaller size is probably a non-starter for the intended audience. This is meant to be a tool that a lot of these folks are using for hours and hours a day so overall typing and reading experience is paramount, and meant to be a "selling" point.
Cost-wise, yes--we're still grappling with costs of the e-ink screen. It's the by far the largest expense in the unit. We've got a good lead that I unfortunately can't talk about at the moment (under NDA).
A cut-down Linux really is overkill for this, and isn't capable of making some of the other specs happen (battery life, availability), at least as far as we've been able to determine. Custom code is unfortunately where we've been forced to go.
The other reason not to run Linux is because the ESP32's a bit underpowered to run Linux (lacks an MMU). Slightly more powerful hardware (eg Raspberry Pi Zero) would do better, and get you a working device far sooner, which would be great for testing out some of the other components while waiting for getting the software written.
Embedded Linux (eg any distro using busybox for glibc) is (imo) the appropriate stack to use for this given how cheap a microcontroller with an MMU is these days, and once you get rid of all the bloat, is capable of very quick boot times (availability), and if the device is off (and not just sleeping), then its battery life is similarly extended. (Don't let the poor battery life of Android phones let you believe Linux isn't capable of long battery life. Smartphones don't actually get to sleep while the screen is off.)
The ESP32 is getting replaced with a better microcontroller (it's down to either an upcoming STM32 ultra-low power or the upcoming Ambiq Apollo4 depending on how well they perform in real life), but ESP32 was what we started with given familiarity and availability.
Remember, the device can sometimes have enough time to sleep BETWEEN keystrokes while typing. (The microcontroller can sleep then wake and power up peripherals with only a tiny, imperceptible delay.) This isn't your typical Linux setup. FreeRTOS is plenty. For the limited things it does, it wants to be a no-compromise device. There is no on button. There is no off button. You grab the device, it has an image on the display because it's e-ink and you start typing. Assuming you've previously connected to a remote device the system will have done what's necessary to keep that connection alive (invisibly waking as needed). Your keystrokes can go through right away to the remote connection. Your results will hit the screen right away too. The device is always on and it is always off, if that makes sense. There's more to it--bits of stuff and bother and implementation details--but I hope this gives you the idea.
Honestly, 13" is more than you need for a 4:3 terminal. A lot of classic character terminals had 9 or 10 inch screens...it's not until you get to like the VT320 that you have a 14" screen. I'd consider a 10 inch screen about ideal, and the keyboard doesn't have to be 13", either.
We are making prototypes in 3 different 4:3 sizes--10.3, 12.1, and 13.3. 13.3 is furthest along. The end of your comment talks about the real size restriction for us--keyboard. We do not want to compromise the typing experience.
Around 12" (in a 4:3 body) is about as low as you can go without messing with the typing experience much. The problem at that size is the available e-ink panels are S-L-O-W; no fast refresh models are out there.
(You might ask why we would even do the 10.3" prototype if we know that's too small for keyboard reasons? It's mostly for marketing reasons when we actually try to try to get attention for this project. The 10.3 is going to use a Thinkpad 701c butterfly keyboard in a custom body just for the "wow!" factor in showing the sorts of things that are possible. The 10.3 would actually be a killer end-product, but no similar keyboard is in current production so we couldn't actually make it).
Have you considered using a DES display or Sharp Memory LCD? I know the first is definitely cheaper than a branded E-Ink display, and the latter has much faster refresh rate and may be more suited to being a terminal (and may also be cheaper than E-Ink, I just haven't looked into it).
Yes we have considered it. Do you know of any such large (over 12 inches) panels with decent resolution and pretty fast updates that are available? Such a thing would probably help with power consumption. (e-inks consume a lot of power during screen updates).
Looking at all of the options a simple full RLCD would probably be best for us--not eink--but we can't find appropriate parts for the size and resolution.
I know that the DES displays go up to 10.1", but I haven't seen displays beyond that size (though I'm unsure if they intend to make larger displays in the future). For the Sharp Memory Displays, I think I may have spoken too soon - looks like they top out at 4.4" currently, which of course wouldn't work for your application.
RLCD is an interesting option, I guess the sacrifice there is readability angles and paper-like-ness?
Ones with good viewing angles exist, but for sure there isn't paper-like-ness and you loose the no zero-power persistence of e-ink. But you get fast, artifact-free refreshes, perfect sunlight readability, at very low power consumption. (No backlight which can be a pro and a con...if only a more modern Pixel Qi type panel existed.)
We have a prototype-y thing part way between P0 and P1 already.
A "you can build it yourself" P1 version of that will probably be well-documented by early next year, but it won't be something you can just go out and buy yet. You'll have to gather together the parts needed, get the PCB produced, etc.
The plan was for us to get something to that P1-stage and then go more public about the project. No worries on jumping the gun with posting it. It's not exactly a secret, just not *intended* for public consumption yet.
I think when we have a couple of copies of P1s ready to show off (and videos of the product, and an actual product website! :-) having something put together we can show off would help open up some doors from people with more experience with getting hardware produced so people can get this more readily (even if just in kit form to start). Right now we're just doing one-off prototyping.
I realize this might simply put me into the "not target demographic" group, but what makes this so useful as a terminal, that a laptop won't do?
I could understand the no-distraction writing i.e. word processor use-case that some people think E-Ink would be good for, but that doesn't appear in your list of possible applications either.
Use as a distraction-free word processor is listed as a use-case if you read far enough. (As mentioned, the notes are a bit of a mess and weren't cleaned up for public consumption.)
But, yes, a laptop can do pretty much everything Paperterm can do. A laptop can do everything a Kindle can do. A laptop can do a huge percent of what your phone can do. If the advantages of this niche device (e.g., sunlight-readable display with no backlight/blue-light, it's insane battery life, a no-compromise keyboard, and it's always-ready-"never-off" state) doesn't appeal to you, then you're right, you're probably just not in the target demographic. Those in the target market find a lot to love in such specs. This is explicitly a niche product, not trying to be everything for everyone (which is closer to what a laptop does).
EDIT: if you have a look at the (also not ready for announcement) root of the domain, you'll see a brief pitch: http://www.paperterm.org/ This page also has notes-to-self in brackets, and I'm not in a spot where I can fix it right now, so ignore that.
I would be pretty close to the exact target for this product. The killer feature that would put it over the edge for me would be the possible "crashcart" KVM feature mentioned later in the notes.
Lugging around a full KVM console is overkill (unless it is literally on a cart and you only need it at one location). And USB crash cart adapters are buggy, overpriced, and unmaintained.
With serial, SSH, and KVM this will fill the perfect "there is a piece of hardware on the rack I need to interface with" role.
A distraction free word processor that could display PDFs along with the text (for writing LaTeX) would be a real godsend for me. In fact I am writing this very comment while distracting myself from some LaTex I am supposed to be writing...
Sounds like a very interesting project, I certainly would be tempted to have an eInk terminal. Can you post images on how the terminal looks on the eInk screens?
I can give you images of how a terminal looks on e-ink screens but not with the final panel we're likely to use nor with final software, so probably best no to since it wouldn't be representative.
Google can give you an idea of how it looks, but with a much smaller screen than we're using (ours is 13.3") so these images feel more cramped and look more "plain jane": https://www.google.com/search?q=e-ink+terminal&um=1&ie=UTF-8... With the larger screen and more refined setup than these Google Images pictures show, it is very pleasant to use. I hands-down prefer it to a laptop running a terminal, except when color is important.
Our panel supports partial refresh (no black flash) which makes it much more performant. The software does have to do occasional flashes to keep the screen tidy (otherwise you get a lot of ghosting over time). You can control how often this happens.
I also have a BOOX note Air, and I am very happy with it. I even installed python and Jupyter LOCALLY. I had no problems processing a few millions of primes in milliseconds. However, the display is not good enough to program as growing code often requieres to fast refresh the screen while browsing code or following stacktraces, which is quite uncomfortable. Also the lack of syntax highlight but I guess some people could get used to those.
I tried to throw together something similar for my Kindle browser just now. I connected my bluetooth keyboard to my phone and ran the following in termux:
Hi, if I can ask, what is that keyboard? My local electronics chain had it listed as "Raspberry keyboard" but it's no longer available and I've been looking for it for months.
Dell logo in the top left corner, bluetooth indicator in the top right; nothing on the Dell website that matches it, but on Amazon and Newegg "Dell KW14M01" looks very similar (though neither have the logo top left, so could be different minor version or not actually Dell...).
The keyboard is a Dell K07M, but beside the cute form factor I will NOT recommend buying it. Maybe mine is damage, but I got a lot of ghosting in my key pressing. I’m looking to replace it, maybe with a K3.
This seens to be an unpublished, unfinished, unindexed document about a nonexisting product whose project status I am very confused about, yet the concept is absolutely intriguing.
Yes, you hit the nail on the head! This was my (private :-) notes-to-self for the project that will be launching as a public project soon. If you want to help, email me (address is in my profile!)!
I have experience with driver circuitry for waveshare e-ink displays and ARM H7 which has USB2 and Wifi. It shouldn't be too difficult to build a small device which is powered by an USB power bank, receives from a USB keyboard and communicates with a USB LTE stick.
So I'm pretty sure that someone has already designed something similar as open hardware that you could fork and customize. I'd start with Googling "kicad eink arm". From memory, the Watchy eink watch with esp32 comes to mind. And I think there are arduino epaper driver boards on Amazon, too.
The earliest generation Kindles had keyboards and various ways to run Linux. I think they tick about every box in this concept, except for the "Great keyboard. Terminal mouse support": the keyboards sucked for typing more than a few minutes. I realise that this is a pretty important "except" if you want to use a terminal, but at least they were actual mass market products.
Concept is very cool. The PineNote seems to nail some of it, though I'm not sure about the battery life (definitely not the battery type). If the PineNote could output its desktop when docked it would be a very interesting product I'd happily purchase.
I have been craving an e-ink laptop with a low voltage RISC processor for twenty years. It is impossible to open a normal laptop at night, after the kids have gone to bed, without becoming more awake than after a double espresso. I can't stare into a bright back lit screen at night. It often ends up with me sitting way to late up at night. At daytime, the often ridiculously bright back lit screen makes me unfocused and almost hypnotized.
Also worth noting though, from the manual linked above: "In the state of secondary monitor, the device is only user for monitor reading. Touch for operation do not work in this state."
I own one, it's a true three star experience. It's completely unique in its class as it's a true e-ink display at A4/Letter scale and even has two monochromatic backlight sources, one without any blue light. That rocks.
It's a near-perfect reader and digital notepad and that's what I use it for.
The software however is bad. Did I say bad? It's laggy, it's supposedly Android but not really. Lots of apps only work semi-well if they use colors or greyscale. It feels like using a tablet device from a decade ago.
In the end, I'm still rather happy, but it's hard to justify the price point.
It's android. Are you disabling the "Whiten Apps Background" optimization? It's on by default and it makes it harder to use apps I find because controls and buttons end up hidden. Turn it off and it's fine.
Thank you for this suggestion! I have a Nova 3 myself and I didn't realize that this "optimization" was on by default. Any clue if there's a way to change this to off-by-default?
No I don't sorry. Other than to root and then uninstall the related code. I haven't personally done it though, just read some posts on mobileread.com about it.
I’ve chasing this dragon for years for the purpose of working outside; first trying to hack a kindle paper white, then using a Dasung monitor, then hacking a reMarkable 2. All were disappointing for a reason or another but I’m ready to try again with the PineNote. 4th time’s the charm, right?
> I’ve chasing this dragon for years for the purpose of working outside; first trying to hack a kindle paper white
Really? I've never understood why Amazon wanted white kindles, but this is the worst possible use case for one. Actual paper books aren't usable outside, because they give off too much glare in sunlight. Kindle solves that problem! Use one of the gray ones; they're better anyway.
I was thinking of the same, however when I look at large eink displays most of the time the vendor specifically cautions against using them in bright sunlight. Check waveshare etc.
I use my kindles in direct sunlight for sure, they work fine, strange enough. This is why I don't understand they caution so much against some of these models.
reMarkable 2 is awesome for it’s purpose, but trying to hack it into a terminal was too finicky and I bailed (same but worse dor the paperwhite). It still works great as a notepad and pdf reader, but 10.3” is the bare minimal practical size IMO.
The Dasung proved to be super finicky for it’s _intended_ purpose and generally awkward as a monitor. I can’t recommend it.
I have a remarkable 2 as well, and although I love it for reading/drawing, the biggest downside for me is the total lack of developer support. There are some cool 3rd party tools for interacting with the file system, but absolutely no support from the manufacturers for running your own code on the thing. I know its possible, but seems like a huge hassle.
Remarkable is actually very open. Getting root access is as easy as going to the bottom of the About page to get the device's ip and its root password for SSH access.
But still, the hacking scene is far from big. There is no SDK. You can do things with QT but for a lot of use cases, you have to work directly with the screen capacities. e-ink screens are not good old framebuffer screens. If you want to have nice performance (like, instant note taking), you have to actually "draw" things on it.
You can draw things relatively fast on an e-ink device. But you can not draw a lot of things at the same time. That's why you have to wait maybe a full second between two pages of your book, but you can also have a blazing fast writing experience.
So the display paradigm is totally different compared to a classic screen and you can't just port existing apps. Well, you can, but it'll be without the "smart refresh" part. So it will be slow. If you want something usable, you have to think what and when to draw things on the screen.
Hence, few usefull apps exists on remarkable, because you have to build them from zero, with no real documentation, and to target a niche.
It would be great, if there were more documentation to get started with developing for the remarkable and perhaps a few shared libraries with commonly used functions, e.g. just to be able to display a given png. Even if it were just a command line program, it would enable many usages.
It is trivial to compile Go programs for the reMarkable - just compile with ARM as a the target architecture. One can do that on any machine with Go installed. But for the lack of APIs, I have had no idea yet where to reasonably start with programming the reMarkable.
Neat! I've been thinking of building something similar to this — a portable Linux machine that has an eInk display and little QWERTY keyboard, in a size that's a just a bit bigger than a smartphone.
I've had a spare eInk display laying around for some time now, and it's about ~~5"~~ 3.7" in size, I think. I managed to get it working with a Pi Zero, and wrote a small Python script which captures the desktop, and then compares it to the previous capture, and then updates the bounds of where the capture is different. Somewhat slow with a Pi Zero, but still somewhat usable. I really need to look into the possibility of performing partial refreshes on the display to save it from having to invert the screen every time there is a change.
I might try and use a Pi 4/ Pi CM4 to drive the whole thing — I believe the bottleneck mainly lies in sending the data over to the display, which the Pi Zero is unfortunately quite slow at doing. Plus, it would potentially be a bit more powerful/useful with the newer processor found on the Pi 4!
Sounds like a neat project. Yes, partial refreshes help a lot, lot, lot!
Battery life might end up becoming a problem if you intend for it to run on batteries. Compared to PaperTerm or smartphones, a Pi uses a lot of juice, but it is great for proof-of-concept!
Thanks! As you say, the Pi does chew up quite a bit of the battery life, but I hope that usage should last for at least a day or two. I plan to use a 3,000 mAh battery with the thing, which seems to be quite a lot — my Pixel 4 has 2,800 mAh _and_ that doesn't even have an eInk display! For the purposes of my project, I'm not really focused on trying to make the device extremely thin either. Something relatively chunky (like 1-1.5 cm) is sometimes quite nice and welcoming imo.
I wrote up my own notes-to-self much like the author of the PaperTerm did, which provides a brief overview of my general ideas: https://github.com/inkySystems/resources
It's a tiny bit outdated since it has no mention of my idea of using a Pi CM4. I haven't got many publicly-available info about what I've done so far with my board (seeing that it's a side-side-project of mine or something to that effect...) but it's something I'm experimenting with whenever I've got time on my hands!
Is the refresh time of e-ink display suitable for convenient terminal use? (I just skimmed the article.)
When reading an e-book, the page is typically refreshed 1-2 times per minute, while the typical CLI use is more fast-paced, not to mention TUI programs.
From the demos I've seen of other e-ink tablet devices like the Max Lumi, it seems like it can handle handwriting pretty smoothly [0].
So it could probably handle typical CLI use too, but higher refresh rates would of course mean higher battery usage. I think e-ink displays can handle local refresh zones, so it doesn't necessarily mean that it would have to refresh the whole screen.
However, without pagination, a lot of our computer usage includes scrolling, and I would imagine that's more power intensive, and can maybe hit the refresh rate limits of e-ink displays. I guess that would be akin to a lot of phones now letting you pick a fixed or variable refresh rate depending on the experience and battery life you want to get out of the device.
Yes, if you're only making small updates and not dumping tons of lines all the time the even an old e-ink display is plenty fast. It works the same way when you're menuing on an e-reader.
I made something similar to this several years ago, and it was pretty usable considering that the software was thrown together in Python and the display I had did not support partial refresh. I got it so I could run terminal applications nicely, and even run X applications poorly. Then my little girl cut the pretty colored wires with scissors, and I didn't have the heart to do the hardware work over again.
It wa a nice toy that might have become a good tool over time. Good luck! Here's my lousy code: https://github.com/ThePaperTop
Ha, this looks great, the list of goals seems really similar to a list I came up with a couple years ago for what I’d consider optimal for a writing device, too:
For PF, I recommend "disconnected by default" I've been using my laptop like this for a while now and the peace of mind is easily worth the one command I need to run to connect each time. Especially on a distraction free device where I wouldn't expect a lot of notifications and synchronizations.
This could only happen if we've got some local apps beyond the main (terminal) app. PF-timeframe, as you say. I will write the idea down so it doesn't get lost.
It probably makes sense as a toggle, perhaps selected when initially setting up/getting a software tour of the device, depending on who is using the system. Writers for example, would want it, sysadmins, not so much.
I'm sorry if I'm misunderstanding you but, why are local apps a prerequisite for controlled networking? Or is that just how you want to build it out?
To be clear, all I'm suggesting is executing a command like `network connect <SSID>` instead of automatically connecting to saved networks.
Maybe I'm just not sold on the concept of a truly remote terminal (like the real old terminals). Why should I have to carry around two devices when Linux could run on this device itself? Perhaps it's a lot more work? but there have been some efforts made on this already. I would like to casually launch vim and start writing, without worrying about connectivity.
As an aside, also consider looking at how the reMarkable tablet implements ether/IP over USB, that has been working pretty well for me too, though I really wish it would broadcast an mDNS entry over WiFi as well.
Ah, I misunderstood you. Without the local apps, unless you are connected to a network, there is literally nothing to do with this device. That's because it is more-or-less a terminal only (excluding the few PF local apps). There are no notifications to speak of.
A Linux OS based device can't meet the goals of the device from a couple of standpoints (power, availability, and the limited RAM/resources on the microcontroller pop to mind right away). Think of this as an instant on appliance. You turn on your old Commodore 64 and you are instantly able to type.
I hear ya, when it comes to "just wanting to be able to open the thing and start typing into vim (or whatever)". We're working on sanding down those edges in a couple of ways--1) eventually, we'd like to point people to a very cheap, simple cloud linux deployment if they don't want to setup their own, with lots of conveniences. 2) regarding actually getting a network connection since we're talking terminal-only the bandwidth requirements are tiny; because of that, it looks like we're going to want to add cell network connectivity. This is early-stages in thinking this through, but there are plans in the $40 - $60 range for an ENTIRE YEAR that would give you unlimited bandwidth that is plenty fast for terminal purposes (128kbps after using a limited amount of faster 4G bandwidth).
I will take a look at the reMarkable ether over USB. Thanks for pointing it out. It'll be a while before we've got a full USB stack working though. Remember, the software footprint for this device is tiny by design.
I promise you can make Linux wake from a low power state much faster than you can wake up the radios and negotiate a stable network connection with "the cloud!?". Not to mention battery life... Even if my host was connected over ethernet I wonder how realtime benchmarks would compare with whatever network hardware you have in mind.
I love the idea of having cell and wifi modems, but these seem like high priority secondary concerns to me personally.
I understand that I may not have the same vision as you exactly, but I really am pretty much your target consumer. I totally get the elegance of reimplementing the "dumb terminal", but I really challenge you to justify it.
I think the disconnect between us is that this is running on a microcontroller. Think "a beefier version of what runs your smart thermostat." Linux isn't unheard of for such a device, but is a pretty heavy lift because of limited resources. Using a microcontroller has its advantages. One advantage goes exactly to the point--with smart design it can maintain a wifi connection, waking for milliseconds at the required interval, so when you want to use it there is no wifi negotiation time. Keeping things open all the way to the remote host is whole other matter, but I believe that's touched on in the document.
What is your use case for this sort of device? We'd certainly like to support as many as possible without compromising the overall vision. You mention PDFs--is your use case for reading or creating documents?
There was no plan to support local viewing of PDFs--again, parsing them is a pretty heavy lift for a low-power microcontroller to do with acceptable performance. We've got a related (very alpha) project that uses Chromium to render websites in a fancy text-only fashion. This is because for most devices, having a modern web browser is table stakes so we want to support that for this device. However, this browser would would be installed on the host you connect to with this device, not on the device itself. The browser can view PDFs (it uses Mozilla's pdf.js). I can show you screenshots of output of this browser, but not much else at this point. Those closest relative of this browser that is public is Browsh. It would give you an idea for what can be done: https://www.brow.sh/
> What is your use case for this sort of device? We'd certainly like to support as many as possible without compromising the overall vision. You mention PDFs--is your use case for reading or creating documents?
Creating documents implies reading them in their final form, unless you have a publisher on staff. Even then I'd argue the medium matters. Most of the time I stick to plaintext, but there's a lot of value in PDF layout as well.
So yes, I plan to use this device for both reading and creating.
And I DO NOT trust my network connections. Just saying.
Gotcha. I don't think we could make this the right fit for you then, sorry.
Well, the more I think about it, it's conceivable it could handle it with some small amount of extra hardware, but would take a LOT of software work and as hobbyists with no funding...
> And I DO NOT trust my network connections. Just saying.
Yes, this should be a hard pass for you then! (Unless built-in, dirt-cheap cell connectivity would assuage those concerns.)
Maybe you make a little RPi-like device that is designed to connect and host this thing as a module that attaches nicely to the enclosure. You could build out the whole idea as you have it and come back to this for people like me. Meanwhile, I might just carry around a RPi for this purpose, as long as they can share power easily.
I hope I'm not being too discouraging. I really like this idea, which is why I'm pushing you on it a bit. I would love to help, but yea, fund-less hobbies are tough to get large scale support for. I wish I had more to offer.
These notes haven't been cleaned up to be public yet (near the end it gets particularly messy and the memory map has changed from the state shown on this page), but oh well, it's been found!
I will answer any questions you may have.
And if you want to help make this, my email address is in my profile. Programmers, electrical engineers, testers, documentation... whatever skills you have, I'm sure you can help!