Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.raspberry-pi > #8909 > unrolled thread

Re: 4.41 inch ePaper Display for the rPi

Back to article view | Back to comp.sys.raspberry-pi

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: 4.41 inch ePaper Display for the rPi Martin Gregorie <martin@address-in-sig.invalid> - 2015-06-18 22:39 +0000
    Re: 4.41 inch ePaper Display for the rPi Martin Gregorie <martin@address-in-sig.invalid> - 2015-06-19 19:10 +0000
      Re: 4.41 inch ePaper Display for the rPi rickman <gnuarm@gmail.com> - 2015-06-19 15:34 -0400
        Re: 4.41 inch ePaper Display for the rPi Martin Gregorie <martin@address-in-sig.invalid> - 2015-06-19 20:36 +0000
          Re: 4.41 inch ePaper Display for the rPi Martin Gregorie <martin@address-in-sig.invalid> - 2015-06-19 23:22 +0000
          Re: 4.41 inch ePaper Display for the rPi Martin Gregorie <martin@address-in-sig.invalid> - 2015-06-19 23:58 +0000
            Re: 4.41 inch ePaper Display for the rPi hamilton <hamilton@nothere.com> - 2015-06-19 18:25 -0600
            Re: 4.41 inch ePaper Display for the rPi rickman <gnuarm@gmail.com> - 2015-06-19 22:44 -0400
              Re: 4.41 inch ePaper Display for the rPi rickman <gnuarm@gmail.com> - 2015-06-20 13:29 -0400
          Re: 4.41 inch ePaper Display for the rPi cl@isbd.net - 2015-07-29 10:26 +0100
            Re: 4.41 inch ePaper Display for the rPi cl@isbd.net - 2015-07-29 21:21 +0100
              Re: 4.41 inch ePaper Display for the rPi rickman <gnuarm@gmail.com> - 2015-07-29 17:18 -0400
                Re: 4.41 inch ePaper Display for the rPi cl@isbd.net - 2015-07-30 10:23 +0100
                  Re: 4.41 inch ePaper Display for the rPi Rob <nomail@example.com> - 2015-07-30 11:14 +0000
                  Re: 4.41 inch ePaper Display for the rPi Dom <domafp@blueyonder.co.uk> - 2015-07-30 12:55 +0100
                    Re: 4.41 inch ePaper Display for the rPi cl@isbd.net - 2015-07-30 13:15 +0100
    Re: 4.41 inch ePaper Display for the rPi Theo Markettos <theom+news@chiark.greenend.org.uk> - 2015-06-19 20:27 +0100
      Re: 4.41 inch ePaper Display for the rPi rickman <gnuarm@gmail.com> - 2015-06-19 15:57 -0400
    Re: 4.41 inch ePaper Display for the rPi Martin Gregorie <martin@address-in-sig.invalid> - 2015-06-19 19:31 +0000

#8909 — Re: 4.41 inch ePaper Display for the rPi

On Thu, 18 Jun 2015 11:42:27 -0400, rickman wrote:

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

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       |

[toc] | [next] | [standalone]

#8923

On Fri, 19 Jun 2015 13:12:28 -0400, rickman wrote:

> If you need 1 second GPS updates, the ePaper display is not the right
> way to go.
>
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?
  
> I'm familiar with navigation units, I've just always called them GPS
> units or even just GPS.
>
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 don't quite understand.  Why would you want
> to duplicate this display and how would you expect to get this on an
> external display?
>
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.

> The Pervasive 4.41 inch display is 400x300 (both temperature ranges) and
> the similar sized Good Display unit is 800x600 (0°C to 50°C only).
>
So, using this with an RPi looks like a sensible way to go. I'll remember 
that.
 
> When you say "bi-colour", you mean black and white, right?
>
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       |

[toc] | [prev] | [next] | [standalone]

#8926

On 6/19/2015 3:10 PM, Martin Gregorie wrote:
> On Fri, 19 Jun 2015 13:12:28 -0400, rickman wrote:
>
>> If you need 1 second GPS updates, the ePaper display is not the right
>> way to go.
>>
> 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?

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.


