Close
0%
0%

PotatoP

A LISP-programmable laptop with battery life measured in years

Public Chat
Similar projects worth following
I got annoyed with my personal laptop always being out of battery when I wanted to work on my small programming projects, so I am building myself a laptop form factor device. It currently has an estimated battery life of up to 2 years depending on ambient light (with a 12000 mAh li-po battery), but I am hoping to eventually make it powered by ambient light alone.

It needs to have a good keyboard and a decent programming environment - compatability with existing software is not a priority, nor is powerful hardware - just the minimum required for a LISP environment. Writing a minimal editor, word processor, spreadsheet app or whatever else I want will be part of the fun!

My current working prototype is based on the Sparkfun Artemis module, running uLisp; and using a monochrome 4.4" Sharp Memory Display.

I'm happy to talk about my project. Ask me anything!

Why PotatoP?

  • The word "Potato" is often used to describe an underpowered/poorly performing device. "This video must have been filmed with a potato!" This device is intentionally underspecced to ensure long battery life.
  • The "toP" suffix refers to the intended eventual laptop form factor
  • The suffix "p" is used for LISP predicates - functions that return true or false, like "evenp" or "primep" for numbers. Is it a potato or not? It depends on your point of view!
  • It lets me call the OS PotatOS! (Or maybe I won't after all, it seems to have been taken by another very cool project)

This project is heavily inspired by Technoblogy's super cool Lisp Badge, the Lisperati 1000, the Open Source Autarkic Laptop and ei2030 working groups, the playdate, various projects featured on r/cyberDeck and lots of other cool stuff I forgot about already!

PotatoP.pdf

Schematic for the current prototype

Adobe Portable Document Format - 127.61 kB - 03/19/2023 at 15:52

Preview
Download

  • 1 × Sharp Memory in Pixel display LS044Q7DH01 I wish they sold a bigger one. But this is surprisingly readable, especially in good light
  • 1 × SparkFun RedBoard Artemis ATP This is the development board that serves as the "motherboard" of my laptop. The Ambiq Apollo3 CPU is the reason it can execute code while using so little power.
  • 1 × Adafruit SHARP Memory Display Breakout - 2.7" 400x240 Monochrome I don't use the display attached to this as I found it too small for a "laptop" form factor. It might be great for a hand-held incarnation of this project.
  • 1 × AEMLION by Jasper Sikken Solar battery charger and power supply. I want to replace this with their AEMLIC and the battery with a Li-ion Capacitor.
  • 1 × Happy Hacking Keyboard Lite 2 An old keyboard which was sacrificed for this project, as I wanted direct access to the keyboard matrix. I really like the layout.

View all 11 components

  • Schematic and CADs

    Andreas Eriksen03/19/2023 at 16:42 1 comment

    Since the last update, I've downloaded KiCad and learned enough(?) to create a basic schematic for the project, which you can now find under the "files" section!

    I had to make my own symbols, I guess it's unusual to make a schematic for development boards wired together like this. But still it should be enough to be able to convey how it's all connected.

    I've also made my WIP, learn-as-I-go style TinkerCAD designs for the case and screen holder public:

    https://www.tinkercad.com/things/igAFacjZWDP

    https://www.tinkercad.com/things/jHrsHk9PIVb

    The bottom and top need to be printed in two parts to fit on my 3D printer bed - which makes me wish I had a bigger one ...I would definitely recommend printing the screen holder as the flex cables for the screen is fragile and won't survive long unprotected (at least on my desk, which is a mess where things get pushed around frequently).

    I've tried bringing the current version of the PotatoP around with me in my backpack, which has confirmed two things:

    The first: It's fun to bring it around with me to show off and hack on, and I wish I could do it all the time.

    The second: It's currently too fragile for me to actually do that. Wires keep getting disconnected, the case pops apart, the keyboard shifts out of position and stops working until I disassemble and reassemble it. It's also pretty thick, taking up most of the space in my backpack when I do bring it, and as it doesn't have a proper hinge for the screen, I have to carefully and separately pack the screen and hook it up each time.

    So my current priority is to keep teaching myself more KiCad, and design a PCB with all the necessary components such as the stand-alone Artemis module, but also possibly a (separate?) custom mechanical keyboard PCB with a similar layout - and a new, much smaller and slimmer 3D printable case for it all.

    This should make the project much smaller, more robust, and much easier to reproduce as you won't need to source and dismember a very specific and somewhat rare keyboard to build it. It should also make it a lot cheaper to make one. It might even be possible to have produced a pre-assembled PCB with all or most of the necessary components already soldered on.

    I have hope that even starting from 0, it shouldn't be too hard, as all the breakout/development boards in the project are open-source designs that can be mashed-up into a combined PCB. For now, I'm experimenting with smaller and simpler projects such as the DigiSpark from this nice Youtube KiCad 7 tutorial, and waiting to see if that project ends up working before making something more complicated. :-)

    I'd love to hear your suggestions for what such a design should be like: should I break out a GPIO section for the unused pins? Should it use a lithium-ion-capacitor instead of a battery? Or perhaps replaceable (rechargeable) AA batteries? Should I add a tweeter for basic sound output?

  • Going viral and miscellaneous

    Andreas Eriksen03/11/2023 at 00:41 0 comments

    Going viral

    I did two things since the last project log that had a much bigger impact than I expected.

    First, I uploaded a short video to Youtube in which I add a tiny new feature to my text editor. I made this to be shared on the uLisp forum, as a quick demo for anyone particularly interested.

    This highly compelling movie consists of 3 minutes of typing mistakes, several long pauses of nothingness where I count the number of closing parenthesis to type out, set to a soundtrack of a clacking keyboard and labored breathing. With an interlude of forgetting what the key code was, right after checking it, and then checking it again.

    The second thing I did was to submit my project to the 2023 Hackaday.io Low-Power Challenge, after which hackaday.com wrote an article about it - and on my birthday! It got some attention, and went viral enough to be picked up by a humbling number of other tech writers, among them a hackster.com article. That article was submitted in a Hacker News post which was voted to the top of the front page for quite a few hours.

    I got very excited and spent hours refreshing HN, reddit and youtube to answer comments and questions, during the time I should have been sleeping before the next day of work. If I didn't reply to your comment (there or elsewhere), apologies.

    That the video I made would get 14 000+ views was unexpected - 230 hours of probably innocent peoples lives have been spent watching it - and if I had known, I would have put in more effort. It might have helped.

    To conclude, I am very happy to see that so many are interested in my hobby project! And several people have approached me to offer assistance, which I greatly appreciate. I am really hoping this will speed along work on the project.

    Running an UXN rom
    Running the "primes" program from the UXN source distribution while measuring power usage
    Power measurement while running UXN rom
    Power measurement while running UXN rom - this is with the cpu at 100% and each discovered prime printed to the display (in hex).

    Some actual miscellaneous project updates

    It's been a long time since the previous project log. I haven't really worked on it as much since then, as I'm trying to get other commitments out of the way first. Here's what I can remember doing:

    • I fixed the bug where holding down the arrow keys would greatly increase power consumption. As a bonus, the keyboard scanning code is also much faster now, although still a bit of a mess.
    • I rewired power to the SD card through some particular special function GPIO pads on the Apollo3. This allows me to completely turn off power to it when it's not being used, which helps a lot. I got a hopefully lower power storage module in the mail but have not tested it yet.
      • This brought max observed average power consumption down to 2mA, which is how I ended up claiming 2 years of battery life.
    • I published the source code to https://github.com/andreer/PotatoP - it's somewhat incomplete as there are also bug fixes and optimizations to the Artemis Arduino core and the Adafruit GFX / Sharp Memory Display libraries which I have not yet published. Don't know how best to - I'll get to it.
    • I put up a list of components on this project page, which should include all the materials needed to replicate this project.
      • I will need to publish a schematic and 3D printing files too. It's not just a matter of uploading existing files, as what I have was cobbled together haphazardly over a long period, and I didn't take notes.
    • I rewrote the text editor to use a list-of-strings data structure. It's not perfect, but editing latency - the delay from my finger touching the key to when the display has finished displaying a new character - is now down to 40ms for reasonably sized files, measured by counting frames from the 240fps slo-mo mode on my iPhone. Compare with danluu's excellent summary of input latency.
      • I can now edit files of up...
    Read more »

  • Snake!

    Andreas Eriksen02/10/2023 at 23:20 0 comments

    Thankfully, I quickly found a workaround for the (second) SPI bug I complained about last time, so now I have a working setup with both a display and SD card!

    That means I can now _really_ write code on the laptop it self - being able to save to the SD card is very useful - and I managed to hack up a passable version of Snake pretty quickly. No (other) computer involved, programmed exclusively on the PotatoP, using the built-in documentation in the latest version of uLisp for reference! I even hooked up a little speaker to some GPIO pins to make some clicks and bleeps for the game.

    The size of the screen is surprisingly OK, the text is very clearly readable at the default 5x7 font size as long as there is decent light. And 53 characters is wide enough that it seems I can get used to it - I should refactor my code into smaller units anyway :-). The editor is still a bit slow when editing more than a screenful of text, but moving to a better data structure than "just a big string" is likely to help.

    I also splurged on a few more items; most importantly a Nordic Semiconductor Power Profiler Kit II. I've also received another solar controller board by Jasper Sikken, this one using supercapacitors instead of a battery for energy storage. I really want to see if I can make this work well enough instead of a battery, as it has a lot of advantages - such as no toxic materials or worries about degrading battery chemistry.

    Of course I had to unpack and test the power profiler - and wow, this is certainly much better than trying to peep at a multimeter. As I suspected there are some current  spikes, and it quickly becomes clear that there is still much room for improvement, but it's not as bad as I feared. power use at "idle" in the editor or uLisp REPL is currently at 2.64mW, and while running uLisp code to draw a fractal while updating the screen, it's 5mW.

    Unfortunately, even when at idle, holding down all the arrow keys makes power jump up to 16.4 mW. So surprisingly, the greatest source of power consumption is the keyboard scanning - hopefully due to some simple-to-fix misconfiguration of the GPIO. My no-name second hand SD card also sucks down another 30mW once it's been initialized, but according to the datasheet the one I have ordered from Adafruit should do a lot better. So I still have hope to get the active power consumption below 6mW, and much closer to 0 at idle, once I get all that worked out.

    Some concessions to usability must come first though - I need to redesign the editor to handle larger files, as well as add some very basic features like key repeat, faster scrolling, selecting text, copy/paste and so on. My library of lisp functions and little toys and experiments is growing quickly and is becoming unmanageable with the current version!

  • Working editor and data storage

    Andreas Eriksen02/05/2023 at 05:12 0 comments

    I'm happy to report that moving the keyboard scanning code into uLisp went well! Initially I got some corruption on the display, but this was later fixed by disabling the keyboard interrupt while updating the screen. I also slightly rewired the keyboard to free up another SPI interface. More on that later ...

    A simple text editor and REPL

    It didn't take me too long to write a basic text editor in uLisp - working name "Typo". For now, it's very naive code and starts working poorly after about a screenful of text, so some optimizations along the lines of emacs's "redisplay" will eventually be required. But I can type and edit interactively on the PotatoP, with support for such niceties as the backspace key to undo my mistakes and arrow keys to move around :-)

    So based on that I now have a basic working REPL, and it is suddenly possible to do further development work on the editor/REPL from the PotatoP itself. In celebration, I've tweaked the prototype display protector and reprinted it in glorious yellow:

    Demo of working REPL
    Planned future work on this prototype includes replacing the damaged display, adding a second display for side-by-side coding and graphics, and removing cat hair from the keyboard

    Error handling

    At first though, usage was severely hampered by the lack of error checking. If there was any problem at all in the code I input, the REPL crashed and had to be restarted from the serial console. Fortunately I came across an uLisp forum post where Goheeca and mgr had extended an earlier version of uLisp with some basic error handling. This couldn't be directly applied to the current version, but with a few tweaks ... it works! I am immensely grateful. I also extended the "testescape" function to respond to keyboard input, so I can interrupt execution if the runtime of my code exceeds my patience.

    Some types of malformed programs can still cause the interpreter to hang, the most likely of which is forgetting to close a double-quoted string or parenthesized expression, which causes the uLisp reader to go into an infinite loop. It will also hang if the code recurses too deeply and there is a stack overflow.

    For the former issue, I've started writing a basic parser (in uLisp!) that will check the validity of my expressions before submitting them to the reader. I hope that this can also be used to give more helpful error messages, making it trivial to find my mistakes. For the latter, I've no plan yet ...

    Storage options

    In the mean time, the presence of these bugs makes it all the more obvious that there's no easy way yet to save my work. If I define a function in the editor, I have to connect the USB-C cable, exit the REPL by sending the escape char from the serial console, "(pprint <function name>)" to display it there, then copy-paste it and save it in a file on my PC. I could streamline this process, but my goal is a stand-alone computer - so I've begun looking into how to store lisp code and text files on the device itself.

    I've still only used about 1/4 of the 1Mb of flash program memory on the Apollo3, and it would be possible to use the remaining space for storage. But although that would fit quite a bit of code/text, it could be vulnerable to being overwritten by later firmware updates, and I'd have to implement it myself and ensure proper wear leveling - and making a mistake in that could kill the flash chip quickly.

    So instead I soldered some wires to a microSD adapter, uncommented a #define and tried out the SD card support already present in the interpreter - and it works out of the box. It's somewhat slow and doesn't support listing files, but that should be easy enough to add. It even supports "(save-image)" and "(load-image)" to save/restore the entire workspace, although personally I want to be able to work with files more explicitly.

    As usual there's an issue to overcome - updates to the display stop working after I've used the SD...

    Read more »

  • Mini update: power usage halved!

    Andreas Eriksen01/21/2023 at 06:24 1 comment

    Now got max power usage more than halved, down to ~2 mA - again that's with scanning the keyboard, updating and refreshing the screen, and now also while running some floating point calculations in a loop, so I'm hoping this is near representative of actual usage.

    The big power gain was mostly from shutting down the GPIO lines used for serial, which were backpowering the serial chip on the dev board ... the blue LED (which happens to be on the port I'm using for SPI clock) is still blinking away, and may at this point be a serious contender for reducing power usage with a swipe of the soldering iron.

    Currently working on completing the keyboard routine and integrating it into uLisp so I can have a working REPL!

  • Starting back up, baby steps

    Andreas Eriksen01/11/2023 at 21:36 0 comments

    Finally, I'm back to getting a little bit done on this project. After getting everything set up again, my first bit of progress is actually figuring out what went wrong with the graphics library and how to fix it. It seems the combination of the adafruit gfx / sharp memory display libraries and the sparkfun artemis arduino core end up doing hw SPI transfers most significant bit first, while the display expects least significant bit first. Not 100% sure where the issue lies, probably in the arduino core, but I was able to hack around it by reversing the bits in each byte before transmitting. Anyway, with that working there's a very nice boost to the screen refresh rate! It was quite distractingly slow.

    Got a good tip on how to reduce power usage too, so looking forward to testing that out next!

  • Falling down rabbit holes

    Andreas Eriksen03/20/2022 at 22:07 0 comments

    To quickly sum up the progress I've made since last time - I can now type on the keyboard, and the words show up on the screen! Those letters in the picture are pretty chunky - but that is for your easy viewing pleasure. I can comfortably read with the default 5x7 font which lets me display 53x30 characters. Moving it closer and adding another one or two next to it should give me sufficient screen real estate.

    I've measured current consumption from the battery at 6mA, or about 22 mW, while scanning the keyboard and constantly updating the screen. That should give me about 83 days of battery life (given constant use) with the laptop-size battery I've ordered.

    It's certainly better than my standard laptop, but not quite as good as could be hoped for - it's 4x the quoted 5 mW power for the Artemis module. Disconnecting the screen or putting the CPU to sleep didn't seem to make much of a difference either, and that means I won't be able to recharge using only the solar panels, certainly not with indoor light at least.

    I suspect most of the power draw is from other components on the board, like the voltage regulator, power LED and possibly more. I've cut the traces to the PDM microphone earlier, but I don't want to start desoldering the other components just yet.

    The keyboard scanning rabbit hole

    I was able to get the timer driven interrupt working, and posted a simple example in the Sparkfun forums in hope that it might help others. The rest was supposed to be simple! But when I coded up the keyboard scanning routine, using the standard Arduino pinMode and digitalWrite / digitalRead calls, it was slow ... unacceptably slow.

    It took about two milliseconds to scan the whole keyboard matrix, which I had naively been hoping to do tens of thousands of times per seconds - but I could barely scan it 500 times per second, and even then the CPU would have been 100% busy scanning the keyboard and have no time left to do anything else.

    I realized I would have to leave the easy and comfortable world of Arduino tutorials, and started digging into the guts below. Happily I discovered that all the source code for the underlying software is included in my ~/.arduino folder!

    Turns out that Sparkfun's Arduino core for the Artemis boards is based on Mbed OS, and every call to pinMode or digitalWrite will spend some time looking up the right mbed::DigitalInOut object. Keeping references to and calling these directly saved about half of the time, getting it down to 1 ms per scan. Reducing the scan rate to 256 times per second seemed acceptable enough for now - that's 25% of the CPU, but I can fix it later.

    Or so you'd think, but I just couldn't accept that. So I dug down through another layer ... the implementation of Mbed OS for the Apollo3 ends up calling functions from the Ambiq SDK. These have somewhat more arcane names, like am_hal_gpio_input_read, but have even less overhead - calling these directly got me down to about 240 microseconds per scan, or about 6.6% of the total CPU time.

    There is yet another layer I could chip away at - there is a "fast GPIO" function, or I could even directly read and write from the I/O registers - but I spent a whole evening trying without much success, and 240 microseconds at 48Mhz is 11520 clock cycles, about ~103 clock cycles per key scanned, and I think I'll be able to live with that ... for now.

    The hardware SPI rabbit hole

    Once I had come to terms with the keyboard scanning, my next step was to display the results on the screen, and I promptly fell into another hole. Screen updates are just a little too slow with software-driven SPI for typing to be responsive. Using he same shortcuts as for the keyboard helps, but it's not great, and getting hardware SPI to work with the Adafruit library on the Sparkfun board is still giving me trouble.

    After consulting the display data sheet and programming app note I was able to write data to the display using hardware SPI without using the...

    Read more »

  • Prototyping progress

    Andreas Eriksen03/12/2022 at 21:33 0 comments

    The photo I originally uploaded shows an Adafruit NRF52840 Express board - this worked great for testing the display, but I wanted more GPIOs for scanning the whole keyboard matrix directly (14 column lines + 8 row lines).

    I had previously ordered the Sparkfun Artemis ATP board (48 GPIOS!) in the hope to get close to the extremely low power usage numbers they are quoting (5mW). Probably not if I'm using that many GPIO lines, but if I could get even close it would be amazing. Currently it idles at around 4mA@3.3V, so 13.2mW ... 

    That board sure took it's sweet time in the mail, but now that I have it I have been able to verify that I can get uLisp running on it, scan the keyboard matrix and read all the keys (from LISP). Success!

    What hasn't gone great is getting the display to work with hardware SPI. I must have tried a hundred different combination of parameters but no luck yet. Are there some assumptions in the Adafruit libraries that don't apply to the Sparkfun board? No idea. For now I'll ignore that display updates are kind of slow, and plod on with the next step ...

     ... which is scanning the keyboard at regular intervals, doing debouncing and turning it in to a nice and neat sequence of keyup/down events. I am lucky to have some code to go by from the uLisp author's own very cool lisp badge project: http://www.technoblogy.com/show?2AEE

    In parallel I'm 3D printing a very simple case for the display and breakout board. I learned the hard way that those FPC connectors are fragile, and ruined one 4.4" display - good thing I ordered extra. And hopefully I've learned my lesson now and the case will keep the next one safe.

View all 8 project logs

Enjoy this project?

Share

Discussions

James wrote 04/03/2023 at 22:23 point

This looks great! Reminds me of my PalmPilot, which makes me think AA batteries would be best :)

