I'm dreaming of general availability of touch enabled e-paper/e-ink displays.
Not just for the Raspberry Pi, but especially with it I would be one step closer to my always-on home dashboard.
I'm imagining literally just a CLI or rudimentary text editor with an e-paper interface... no video or images, just text. Very spartan. Response time is more than good enough for something like that.
I could also imagine that searching through a textfile to find the place you want to edit would be pretty frustrating if you had to do it at Kindle speed.
In 1-bit mono mode you can flip a pixel in ~100ms, which is plenty fast enough for text entry, although scrolling might not be good.
Early LCDs had terrible ghosting (anyone remember trying to play Doom on an early mono LCD and the image instantly turning into incomprehensible hash?), but I can't find any references for actual numbers for the pixel flip time. I'd be interested to know how they compare to eink. Does anyone know?
If only the Nook had a powered USB port...
I will say the market might be too small. But if the market existed slow response times (which are still sub-second) would likely not hurt it too much for that usage.
(It looks like the Nook is probably my best bet, but it unfortunately doesn't have a powered USB port so I'd need to find an external power supply of some description for the keyboard. Any other suggestions gratefully appreciated.)
https://www.google.com/search?q=earthlink+mailstation&tbm=is...
Also guaranteed to cause comment as practically no-one has seen one before.
The key piece of hardware is the Keyrah:
The specs are modest, but I bet it can handle your one requirement: "text editing".
[1] http://www.amazon.com/Notepad/dp/B004LSLN0I
[2] http://www.mobileread.com/forums/showthread.php?t=150434
http://the-digital-reader.com/2015/07/10/one-week-with-dasun...
It's a 13 inch eink monitor. Refresh rate is apparently reasonable. The price is ludicrous, unfortunately, because I want.
It would be ideal if they provided a shell, but I haven't heard them making any of those noises.
https://en.wikipedia.org/wiki/TRS-80_Model_100
I really do wonder how much the eink saves vs going for a monochrome screen that early laptops used, and just do ones writing in a *nix shell.
For some reason the shiny, curved black plastic reminds me of a weird cross between Darth Vader and something a character in a Terry Gilliam film would use. Stick a Fresnel lens over the screen and you're all set.
Even in non-power-constrained environments e-paper can be preferable - the glow of a typical LCD display is really distracting and doesn't fit in a lot of (most) environments. Have enough gadgets around with LED displays and indicators and your home suddenly seems like a really bad 80s movie.
Though, it's not so easy to read the temperature across the room on these bad boys either:
https://en.wikipedia.org/wiki/Thermostat#/media/File:Honeywe...
I think those are much more common in new installations. These are segmented LCD displays. An eInk display would not require an explicit segmentation layout, so new layouts could be programmed on the fly, prototyped very quickly, etc. And might even be a little easier to read, even during daylight hours I find these types of LCD displays difficult to read, especially from off-angles.
One of the more glaring problems with smart devices - smart watches especially - is that they have have a slight pause before they realize they're being used and activates. An always-on device doesn't have this problem and can be immediately used without delay.
By themselves they're not huge issues, but as you own more and more such devices it becomes really annoying to be surrounded by "smart" inanimate objects that constantly make you wait - even for a brief moment - before they are usable, and in that way they seem much less pleasant than the dumb objects they replaced.
Imagine having to rest a pen on paper for 500ms before you can begin writing, every time.
Smart but task-dedicated devices should probably run the display/buttons on a dedicated chip that talks to the CPU asynchronously, to avoid this problem.
Your microwave and VCR are always on - their displays are also always on, so they don't need to be woken up before being used, they are already awake.
A thermostat with an always-on screen is the same, they're already displaying information and the touch screen can be immediately used without delay - but we don't want the display to be always on, because in general LCDs look awful in their environments. In general people prefer their homes to not look like server rooms with blinking lights and garish panels everywhere.
So there is a non-technological need to keep the screen off, and this presents a fundamental problem - before anything can be done, the screen must first be woken up. No matter how fast you make this process, at the end of the day is one extra step that the user must do before the device can be used.
Apple Watch detects when your wrist is held in a certain position to activate - but sensing this gesture itself introduces lag. Hell, even a simplistic "on" button on the device itself - even if the response is perfectly immediately - necessarily requires the time for the user to trigger the action itself.
You can't work around this with better software, because at the end of the day "activate device" is step 1, whereas with dumb technology step 1 is "use device".
The only real solution is for your devices to be always-on in a much more fundamental way - like your VCR or microwave - and that in some cases means e-ink screens.
Another example, look at this handheld game: https://www.youtube.com/watch?v=1naGfmzkh9w
Is there any perceived delay when the On button is pressed? I frankly can't see it.
EDIT: This one even has full color and movement: https://www.youtube.com/watch?v=xD4DDewpOF8&feature=youtu.be...
It goes from complete shut-off of the entire device to moving animation in less time, from what I can tell, than it takes for him to move the button until the end.
EDIT2: I measured it frame-by-frame, it takes 5 frames from the moment the button starts to move until the screen is completely functional, showing the proper image. The video is at 25 fps, so that's 200ms, for the whole device to go from non-powered to fully working animation.
That's 200ms more than 0ms, which is the status quo for dumb devices.
> "yet, it's still fast enough that I can't perceive any delay."
Right, because the inputs aren't on-screen. Touchscreen devices inject more delay because you have to:
- wake the device
- read the output
- decide on input
- press the input
With a device like your microwave (or your arcade game) steps 1 and 2 don't exist, because the inputs are visible even when the screen is off. With your microwave you just walk up and start punching your desired buttons right away, the screen will catch up to you quickly.
And this is also why this is fundamentally a product design problem that isn't fixable via simply faster software - a non-primed human will take 500ms+ at each of these steps just in reaction time, the 200ms wake-time and whatnot is minor in comparison to the delay caused by having the human take multiple steps to do something. This is fundamentally about modes of interaction and not really about software performance.
We are at a stage in tech development where human delays vastly overwhelm purely machine-caused lag time. This is why compressing multi-step processes into a single step (or eliminating them altogether) is so valuable in terms of improving usability. Conversely - and this is something a lot of futurists just don't get - injecting additional steps into the use of something, even with very high performance software, results in disproportionate delays, and makes the product overall more annoying and cumbersome to use. This is the heart of why nearly all smarthome devices have been utter failures so far - despite doing something useful, they dramatically increase the human load on their usage.
Now, you could have a single home control display - or perhaps a single display in every room. And they'd all show the same information, maybe customised for each room, and include a few extra pages for setting up timers, lights, proximity sensors, or whatever.
There are plenty of applications for this kind of IoT, but the tech just hasn't come together yet. I think the lack of good, cheap, large, low-energy displays is more of an issue than wake up times - because if the display uses very little energy, you can skip the wake up time.
You can more or less pick any two from the list, but getting all four seems to be impossible for now.
Sure, yes, one reason we keep displays off most of the time is because of their usage, but more and more so it's the secondary reason - there are lots of power efficient displays nowadays that can maintain an always-on screen at relatively low power cost, and smarthome devices generally aren't reliant on battery power.
But the bigger problem is that LCD displays are ugly. They are backlit, and their response to better lighting in the room is to increase its own strength to make itself even more apparent. They are ugly, obnoxious, and annoying in the same way blinking router lights are, but multiplied several times over.
So we keep them off - we can afford to keep them on, but the fact that we keep them off 99% of the time less environmental consciousness but more an acknowledgment that they're visually noisy, distracting, and just kind of don't fit in. When you walk into a room you don't want your attention immediately drawn to this LCD panel on the wall with its pale glow.
E-ink fortunately doesn't suffer from this problem. It's clearly legible, doesn't require backlighting, and more importantly doesn't appear distractingly electronic in everyday use. You can afford to keep an always-on e-ink display, not just because of its low power use, but because it won't be this annoying glow in your peripheral vision always.
1. Wonder what the thermostat is currently set to.
2. Approach thermostat hoping to trigger the proximity detection.
3. Stand in front of thermostat like idiot for 2.4 seconds to see if proximity sensor activates.
4. Decide proximity sensor won't activate.
5. Turn bezel by smallest possible amount to wake thermostat without changing setting.
6. Overshoot and change setting anyway.
7. Realize original setting was acceptable. Put it back.
Being always on would be nice. You can work around not having it be so (I'm sure the Nest's implementation can be improved) but the ideal would just be to have it always be visible.
Of course, half the time I'm doing this, it's dark enough that I couldn't read an e-ink display....
Or you could tile smaller modules: http://www.eink.com/press_releases/e_ink_mpicosys_pdi_eWall_...
http://www.essentialscrap.com/eink/index.html
http://www.eevblog.com/forum/microcontrollers/interfacing-ep...
I'm more inclined to do the 6 rows of 7 displays which allow for a day aligned calendar for every month. It wastes a few displays of course, but the displays are easier to get.