4.41 inch ePaper Display for the rPi

There are a number of displays on the market for the Pi. I need one that will work over a wide temperature range. I would like to use an ePaper display, but there is very limited selection currently. Between the size needed and the temperature range I find no existing ePaper product that will work.

I have found a couple of Kickstarter projects that seem to use the Aurora type of ePaper display which meets the temperature requirement, but they are only for the smaller displays, the largest being 2.7 inches I believe. These controllers are not compatible with the larger size displays.

I have also found 4.3 inch displays in a different ePaper technology which won't meet the temperature requirements.

I am thinking about making a Pi oriented controller board for the 4.41 inch size display. The resolution is 400x300. There is a controller chip that is promoted for the larger displays, but I haven't found documents explaining what it does. I actually can't find any documents on exactly how to drive the larger displays other than using the eval controller module which uses the controller chip. So clearly it will be a long row to hoe to try to get the info and design a board.

In essence, the difference between this display and others out there is the temperature range and the fact that the display size is not limited by the rPi size. I'm wondering how much interest there might be in such a product if I make it.

--

Rick
Reply to
rickman
Loading thread data ...

Are any of these displays coloured ePaper? What about touch screen capabilities? The 4.4" size sounds useful for what I'd need: a display with low power consumption that is easily readable in direct sunlight. The space limitation is because that's as big as I can use in my glider without hiding other instruments. Touch screen would suit me better than a separate controller. I'd only need single touch.

I'm currently using a Medion S3747 with a transreflective screen. This remains readable in direct sunlight though its contrast does tend to reduce in very bright conditions. ePaper would be better despite its relatively low refresh rate. The software I run is available for both WM

5/6 and Linux, so should work well any RPi.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

One thing to keep in mind is that ePaper is only low power when you aren't changing the display. When you *are* changing the display it is

*very* slow compared to any other technology *and* not remotely low power. For low power stick with LCD reflective.

How often does the display need to be updated? I haven't been looking hard at ePaper for awhile. Back a couple of years ago there was a dearth of info on the displays. More recently I am finding a bit more info on the displays and how to use them. Somewhere in my travels I think I found one manufacturer of a display unit that included a touch screen and even illumination LEDs (they have to be front lighted rather than back lighted). If I come across it again I will make a note of it for you.

My app needs to be protected from the weather, so no touch screen. I wonder if a capacitive touch sensor can be placed below a piece of glass? But I'm sure it would need to be thin and so fragile. They use gorilla glass for cell phones I believe. They do a hot dunk in potassium salts which displace sodium atoms on the surface with potassium. Being larger this puts strain on the two surfaces which make it very hard. There may be a decent product there, but it would be a sizable investment to get started with unknown payout.

Transflective is the poor compromise between reflective and transmissive, marginally usable in either light or dark but excelling in neither. I think the transflective works best with indoor lighting... of the right type. You could use a reflective display with a front light when dark.

I think you can roll your own touch screen. It just lays on top of the display. Can you find any that would fit?

I had a phone conversation with Pervasive today. I am not the only one who is not crazy about the way ePaper is marketed. It has always been short on detailed info. I think they are mostly targeting the "large" users and just don't put much into the public info. No one has said anything about an NDA yet, so I guess that is not the issue. This conversation seemed to show interest on their side.

The current product is a panel from Pervasive with a controller board from Mpicosys. Mpicosys rolled their own chip which may be a hard version of an FPGA. I can't imagine anyone investing the bucks for an ASIC, but maybe. I was told when they produced it the result was better than the Pervasive chip so Pervasive dropped their chip. However, they are designing a new chip which will work better and will be incorporated in their new 4 inch display. So it will eliminate one board from a system.

He said the new Pervasive chip is not compatible with exiting displays because it must be incorporated into the display. I'm guessing the new controller included some of the circuitry that is currently included on the display. The docs for the smaller displays refer to loading the image into memory before giving the command to display it, so there must be a chip with memory and the actual timing logic on board. The 4.41 inch and larger displays are a bit different, but they still have an SPI type interface, so clearly there is some sort of a digital device other than simple drivers. Maybe I'll know more when I get the info. I wish I could figure out why they hold back so much.

--

Rick
Reply to
rickman

