Working Title

During the COV-ID craziness I gave up on github because Microsoft started demanding a 2 factor setup for logins, which made it feel way too much like work.  I hate that stuff.  But it's been like 5 years and I still get the urge to code so I finally gave in and set it up.  The MS github still complains my 2 factor selection is obsolete and threaten to lock me out, but it works for now.  So I've resumed work on the ziptuner, trying to knock off some lingering items on the To Do list and clean up the crusty old code while I'm at it. 

https://github.com/deeice/ziptuner/commits/master/

Here you can see the "Now playing" line shows the station name instead of just the number.  I've also added several additional example scripts for more back-end players, including some that run in a separate window.  

  

I kinda like the way SMPlayer shows the current song title from the meta tags and provides convenient access to the volume control.  I can't really incorporate that into the main window since the Dialog program is doing all the work and I don't think it has an API for async updates.  Back in the day I borrowed alt console /dev/tty4 on the zipit for status and control of the player program because the ziptuner dialogs hog the entire 320x240 pixel screen. 

 

 

Unfortunately the modern internet moving from http to https has forced me to build a new curl for the zipit to use as a middle man, fetching and decrypting https streams and piping the unencrypted stream to the old players which lack support for that.  Changing standards... what a hassle.  The 15 year old libcurl from IZ2S couldn't do it so I'm now using tiny-curl with bearssl.  Seems to work, but my build skills are week.  It's significantly smaller than the old IZ2S curl, but bleeding edge openwrt is still the sleekest.  They got some amazing build config setups.

Anyhow, here's a terminal screenshot of the new tiny-curl pipes that I made in an ssh session on the zipit.  The new ziptuner is still pretty lean at 33 Kilobytes.  I'm pretty happy with that.  The mpg123-curl helper is used for http or https streams and mplayer-curl is used for the rest.  This keeps the player pipeline as lean as possible.  That's vital when you only got 32 Megabytes of RAM.

 

I still need to patch in /dev/tty4 support to catch the song titles.  Hopefully I'll can keep this up and have more to say on this soon... 
 

UPDATE Apr 19, 2026

I had thoughts about redirecting the output from mpg123 into a logfile and using a tailbox dialog to monitor it in the ziptuner.  I'd have to add a 4th button called <Logs> to the main screen for but the code for that is really minimal and you get something like this mockup dialog I ran from an ssh session while mpg123 whipped up a log file.  A tiny dose of grep and sed would clean that right up.

But apparently the ICY metadata with song titles is nonstandard web stuff, and curl needs special options to request it and keep it in the stream for https URLs.  It also seems like mpg123 doesn't like the ICY meta in the pipeline when you do that.  Is ICY meta not the same as ID3 tags?  Probably not.  So for the zipit the log idea would really only work for http streams because curl is not required.

This needs some research, and it may just be simpler to rebuild mplayer and mpg123.  Darn it.  I think I'll add the code anyhow since it's so small. 

UPDATE Apr 23, 2026

I compiled the latest mpg123.  It seemed about 10x bigger than the old mpg123 but a long session with the google AI eventually whittled it down to a similar size, cutting junk that's useless on the zipit with quite a few iterations thru the configure script.  Turns out mpg123 itself uses an external curl pipe for https in the current code, but the command line is like a mile long to negotiate all the ICY header junk.  The google AI only gave me tiny subsets of that nonsense in conflicting circular broken answers.  So I never woulda got it working in the ziptuner script.  The good news is the new mpg123 works for both http and https on IZ2S and may actually be tinier tighter code.  It certainly helps keep the ziptuner script sleek with mpg123 handling the curl audio pipelines instead of me.

Mplayer was another story.  I got it to compile but it refused to link.  The problems were all in the internal ffmpeg library.  Something wrong with libm and the floating point.  With an FPU-less armv5te processor any floating point code is gonna be slow and problematic on the zipit.  Meanwhile, mplayer is now mostly just a wrapper around ffmpeg so if I can get a modern ffmpeg to build then maybe I can use that for ziptuner instead.  So I dug in with the AI and eventually came up with an ffmpeg config script for a fairly small fixed point only build.  Sadly I gotta get another ssh/tls library built first if I wanna do https.  It looks like mbed tls is the future.  BearSSL is unsupported by ffmpeg, but mbed tls is currently supported by ffmpeg, curl, and openwrt.  A zipit trifecta, I can get it to build.  They switched to CMAKE after version 3.6.4 so I think I'll start with that code... but it's all taking too long so I'll have to get back to it later.