Have you considered attaching two 4.4" LCDs? I'm thinking that if you stack them vertically you'd have the best setup for text as you could effectively have one long display. Of course, you could also do cool things like having the REPL in the bottom half and the graphics display in the top half (Apple ][ Logo?), having two files open at the same time, etc.

This is making me want to learn how to do hardware.

EDIT: looking at your artist rendering, seems like you've already had the 2 LCD idea. Carry on!

  Are you sure? yes | no

NeccoNeko wrote 04/03/2023 at 06:13 point

I wonder if this project would benefit from incorporating a keyboard that can harvest energy from key presses. 

https://www.sciencedirect.com/science/article/abs/pii/S2211285521004882

  Are you sure? yes | no

DOminique wrote 03/28/2023 at 16:31 point

with your power requirements I wouldn't bother with a powerbank. I'd experiment with a hand-crank or a tiny DIY stirling engine run by a tealight to drive a generator that charges a supercap

  Are you sure? yes | no

NeccoNeko wrote 03/14/2023 at 05:44 point

this project is extremely interesting. Would be neat to integrate lora/loranwan for low power, long distance communication

  Are you sure? yes | no

michimartini wrote 03/13/2023 at 11:13 point

The world very much needed this thing. I love the Idea of a laptop type device that requires next to no power to do the very basics. Just imagine a writer that goes to a remote cabin to type up his book. He normally would use his ridicuously overpowered macbook, when all he needed was what you built here.

  Are you sure? yes | no