I don't think that's a problem - ever seen the power a standard PNA burns with the brightness full up for outdoor use?

I just looked back at my records and see the PNA that was I measured power consumption used 320 mA - I don't know whether that was a Binatone B.350 or the Medion S3747 that I use now, but subjectively they have similar brightness indoors. FWIW the avionics draw is 483 mA for two varios, my FLARM and the PNA running LK8000. By comparison the ATR500 airband radio draws 200mA when its listening (1100 mA transmitting) and my mechanical T&B draws 500mA. All currents measured at the 12V inlet to the panel.

The principal limit is the GPS subsystem in the PNA - that updates once a second, so that's the fundamental refresh rate for the display as a whole. If the EPaper display refreshed once every 50mS that would be good enough for navigation etc, and possibly even fast enough during interactions such as selecting a new destination, etc.

I doubt I'd need the extra LEDs since we never fly gliders at night.

For my use case the transreflective display is never worse than a standard PNA such as the Binatone B.350 and usually is far more readable, but then I am talking about use under a fully transparent bubble canopy and with a certain amount of illumination coming off my shirt etc as well as directly from the sun.

I haven't looked yet, since the Medion is doing an acceptable job so far, but I realise that virtually all PNAs were WM/WinCE based and new ones are almost non-existent now M$ pulled the plug on those OSen. So, I'm keeping a listening watch to see what would be available if my Medion dies.

I had noticed that comparable TFT displays are available for the RPi but wasn't aware that you could get small ePaper - hence my interest.

Certainly sounds interesting. Thanks for the heads-up.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

I don't know what a PNA is.

Then that is a problem. At room temperature the display refresh takes about a second and slows considerably as temps drop. This is the extended temperature version I'm referring to. Maybe the standard temp version updates a bit faster, but 50 ms is totally out.

The standard temp version does have a partial update capability which might help with refresh of just the data and not the entire display.

Yeah, these things are nothing like conventional displays.

I wish I knew what a PNA is. I assume it is nothing like PDA...?

Would a 2.7 inch display be ok? That is out there now with FOSS. Check out repaper.org.

BTW, I found that display with the touch panel. 6" diagonal and 600x800 resolution, 0?~50?. Refresh time is also about a second.

formatting link

Here is a link for the smaller display eval board.

formatting link

I think this industry is under capitalized. I can't think of any other reason why it is so hard to get info and why they seem to be slow to bring new products to market. After thinking about it a bit I realize they probably rolled their timing controller for the larger displays in an FPGA because of limited funds and got a minimum implementation. A third party did a chip design of some sort that worked a lot better. Still, this is only good for them, but why did someone else need to do it? Now they have their new chip but it is only forward compatible with new product. I guess it is still early days in the industry.

Too bad I couldn't have been involved with them sooner when they were doing the FPGA design. I can rock FPGAs, especially the low power ones!

--

Rick
Reply to
rickman

Another one with just the touch screen.

formatting link

--

Rick
Reply to
rickman

If this is an application where you can roll your own CPU board, it may be worth looking at the SoCs used in e-readers. For example, the Kindle Voyage uses a Freescale MCIMX6L8DVN10AB from the iMX6 family, which includes onboard e-paper support. If not roll your own board, perhaps there is a dev board you can use?

It would seem that the niche where you want HDMI or RGBHV into a separate e-paper driver chip is pretty small (and such would be inefficient burning power for sending unchanging video) so it makes sense to have the controller integrated onto the SoC.

Theo

Reply to
Theo Markettos

Sorry: PNA = Personal Navigation Assistant

This which covers portable/pocketable devices ranging from something like a Garmin GPS II+ or eTrex (simple walking or cycling GPS) to devices with moving maps like the Binatone B.350, MioPocket, (advanced hiking GPS, portable satnavs for cars, etc).

They tend to get specialised programs installed for less-common uses, e.g. my Medion came with both road navigation and trekking programs in ROM but I run the LK8000 glider navigation program off an SD-microcard.

How fast could it manage a full-screen refresh? 2Hz should be OK provided that it can update displayed text fast enough to handle data entry through menu selection or via an on-screen keyboard (single key at a time).