The ziptuner c code for the log viewer dialog was actually quite simple, as I said.  But making the metadata logging work from inside the ziptuner was much trickier than expected. The problem is formulating the play script I want to pass to mpg123.  The trouble with this is when you run it in the background mpg123 wants to buffer the ICY message output in 4K blocks.  That's like 100 lines buffered before you see anything.  Not good.  So I spent a few long days back and forth with the google AI before I got something that works.  It suggested stdbuf (or a one line c code shared lib that does the same thing for small systems without coreutils).  That seemed reasonable but it doesn't work with static executables.  That's a no go on the ancient zipit running IZ2S and it took like forever and a day to get the AI to admit it.

Fortunately busybox (which runs most of the zipit) comes with a script applet that does the trick, but formulating the exact command to make it work was like pulling teeth.  Again the AI sent me off in the wrong direction with many ever so slightly broken variations of the same command.  But eventually I got it down to the mp3 line in this, which gives me pretty much what you see above from my initial tests with command line scripts.  

LANG=C DIALOGRC=/usr/local/share/ziptuner/dialogrc.soho ./ziptuner $A -u \
 -mp3 'script -aqc "echo && date && mpg123 %s 2>&1" /tmp/ziptuner.log >/dev/null' \
 -p '>/dev/null 2>&1 mplayer-curl' \
 -s '{ killall mpg123; killall mplayer-10rc2; killall curl; } 2>/dev/null' \
 /usr/share/radio /mnt/sd0/gmu/playlist.m3u

It drops a date/time stamp in the log before running mpg123.  The -a tells script to append to the /tmp/ziptuner.log file or else it would overwrite whenever I change the channel.  The q is for quiet and the c runs the command in quotes.  The >/dev/null after /tmp/ziptuner.log is for stdout from script itself.  Without it script will spam your tty with the same stuff it redirects into the ziptuner.log file.  

 I want to add a sed pipeline to the script command and maybe clean up the log a bit.  This example leaves only the "Artist - Song Title" part of the ICY-META lines.

sed -u -e "s/.*Title=.//" -e "s/\x27;.*//" 

Unfortunately incorporating that is yet another struggle.  The sed commands themselves are relatively simple, and I've already tested some that make it look pretty nice, but it leads to triple nested quotes (and maybe a subshell) when I add it the the scripty mess above.  So I suspect I should push this down to the bottom of my new To Do list.  

The AI seems to agree, or it was just trained to be obsequious.  When questioned on the evaluation order with it's choice of nested quotes it said, "You’re right to be skeptical—nested quoting is the fastest way to break a shell script."  Then reworked it's shoddy code to put the single quotes on the outside.  In the end I think this is gonna make me bring back the player helper script.  I hate to do that, but Dialog really seems to need the \r characters stripped out for the tailbox or textbox to work and it's the least ugly way to isolate quote nesting layers.

First on the list should be another button or two in the Log Viewer so I can toggle it from a live tailbox to a static textbox with scrollbars.  Also a log <DELETE> button might be nice if it gets too big.  I should be able to code that up quickly in the ziptuner c code.  Then maybe do some serious regression testing and a new release before I get bogged down in sed pipelines and triple nested quotes, or ffmpeg builds.

 

Treasure from the Junk Drawer?

Is it just me, or does everyone have trouble with accumulating junk in drawers, boxes, under beds, and even coat pockets?  For some reason I hold onto all sorts of stuff, hoping that someday I'll find a use for it.  Usually I can't find it when I come up with an idea, but that's another story.

Anyhow, I recently had a need for a small serial data logger and thought one of the retired zipits from junk box 42, under the bed might be just the ticket.   Over the years I've accumulated a few zipits with various disorders such a dead pixel row or whatever.  That wouldn't be too much bother for something spending most of it's time out of the way, logging things.

Rather than build another special purpose cable I decided to go with the original dock from mozzwald, albeit with a tiny modification to run the ttyS1 serial Rx line out the through the dock power connector instead of 1.8V.  I've had the disassembled dock and header pins for like forever, and finally found someone with the skilz set to solder the pins and the tiny jumper wire, move the dock detect resistor aside, and cut the exposed 1.8V trace on the other side of the board.   There's even some leftover solder blobs to rejoin the cut trace if I change my mind.  Heh, unlikely.

