Printing a handheld PC

Quick update on my machine:

It's largely complete, as you can see from the photo below. Distortion is from the photo, it actually looks a fair bit better in real life.

As expected I'd miscalculated a few dimensions and will have to re-print a few parts. My main focus has been on getting the internals working though. So far I've managed:

- Screen brightness control (via PWM on the backlight).

- Getting the trackball working by essentially writing a crude driver in Python. Sadly I very soon after broke the trackball mechanism so I have to wait on a replacement now.

- Battery level indicator - Turned out someone else had already written one that works with my battery charging board so no credit to me here.







Attachments
----------------
20200109_092525.jpg (98KB - 0 downloads)

Hi!
Very nice project. I love your work!


Stefan

Very nice!

It's looking great, excellent work.

Wait! I know that website!

Looking good...

I'll take two....

Thank you, everyone! Your encouragement means a lot.

I'll get some better photos up once I've cleaned it up a bit and added the final cosmetic bits, meant to mention that the screw holes in the lid are recessed slightly so that I can fit little plastic 'blanks' over them. The only visible screw heads will then be on the underside of the base. Should look a bit less like a prototype that way.

I have played with it quite a bit in its current form (did all the programming so far on the device itself), it's definitely an improvement over the first prototype - it feels a lot nicer in the hands but also better balanced. Good to know all the design work paid off - in the end there are no printed parts used unmodified from the first prototype.

Next thing to do is rewrite my little 'sleep mode' program to work on the Pi 4 - it won't feel like a HPC to me until it has 'instant on' type functionality.

Thats impressive Im looking forward to see how it works out!

Small update:

I've been battling with the Raspberry Pi 4's power consumption pretty much daily since my last post. It certainly represents a big jump in processing power vs. previous Raspberry Pis, to the point where for basic tasks it's not noticeably slower than my desktop PC, but along with this this has come a significant increase in power used.

Anyone interested in the Pi 4 probably knows of the heat issues it has had - I'm pleased to say that the latest firmware update reduces this to almost a non-issue, even for my application - basically a torture test - a cramped unvented space with two other heat sources (battery and charging board). Nevertheless I've designed in some inconspicuous vents for the next iteration of the case.

Power usage has so far been quite the battle however - I had hoped the firmware update would help reduce idle power consumption as much as it had under load, but sadly it is still fairly high. Turning off USB, Wifi, Bluetooth and Ethernet gets me to about 10 hours of 'sleep' with my battery - still a long way to go until I'm happy.

Whilst getting increasingly frustrated and searching again to see if anything close to a proper 'suspend' mode was plausible on the Pi I stumbled across 'suspend-to-idle', a kind of pseudo-suspend that works entirely in software and therefore could potentially work on something like the Pi that has no hardware/firmware suspend modes available. For those unaware (like me until very recently), suspend-to-idle, as I understand it, works as follows:
1. Freeze all processes that allow freezing.
2. Put all peripheral devices (internal and external) into low-power / suspend modes, where possible.
3. CPU(s) can idle in lowest power mode possible, with minimal interruptions.
Suspend-to-idle is present in the Linux kernel (and has been for the last few years, it seems), but is not by default enabled on the kernel provided with Raspbian. With a bit of fiddling (and my first kernel build) I got it enabled. When I issued the command the Pi froze. A bit of investigation reveals it can get to the point where it has frozen all processes and reliably resume, so it seems I have a problem somewhere in the 'suspending devices' stage of the process. Finding the guilty device(s) is likely to be quite time-consuming and given that I'm already able to manually turn off the most power-consuming devices I'm not sure how much power this will actually save in the case of this machine. I'll leave this one for later I think.

Freezing processes, however, seems to have more promise. I'm currently working to see if I can separate out the 'freeze processes' command and issue it on its own from my 'sleep' program. Failing that I can have a look at which processes are the worst offenders in terms of interrupts to the CPU and freeze those individually (already know how to do that). I'll be interested to see how much benefit I get from this.

All in all I'm getting far deeper into the software side of things than I intended, likely to be a slow and clumsy process as I have no background in this field whatsoever. Interesting stuff though!

Can you perform dynamic under clocking of the CPU with the Pi 4? On older models it could be done, but via the boot config. You could add an activity watchdog to under clock it when it's not under load perhaps?

The Pi 4 by default drops the CPU and GPU clocks when it's idle (or under light load), so if I'm understanding you correctly it's basically doing this for me already. The new firmware also has it drop CPU voltage, which is where I believe the bulk of the reduction in heat is coming from. With the config file I'm able to set the minimum (ie idle) clock speeds for both, I would guess that there's not much in the way of power savings to be gained vs. the default values but I'll attach my little power meter and have a go with different values.

Ah, sounds like you've got it covered on that front then.

Another small quite lengthy update:

I've been playing with freezing processes (crudely) and got this to work reasonably well. I was able to make quite a difference by freezing all the user's processes. Prior to this the battery would drain faster if more programs were running, even if left idle. Sadly not a great deal of difference vs. just left at the desktop with nothing running, however. I tried freezing root processes as well (minus a few key ones) and found it was running hotter. Probably some interaction where one processes is trying to speak to another and not finding it. It also resulted in a 'wake' time of about 30 seconds before I could turn the screen back on. Nowhere near 'instant-on', and I can probably boot the Pi from cold in less time. This could probably be improved by better programming of the wake-up routine, however I'd have to find the misbehaving processes before I could justify this.