Its really just a PDA with built-in GPS receiver. I thought PDA was a well-known term or I'd not have used it.

Its a bit small - both the PNAs I've been using have 3.5" displays. Here's a shot of mine doing its thing while sitting in a tree in my garden. It gives a reasonable idea of the sort of display I like:

formatting link

All the zeros being shown are because the device is stationary at ground level and, because it has been stationary since it was switched on, it doesn't yet know what direction is north.

The partial update video makes it look as if the display might be fast enough, but there's one odd omission - nowhere does it quote the screen resolution in pixels.

The typical 3.5" PNA display is 320 x 240 pixels which, as you can see above, gives an adequate display. Any less probably wouldn't be much use.

I notice that the Embedded Artists 2.7" display (the one Pervasive is using) is only 264x176 and bi-colour, so would not be high enough res for what I want. Pity, as its contrast is good and it looks easy to connect to an RPi.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

Neat, but far too big for me; I could just squeeze in a 4.2" landscape display, but there just isn't enough room on or in front of my panel. Here's a pic of the full panel with a Binatone B.350 (3.5" display) mounted and running:

formatting link

My current PNA, the Medion S3747, is an almost identical size.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

I think using a big MCU chip to drive a low power display over an SPI port is a bit of overkill. These displays come in families and I have only found one family of ePaper displays that work over an extended temperature range. The larger displays in this family have exactly one display controller (board and chip) and that is provided by a third party, resold by the display maker. Oddly enough it seems the controller chip is not rated for the same temperature range as the display. So although they have an extended temperature range display, there is no extended temperature range controller for it!

I'm going to use the lack of an extended temperature range controller (board or chip) as a lever to get the spec for the display and maybe I can roll my own in an FPGA.

I'm not sure why you are talking about HDMI or RGBHV. These are purely black and white displays, not even gray scale. They are not refreshed on a regular basis, only updated when needed and take about a second to redraw the screen.

--

Rick
Reply to
rickman

Not even a 1 Hz update rate. I checked the spec and it takes 1.4 seconds to update the display at room temperature and during that time the display is flashing from image to reverse image to image. They write a negative image to minimize ghosting.

If you need 1 second GPS updates, the ePaper display is not the right way to go.

I get a bit tired of people using specialized technical jargon here when they don't know who they are talking to. Sometimes it is hard to find the meaning in a google search if you don't have an idea. After I made the post I googled PNA and it showed up in the first hit as Personal Navigation Assistant. So obviously it is fairly common even if I didn't know it. I guess I should have searched first, lol.

I'm familiar with navigation units, I've just always called them GPS units or even just GPS. I don't quite understand. Why would you want to duplicate this display and how would you expect to get this on an external display?

The Pervasive 4.41 inch display is 400x300 (both temperature ranges) and

When you say "bi-colour", you mean black and white, right?

--

Rick
Reply to
rickman

Notice that both devices have a huge border around the display. You can use a larger display if you get one that is wall to wall display.

--

Rick
Reply to
rickman

Fair enough. It's just that some people are running this type of navigation application on Kobo eReaders and are reporting good results. Is thr Kobo refresh noticeably faster than the Pervasive displays and their controllers?

We tend to reserve this term for the 'traditional' Garmins and so-called 'blind GPS' or 'GPS puck' such as the Garmin GPS35 or GPS18.

I'm looking at the possibilities of running one of the OSS glider navigation programs on an RPi with a small TFT or ePaper display. That would work well. I have plenty of space behind the panel for the RPi and its display would go where the PDA is mounted at present. Both the leading OSS programs, LK8000 and XCSoar have already been ported to Linux.

So, using this with an RPi looks like a sensible way to go. I'll remember that.

Yes. That's Embedded Artists term, not mine. The other reason, apart from better resolution for using the Pervasive 4.41 display is that it seems to offer four grey shades plus white, but is it fast enough to be worth consideration?

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

You didn't say the panel spoke SPI. Is this it:

formatting link
I'm a little unsure why it speaks SPI but also needs a timing controller (TCon) as well. Does the display need refresh (like traditional hsync/vsync timing) with the SPI just being state changes, or are they more closely related? Could you run the SPI from the CPU and the timing from a CPLD/FPGA?

That's probably a useful strategy.