>> I'm familiar with navigation units, I've just always called them GPS
>> units or even just GPS.
>>
> 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.

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


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

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.


>> The Pervasive 4.41 inch display is 400x300 (both temperature ranges) and
>> the similar sized Good Display unit is 800x600 (0°C to 50°C only).
>>
> So, using this with an RPi looks like a sensible way to go. I'll remember
> that.
>
>> When you say "bi-colour", you mean black and white, right?
>>
> 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?

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

[toc] | [prev] | [next] | [standalone]

#8928

On Fri, 19 Jun 2015 15:34:11 -0400, rickman wrote:

> I haven't seen a Kobo.  Is it ePaper?
>
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.

>> 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.
> 
> "Traditional"?  Does that mean a handheld GPS or a "pro" unit intended
> for flying?
>
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. 
 
> 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.
>
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.

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

> Are you using this for velocity and altitude as well as mapping?
>
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.

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

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


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

[toc] | [prev] | [next] | [standalone]

#8931

On Fri, 19 Jun 2015 17:35:10 -0400, rickman wrote:

> I'm not really following you here.  Color is better than BW so the Kobo
> must be ePaper?
>
No, colour is generally better than monochrome, all other things being 
equal. But for outdoor use under an open sky a high contrast monochrome 
display is preferable given that any colour display apart from coloured 
ePaper is going to be washed out and hard to read, especially with direct 
sunlight on the display.

Thats no different from trying to use a viewfinderless camera outdoors on 
a sunny day, but you'll know that.

 
> Why don't you ask the people who have the Kobo how fast it updates?
>
Because there is nobody at my club who is using a Kobo. Question posted 
on rec.aviation.soaring
  
> Again, I'm not following.  If you have an Andriod app, how does that get
> an ePaper display?
>
It doesn't, but it does tend to get you a commercial device with standard 
standard APIs for accessing its colour display and touch screen, enough 
flash memory to install the app on and facilities for uploading maps etc 
and for downloading flight logs.
  
> 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.
> 
Indeed, and it gets you a device that is small, light, not particularly 
hungry and cheap. As I said, I have a feeling that LK8000 has been ported 
to it, which would mean that somebody has added code to use SPI or I2C to 
handle small displays. It has to be them since we know there are no 
suitable HDMI displays and, although the el-cheapo Chinese back-up video 
displays accept a composite signal, the resolution looks to be 
unacceptably low.

The Beagle Board might also do the trick, but (so far) its not been 
mentioned as possible hw for LK8000.
 
> 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.
>
Some of the better varios are using 3D accelerometer arrays, but that's 
for gust sensing. Similarly, solid state blind flying panels are now 
common, good and quite cheap but lets not go there: they are for a rather 
different purpose.
  
> Ok, so for your app power is not really an issue.  Do you run from
> batteries or use a prop powered generator?
>
Batteries. Wind driven generators cause drag which stuffs glide 
performance. 12v systems are almost universal (Light aircraft use higher 
voltages). I carry a pair of 12v 7AH lead-acid batteries which can easily 
run my electronics for more than the longest day.

> 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).
>
Wander over one day, take a look and ask questions. Pilots are friendly 
and generally happy[*] to talk, answer questions and show you stuff

* just don't talk to a man who is in the middle of assembling and pre-
flighting a glider: he needs to concentrate on what he's doing.
 
Propellers: some gliders do have them because they carry auxiliary 
engines: if conditions deteriorate they can fire up and fly home rather 
than ending up in some farmer's field. Usually the engines and props are 
retracted behind the cockpit so you can't see them and come out on a 
pylon when needed, but nose-mounted, electrically driven folding props 
and small gas turbines are becoming popular. However, piston engines are 
still the most common, if the most problematic - because they add a huge 
amount of drag when extended, which is a big problem when it doesn't 
start. Thats why electric and jets are coming in: electric always starts 
and an extended jet adds very little drag even when not running. 

I fly a pure glider and usually winch launch rather than aero tow.
 
