The plausibility of an E-Ink Display

[spud42]

http://essentialscrap.com/eink/
electrical connections http://essentialscrap.com/eink/electronics.html

looks like you need to be able to generate +- 22V and +-15V
there is a schematic to drive a display there as well.

found some eink kits , here is the link
http://the-digital-reader.com/2013/05/23/e-ink-dives-into-the-diy-market/

 

[JustSimon]

looks like you need to be able to generate +- 22V and +-15V

The displays that I have seen only required 3 and/or 5 Volts.
I personally would prefer a screen that is smaller than the Pyra, so I can put it at the back of the screen.
We can drive the display easily using software and I2C.
The only problem is finding a display that is that size, doesn't cost too much and has an I2C interface.
The rest I can solve in software.

 

[Grench]

It is a screen that doesn't need constant refresh and very little power though. It would be far easier to -not- have it hard wired in. Bluetooth Oaxis is the right format, but someone would have to code up something to talk to it. If you need to have it connected to the screen/lid, then double sided tape would work.

Essentially an app would have to be coded for the Pyra to take a "screen shot" every 5 seconds and push it to this over bluetooth. "Screen Shot" doesn't mean that the main screen has to be 'on' or illuminated.

 

[Pyramancer]

Each of these 4 accessible busses run at 400KHz, meaning you can get a theoretical bitrate of 350 bits/second through each of the busses.

Was that a typo, or do I need to go and get myself another coffee?

Seems to me that single-rate 32-bit bus running at 400 kHz should have a maximum throughput of 1.6 MB/s. I don't know what the width of the Pyra busses are, but even if they were only 1 bit wide they'd need to transfer only one symbol every 1140 clocks (or so) to only transfer 350 bits/s.

What am I missing?

 

[slaeshjag]

http://essentialscrap.com/eink/
electrical connections http://essentialscrap.com/eink/electronics.html

looks like you need to be able to generate +- 22V and +-15V
there is a schematic to drive a display there as well.

found some eink kits , here is the link
http://the-digital-reader.com/2013/05/23/e-ink-dives-into-the-diy-market/

In the cheap e-paper displays I've seen, the switching powersupply is included in the chip-on-glass. You just need to hook up the passives to the connector.

 

[Pocak]

Was that a typo, or do I need to go and get myself another coffee?

Seems to me that single-rate 32-bit bus running at 400 kHz should have a maximum throughput of 1.6 MB/s. I don't know what the width of the Pyra busses are, but even if they were only 1 bit wide they'd need to transfer only one symbol every 1140 clocks (or so) to only transfer 350 bits/s.

What am I missing?

That was in the context of I2C buses, so it's 1 bit per clock and an ACK bit after each byte. @Rolf van Kleef meant 350 kilobits/s. That should be fine for the logo sized panels, but it's something to keep in mind when looking at larger ones.

Thanks for updating that! I'd forgotten what we lost if we went for a standard (non-cellular) version, and that explains that it's the thermo-, baro- and hygrometers (and GPS I think). They keep the compass, accelerometers and gyroscope, meaning they can all be used by software regardless of the model.

@Rolf van Kleef, do you have a source for that? In the schematics, all the sensors are crossed out on the standard edition PCB.

@levi The vibra motor, the 5Ghz WiFi, and (some or all) keyboard lights were also on the chopping board, but ED managed to squeeze them in.

 

[Pyramancer]

That was in the context of I2C buses, so it's 1 bit per clock and an ACK bit after each byte. @Rolf van Kleef meant 350 kilobits/s.

Thanks for this. I mostly live in an abstract world; it's always interesting to learn something concrete. With that and taking into account the typo, everything adds up.

That hardly deserves to be called a bus, though. More of a unicycle. Or a tandem bike, if you also count the clock line.

 

[Failbert]

I'm planning to build this myself when the Pyra is out and 3D-Print a case and solder the display to the display to the sceen myself.
I'm posting this here for two reasons:
1. I will probably make mistakes and/or need help in general.
2. I think this is pretty cool and others might be interested in modding their device jn the same way.

And I would like to have only one device. Even if the Eink screen turns out to be too small for use as a proper reader. I just like the idea of a second screen. And in the wrost case, it's gonna be a nice clock/notification list/newsfeed/mp3-player-info-display.

Good approach. I surely will follow and root for it to happen

you can drive some ereaders (from pocketbook, but maybe also others) as external display):
https://github.com/borzunov/remoteink

maybe someone can compile this for pandora & eventually pyra?

This is great... Going a step further in analysis, I wonder, will it allow to conserve more power on the battery? I'm not too savvy in these matters and wonder (in layman's terms, please bear), if using high-level software to make an external e-ink screen display with the main one un-powered would actually give a positive balance, so to speak? Or would it require low-level magic and hard work with adapting the e-ink display

facts for nerds about power consumption of varying display technologies: http://www.mdpi.com/2071-1050/7/8/10854/pdf

 

[Urben]

If someone sells a lid-mod with an e-ink display for not too much money, I will buy it for sure.

 

[kabaiakh]

I'll be the second buyer then.

 

[Rolf van Kleef]