Since we're on the RPi group, most people are going to assume you're wanting to show the Pi display on the e-paper panel, which means HDMI-to-something conversion. If it's as SPI then it's just a peripheral, so nothing particularly Pi-specific here, except perhaps in terms of code to drive it.

Theo

Reply to
Theo Markettos

Agreed, but you only seem to find narrow borders on the larger displays. I have no idea why this is the case, but narrower borders only start on some of the devices with 4.2" screens. Putting numbers on it that Binatone B.350 is 4.7" on the overall diagonal. I know that I can get away with using a 4.2", narrow bordered screen but those have recently turned into unobtanium.

A couple of years back a very narrow bordered 5" device appeared on the market, so I made a cardboard frame for the Binatone with its dimensions to check it out. It didn't look very much bigger, but mounting that on the panel soon showed that it was too big: it hid more of the vario at top right than I was happy with and it extended sideways far enough to encroach on the radio at lower centre.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

I haven't seen a Kobo. Is it ePaper? Lots of readers are LCD these days, no different from a tablet. The ePaper displays I have seen may be faster than 1 second update time, but not by a lot. You watch the page get refreshed. It is not at all unnoticeable.

"Traditional"? Does that mean a handheld GPS or a "pro" unit intended for flying?

For $50 ball park you can get one of the smaller displays to test and see if you think it will work for you. I don't know drivers are available that integrate it as a standard display. Everything I've seen so far just lets you roll your own app to talk to it.

I don't know. I'm not sure you really need even a 1 Hz update for a GPS display. Some time back when I was building a GPS product they were just coming out with modules that would update the coordinates at 4 Hz. Until then the low cost devices were all updating at 1 Hz. This data is basically 1 second old by the time the calcs are done and you receive it. I can't imagine you need second resolution on a display with so few pixels. Are you using this for velocity and altitude as well as mapping?

Bottom line is ePaper is not really real time unless you are a snail. The nature of ePaper is that it is slow to update and the low power aspect is only apparent when you aren't updating. When it updates it uses a similar power level to the LED backlight of a small LCD display, ~30 mA at 3.3 volts just for the display, not counting the controller.

--

Rick
Reply to
rickman

Yes, that is the extended temperature version of the panel. The standard temperature model is ET044AS013, doc 1P038-00. Very similar specs other than the temperature. But the standard temp model can have partial updates and another feature I can't recall at the moment. The docs suck in some ways. It can be hard to find info at times. Best to memorize everything once you find it, lol.

That is the $64,000 question, how do the interfaces work?

The smaller units (2.7 inches and smaller) have an SPI interface and some discrete controls. The larger displays are "more complicated" according to the rep. I guess the interface is complex enough that they just don't want to give out the specs so they don't have to support that level of user.

There is no timing like a video signal because this is *not* video. The data sheet describes the operation as, display is powered up, data is sent, the display updates and power is removed. I expect the power up/down is optional, but you get the point. Only the Ents would be able to watch "video" on this display.

I'm getting rather weary of trying to pull teeth. If this go around doesn't get an info, I will have to give up on ePaper.

HDMI ain't happening. No need whatsoever and much difficulty. I don't see how an HDMI interface on a display would be at all rPi specific. Lots of pies have LCD or LED text displays. This is a similar interface but supports graphics.

Now that I recognized Pervasive doesn't have a wide temperature controller, I also realize they are asleep at the switch. ePaper displays have always been hard to get info on. That still has not changed. If you think Pervasive is hard to get info from, try getting good info from Good Displays, a purely Asian company.

--

Rick
Reply to
rickman

As far as I know it is, assuming I've gotten the name right. If it wasn't, people wouldn't be using it in their cockpit.

Don't forget that, with the large amount of info crammed onto the display by clever use of colour, e.g. different types of airspace have different colours. My example shows two types. GRL under the glider symbol and BOUrn are ATZ (not to be entered unless you're landing there) are filled with grey diagonal lines. The plain grey arc on the right is a NOTAM (temporarily restricted airspace), but Control Zones and danger areas are differing colours of red.

Bottom line: colours are very useful, so giving them up for a monochrome display means that the latter must be very much easier to read under all conditions.