Now I have a row of 3 pins (GND, 3V, Rx) on the power connector that exactly match what I used in the custom serial GPS cable I made once upon a time.  I only need Rx and GND for the current logging project, but who knows what might tempt me in the future?  If it needs power, I've got it.  If you zoom in you can see the cut trace above the 1V8 pin in the image below.

And here's the formerly retired zipit (with a dead pixel row) hooked up to a test contraption assembled from other junk box parts.  For some reason the only serial cable I could find came with a 25 pin connector on one end.  What in the world was I thinking when I kept that one?

I also dug up an ancient 300MHz laptop with a real serial port to say "Hello" to the zipit and prove the board mod works. My actual plan only requires the red and black wires for 3V TTL comms, so it'll be significantly less clunky.

There's more to tell in this story, but for now I just wanted to drop some pics before I lost track.  Hopefully I'll find the time to finish.

Why Don't We Do it With Windows?

Due to the never ending plandemic lockdowns it's now been well over a year since I've done any sorta substantial coding effort at work.  It's been mostly just endless talk about maybe getting into the lab and doing something when things finally open up.  But now I don't even do that because I got myself "resigned" for resisting the jab. 

So I thought maybe I should try and code something in my now copious free time to see if I still got what it takes.  And this is where it took me.  Ziptuner on Windows 10.  Why not?

I think the play button works, but I have no speakers yet to be sure.

 

It still needs a whole lotta of tender lovin care, but all the essentials are there.  I had to build an updated dialog.exe for Windows based on this old cdialog for windows recipe to get all the extra button options required for the ziptuner.  So I'll probably publish that procedure and put out a binary, real soon now.  

And eventually a ziptuner "package" for Windows will follow.

 

Update Feb 11, 2022

Problems, problems, problems.  The Windows 10 PC is really throwing up some roadblocks.  Apparently the Windows Terminal app has quite not come along as far as I'd hoped.  The internet and linux have rallied around the versatile variable length utf-8 Unicode encoding, but MS support is spotty, even in the spiffy new tabbed terminal app.  I can't seem to stabilize it on one set of glyphs that works well in the ziptuner.  I'm sure this is partly due to ignorance on my part, but the OS still gets some of the blame in my mind.

To test it I saved the dialog command from a sample ziptuner query to a simple batch file called dlg.bat and ran it through several paths to the display to try and sort out what's going on.  First I just typed it out in the command prompt.

D:> Type dlg.bat 

It's all Greek to me, but I think it looks right.  So I typed it out again, but this time I piped the output through the more utility. 

D:> Type dlg.bat | more 

 

 

That looks like it dropped the utf-8 support and went with a representation using the ibm pc code page 437 setting.  I get the same thing if I simply type it out in the older CMD prompt window instead of the terminal app.  Disappointing, but no surprise there.

 

Next I ran the batch file to see what the dialog program itself would do with it. 

 

D:> dlg.bat 

 

 

It looks like it interpreted it as utf-8, but forgot it had all the glyphs in the font.  Weird.  

Finally I ran ziptuner, resumed the previous search, and had the ziptuner run the dialog program in a sub-shell.

D:> ziptuner

 

That looks like it maybe tried to go back to an 8 bit code page interpretation again.  But which code page?  

 

I could live this for a while, but it also confuses the dialog and garbage gets left behind when you scroll through the list.  Oh well, I got some work to do to sort all this out...

 

 

 

And meanwhile, to add to my woes the sound card in the Windows PC is busted and produces no sound, so I've gotta fix that as well.

Update May 2, 2022

Wow, almost 3 months and no update.  What's up with that?  Well, I gotta admit I almost gave up right then, but sometime after discovering the dead sound card I remembered a dirt cheap USB Music Fairy sound stick that I bought back in the dark ages to provide some sound in desperate times.  

Unfortunately, the alternate "Engrish" name on the purple Music Faily disk proved more apt, and it performed as promised.  It failed.  Or more precisely, it failed for me on Windows 10.  I suspect the ancient drivers delivered on the purple mini CD made extensive proprietary use of the CPU for extra signal processing horsepower to assist the stick. Sadly, those drivers only work on expired Windows from the distant past, and while Windows 10 has some generic drivers that claim to support the sound stick, the audio output is a cacophonous discordant disaster.  Very discouraging.

