Light Phone 2


hm, i kinda like it for what it is. but i wish it had twice the battery capacity. usually the estimations of battery lifetime are off.

also interested in if there is the ability to write your own apps for it...

also, people could just buy a dumb phone. that's what i did. but e-ink is pretty sexy...

[edit]
couldn't help myself based on their marketing
AllTheThings.png
 
Last edited:
It's running android apparently, so signing your own apks should be possible - it really depends if they document what their screen interface is.

For me, it's disappointing they're running android along with all the android exploits that are around these days (although screen overlay attacks are going to be tricky given that screen, I suspect). And what was wrong with them updating the lightphone 1 to include these features; makes me suspect that for half of those extra features they promise you'll need to pay another $250 for a lightphone 3.

And I'm not keen on them saying they need a quarter of a million dollars and they still need a few extra million dollars in venture capital to make a profit. Maybe it's not a million miles away from the Pyra though, where ED needs to get orders for 3000+ Pyra to break even, coming in at some 2.1million euros by my calculations. At least they're being upfront about the money.
 
hm, i kinda like it for what it is. but i wish it had twice the battery capacity. usually the estimations of battery lifetime are off.

also interested in if there is the ability to write your own apps for it...

also, people could just buy a dumb phone. that's what i did. but e-ink is pretty sexy...

[edit]
couldn't help myself based on their marketing
View attachment 31553

Using your graphic...
I want the 'One Thing' to display and interact (touchscreen only) with the screen of my 'All the things' device while being a bluetooth handset and dialer.

A version with just e-ink and bluetooth (no mobile phone radios). The battery should last seemingly forever.
 
there is something very satisfying about the tactility of a thin card-like object. my hand wants to hold it.

i could be sold on your vision, @Grench, as a companion to the pyra, with openness of course. for some reason i want a calculator on it.
 
I am with Grench because I will probably never get my perfect tablet/e-reader unless I do it myself.

Not all that fond of Android on it, but could be worse. I will pass for now.
 
there is something very satisfying about the tactility of a thin card-like object. my hand wants to hold it.

i could be sold on your vision, @Grench, as a companion to the pyra, with openness of course. for some reason i want a calculator on it.

Since my vision device would mimic the screen on the host device - any touchscreen capable calculator you have on your phone/pyra/laptop (whatever bluetooth host that can drive ~2 fps black & white or 16 gray scale) would be available on the device.

The device itself only has to be smart enough to connect to and communicate with the host. The host side is where this idea would get complicated. It would require an application to recognize the relatively dumb e-ink card-like handset. Getting the host side to work and send the requisite data to - and accept data from - the device... that is the harder part of things. Ideally the host device would switch it's desktop to scale to and be whatever the e-ink display is so there is no interpolation needed.

They only make e-ink / epaper displays in a limited set of sizes and resolutions...
Finding what those sizes are was pretty much impossible on the eink website. But - Wikipedia saves the day.
https://en.wikipedia.org/wiki/E_Ink
I think ED043WC3 or ET047TC1 would work best? 4.3" 800x480 OR 4.7" 960x540?

The 4.7" screen would be a device dimension of roughly 65mm by 120mm by (1.5mm case + 2.5mm battery + 1mm screen +2mm board & features) 7mm thick.

Would the bluetooth handset / dialer / touchscreen device need a 3.5mm headphone jack and the implied amplifier circuitry?
 
i'd say no to a headphone jack on the dialer, unless you want to be able to play music off of it or something -- but then it becomes a more standalone device. i wouldn't have it replicate what's on the main screen, however. i'd just make a few apps possible (mini e-reader, served from books on the main computer, calculator, dialer, etc.).
 
Yeah, I don't see how mirroring the screen would work. Does that mean the handheld unit would need to be the same shape and orientation as the main screen? And when the main screen is showing a windowed interface, would that really work all that well on an e-paper screen?
 
I get where Grench is coming from, and think his implementation would be simpler and easier. If anyone here has the skills to make this device so the above mentioned options instead maybe we should get started on it.
 
i'd say no to a headphone jack on the dialer, unless you want to be able to play music off of it or something -- but then it becomes a more standalone device. i wouldn't have it replicate what's on the main screen, however. i'd just make a few apps possible (mini e-reader, served from books on the main computer, calculator, dialer, etc.).

Headphone jack idea is to be able to support wired headsets/headphones - music/phone/mic audio would still transmit/receive via bluetooth from the host computer/phone/tablet/Pyra. No substantive memory on the device itself. Hypothetically the audio portion could be audiophile levels via a headphone jack and a high end DAC - would raise the costs of the device a bit.

Replicate what is on the host's screen and then there is no need for any on-device apps - just the connection & control & display stacks.

The one on-device app-exception that might be required is a numeric dialer - though that could be done by click-opening the dialer on the host computer/phone/tablet/Pyra and remote-pushing it's 'buttons' on the device's touch screen.