> 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.
>
Depends: at one extreme the Antares 20E is a 20m span electric self-
launcher with a pop-up 47 kW brushless motor and wings full of batteries. 
It has the power to take off and climb 10,000 ft. I have no idea what its 
batteries weigh. At the other end of the battery scale my pair of 7AH 
motorcycle batteries only add about 5 Kg to a glider with a normal flying 
weight of 280 Kg. 


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

[toc] | [prev] | [next] | [standalone]

#8932

On Fri, 19 Jun 2015 17:43:50 -0400, rickman wrote:

> This points to another short coming in the ePaper info.  What is
> different about the displays used in eReaders and the displays Pervasive
> sells?
>
Might the Kobo use a faster, more capable controller? 

I wonder how much the update speed is affected by the transfer rate. 

Off the top of my head, if you're sending every pixel down an SPI 
connection uploading changes to the controller will be relatively slow, 
but IIRC pixel flipping is a physical process, and so is also pretty 
slow. I'd guess a cheap bit-serial controller would be rate-limited by 
pixel flipping rather than the SPI transfer rate, but what do I know. A 
full refresh on that 2.7" display is taking about 30 uS to set a pixel, 
so how does that compare with normal SPI transfer rates?

Would I be wrong to expect a more complex and expensive controller, which 
might accept byte-wide uploads over some sort of parallel interface, 
could speed up the overall refresh by flipping several pixels in parallel 
or at least double buffer the uploads so it could accept uploads in 
parallel with pixel flipping.
 

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

[toc] | [prev] | [next] | [standalone]

#8933

Sorry if this has been suggested.

How about hacking the original Kindle w/ paper white display.

http://hackaday.com/category/kindle-hacks/

[toc] | [prev] | [next] | [standalone]

#8937

On 6/19/2015 7:58 PM, Martin Gregorie wrote:
> On Fri, 19 Jun 2015 17:43:50 -0400, rickman wrote:
>
>> This points to another short coming in the ePaper info.  What is
>> different about the displays used in eReaders and the displays Pervasive
>> sells?
>>
> Might the Kobo use a faster, more capable controller?
>
> I wonder how much the update speed is affected by the transfer rate.

I can assure you the limitation has nothing to do with the controller. 
It has to be in the display as it would be very easy to design a 
controller that would be *much* faster than a 1 second update.  The HDMI 
interface you mention supports 60 Hz updates at full HD resolution. 
That's just not the limitation.


> Off the top of my head, if you're sending every pixel down an SPI
> connection uploading changes to the controller will be relatively slow,

Why?  There are 120,000 pixels.  At 20 MHz the SPI can support 166 
updates per second.


> but IIRC pixel flipping is a physical process, and so is also pretty
> slow. I'd guess a cheap bit-serial controller would be rate-limited by
> pixel flipping rather than the SPI transfer rate, but what do I know. A
> full refresh on that 2.7" display is taking about 30 uS to set a pixel,
> so how does that compare with normal SPI transfer rates?
>
> Would I be wrong to expect a more complex and expensive controller, which
> might accept byte-wide uploads over some sort of parallel interface,
> could speed up the overall refresh by flipping several pixels in parallel
> or at least double buffer the uploads so it could accept uploads in
> parallel with pixel flipping.

None of this is a controller limitation.  That is all determined by the 
display.  I don't know for sure, but I think the larger displays are 
divided into multiple sections that work in parallel.  Otherwise the 10" 
display would be more than four times slower than the 4.41" display. 
The 7 and 10 inchers even have two connectors.

No point in speculating.  If I can't get the info on rolling my own 
controller, I am probably drop the ePaper thing for another couple of 
years until they get their act together.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#8943

On 6/20/2015 7:18 AM, Martin Gregorie wrote:
> On Fri, 19 Jun 2015 22:44:00 -0400, rickman wrote:
>
>> No point in speculating.  If I can't get the info on rolling my own
>> controller, I am probably drop the ePaper thing for another couple of
>> years until they get their act together.
>>
> You asked about the Kobo refresh rate. Here's a video of one, illuminated
> by direct sunlight and running LK8000, which is news to me since I didn't
> know it had been ported yet.
>
> https://www.youtube.com/watch?v=Lxojrs4f2I4

