Project Logs

Collapse

• Louia ObScura on Solar Power

  Lee Djavaherian • 04/13/2026 at 23:05 • 0 comments

  Last month, I created a new project to run a Louia ObScura server outside on pure solar power, all year round, something for which the low-power Pico boards are well-suited, and something I've been wanting to try ever since I ported Louia to those tiny Picos last year.  I am now glad I added that Powersave Mode last December (although this can be further improved upon).  I'll probably have to switch to a slower Pico W instead of the Pico 2 W in order to use its GPIO, since the RP2350 Pico 2 W GPIO doesn't seem to be supported in MicroLua yet, and I'd rather not have to delve into the Pico C SDK.  But the news last year that the Pico W can now run at 200 MHz instead of 133 MHz in SDK 2.1.1 provides a nice boost to an otherwise less-suitable board (as it has about half the RAM and flash storage of the Pico 2, things of dire need in a multitasking Spartan server).  In some ways, doing all of this is similar to #TrillSat (which is now 10 years old) minus the robotic platform, but it's much less complex and around 1/10th the cost.  It's basically just a fixed-panel solar Meshtastic node with a Raspberry Pi Pico W board alongside it, although I designed the solar node myself instead of using an off-the-shelf one since they're not designed to also power a WiFi-enabled Pico alongside them (which sits somewhere between an nRF52 and an ESP32 in terms of power usage), and I wanted to use a different battery chemistry.  So far, this has been the most difficult part of this new project, although I haven't tried building it yet but just have the parts.

  It was actually my first attempts to try Meshtastic in the last few months that led me to try this, as this hobby turned out to be more complex than it seems on the surface which intrigued me and also provided enough leeway to create my own systems.  I figured that if I'm going through the trouble of setting up a solar node, I might as well do the same for Spartan.  Being first released in 2020, Meshtastic did not exist when I started TrillSat yet has some similar design goals.  LoRa did exist and was seen as having much potential, so, years ago, I noted it in my project as a future expansion for TrillSat called the "Planetary Space Pod" where I intended to use an RFM95W SX1276-based LoRa module and an ATtiny3216, then would design my own point-to-point, LoRa-based protocol.  But with the wide availability of the inexpensive nRF52, ESP32, and even Pico-based open-source Meshtastic firmware and the newer and better SX1262 modules, I don't need to design my own LoRa-based protocol nor control it with my own MCU but can take advantage of the unique Meshtastic mesh (which has grown in recent years) along with the supported hardware and kits.  What I learn in this new project can be applied to that old space pod.

  Interestingly, the Louia "OS" abstraction within Louia ObScura might now have its first practical use case for me (other than the administration console) as I can now easily create an application that runs independently alongside the Spartan server to monitor and reset the Meshtastic board if it locks up, as it will be difficult to do this by hand when it is mounted outside.  My default 30-minute TIMEOUTSCRIPTSECS parameter interferes with this type of watchdog, so I'll have to increase it to a much larger value for 24x7 operation.  And I didn't consider creating a "startup list" of applications to run at boot if the board is reset, which would have been useful in the case it loses power at night until restored the next day, as it was just a novelty function at that time.

  I likely won't add many logs to this project regarding this new solar-based system, since Louia ObScura is simply the software that runs the Spartan server and OS, not a hardware platform that also hosts other servers/transceivers.  It's currently a work in progress called Asteroid Station Delta.

• Added Powersave Modes to Version 1.2 and Louia 1.4

  Lee Djavaherian • 12/06/2025 at 02:03 • 0 comments

  I added what I learned and did with Louia ObScura over the last 2 1/2 months on the Pi Picos to my original Linux-based Louia, releasing version 1.4 today which also contains a new, experimental powersave mode, turned on by default (although I probably should have kept it off).  I also added that powersave mode to this Pico-based project, and released version 1.2 of Louia ObScura today under GPLv3, the tarball attached in the Files section.

  I've got both the Pico 2 W version and the Linux-based version running simultaneously over at spartan://greatfractal.com now on different ports, the default Spartan port still directed to the Pico 2 W.  The Linux-based version has always been many times faster running on a single-core 32-bit Pi Zero, but of course that is at 1 GHz with 512 MB RAM, and it gets to use all of the CPU, Linux, and LuaJIT optimizations, too.  The Pico 2's RP2350 is also 32-bit (even dual-core with two more RISC-V cores), and similarly, I only use one of its two ARM cores, but it only runs at 150 MHz with almost a thousand times less RAM.  Using Lua 5.5 to also implement its own OS, the code got 3x larger on the Pico so the server is running a lot more interpreted code per request which also slows it down, as I have not optimized it.

  But I did take the time to add one optimization lately to reduce power.  In both versions, I had previously turned off blocking for TCP/IP sockets and just quickly looped through the socket function checking to see if there was a new connection before spawning a new coroutine.  Since I needed to loop anyway to allow my main dispatch loop (a sort of "kernel") to process multiple, concurrent requests so that I could avoid actual blocking of the socket for other requests, I had to use a lot more CPU cycles when I turned off the blocking on those socket checks.  In my early versions of Louia, I used something like the Unix select() function under LuaSocket's socket.select() to check for new or changed connections or block if nothing was happening.  But once I got a connection and the dispatch loop returned around to that socket check again, a lack of network activity would block its concurrency, becoming network IO bound and not CPU bound.  So I had to time it out quickly, negating much of the reason to use select in the first place, which would have saved me a lot of CPU cycles and power otherwise.

  But in working with them lately I realized that there is no good reason to keep the socket check unblocked if there is no concurrency in progress (no running coroutines).  So during the idle periods where there are no connections coming in and the last coroutine has ended, it starts blocking again which stops the main dispatch loop to save CPU power.  So on the Linux-based version, I just did a simple check to see if there are any coroutines running, and if not, set the socket.select() timeout variable to nil (blocking indefinitely until network activity).  It works in testing although I'm not sure yet if the socket itself is timing out after long periods of inactivity since I'm not calling it anymore, as I've gotten occasional locks with 1.4, so I may have to add a (long) timeout or periodic watchdog anyway.  Nevertheless, this new feature can be turned off.  But if there are coroutines running, or this feature is turned off, it sets it instead to the TIMEOUTCHECKSECS variable, a short delay that I use to control the dispatch loop speed and CPU.  On the Pi Zero when running atop Void Linux, when the powersave mode was turned on, the CPU use for louia.lua dropped so low during idle it was off the screen where I couldn't even see it.  Great!

  Yet... when I tried to do the same thing for the Pico 2 W, I ran into some problems.  Firstly, select(), of course, is a Unix-like construct that does not usually exist if you have no Unix-like OS (which is what I have here).  MicroPython (which I've never...

  Read more »

View all 2 project logs