Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PaperTerm Concept, An e-paper remote terminal device

paperterm.org

Post reply on HN
Print view View original

81–90 of 94 posts

Re: PaperTerm Concept, An e-paper remote terminal device

#81

Post by fragmede »

torgoguys wrote: post #59
wanderingjew wrote: post #54

Earlier quoted context omitted.

I built something similar: https://bbenchoff.github.io/pages/dumb.html 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…

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 expe…

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

Re: PaperTerm Concept, An e-paper remote terminal device

#82

Post by siraben »

pjerem wrote: post #25
jbverschoor wrote: post #11

Earlier quoted context omitted.

Sounds like an easy 'dev mode' to add, and capture a large market of developers. For years I've been looking into eink for development etc.

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 perfo…

> But still, the hacking scene is far from big. There is no SDK.

There is an open source SDK[0] for compiling things to the reMarkable (1 and 2), and it's also a cross-compile target (1 and 2) in Nixpkgs[1][2].

[0] https://github.com/toltec-dev/toolchain

[1] https://github.com/NixOS/nixpkgs/pull/102503

[2] https://github.com/NixOS/nixpkgs/pull/105432

Re: PaperTerm Concept, An e-paper remote terminal device

#83

Post by salamandersauce »

dont__panic wrote: post #80
salamandersauce wrote: post #30

Earlier quoted context omitted.

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.

Re: PaperTerm Concept, An e-paper remote terminal device

#84

Post by torgoguys »

fragmede wrote: post #81
torgoguys wrote: post #59

Earlier quoted context omitted.

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 expe…

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…

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.

Re: PaperTerm Concept, An e-paper remote terminal device

#85

Post by NoGravitas »

torgoguys wrote: post #59
wanderingjew wrote: post #54

Earlier quoted context omitted.

I built something similar: https://bbenchoff.github.io/pages/dumb.html 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…

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 expe…

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.

Re: PaperTerm Concept, An e-paper remote terminal device

#86

Post by shadowoflight »

torgoguys wrote: post #78
shadowoflight wrote: post #73

Earlier quoted context omitted.

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?

Re: PaperTerm Concept, An e-paper remote terminal device

#87

Post by nixpulvis »

torgoguys wrote: post #75
nixpulvis wrote: post #71

Earlier quoted context omitted.

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 seco…

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 i…

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

Re: PaperTerm Concept, An e-paper remote terminal device

#88

Post by torgoguys »

NoGravitas wrote: post #85
torgoguys wrote: post #59

Earlier quoted context omitted.

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 expe…

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

Re: PaperTerm Concept, An e-paper remote terminal device

#89

Post by torgoguys »

shadowoflight wrote: post #86
torgoguys wrote: post #78

Earlier quoted context omitted.

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-li…

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

Re: PaperTerm Concept, An e-paper remote terminal device

#90

Post by torgoguys »

nixpulvis wrote: post #87
torgoguys wrote: post #75

Earlier quoted context omitted.

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 i…

> 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 P…

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

Post reply on HN