A handheld unit. The non-mapping aviation GPS units tend to show analogue dial-like images plus digital values for each output because those are easier to read fast. They'll show speed, altitude and track (not heading: a GPS doesn't know where the plane is pointing, just the direction in which its going).

GPS units that can display maps appeared several years later than the 'traditional' non-mapping units. I think there are two reasons for this: LCD displays large enough to show a usable map took their time arriving and so did big enough affordable non-volatile memory to store maps that covered enough country and were detailed enough to be useful.

That's about right. XCSoar, which I don't use, solved the problem by becoming an Android app, so by definition the stuff it needs (SD-cards, touch screens, sound, colour displays) are already there.

LK8000, which I prefer, is probably heading for the RPi but may also appear on Android.

The only time I really notice the full screen update lag is when I'm climbing in a thermal, typically taking 15-30 seconds per turn. The display is far enough that its useless for rolling out on a heading when you leave the thermal: you use sun and landmarks instead and this way the display has caught up when you next look at it.

Not as prime instruments. LK8000 shows other, but related stuff such as wind speed and direction, ground speed, distance to the next turn point and whether you're above or below glide path to get there. Sometimes that can be amusing: I remember rolling out of a climb over Bury St Edmunds at

4500 ft with the system saying I had 150km to go into wind to Edgehill and that I was 49,000 feet too low to get there. Stupid instrument: I already knew I needed a few climbs along the way.

Fair enough, but its high contrast in direct sunlight is also a useful feature. That contrast is one reason why very many LCD aviation instruments are still monochrome reflective rather than backlit (except at night), just as most mechanical instruments have white markings on a black background.

Understood.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

I'm not really following you here. Color is better than BW so the Kobo must be ePaper?

Why don't you ask the people who have the Kobo how fast it updates?

Again, I'm not following. If you have an Andriod app, how does that get an ePaper display?

When you say rPi, you mean Linux. There is not really anything special about the rPi that I have been able to see. I'm a rank novice with Linux but nearly everything I've learned about it applies equally to any Debian system.

In the system I'm looking at building I likely won't actually use the rPi as it is not rated over temperature, etc. I'll likely end up using another board which has proper specs. Not the Beagle board as the proprietor has indicated very emphatically that their boards are *not* to be used in commercial systems. I guess I'll need to start looking for a decent alternative.

You are talking about the lag in your GPS? Yes, I've seen that with hand held units even while walking, lol. To get real time updates... I mean truly real time, you need an inertial nav system. Entirely possible with a simple G force sensor like they use in phones these days. It requires some data fusion as the sensor won't be as accurate long term as the GPS, but over the short interval the sensor is faster to respond.

If they are backlit that is called "transflective". It's a partially mirrored back and is a compromise. Like most compromises it makes everyone equally unhappy. In this case it works in most lighting conditions, but not well.

Ok, so for your app power is not really an issue. Do you run from batteries or use a prop powered generator? I've never seen any sort of prop on a glider (I live very near an airport so I do get to see a lot of them). I just wondered if the weight of a generator would be less than the battery, but maybe you don't need a large battery so the weight just isn't an issue.

I know what you mean about the contrast of the ePaper display. I have thought about designing a clock using one of the smaller displays. Unlike LCDs you can't find a decent ePaper clock display. I'd have to use a graphic display and the power goes up significantly... I think. Like I keep saying, they aren't very good about releasing info.

Maybe I'll do the clock display just to get my feet wet. I'm pretty sure the timing controller for the small ones is just an MCU.

--

Rick
Reply to
rickman

I found this on the Kobo.

Kobo Aura features a beautiful edge-to-edge design and is equipped with ClarityScreen, a low-glare 6? HD Pearl E Ink screen boasting a stunning

1014 x 758 resolution for a print on paper reading experience even in direct sunlight.

They have a video showing use of a magnifying function on the display. The small window for setting the zoom is a partial update and so is faster. But when the entire display updates you can see it happen and I think it takes maybe 300 - 400 ms. If you used a 1 second refresh on the entire screen it would flash pretty badly I think. Use a partial update and you can make it work pretty well.

This points to another short coming in the ePaper info. What is different about the displays used in eReaders and the displays Pervasive sells?

--

Rick
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.