Egil Möller wrote 03/09/2023 at 11:12 point

Super cool project! What is the reasoning behind the choice of display? You mention display size, and there are epaper displays that are much larger, so what is the advantage of this display type over epaper that makes you chose this display anyway?

  Are you sure? yes | no

Andreas Eriksen wrote 03/10/2023 at 23:36 point

Thank you! The main reason is power usage, being the main focus of this project. E-paper in theory uses no power when not updating the screen, but updating even just a part of the screen is costly. For a device you type on, you'll be updating the screen after every keypress. There will also be a noticeable delay, which I find very annoying after having tested with a Kindle.

I recently got the total system latency down to about 40ms from keypress to completed screen update, including pixel transition, which makes the system feel very responsive and fast. Compare with data from https://danluu.com/input-lag/

I also found the e-paper displays harder to integrate with, although better options have appeared since I started.

  Are you sure? yes | no

Corba the Geek wrote 03/07/2023 at 18:19 point

I fear that you are going to go blind using a screen that small. Aren't there larger screens that wouldn't reduce your battery life too drastically?

  Are you sure? yes | no

Andreas Eriksen wrote 03/07/2023 at 20:48 point

Haha. I really hope not! Good light helps.

I'd love a bigger screen. I think I saw some bigger of the same type on aliexpress once, but not through "official" channels

  Are you sure? yes | no