Disappointingly, none of this resulted in a significant increase in battery life, and I am still nowhere near to getting a day in 'sleep' mode. I get a little over 2 hours in 'active' use. I believe any further improvements I can make will be incremental, and the only real option remaining would be to throw a bigger battery at the problem. Given how far short of target times I'm falling, we're probably talking double the capacity - For me an unacceptable increase in bulk and weight.

The fundamental problems all lie with the Raspberry Pi. It's a wonderful product in many ways, and I am happily running one as a 'local cloud server' for my parents (in service for over 5 years), and one here as a mini-server running and monitoring my 3D printer. In these applications, I could not fault it. However, it was never really intended to be run on batteries (except maybe for the Pi Zero) and this is readily admitted by the team behind it. It shows in a number of ways:
1. All versions of the Pi have been based on SoCs designed (originally) for set-top boxes and as such are not optimised for power efficiency. They expect to be plugged in most of the time (as most Pis are). They also boot on the GPU and the GPU cannot be turned off or put to sleep.
2. Each mainstream version of the Pi has consumed more power than its predecessor. Understandable as performance and features have increased each time. In my experimentation I have never been able to get less than about 350mA current draw (in my 'sleep' mode) for the Pi 4, vs. <200mA for the 3B+.
3. There is no sort of suspend / sleep mode implemented in the hardware or firmware. Not even 'suspend-to-idle' works, which would basically be a software matter. If my experiences are anything to go by, probably at least partially because it's unlikely to offer much in the way of power savings.

With quite a heavy heart I have now decided to move away from the Pi as the 'brains' of this machine. I've spent too much time battling with the Pi, trying to get it to do something it was never intended for. In the end I was faced with having to give up so much of the original idea that it would no longer be something that could be put in the same category as a HPC. A Linux-only mini-netbook, perhaps - not something I'm much interested in. What was especially bothersome is a kind of anxiety it gave me using it away from a power socket for any length of time - I found the HPC experience to be almost the opposite of this. I don't imagine too many people would welcome a device of this size that has to be managed like a 15" laptop.

I've decided to start experimenting with the Pine A64 (LTS version) - example here: . It does come with some downsides, all of which (to varying degrees) are reasons I originally went with the Pi:
- It's less powerful than the Pi 4 - Closer to a Pi 3 but with the option of 2GB RAM.
- It's quite a bit bigger than the Pi - Probably twice the board area.
- It doesn't have anything like the Pi's level of software support or anything like the size of community.
- Wireless card is an additional module, at extra cost.
- If I want to try and sell (a few units of) the finished product, it lacks some of the appeal of a Raspberry Pi based product.
However, it offers the following advantages for this application:
+ On-board battery management and communication of battery data at kernel level (mitigates size - no extra board required).
+ Tablet-derived SoC is capable of proper suspend modes, and draws significantly less power flat out than the Pi.
+ Of the many Pi rivals, it's one of the older ones, and has what appears to be quite a successful and innovative company behind it.
+ It supports eMMCs for faster onboard storage.
I've ordered one (with the add-on wireless card) and I'll start testing as soon as it arrives. I'll thoroughly test it on the bench before I do much redesign work. In any case I can keep the lid and hinge design as-is, and modifications to the base shouldn't be too drastic. Assuming test results justify this of course!

Small update as promised:

In my previous post I mentioned that I'd decided to change to using the Pine64 as the 'brains' of my machine, the redesign and prep work is now well under way. I've also gone with the LCD provided by the makers of the Pine64 - this has now arrived, enabling me to test it and get its dimensions for CAD modelling.

Observations from testing:
- Pine64 OS support is a lot more patchy than for the Raspberry Pi and almost entirely community-driven, so far Armbian seems the best bet but I do want to have a bit of a play with Android. Decent variety of options though.
- The Pine64 runs very cool compared to the Pi 4 or 3, and consumes far less power. Performance does seem about on a par with the Pi 3 - for a HPC-sized device I believe this will be acceptable, though more power is always nice.
- The LCD is far lighter than my previous one, and roughly half the thickness as it does not have a HDMI conversion board on the back of it, nor a HDMI socket. Not as plug-and-play as a HDMI screen though. Still 7", 1024 x 600 resolution, capacitative touch and decently bright. Brightness control should be possible at OS level.

Physical changes to the machine (due to new parts):
- Footprint is unchanged at 230mm x 130mm (approx 9.1" x 5.1"). May be possible to lose a few mm in each direction but not a priority for now.
- Thickness reduced to 27.5mm (1.1"). Reduction all in the lid - Was hoping I might be able to get down to 1" total thickness but not quite.
- Estimated weight savings somewhere in the region of 50 - 100g, I'll weigh the bits and get a total weight estimate. Crucially most of this is in the display module so the lid hinges will have an easier time, and the machine should handle better (not that prototype Mk2 was bad in that respect.)
- No lid 'bump', cleaner lines on lid and base part of casing.

Photos (in order):
- Main components being tested
- Front and rear views of model - more work to do on fixings but external details should not change much.










Attachments
----------------
IMG_20200412_1812260.jpg (68KB - 0 downloads)
HPC Mk3.JPG (53KB - 0 downloads)
HPC Mk3 Rear.JPG (30KB - 0 downloads)

Excellent. Wish I could do what you're doing. Keep it up!

Your device looks like a Sony Vaio P, one of my favorite handhelds of all time. I still have one hidden in a drawer, the Japanese version that came with SSD instead of HDD