I think that is faster than the update I saw at the Kobo site.  So less 
than 300 ms.

> I tried timing it with a stopwatch but found it quite difficult to get
> accurate times off the video. All I can say is that a whole screen
> refresh is comfortably under 0.5 secs and scrolling through configuration
> settings is a lot faster than that.

I would say this is usable for any app other than a video type function. 
  Next time I speak with the salesman from Pervasive, assuming he speaks 
to me again, I will ask why the huge discrepancy in update rates.  I 
expect I am flying below their radar since I won't be buying 100,000 a 
year.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#9207

rickman <gnuarm@gmail.com> wrote:
> On 7/28/2015 10:02 AM, cl@isbd.net wrote:
> > rickman <gnuarm@gmail.com> wrote:
> >>>
> >>> LK8000, which I prefer, is probably heading for the RPi but may also
> >>> appear on Android.
> >>
> >> Again, I'm not following.  If you have an Andriod app, how does that get
> >> an ePaper display?
> >>
> > It's quite possible to get an Android device with an ePaper display, I
> > have one and it's pretty good at what it does.
> >
> > Take a look at the Icarus readers, the E653 in particular.
> 
> How fast does it redraw the screen?
> 
My guess would be somewhat less than 1 second though that's only
subjective.  It does produce some strange effects with standard
Android app animations but it mostly works pretty well.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#9210

rickman <gnuarm@gmail.com> wrote:
> On 7/29/2015 5:26 AM, cl@isbd.net wrote:
> > rickman <gnuarm@gmail.com> wrote:
> >> On 7/28/2015 10:02 AM, cl@isbd.net wrote:
> >>> rickman <gnuarm@gmail.com> wrote:
> >>>>>
> >>>>> LK8000, which I prefer, is probably heading for the RPi but may also
> >>>>> appear on Android.
> >>>>
> >>>> Again, I'm not following.  If you have an Andriod app, how does that get
> >>>> an ePaper display?
> >>>>
> >>> It's quite possible to get an Android device with an ePaper display, I
> >>> have one and it's pretty good at what it does.
> >>>
> >>> Take a look at the Icarus readers, the E653 in particular.
> >>
> >> How fast does it redraw the screen?
> >>
> > My guess would be somewhat less than 1 second though that's only
> > subjective.  It does produce some strange effects with standard
> > Android app animations but it mostly works pretty well.
> 
> That is an e-paper display for sure then.  I'm surprised they included 
> this display in anything other than a book reader.  So much of what a 
> tablet or PDA does requires faster drawing times.
> 
> Wait until you try to use it in cold weather.  They slow down a *lot*.
> 
I'm rather unlikely to use it in the cold! :-)

It's promoted mainly as an e-reader but with the advantage of being
much more 'open' than the proprietary Kindle etc.  I bought it for its
openness, it means I can read Amazon Kindle books *and* ePub books
from my public library (and for that matter other proprietary formats).

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#9211

On 7/29/2015 4:21 PM, cl@isbd.net wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 7/29/2015 5:26 AM, cl@isbd.net wrote:
>>> rickman <gnuarm@gmail.com> wrote:
>>>> On 7/28/2015 10:02 AM, cl@isbd.net wrote:
>>>>> rickman <gnuarm@gmail.com> wrote:
>>>>>>>
>>>>>>> LK8000, which I prefer, is probably heading for the RPi but may also
>>>>>>> appear on Android.
>>>>>>
>>>>>> Again, I'm not following.  If you have an Andriod app, how does that get
>>>>>> an ePaper display?
>>>>>>
>>>>> It's quite possible to get an Android device with an ePaper display, I
>>>>> have one and it's pretty good at what it does.
>>>>>
>>>>> Take a look at the Icarus readers, the E653 in particular.
>>>>
>>>> How fast does it redraw the screen?
>>>>
>>> My guess would be somewhat less than 1 second though that's only
>>> subjective.  It does produce some strange effects with standard
>>> Android app animations but it mostly works pretty well.
>>
>> That is an e-paper display for sure then.  I'm surprised they included
>> this display in anything other than a book reader.  So much of what a
>> tablet or PDA does requires faster drawing times.
>>
>> Wait until you try to use it in cold weather.  They slow down a *lot*.
>>
> I'm rather unlikely to use it in the cold! :-)
>
> It's promoted mainly as an e-reader but with the advantage of being
> much more 'open' than the proprietary Kindle etc.  I bought it for its
> openness, it means I can read Amazon Kindle books *and* ePub books
> from my public library (and for that matter other proprietary formats).