Again I almost gave up, but I can be a glutton for punishment so I pushed on with the UTF-8 issues.  However despite some interesting investigations like Bush hid the facts and a run in with the 8K Windows command line length limit, I was ultimately unsuccessful making UTF-8 work with the dialog program running in a separate subprocess.  Oh well.  

Now, I know I promised to deliver an updated dialog program for Windows, but it turns out I actually found one already available on Github that behaves pretty much the same as my build.  So I'll simply link to that instead.

 https://github.com/tenox7/ntutils/tree/master/dialog

At this point I think the right way to go on Windows would be to pull the libdialog.a static library right into the ziptuner executable itself and run the dialogs directly as local procedure calls so everything can be done in a single process.  That'd be a whole lot easier to debug, would also avoid the command line length limit, and actually seems like a more Windowsy approach.  If I ever get some working sound hardware running on the Windows box, I still may do just that.  We'll see...

Integration Testing

I've remained committed to the gluqlo clock for months now, running it all day and night on the zipit as my replacement alarm clock radio. So maybe it's about time I integrated more stuff. Like the music. That's already pretty decent. I can use the alt-home key combo to return to the gmenu2x screen and pull up an internet radio stream in the ziptuner. Then maybe set a sleeptimer and alt-arrow back to the clock screen. The default ebindkeys OnPlay and OnStop scripts provide rudimentary controls via the Play and Stop buttons, even when the clock app is on-screen. Same for the side mounted volume control buttons. Nice, but there's always something more...

I only have a 2GB bleeding edge Openwrt SD card in the alarm clock zipit.  So no space has been available for any music from my personal stash that I meticulously converted from my super awesome record collection. And that got me thinking... Plenty of people have hooked up their zipits to network media players in the past. Maybe it was high time for me to do the same. With that in mind, I launched the python simpleHTTPserver in the music folder on my laptop, and it worked well enough to play some music via wifi on my chromebook. That's a good sign. So I whipped up a script to auto generate album playlists for every folder in the entire music directory tree.  Sadly, I found less success with that on the chromebook than I expected. No can do the playlists?  Oh well. The zipit's my real target anyhow. And it seems mplayer on the zipit can make use of the wifi playlists.

There's issues though -- mplayer runs out of memory on large ogg files, and I need to check if it can handle any of the large mp3 or flac files in the collection. Meanwhile gmu 0.10.1 supports streaming for mp3s and opus, and new source code is available to extend that to the other codecs.  So I tested gmu on a few large mp3s, and it works, but has some limitations.  Mplayer can fetch and use remote .pls files with relative web paths, and it allows spaces in the URLs. Gmu needs a local .pls file with absolute web paths containing %20 instead of spaces in the URLs.  Not a big deal, but then the marquee scroller up top shows the %20 substitutions instead of spaces, which is a bit ugly. It'd be nice if gmu did the %20 substitution for me, or perhaps displayed the TITLE tag in the scroller instead of the URL.

Must tweak my playlist creator script to cut the track numbers from the TITLE tags.

Also gmu fails to refresh most bits on return from other ttys via ALT-arrows. Actually, only the top blue bar with the scrolling status got redrawn.  I got some more to display by cycling through the playlist with the up and down arrow keys.  I’m not sure if it gets an SDL refresh event or somesuch, but it’d be nice if there was some way to trigger a full screen redraw.  Otherwise I normally prefer to keep the stingy redraws, limited to things that are actually changing on-screen in order to maintain the lowest possible cpu usage.  Which reminds me, I still need to dig into the gluqlo code and put it's screen refresh routines on a diet.

 

If you read between the lines you can see the gmu log messages bleeding thru.

The final piece of this puzzle was the front end. For a while I considered hacking the ziptuner, but it turns out the links browser works adequately for searching on the web server for album playlists. You can config it to launch an audio player either in the foreground or background. But I chose to simply save a playlist in a convenient location and quit links before starting the audio, to conserve memory for the playback task.

I wonder if the node server has an option to skip the file permissions on the left.

In my opinion the node.js simple http-server seems a bit smoother than the python one, so I settled on that for now. It passes a unique pls+xml mime ID for playlists that I was able to capitalize on with a new association in the ~/.links/links.cfg file.

    association "music playlist" "application/pls+xml" "getpls %" 21 1