Yeah, I don't see how mirroring the screen would work. Does that mean the handheld unit would need to be the same shape and orientation as the main screen? And when the main screen is showing a windowed interface, would that really work all that well on an e-paper screen?

All of the processing takes place on the host device. Effectively the host-side application would take a screen shot of what would have been on the host's display if it were on, host scales that image to match device screen and converts to 16 grey scale. That now tiny little image file is transmitted from the host to the device. If it can do >=1 fps that is a success.

For this purpose, we don't really care whether the item on the host is windowed or if it's colors convert right or any of that - just that it shows up at all. To change how they appear - change what is going on at the host, not the device. The device is a very slow to refresh 'dumb monitor' with a touchscreen overlay that acts as a 'bluetooth mouse touch pad' (easiest to implement and eliminates the need to sync absolute x,y coordinates). It would also have bluetooth audio for voice communications.

I get where Grench is coming from, and think his implementation would be simpler and easier. If anyone here has the skills to make this device so the above mentioned options instead maybe we should get started on it.

So far this is just an idea. I don't have the time, facilities or connections to do it. I do think that the hardware needs to be kept as simple and app free as possible. It isn't meant to replace the host device. It is just meant to be a handy and very low power remote interface to the host device's storage, processing and communications capability.
 
Yeah, but I don't want a 16 colour greyscale view of what's on my Pandora screen at present, and will theoretically be on my Pyra screen. I support apps writing to a specific framebuffer that's designed for the target screen, even though that would be a little more work to get something working.
 
Yeah, but I don't want a 16 colour greyscale view of what's on my Pandora screen at present, and will theoretically be on my Pyra screen. I support apps writing to a specific framebuffer that's designed for the target screen, even though that would be a little more work to get something working.

The drawback to that approach is compatibility would be programming/changes app by app within the device. The advantage is that apps that do address it directly would suck less. We're still not talking about speeds to impress or play games by, though. For the most part it is just enough information to be able to tell what your phone is doing and to tell it to do something else.

Just doing it by screen captures would be programming/changes OS by OS or at worst device by device. Yes, <=1 FPS based on screen captures scaled & converted to 16 shades of gray has it's limitations - but those limitations nearly match the limitations of the e-ink display.

How about this - do both.
Device connects to host via Bluetooth (security through code of 4 to 128 user chosen numerics input on both used as seed).
User needs to install an app on the host. The app would have two modes of operation. Default would be screen captures. However, have a handle for apps to engage with that allows the foreground application to directly address the on-host frame buffer for the handset device. This way the device is usable regardless of the application - but room is left for applications to be optimized to work with it.

Envisioning the hardware of this is the relatively easy part. The software... I wonder if this could even be done to an Android host without rooting. It would have to bypass the host's security screen after all and run with the host screen turned off. Getting it to work on the Pyra would conceivably be easier (less restrictive OS), but then we're talking about a niche of a niche population - not big enough sales to create molds for. It would need iOS, Android, Debian & Sailfish host apps, and the permissions requirements could be a bit rough.
[doublepost=1520014605,1520014363][/doublepost]Clearly we've gone down a rabbit hole and figured out we want something in the form-facctor of the, "Light Phone 2", but we want a different software stack - and no cell phone radios - and maybe an audiophile grade DAC and amplifier with a headphone jack ...

But the screen type & form factor for a handset/dialer - Light Phone 2 has that nailed nicely.
 
i still think it's better to do apps. one such app would be displaying things from the main screen. do something with an esp32 and make it hackable. i like the idea of this dialer in my pocket and the pyra in my backpack.

i'm all for a headphone jack, but then why have the light-blue-tooth in the first place over a headphone jack into your pyra?
 
i still think it's better to do apps. one such app would be displaying things from the main screen. do something with an esp32 and make it hackable. i like the idea of this dialer in my pocket and the pyra in my backpack.

i'm all for a headphone jack, but then why have the light-blue-tooth in the first place over a headphone jack into your pyra?

The concept of having an audio jack on it - Not just a device for the Pyra. Usable to get a more solid DAC and amplifier behind a high quality set of headphones on any bluetooth enabled host device regardless of whether the host device has an audio jack or not. I.e. the audio quality (and quantity) through the 'device' would potentially be higher than gets included on most consumer phones or stand alone consumer bluetooth headphones.
 
But the audio first has to go through bluetooth to get to the device which then amplifies a necessarily compressed audio stream into your wired headphones. Unless you've got much better headphones with a 3.5mm plug on 'em than you've got bluetooth ones then I'd expect the audio quality to be limited by the bluetooth codec.

Not that I have a problem with bluetooth quality normally, I have more of a problem with audio delay versus video, but with this not being a video device, that's probably not a problem. But for your real hifi nerd, I don't see the benefit.
 
Back
Top