I assume you can also run your own code on it?  I've never been clear on 
just how open Android devices really are.  I don't have one of my own, 
but maybe it is only the Android cell phones that aren't very open.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#9212

rickman <gnuarm@gmail.com> wrote:
> On 7/29/2015 4:21 PM, cl@isbd.net wrote:
> > rickman <gnuarm@gmail.com> wrote:
> >> On 7/29/2015 5:26 AM, cl@isbd.net wrote:
> >>> rickman <gnuarm@gmail.com> wrote:
> >>>> On 7/28/2015 10:02 AM, cl@isbd.net wrote:
> >>>>> rickman <gnuarm@gmail.com> wrote:
> >>>>>>>
> >>>>>>> LK8000, which I prefer, is probably heading for the RPi but may also
> >>>>>>> appear on Android.
> >>>>>>
> >>>>>> Again, I'm not following.  If you have an Andriod app, how does that get
> >>>>>> an ePaper display?
> >>>>>>
> >>>>> It's quite possible to get an Android device with an ePaper display, I
> >>>>> have one and it's pretty good at what it does.
> >>>>>
> >>>>> Take a look at the Icarus readers, the E653 in particular.
> >>>>
> >>>> How fast does it redraw the screen?
> >>>>
> >>> My guess would be somewhat less than 1 second though that's only
> >>> subjective.  It does produce some strange effects with standard
> >>> Android app animations but it mostly works pretty well.
> >>
> >> That is an e-paper display for sure then.  I'm surprised they included
> >> this display in anything other than a book reader.  So much of what a
> >> tablet or PDA does requires faster drawing times.
> >>
> >> Wait until you try to use it in cold weather.  They slow down a *lot*.
> >>
> > I'm rather unlikely to use it in the cold! :-)
> >
> > It's promoted mainly as an e-reader but with the advantage of being
> > much more 'open' than the proprietary Kindle etc.  I bought it for its
> > openness, it means I can read Amazon Kindle books *and* ePub books
> > from my public library (and for that matter other proprietary formats).
> 
> I assume you can also run your own code on it?  I've never been clear on 
> just how open Android devices really are.  I don't have one of my own, 
> but maybe it is only the Android cell phones that aren't very open.
> 
You'd have to root it, as delivered Android isn't open like a Linux
installation.  Android on a tablet is near enough the same as Android
on a smartphone, one of its advantages in a way.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#9213

cl@isbd.net <cl@isbd.net> wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 7/29/2015 4:21 PM, cl@isbd.net wrote:
>> > rickman <gnuarm@gmail.com> wrote:
>> >> On 7/29/2015 5:26 AM, cl@isbd.net wrote:
>> >>> rickman <gnuarm@gmail.com> wrote:
>> >>>> On 7/28/2015 10:02 AM, cl@isbd.net wrote:
>> >>>>> rickman <gnuarm@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>> LK8000, which I prefer, is probably heading for the RPi but may also
>> >>>>>>> appear on Android.
>> >>>>>>
>> >>>>>> Again, I'm not following.  If you have an Andriod app, how does that get
>> >>>>>> an ePaper display?
>> >>>>>>
>> >>>>> It's quite possible to get an Android device with an ePaper display, I
>> >>>>> have one and it's pretty good at what it does.
>> >>>>>
>> >>>>> Take a look at the Icarus readers, the E653 in particular.
>> >>>>
>> >>>> How fast does it redraw the screen?
>> >>>>
>> >>> My guess would be somewhat less than 1 second though that's only
>> >>> subjective.  It does produce some strange effects with standard
>> >>> Android app animations but it mostly works pretty well.
>> >>
>> >> That is an e-paper display for sure then.  I'm surprised they included
>> >> this display in anything other than a book reader.  So much of what a
>> >> tablet or PDA does requires faster drawing times.
>> >>
>> >> Wait until you try to use it in cold weather.  They slow down a *lot*.
>> >>
>> > I'm rather unlikely to use it in the cold! :-)
>> >
>> > It's promoted mainly as an e-reader but with the advantage of being
>> > much more 'open' than the proprietary Kindle etc.  I bought it for its
>> > openness, it means I can read Amazon Kindle books *and* ePub books
>> > from my public library (and for that matter other proprietary formats).
>> 
>> I assume you can also run your own code on it?  I've never been clear on 
>> just how open Android devices really are.  I don't have one of my own, 
>> but maybe it is only the Android cell phones that aren't very open.
>> 
> You'd have to root it, as delivered Android isn't open like a Linux
> installation.  Android on a tablet is near enough the same as Android
> on a smartphone, one of its advantages in a way.