To pull all of this together I created some new glue scripts in /usr/local/bin, and tweaked the existing onPlay and onStop scripts. And then added some new Find and Play gmenu2x apps to work together with the glue scripts and flesh it all out.  Still need to dig up some new icons.  I'm thinking maybe some jukebox icons -- one focused on the jukebox menu for Find, and one with musical notes coming out for Play.  I'm sure the internet already has something like that.

I got pretty lazy with the icons...

For the new scripts I simplified things by always saving the fetched playlist as /tmp/__album.pls and then keeping a permanent __album.pls softlink in the gmu directory that points to the one in /tmp.  There's more work to do, but eventually I should have some new zipit goodies to share here...

 

Update March 20, 2021

Progress is slow, but I did manage to improve the playlist creator script so it strips out the file number prefixes and file extension suffixes when creating TITLE entries in the playlist files.  Looks much cleaner on the gmu playlist screen.

 

 Still need to fix the marquee scroller text up top

 

I also remembered how to pull the new gmu 0.10.2 RC1 sources into the byzantine openwrt build system and compile it.  However the new executable segfaults on the first song in the playlist. Stack overflow in one of the threads, so some debug is required.  Perhaps it's an issue with musl version of libc used on the zipit?  I need to refresh my debug skills and dig into the code.  That should be fun.
 

 

Update March 28, 2021

 

After a few sporadic nights of intense debugging failure I finally found the problem.  The gmu notify frontend is really meant for popup notifications in X11, which is unavailable on a zipit running openwrt.  So the zipit notification thread simply crashed gmu whenever the song track info was updated from embedded tags in the music file.  I suspect notify didn't build in the 0.10.1 release for some reason, and thus was unavailable to muck things up previously.  Once I disabled it in the zipit build configuration for 0.10.2 everything ran just fine.   Perhaps someday I might revisit what sort of notification would be meaningful on a zipit.  Probably not though...

 

Oh well, at least some good came out of the debugging sessions.  In my struggles to remember how to debug properly, I was reminded of various tricks from the good old days.  Like how to run gmu without the SDL display, so it can get along better with the clock.  Simply launch gmu with -p frontends/gmuhttp.so and it'll operate with only the web server frontend, which can be controlled conveniently with gmuc in a remote ssh session.  It can tell gmu to do things like gmuc -u play (or pause) on the command line, or run an ncurses gui for more visual tasks.  Like this.

 

I don't know how to screenshot from the chrome book, but you get the idea...

 

I suspect I may want to toss dtach into the mix for the gmu web server startup, especially if I want to make it fully remote control capable from an ssh session on my chrome book.  But I think that's my end goal.  Leave the gluqlo clock app running pretty much always and control the music remotely from a comfy chair.  So that's my new focus for now.  

 

The first task is to clean up the clock app to not be such a cpu hog.  Gmenu2x got a cpu hog fix a while back and so gmu runs in the background just fine with the gmenu2x app screen (pictured above somewhere) running.  A clock app only needs to update once a minute, so it shouldn't be difficult to fix as well.  But my confidence took a hit in the debug sessions, so who knows...

Also I should do some more testing with the gmu control web page.  I had to disable the gmuhttp.DisableLocalPassword setting to get it to work, but it's pretty nice once you do that.

If only the file browser tab could browse for playlist files from the webserver on my laptop then my work here would be done, I think...

Update April 5, 2021

 

Turns out the clock app was an easy fix.  Simply replace SDL_WaitEvent with an SDL_PollEvent call and include a quarter second SDL_Delay when no event is available.  Runs at less than 1% cpu now, as expected.  The SDL wait and the SDL timer functions appear to be busy loops of some sort on the zipit.  Same for the pthread cond_wait functions.  Must be something odd in the musl libc implementation we're using.  Maybe an openwrt musl update would help?

Anyhow, that let the music play, even with gmu running in the background behind the clock.  However gmu still needed work as it was hogging over 70% of the cpu.  I got it down to 60%  by eliminating the SDL timer init whenever I excluded the sdl frontend with a -p frontends/gmuhttp.so command line option.  Then I realized I could save another 10% by eliminating all frontends with a -p dummy option.  

There's gmu.bin at 52% up top, gluqlo at 0% in the middle, and dtach down below.

