zlacker

>>asimop+(OP)
I want a thick clunky device without a screen that can run for 4-7 days without charging. Then i want 1) a normal size device, 2) a tiny one and 3) a tablet. These should be terminals, little more than a screen, a battery and some radio to communicate with the herefore mentioned brick that does all of the heavy lifting. It needs only 20-30 meter range. The brick may also feature a webserver captive portal with public bluetooth and wifi access.

>>theend+Ig
Except that the screen and the radio are 80% of power usage, so this doesn't help anything. For what most people do with their laptop/tablet/phone, the little bursts of CPU are effectively "free" — increasingly cheap with each process shrink! — while the IO is as expensive as ever.

>>derefr+Mh
What fun comment. You are mistaken in so many ways :)

When idle GSM uses a lot of power. Listening for a wakeup signal doesnt seem expensive at all. It even seems one could pull off the trick for free.

Free < bluetooth < wifi < gsm

There shall be e-paper ofc

The brick can have a battery like that of a quality powerbank. For emergency charging the display snaps on top with some magnets.

There will be heavy cpu loads with lots of reads and writes.

Think a room full of people hammering the media server.

Host websites on it. Imagine the fun!

GPUs may work quite hard to decode and fit the picture on the screen. How to do io better is left as an exersize for the reader. (这意味着你)

Whatever components we can get rid of buys extra space for the battery.

It also makes the handheld device cheaper to replace.

You may swap the battery or have a spare.(slide the empty one into the brick)

You may also break or lose it. It can conveniently be replaced. Nothing important is stored on it.

Lets make them with and without cameras. Imagine the opportunity to not make photos :)

>>theend+Av
To be clear, I meant that, when running your average (i.e. mostly-idle, not-very-graphically-intense, yet smoothly-animated) interactive-UI application, with the CPU+GPU module needing to stream vaguely-realtime updates wirelessly over to the display module, the display module would end up using nearly as much battery to receive and display the updates as the CPU+GPU module would be taking to generate and send them. It would be a negligible cost for the display module to just do the rendering itself.

Playing games or using the CPU+GPU module as a media server is a 1%-of-the-time use-case. If you want this architecture to not need a lot of battery in the display module, it needs to be low-power for the 99%-of-the-time use-case: scrolling a webpage.

(This is basically the classical thin-client / fat-client paradox: thin clients save on power right until you want them to do anything continuously. Then the IO costs outweigh the hypothetical costs of localizing that continuous CPU/GPU activity by pushing it down into a fat client.)