x
This website is using cookies. We use cookies to ensure that we give you the best experience on our website. More info. That's Fine
HPC:Factor Logo 
 
Latest Forum Activity

Printing a handheld PC

Moderators: C:Amie

Jump to page : First : Prev : ... 4 5 6 7 8 9 [10] Last
Now viewing page 10 [15 messages per page]

robertojones Page Icon Posted 2020-01-15 9:50 AM
#
Avatar image of robertojones
Factorite (Junior)

Posts:
43
Location:
United Kingdom
Status:
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.





(20200109_092525.jpg)



Attachments
----------------
Attachments 20200109_092525.jpg (98KB - 0 downloads)
 Top of the page
_dev-null Page Icon Posted 2020-01-15 11:27 AM
#
Avatar image of _dev-null
Subscribers
Factorite (Junior)

Posts:
26
Location:
Austria
Status:
Hi!
Very nice project. I love your work!


Stefan
 Top of the page
stingraze Page Icon Posted 2020-01-15 12:19 PM
#
Avatar image of stingraze
Writing Team
H/PC Elder

Posts:
2,302
Location:
Japan
Status:
Very nice!
 Top of the page
C:Amie Page Icon Posted 2020-01-15 12:39 PM
#
Avatar image of C:Amie
Administrator
H/PC Oracle

Posts:
15,081
Location:
Fields End, UK
Status:
It's looking great, excellent work.

Wait! I know that website!
 Top of the page
ArchiMark Page Icon Posted 2020-01-15 2:48 PM
#
Avatar image of ArchiMark
Subscribers
H/PC Philosopher

Posts:
262
Location:
Silicon Valley
Status:
Looking good...

I'll take two....


 Top of the page
robertojones Page Icon Posted 2020-01-15 4:56 PM
#
Avatar image of robertojones
Factorite (Junior)

Posts:
43
Location:
United Kingdom
Status:
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.
 Top of the page
OmniCore Page Icon Posted 2020-01-27 5:35 PM
#
Avatar image of OmniCore
H/PC Newbie

Posts:
3
Status:
Thats impressive Im looking forward to see how it works out!
 Top of the page
robertojones Page Icon Posted 2020-01-30 11:37 PM
#
Avatar image of robertojones
Factorite (Junior)

Posts:
43
Location:
United Kingdom
Status:
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!



 Top of the page
C:Amie Page Icon Posted 2020-01-31 9:21 AM
#
Avatar image of C:Amie
Administrator
H/PC Oracle

Posts:
15,081
Location:
Fields End, UK
Status:
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?
 Top of the page
robertojones Page Icon Posted 2020-01-31 10:31 PM
#
Avatar image of robertojones
Factorite (Junior)

Posts:
43
Location:
United Kingdom
Status:
Quote
C:Amie - 2020-01-31 9:21 AM

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.
 Top of the page
C:Amie Page Icon Posted 2020-02-01 8:31 AM
#
Avatar image of C:Amie
Administrator
H/PC Oracle

Posts:
15,081
Location:
Fields End, UK
Status:
Ah, sounds like you've got it covered on that front then.
 Top of the page
robertojones Page Icon Posted 2020-02-05 11:06 PM
#
Avatar image of robertojones
Factorite (Junior)

Posts:
43
Location:
United Kingdom
Status:
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!

 Top of the page
hpc:factor« View previous thread · Handheld PC General Discussion · View next thread »

Jump to page : First : Prev : ... 4 5 6 7 8 9 [10] Last
Now viewing page 10 [15 messages per page]

Jump to forum:
Seconds to generate: 0.125 - Cached queries : 65 - Executed queries : 12
Server Time now is: Tuesday, 18 February 2020 - 6:18