ironpotato wrote 03/07/2023 at 16:00 point

Awesome project! Come join us on the Cyberdeck cafe discord! https://discord.gg/EFq2Jdqt

  Are you sure? yes | no

tuxadecimal wrote 03/07/2023 at 01:40 point

Very cool project! Is the screen a LS044Q7DH01? In your video It looks higher res then 320x240 but that is the only Sharp 4.4 monochrome screen I found.

  Are you sure? yes | no

Andreas Eriksen wrote 03/07/2023 at 03:31 point

Thank you! 

Yes, that is correct. The text is only 7x5 pixels - smaller bitmap fonts are possible, but I found this the minimum for comfortable reading on what is really a quite small display. 

I wish they made a bigger one. I do still hope to add another one next to it at least.

  Are you sure? yes | no

tuxadecimal wrote 03/07/2023 at 03:40 point

Awesome thanks! Yeah I'm having the same debate internally for a similar kind of project. 4.4 seems like it is just a little too small but large monochrome displays are tough to come by, especially at reasonable prices. I keep waiting for the right one to come along. Using two is a good idea, maybe that is the way to go for me too.

  Are you sure? yes | no

crun wrote 03/03/2023 at 08:34 point

I'm surprised the Apollo chips havn't had more attention, they are very cool. I fancied much the same idea, but using Forth, for all the same reasons.