But all that effort left me with no interface to control it with.  Until I realized the code was already handling the SIGINT and SIGTERM signals as a way to do a clean shutdown.  So I expanded that to include SIGSTOP, SIGUSR1, and SIGUSR2 to provide basic pause, prev, and next functionality via signals sent by the killall command.  Then I created a half dozen simple scripts in /usr/local/bin and recycled the media app buttons from IZ2S to run them.  Looks pretty functional...

I'm undecided about that ambiguous looking pause/play icon with the bar and arrow.

After a round of testing I realized I sorely missed the "now playing" screens from the web and gmuc frontend interfaces that I'd eliminated in the lean and mean setup.   So I added a handler for the unused SIGSYS signal to dump some now playing text to a file in /tmp.

It's simple, but it works.

I also found a convenient spot in the code to fix all the %20 text in the "now playing" song title from the web playlists.  You can see the result on the PLAYING line of the gmuinfo text above, and also in the marquee scroller on the SDL GUI.  Yes, you can actually read it now.  I also tweaked the code to skip the current song and playlist autosave options whenever a playlist is passed on the command line.  That makes so much more sense for my purposes.   To add the finishing touch I gave the gmuinfo script a ziptuner msgbox dialog style makeover, because I like it, and it was easy -- only 3 more lines of script code.

That purple border really hits the spot.

I think I'm getting to the point where some goodies should be made available.  So expect something of that nature shortly...

And, just like that...gmu is now on github, so I forked and added my patches.

I also made a pre-release executable tarball just in case anyone is desperate to try it.

And I stashed a substitute playlist fetcher script in my scriptuner repo.  It's a bit nicer than repurposing the links browser for that job.

Sound the Alarm!

 Well, wouldn't you know...  It's time for yet another holiday season to be "celebrated" under strict covid lockdown!  So I was gonna call this story "The Holiday Formerly Known as Thanksgiving", but I've already done that title, or at least something quite similar.  And I prefer to produce only the freshest nuggets of high quality content.  So instead of grumbling about the holiday that might've been, I'm gonna sound the alarm with this tiny tale of what can only be described as the most zipit alarm clock, ever.

This is the old clock, not the zipit clock

Now I realize I've dipped into this well before, but this time is truly special because I'm totally invested in the outcome.  You see my former alarm clock -- an all-in-one alarmClockRadioPhone purchased long ago when Radio Shack was a thing -- has finally passed on to another existence that clearly does not involve monitoring the passage of time.  It's dead, Jim.  And so it must be replaced ASAP lest I find myself late for some early morning Zoom meeting of ultra vital importance.  You all know how that is I'm sure.  Meanwhile, I'm an old crank so don't even bother to suggest how my smart phone can totally do all those things and so much more.  Yes, yes, I know!  But the darn thing has a touch screen interface, and that makes it simply unsuitable for covert operation in a darkened room.  Not to mention the screen blanker.  Great for battery life, but it renders impossible any sort of casual consultation upon return to bed from the usual 3 AM restroom visit.  And don't get me started on the bothersome late night texts, alerts, and spam calls.  That thing is banned from the bedroom.  So yes, I'm truly motivated to make the zipit clock right this time.

The zipit flipclock app of my former essays is pretty darn spiffy, but it's far too bright for nighttime use if you're actually planning to sleep.  And this can't be remedied without ruining the aesthetics.  So I reached a bit further back in the bag of tricks and took a second look at the ttyclock sources.  At first I simply tried it with red numbers and the largest font in my possession that could render it complete on the zipit screen.  The red numbers won't roast your eyeballs in the dark, but the digits are still sorta small for a quick glance from far away across the room.

You've probably seen this one before

Sadly, the largest font can only fit the hours, but the character height is close to ideal.

Not quite

Eventually it dawned on me that ttyclock emulates a BOLD font with double-wide digits.  So I whipped up a new build with a skinny digit option.  This version fills the tiny zipit screen with minimal waste when rendered with the 32 pixel tall character blocks of the large terminus console font.  As a bonus, that font is already used by my cheesy setclock app and the matching, if somewhat inadequate, alarm app.  At this point I felt I had an adequate replacement for the 7 segment LED display of the deceased all-in-one alarm clock.  

That's the stuff

But then I chanced upon the graceful lines of the gluqlo flipclock on github, and imagined how that might look in red.  The code makes use of sdl and a ttf font for the display, which makes it a really nice fit for the zipit.  So I hacked the code to add an option for red, and took it for a test drive.  It looks pretty darn sweet when viewed from a certain angle.  I also added an option to display an alarm time down below on the right in the margins.