To install a user developed Android application, you don't need to root
it.  This is different from an iPhone.  An Android device can be configured
to install packages from .apk files or from user defined app stores.

Of course an Android application has no full control over the system, that
is where the rooting comes in.

[toc] | [prev] | [next] | [standalone]

#9214

On 30/07/15 10:23, cl@isbd.net wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 7/29/2015 4:21 PM, cl@isbd.net wrote:
>>> rickman <gnuarm@gmail.com> wrote:
>>>> On 7/29/2015 5:26 AM, cl@isbd.net wrote:
>>>>> rickman <gnuarm@gmail.com> wrote:
>>>>>> On 7/28/2015 10:02 AM, cl@isbd.net wrote:
>>>>>>> rickman <gnuarm@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> LK8000, which I prefer, is probably heading for the RPi but may also
>>>>>>>>> appear on Android.
>>>>>>>>
>>>>>>>> Again, I'm not following.  If you have an Andriod app, how does that get
>>>>>>>> an ePaper display?
>>>>>>>>
>>>>>>> It's quite possible to get an Android device with an ePaper display, I
>>>>>>> have one and it's pretty good at what it does.
>>>>>>>
>>>>>>> Take a look at the Icarus readers, the E653 in particular.
>>>>>>
>>>>>> How fast does it redraw the screen?
>>>>>>
>>>>> My guess would be somewhat less than 1 second though that's only
>>>>> subjective.  It does produce some strange effects with standard
>>>>> Android app animations but it mostly works pretty well.
>>>>
>>>> That is an e-paper display for sure then.  I'm surprised they included
>>>> this display in anything other than a book reader.  So much of what a
>>>> tablet or PDA does requires faster drawing times.
>>>>
>>>> Wait until you try to use it in cold weather.  They slow down a *lot*.
>>>>
>>> I'm rather unlikely to use it in the cold! :-)
>>>
>>> It's promoted mainly as an e-reader but with the advantage of being
>>> much more 'open' than the proprietary Kindle etc.  I bought it for its
>>> openness, it means I can read Amazon Kindle books *and* ePub books
>>> from my public library (and for that matter other proprietary formats).
>>
>> I assume you can also run your own code on it?  I've never been clear on
>> just how open Android devices really are.  I don't have one of my own,
>> but maybe it is only the Android cell phones that aren't very open.
>>
> You'd have to root it, as delivered Android isn't open like a Linux
> installation.  Android on a tablet is near enough the same as Android
> on a smartphone, one of its advantages in a way.

I run my own app on my Android phone. I compile the .apk file on my 
Linux PC using ant and then upload to the USB connected phone using adb.

The phone needs to have the developer options enabled, but that is a 
simple option and doesn't "root" Android in any way.

[toc] | [prev] | [next] | [standalone]

#9215