That was in the context of I2C buses, so it's 1 bit per clock and an ACK bit after each byte. @Rolf van Kleef meant 350 kilobits/s. That should be fine for the logo sized panels, but it's something to keep in mind when looking at larger ones.


@Rolf van Kleef, do you have a source for that? In the schematics, all the sensors are crossed out on the standard edition PCB.

@levi The vibra motor, the 5Ghz WiFi, and (some or all) keyboard lights were also on the chopping board, but ED managed to squeeze them in.

I pulled all this data from the PCB's of the pyra, mostly MAIN and MAIN_4G. Not all sensors are crossed out, but a significant amount are indeed. My data (and consequently the data on the wiki) should be correct and is so far almost entirely confirmed by devs apart from a few components I left out since they were missing on PCB's.

 

[levi]

Out of interest (and completely OT FWIW) does anyone know where the vibra motor is on the physical PCB. I guess it's wired up to some GPIO or other and driven using PWM, but I'd expect it to be some silver box that's fairly visible on the PCB shots. I wonder if it's actually that rectangular mystery box on the right of the keyboard, on the opposite side to the big chips, but being rectangular rules out it being a standard motorised off-center weight providing the vibrational forces, but instead perhaps uses some ball bearing that shuttles from end to end under control of a magnet. Or is the motor not actually seen on the PCB, because it is a traditional rotary device that's not soldered to the PCB, but a separate assembly that plugs into the PCB somehow, like dualshock motors sit in the handles of that controller, and are plugged into the PCB that carries the game buttons?

 

[Neelix]

It's on the the top back edge of the PCB, right beside the "wonky" chip.

-Neelix

 

[levi]

Ah right, thanks! Also, looking at the mystery box on the photo of the old populated board on the wiki mainboard page shows it was labelled as GPS-ANT, so it's the GPS antenna.

 

[Urben]

I've read here about using the display lines for the e-ink display, but if it is just for keeping notes, couldn't the back of the lid, where the glowing logo is, the place for the e-ink display? And with the LED lines (which would be unused if there is an e-ink display where the Pyra logo is) one could load the data for an image refresh into it. Nothing for videos, but as I said, notes or messages while the Pyra is closed.

 

[levi]

That does seem to fit the technical requirements. I don't know if +5V is available in that space, or just GND and 2 GPIOs, but it shouldn't be beyond the ken to wire it off the display board. And I think TI's GPIOs can handle some 10kbps which should be enough to sense page data quickly enough. Whether anyone builds e-paper displays at the right size and suitable to be driven by two GPIOs is a question I haven't researched though.

 

[Grench]

Whether anyone builds e-paper displays at the right size and suitable to be driven by two GPIOs is a question I haven't researched though.

Right size is the largest one available that is smaller than the Pyra lid.

 

[JustSimon]

That does seem to fit the technical requirements. I don't know if +5V is available in that space, or just GND and 2 GPIOs, but it shouldn't be beyond the ken to wire it off the display board. And I think TI's GPIOs can handle some 10kbps which should be enough to sense page data quickly enough. Whether anyone builds e-paper displays at the right size and suitable to be driven by two GPIOs is a question I haven't researched though.

Oh my god! That's an awesome idea!
The LEDs are very likely to use more energy than the e-ink display and since they would be covered by the display, why not fully replace them...

I think if that is possible, then I will order a second display-board for my pyra to make these modifications to.
The display uses I2C to get it's data and guess what the LEDs use to get their color values: Yes, I2C!
Most e-ink-displays only need tiny amounts of energy when updating, so I'm not worried about power consumption at all.

This would make for an awesome music-player that you can control with the shoulder buttons and see the song title on that screen.

Thanks for this great idea!

 

[levi]

Looking at the schematics, I assume the back of lid LEDs are the two on the second page of the DISP2 pdf. Those have two connections; VBATT-DISP2/41.1B and GND-DISP2/41.4C, which I take to be one data line at best. I don't know what the chips between those and the LEDs, but that looks like no I2C interface I've ever seen.

 

[Grench]

Looking at the schematics, I assume the back of lid LEDs are the two on the second page of the DISP2 pdf. Those have two connections; VBATT-DISP2/41.1B and GND-DISP2/41.4C, which I take to be one data line at best. I don't know what the chips between those and the LEDs, but that looks like no I2C interface I've ever seen.

Getting back into this idea... Does the e-ink in the lid idea really need to be 'graphical' in nature? Or would just plain text be good?

Long, long ago in a time of computer terminals with green screens... I seem to recall that there were direct text to screen protocols. I.e. instead of drawing things with dots, the screen was handed a line number, position and the letter/character to populate there. I'm talking about pre-ASCII stuff here. The screen required bandwidth was in the 300 baud range.

I suspect that most modern hardware has, hidden away in the background, those kinds of protocols so that they can be tested to 'hello world' level without much input.

A lot of times old protocols just get rolled into new signals & paths. This guy tore into the VGA protocol to write text to a screen using very little CPU, memory or bandwidth:
http://damian.pecke.tt/vga-on-the-arduino-with-no-external-parts
It appears to me that he is simply sending the display a set of characters and the coordinates to drop them on.

I wonder if the e-ink or e-paper displays on the market have some hidden protocol that could be interpreted as an 80 column by 25 row character text mode display.