I like it!

Even so the zipit is less than ideal for this purpose, with several considerable shortcomings, especially for nighttime operation.  The zipit's three status LEDs are simply blinding at night, and must be dealt with.  The adjustable screen and keyboard backlight gradients are far too granular.  Try it yourself.  Turn off the lights and press the ctrl-volume or shift-volume buttons to adjust the backlights.  There's simply too much light at the lowest setting above zero.  And the display backlight leaks out the side of the screen like nobody's business.  Meanwhile the optimal viewing angle on the zipit is quite narrow.  As you rotate outside the viewzone the digits disappear into the leaky backlight which washes over you with the cold white intensity of an auto headlight.  I swear you could read a book in that glare.  

I've addressed these issues as best I could, and have used the zipit this way for about two months now. So it's good enough, if only just barely.  My alarm and clock apps both use a wrapper script to temporarily disable the status LEDs.  It took a while to sort out the best method because we've got kernel notification events tangled up with the ebindkeys daemon.  The details for dealing with this are found in the small /etc/init.d/S11z2-leds script and the /etc/ebindkeysrc config file.  For temporary LED light relief it's better to set the triggers to "none" than set the brightness to 0.  And be aware that "S11z2-leds restart" does nothing.  You must use "start" to restart.  Also, ebindkeys does not restore the charging LED trigger properly after a notification.  For the backlights I decided I needed 3 levels of auto dimmer adjustments to tune it between daylight and sleep at certain hours, with a manual override via the spacebar.  To automate it I needed to put that fix in the gluqlo C code.  Meanwhile the alarm itself is still implemented in a wrapper script that runs in the background behind the gluqlo clock display.  

Nothing new here...

Perhaps someday I'll find the time to integrate the whole mess into the C code, and also incorporate a GUI for various music options.  In other news, while testing I grew tired of entering the time of day via the setclock app after every reboot.  The alt key for numbers gets wearysome.  So I added a webtime app to do it via the magic of the internet.  I also had to update the /etc/TZ file with explicit spring ahead and fall back settings.  eg.  EST5EDT,M3.2.0,M11.1.0

It looks right at home there

 The sources and bleeding edge openwrt zipit binaries are available on github.

gluqlo_wrt_be_1_1.tgz

ttyclock_wrt_be_2_0_1.tgz 

Weather Report

There's something about the weather.  People always seem want to know about it, including me.  So I've been searching, every now and then since like forever, for a simple weather app for the zipit.  The darn thing's got an alarm clock radio and plenty of music apps to help me start my day, and keep it going.  But what if I just want to go outside?  The zipit really oughta help out with that too.

So when I recently discovered The Right Way to Check the Weather with a short and simple command line (like curl wttr.in) I thought I was finally there.  The documentation said there were many options -- including some that seemed ideal for the tiny zipit screen.   But no, sadly, I was not quite there yet.  The zipit is simply not made of modern stuff, and so was not quite up to the task.  Actually that's not completely true.  An ASCII only -- black and white -- weather report is supported.  But who the heck wants that?  The weather is life itself, and black and white just doesn't cut it.

So I set it aside and went about other business, until someone else on the zipit IRC channel made note of wttr.in and got me thinking.  Apparently some ideas had germinated with the passing of time, because I now realized I could make a filter to re-tune the output for the zipit.  Yeah, that might just do it.

The two most obvious problems I'd noticed with the standard colorful weather output were the use of fancy xterm 256 color escape codes, and some utf-8 unicode glyphs that I just didn't have.  The old fbcon terminal only supports the escape codes for an ancient, under-powered 16 color palette.  And the tiny psf console font simply has no room to waste on a dozen subtle variations of the standard single quotation mark.  How many different ways can you tilt that thing?  And honestly, how often am I gonna use that lightning bolt glyph?  So I ran about a zillion weather reports from various airports (and some extra tall mountains) and built up an enormous sed filter to coral the nonsense into a smaller pallette and a reasonable character set.  As you can see, the 16 color spectrum is quite limited, but gets the job done adequately for the temperature and wind speed ranges.
 

Yeah, that "dark yellow" is really more brown than orange, but whatcha gonna do? 

Here's the filter script:

zipweather

After a while I realized the 5x8 zipit font provided just enough text to fit something slightly more advanced -- an actual forecast.

At that font size I can't actually read it, but I can still make out the pictures.

The zipforecast script should be available here shortly...

Update June 12, 2020

And...suddenly I'm reminded on the zipit IRC that the st-sdl terminal can handle xterm color escape sequences, so I had to try it.  I did a quick hack to set the display to the 320x240 zipit screen size and built it on the laptop to see if it was viable.  The larger color table looks pretty good.  I noticed that it also handles the UTF-8 characters, including the lightning bolt, which is a nice bonus.

Note the many subtle shades of orange and greenish yellow.

It was easy enough to build on the zipit.  But once again pthreads gave me segfaults when I tried to run it on a zipit with IZ2S.  Eventually I remembered to search the blog for hints on that.  This time I ended up linking with -pthreads before and after the SDL libs, and I also had to remove an extraneous -lc early in the link args to make it work.

 Once again, the weather here is mostly greenish yellow.

The truetype dejavu font struggles a bit at this size.  And it's taller than the 5x8 psf font, so some of the forecast scrolls off the top.  Also, I still need to add support for the weird zipit keyboard.  Gotta borrow that mess from links, or maybe pspmaps.

Update June 20, 2020

And...it turns out the clunky truetype font looks much, much better with antialiasing enabled, although It's still too tall.  And there are some questionable spacing choices on the 80 and the 86.  Is it a failed attempt at kerning?  Maybe I should add a command line option to select another font.

The trend is now slipping into the orange end of the spectrum.

Meanwhile the zipit keyboard works pretty well with a simple change to ignore the Alt key modifier whenever there's a nonzero unicode value available for a key press event.  All one line fixes so far.  I also borrowed a slightly larger chunk of code from the current X11 version of st to support for the DSR Device Status Report escape sequence required to make qe work properly.  It probably wouldn't be much trouble to import the truecolor escape sequence support from there as well.  But first I'd need to find an interesting shell app to test that with.

At this point I've got my st-sdl patches up on github and need to start thinking about making a release.

But first a quick distraction from the comments...  I took the mydingux SDL myterm program mentioned by user Unknown in the comments below for a spin.  And while it clearly does not support enough escape sequences to do a proper job rendering the weather, it does provide support for a nice shiny background image that I'm gonna probably borrow for st-sdl.

I do like the shiny stuff.

Ok, I realized that a colored background image is only easy if you don't support the escape codes for background colors on the text (myterm does not).  So I decided to release an iz2s st-sdl binary before I dive into that mess.

https://github.com/deeice/st-sdl/releases/tag/v0.3

Pandemic Coronavirus Lockdown Coding Weekend (formerly known as Easter)

Shortly after yesterblog, I discovered www.radio-browser.info was gearing up to switch over to a new API, cutting off the old incompatible API (and the ziptuner along with it) on August 1, 2020.  Uh Oh!  Better get right on that. 

So now in my third or fourth week (I've lost track) of coronavirus pandemic lockdown, with the impending deadline starting to loom, I decided to get busy with the API update.  The docs claim to "prefer" https, but after some initial success with http, I started geting 301 errors.  So I suspect the https has evolved from a mere preference into a full blown requirement. Ok, so be it. Cryptonecronom here we go again...

On the zipit, the openwrt build of ziptuner adapted just fine to the the new "secure" https API, but the IZ2S build had issues with the certs.  I have no idea where the ancient IZ2S build of libcurl expects to find them.  I was able to pass a cert location to the command line curl program, but was unsuccessful overriding it in the ziptuner code with curl_easy_setopt().  So I'm currently running the new API build of ziptuner for IZ2S with cert verification disabled.  I don't see how that's any less secure than the original http API, so I'm not gonna sweat it for now.  But I'll keep trying...

In the meantime, I managed to squeeze a bit more utility out of the dialog program, making use of backsplash option to show the selection number of whatever station might be currently playing.  Just in case you scroll further down and forget...

I'd like to play some Groovetube, but wait, maybe I should save station 56 first.

Unfortunately this puts the squeeze on size of the station listing box, slicing off a few more precious lines.  So I limited it to screens of 24 lines or more.  On the zipit that's the iz2slat font, or something even smaller.

I also did a bunch more code cleanup and bug fixing.  The code is still not pretty, but it's inching ever closer.  Good enough for a ziptuner 0.6 release on github to support the new API.  And I've included an updated IZ2S binary with the certs.

Bunny tax.  My daughter suggested this, to brighten things up.