Dom <domafp@blueyonder.co.uk> wrote:
> On 30/07/15 10:23, cl@isbd.net wrote:
> > rickman <gnuarm@gmail.com> wrote:
> >> On 7/29/2015 4:21 PM, cl@isbd.net wrote:
> >>> rickman <gnuarm@gmail.com> wrote:
> >>>> On 7/29/2015 5:26 AM, cl@isbd.net wrote:
> >>>>> rickman <gnuarm@gmail.com> wrote:
> >>>>>> On 7/28/2015 10:02 AM, cl@isbd.net wrote:
> >>>>>>> rickman <gnuarm@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> LK8000, which I prefer, is probably heading for the RPi but may also
> >>>>>>>>> appear on Android.
> >>>>>>>>
> >>>>>>>> Again, I'm not following.  If you have an Andriod app, how does that get
> >>>>>>>> an ePaper display?
> >>>>>>>>
> >>>>>>> It's quite possible to get an Android device with an ePaper display, I
> >>>>>>> have one and it's pretty good at what it does.
> >>>>>>>
> >>>>>>> Take a look at the Icarus readers, the E653 in particular.
> >>>>>>
> >>>>>> How fast does it redraw the screen?
> >>>>>>
> >>>>> My guess would be somewhat less than 1 second though that's only
> >>>>> subjective.  It does produce some strange effects with standard
> >>>>> Android app animations but it mostly works pretty well.
> >>>>
> >>>> That is an e-paper display for sure then.  I'm surprised they included
> >>>> this display in anything other than a book reader.  So much of what a
> >>>> tablet or PDA does requires faster drawing times.
> >>>>
> >>>> Wait until you try to use it in cold weather.  They slow down a *lot*.
> >>>>
> >>> I'm rather unlikely to use it in the cold! :-)
> >>>
> >>> It's promoted mainly as an e-reader but with the advantage of being
> >>> much more 'open' than the proprietary Kindle etc.  I bought it for its
> >>> openness, it means I can read Amazon Kindle books *and* ePub books
> >>> from my public library (and for that matter other proprietary formats).
> >>
> >> I assume you can also run your own code on it?  I've never been clear on
> >> just how open Android devices really are.  I don't have one of my own,
> >> but maybe it is only the Android cell phones that aren't very open.
> >>
> > You'd have to root it, as delivered Android isn't open like a Linux
> > installation.  Android on a tablet is near enough the same as Android
> > on a smartphone, one of its advantages in a way.
> 
> I run my own app on my Android phone. I compile the .apk file on my 
> Linux PC using ant and then upload to the USB connected phone using adb.
> 
> The phone needs to have the developer options enabled, but that is a 
> simple option and doesn't "root" Android in any way.
> 
Yes, you're both quite right of course.  It's easy enough to install
an app you have written yourself on an unrooted Android device.  I was
rather thinking of doing the development on Android in the same way I
develop on Linux.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#8924

rickman <gnuarm@gmail.com> wrote:
> 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!

You didn't say the panel spoke SPI.  Is this it:
http://www.pervasivedisplays.com/LiteratureRetrieve.aspx?ID=214528
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?

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

That's probably a useful strategy.

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

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

[toc] | [prev] | [next] | [standalone]

#8927

On 6/19/2015 3:27 PM, Theo Markettos wrote:
> rickman <gnuarm@gmail.com> wrote:
>> 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!
>
> You didn't say the panel spoke SPI.  Is this it:
> http://www.pervasivedisplays.com/LiteratureRetrieve.aspx?ID=214528

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.


> 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 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 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.
>
> That's probably a useful strategy.

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.


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

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

[toc] | [prev] | [next] | [standalone]

#8925

On Fri, 19 Jun 2015 13:17:48 -0400, rickman wrote:

> On 6/19/2015 7:45 AM, Martin Gregorie wrote:
>> On Thu, 18 Jun 2015 21:36:17 -0400, rickman wrote:
>>
>>> Another one with just the touch screen.
>>>
>>> http://www.good-display.com/products_detail/&productId=301.html
>>
>> 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:
>>
>> http://www.gregorie.org/gliding/libelle/FLARM_panel.jpg
>>
>> My current PNA, the Medion S3747, is an almost identical size.
> 
> 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.

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       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.raspberry-pi

csiph-web