If you don't know, the standard way to do zero power kbd, is to set all scan out lines on, and leave all scan in lines with interrupt on pin change. Then go to sleep.

When any key is pressed you get an interrupt, and then you scan the kbd to find out which key it was.

  Are you sure? yes | no

Andreas Eriksen wrote 03/03/2023 at 08:53 point

Yeah they are amazing.

Implementing that keyboard trick to save power is definitely on my TODO list. I learned about recently it in a TI pdf I found on google: Implementing An Ultra-Low-Power Keypad Interface With ...Texas Instrumentshttps://www.ti.com › lit › pdf › slaa139

In it they use diodes for the rows, I didn't fully understand why. After reading your comment I can't think of any reason I'd absolutely need them to implement this. I guess all I need is time to sit down and think about it for a quiet moment, but such moments are rare :-)

  Are you sure? yes | no

crun wrote 03/12/2023 at 05:35 point

Diodes are used so that multiple keys can be pressed at the same time, (assuming I havn't misunderstood you)

  Are you sure? yes | no

Geno wrote 03/02/2023 at 04:14 point

K750 keyboards from use specialized solar cells for indoor and ambient lighting to charge I know there are different solar technologies so it may be wise to investigate this portion of it as some of those epoxy encapsulated jobbers are not all that efficient at all really at supplying power.
Maybe if you can get enough NDB's if you can get them yet and wire them up in series dunno how safe they are but supposedly they are legit the Nuclear Diamond Batteries. 


Well good luck way cool seeing many of these low powered projects this is the future really eventually we will bring the cost of compute TDP's down substantially to where it will be extreme beyond what we currently even imagine I presume. I've already seen what I thought was impossible in my lifetime but there is this odd effect the less powerful the CPU's it seems like the more powerful processors operating systems expect that you use. Some processors that use 15 watts are more powerful by far than the PC's I used to use as a younger man its nuts to just think of 20 years ago what I had vs what is now. If we had that 15watt TDP CPU back then we would have had something that topped anything that existed in processing yet today that same PC is outlawed by windows 11 essentially and some Linux Variants I presume kind of an oddity. Ahhh well what do you do to me things have become more interactive which is good but more video filled more eye candy etc.. But how much better have things become its almost as if things are more bloated than they need to be as well at the same time.

  Are you sure? yes | no

Andreas Eriksen wrote 03/02/2023 at 06:14 point

Thank you! Yes, that keyboard is very cool, looking into what solar cells it uses is a good idea. I think the number of nuclear batteries required would be too large to be feasible but perhaps with future refinements ...

I recognize your sentiments, I have actually considered writing an emulator so my computer could run all the efficient software we were effectively forced to develop back then.

  Are you sure? yes | no

Giovanni wrote 01/09/2023 at 01:02 point

https://www.tindie.com/products/jaspersikken/solar-harvesting-into-lithium-ion-capacitor/  
https://www.farnell.com/datasheets/3816250.pdf


This 250 Farad LIC is the equivalent of 90mAh , which I calculated to be 5 days (1500mAh/90mAh= 16.6. 83 days/16.6=5. Maybe more since there seems to be less leakage:
https://hackaday.io/project/178177-solar-harvesting-into-lithium-ion-capacitor/log/203869-leakage-current-of-lithium-ion-capacitors-vs-supercapacitors


The 30F one is 11mAh- which suggests it would run about 15hrs: 

https://www.farnell.com/datasheets/3816249.pdf Amazing, for a capacitor! 

https://cdn.tindiemedia.com/images/resize/3dSIGSPzVMs8evlooO5-ae1E4CM=/p/full-fit-in/2336x1752/i/20561/products/2022-01-25T11%3A14%3A13.100Z-EDLC_LIC_LIB_comparison%20table.png

I can pay for one if you'd like to test one.

  Are you sure? yes | no

Andreas Eriksen wrote 01/09/2023 at 05:39 point

I am flattered you still remember my project! And your comment shows up just as I've really started playing with it again only a few days ago, after being swamped with work, life, Christmas and a few other projects.

The board I'm already using for solar is, as I understand it, basically the same, just configured for lithium-ion battery. I have indeed thought already that this might have been the wrong choice. Your calculation of 5 days is not bad at all, and with the reduced size and worry about battery chemistry it makes a lot of sense! And I do still have hope to bring the power consumption closer to "advertised" numbers.

But for now what I have must do, as I need to focus on making a little more progress on the software - to bring the device into a somewhat usable state before making any other changes. The good news is I believe it should be trivial to swap in the capacitor version later, and I do intend to try it!

  Are you sure? yes | no

Giovanni wrote 05/22/2022 at 14:54 point

Nice, I just completed a small test of a solar panel https://hackaday.io/project/185456-diy-solar-powered-inverter

  Are you sure? yes | no

Andreas Eriksen wrote 03/10/2022 at 15:54 point

My current estimate is 87 days of continuous use. I'm sure that will change as I refine my estimates, but I hope to keep it in that ballpark. If I can make low power sleep mode work when closed, it should be effectively perpetual. But I foresee some difficulties with self discharge of li-poly batteries.

And yes, I'm already testing solar! Using the "aemlion" board by Jasper Sikken and some Powerfilm low-light solar panels, I hope to be able to recover some power even indoors.


But take all of this with a generous pinch of salt! This is not my area of expertise, I'm just a software dev playing around for fun, not being very rigorous in my research and testing. Time will tell!

  Are you sure? yes | no

sup wrote 03/10/2022 at 09:47 point

how long this device work? week ? month?

meybe add solar panel? Many project (like fuzix) no need big cpu 

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates