Wednesday, November 25, 2020

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 



Monday, June 8, 2020

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

Sunday, April 12, 2020

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.


Sunday, March 1, 2020

Saved at Last

This blog really needs some new life, maybe gotta take it in a new direction because the previous post is dated well over a year ago.  Yikes!  I suppose the problem here is that I really haven't done anything for a long while that felt interesting enough to discuss.  And then time passes and leaves me behind.  Youtube moved on, dropping support for the smaller, lower bitrate video streams of the past, as google is known to do.  So nothing suitable for the zipit.  I think that killed some of the spark that motivated my tinkering.  Keeping up with youtube on the zipit had become something of a quest.

At the same time, a 64GB micro-sd suddenly went read-only in the zipit I use exclusively for music in the car -- with only 34GB of the storage actually used up.  I can still play the music on it, but can't add any new stuff.  So much disappointment in such a small package!  I wasn't using that particular zipit for anything else, so I gotta assume maybe rockbox does too many small writes, possibly saving the current song location?  But I really don't know.  So I started over with a new 32GB sd and some new music.  I also went back booting into rockbox from the internal jffs instead of the sd card.  I'm pretty sure the internal nor flash supports many more writes, and the jffs most likely does much better wear leveling than the junk in the sd card.  Perhaps in time I'll regain the confidence to try a bigger sd again... 

Meanwhile I finally retired the old iphone 5 and got a new android phone. And the car supports android auto, so I figured I'd see how well that works.  After using it for a while, I'd say it has potential, but Rockbox is still a better interface for my stash of mp3s than any android app I've tried so far.  Musicolet is ok, but the android auto interface stinks compared to the one on the phone itself.  So much failure is built into car touch screens.  Don't get me started on the software built into entertainment system of the car itself.  A touch screen is a really stupid interface for a car because it forces you to look away from the road, unless maybe you've got a robot behind the wheel.  I don't have one yet, so Musicolet demands I stop touching and speak to it whenever I hit the android auto screen more than once a minute.  Makes sense, but I'm just not quite ready to go there yet.  And anyways, how's all that talking supposed to work when the music is blasting?

Also in the last year, at some point, Notepad++ was driving me nuts on the junky Windows machines I'm forced to use from time to time.  So I took up the defunct Windows port of qemacs and "finished" it.  There, that's much better...


Yes, I confess.  I do still use Windows XP sometimes...


Apparently there's loads of fairly new unreleased goodies in the official qemacs repository.  I need to play with all that and see what I like.  So I made a separate qemacs fork in my github, and updated the Windows fixes to fit.  I'll probably put it on the zipit as well someday and see if all the new code bloat is worth it there.

OK, so by now if you're paying attention you're probably wondering about the title of this post.  Yeah, I know.  If you got this far, you've already forgotten.  It's "Saved at Last".  What's all that about, you say?  Well, one area where the zipit still excels in my mind is for internet radio.  For that the zipit still works best for me.  But there was one key feature missing from the ziptuner.  It gave you the ability to find, sample, and save stations, but you still had to use another app to make use of the saves.  I finally got around to fixing that.  Hence the title.

Originally the ziptuner was supposed to be a quickie hack to fill a gap on the zipit.  At the time, there were several apps to play internet radio, but no easy way to find new stations and save the urls.  Hence the need for the ziptuner.  But the ziptuner grew up as I used it and learned what I really wanted it to do.  Unfortunately the code grew in the same haphazard fashion, new bits grafted on here and there, with no real plan or design.  It's a real pain to debug ncurses apps because they take over the screen you want to use for the debugger.  So bugs crept in and went unfixed.  Eventually I could no longer stand to even look at the code, much less work with it.  So I never added that final critical missing feature. 

Well, eventually it dawned on me that I could use Xdialog on my laptop as a cheap substitute for the ncurses dialog program.



It's missing some of the advanced button options.  But I could work around that, and it frees up the text console for the debugger.  So I was finally able to test and fix things in a comfortable debugging environment.  The ziptuner was saved at last from the code rot!

While smashing bugs I identified some code symmetries, allowing me to break it up into more manageable chunks instead of the deeply nested nonsense that it once was.  And when I could see what I had, I knew what I could do next, and voila!  Option 9 -- List Saved Stations -- was born.

 

Here's a sample Saved Stations list from my zipit.  Gonna play me some Groovetube.  And I'm all hooked up for Saint Patty's day in two weeks.  I'm pretty excited about it.


There's still more to be done.  I eventually added a -a command line option to resume playing a saved station on startup.  But the .pls format support is unfinished.  At least now there's some hope for that...