Tuesday, October 16, 2018

Where do we go from here?

This blog seems to be running out of steam, or maybe it's just me.  Anyhow, I guess it's time for an update of some sort.  So I'll have to cobble something together to fluff up the word count...

Some ideas to write about include:

Compiling code for the zipit on my chromebook.  That was fun.
Tinkering with voidz linux on the zipit.  Also sorta fun.

My original plan for the chromebook was to use the compiler from chromebrew to make a smallish static dietlibc build of the current movgrab source code to work around a problem with the musl builds.  The chromebook has an arm processor, so many static zipit executables actually run on it, allowing me to test things without having to transfer to the zipit.  More on that here:

https://mozzwald.com/irclog/zipit/2018/05/28

My hopes for dietlibc were many.  It builds smaller static executables than other libc implementations.  It might not have the socket reuse issue I was getting with musl.  And it had a recipe for building a static openssl, something that had eluded me last go around when I made the static uclibc build of movgrab.

I got dietlibc working, and made a static qemacs with it, but the movgrab build never came to fruition.  I suspect it really only works with glibc, and glibc now actively resists static builds.  So I gave up.  But then the voidz linux distro got created for the zaurus and and seemed like it could be a really nice fit on the zipit, with musl and no systemd.  I didn't have a compiler for it, but wanted to give it a test drive.  So I went back to the chromebook and built a set of static executables to let me run the ziptuner.  This tarball has ziptuner, dialog, mpg123, with some config files and scripts.

ziptuner_static_with_dialog_and_mpg123.tgz 

The executables are all static builds that I compiled and tested a bit on the chromebook.  The ncurses setup on the chromebook has issues with terminfo and I remember mpg123 was a bit of a challenge, but I eventually managed to coax some sound out of it. Unzip it into /usr/local on voidz and run ziptune to give it a try.  It might also work on other zipit distros due to the static executables.  For all the trouble it gave me in the build, the mpg123 executable actually runs pretty well on the chromebook.

Here's a shot of the ziptuner compiled and running on voidz.

I'm hoping to try and learn how to turn ziptuner into an actual xpbs package for voidz.  We'll see how it goes. 

Saturday, April 21, 2018

Return of the Toys

I'm not sure where I'm going with this, but I'm gonna take some notes here and just see what happens.

Not long ago I was doing my semi-annual browsing at ldraw.org, just poking around to see what's new there.  Coincidentally on that very same day, someone happened to submit a small enhancement request for lsynth, an ldraw program that I took on maintenance duties for many years ago when the original author ran out of steam.  It was a simple request for an addition to the config file, no coding required, so I thought why not?

Naturally things got more difficult and I ended up moving both ldraw projects that I pretend to maintain from the sourceforge over to github.  The sourceforge has been troublesome lately, and I'm now more familiar with github anyways.  And besides, there always the hope on github that someone else will fork it, pick up the slack, and add new features.

It didn't quite work out that way.  Shortly after I moved the two programs, I started getting bug reports and feature requests.  Who knew there was still any demand for the old stuff?  And why do I still have to do all the coding?  Oh well, at least these were high quality, interesting topics. Like how to get a synthesized rubberband part to fit properly on the pins of these wheel holders, when the pin is not aligned with a convenient axis and the parts are rotated in different directions.  I eventually remembered enough math to get it fixed.



I should probably put together a new lsynth release with that fix, but no sooner had I completed it when the ldglite requests started rolling in.

The idea behind one of the ldglite enhancement requests was to change the transparency rendering for some "faded" parts so the rear faces and edge lines don't show.  It wasn't to difficult to whip up some test code that does it with an extra run through the render, updating only the depth buffer, before a final render pass to draw the edge lines.  It should be reasonably fast if I only do it for certain transparent parts.  At least that's the plan, I think...

Here's a picture.  More later.


Another aspect of that feature request was to support more than one level of transparency in ldglite.  Ok, ldglite uses an ancient deprecated polygon stipple technique for transparency.  And back in old school days, when there were 16 or at most 256 colors available, we had some commonly used 25% and 75% stipple patterns to mix up some more colors.  So I added those to the 50% pattern already in ldglite to get to three levels of transparency for fade effects.  That should be enough.  Hopefully downsampling the new patterns won't produce any painfully hideous aliasing effects.

Here's a shot with the 75%.


And here's the 25%.


Another of the requests was to come up with a simple way to provide a glowing silhouette in some selected color for certain parts.  I've started work on that, but so far I only have this really unimpressive picture.  For some reason the opengl driver is ignoring line widths (and antialiasing) so the glow is reduced to that feeble yellow outline that you can barely make out on the black technic pin.


Heh, it turned out to be a bug by me that made the yellow glow lines so thin and feeble.  But no matter, it also happened that my clever plan to use only type 5 ldraw lines was not so good.  That doesn't actually provide the entire silhouette.  So it was back to the drawing board for this one.  I gave up on cleverness and implemented the well known stencil buffer silhouette technique.   Unfortunately the stencil buffer commands always seem to confuse me, but eventually I connected the right bits in the graphics pipeline and got a decent halo.
 

I just wish I could convince myself I knew what I was doing.  But the sad truth is I don't.  You see, I'd really like to have the yellow silhouette showing slightly through the 50% transparent part.  But the stencil setting that I thought would do it had no effect.  Oh well.  Maybe I'll get it eventually by trial and error...

Or maybe not.  It just occurred to me that it's not the stencil function blocking the glow inside the faded part, it's the depth buffer blocking all edges inside the faded part.  I'll have to try moving the drawing of the glow lines to before the depth buffer writes are done for the faded parts.  That just might work.

Anyhow, the final request (so far) was to allow a wider range of color codes that will make these new features more compatible with the calling program LPub3D.  I've added some code for that already, but it's not something that provides a spiffy picture.

Tuesday, January 16, 2018

Long Time No Talk

I haven't done much worth writing about lately.  Or maybe I've just simply been too busy doing other things.  I don't know...  So I'm just gonna jot down a few brief notes for now to keep this zombie blog twitching.

On the zipit IRC we recently started tinkering with Devuan.  So far, it feels pretty similar to the old Arch distro from two years ago, except you have to mount the SD card on your PC in a qemu chroot to fetch packages.  That's not as difficult as it sounds, so it's not huge burden.  I noticed that several of the executables I built for Arch, like qemacs and gmu, actually work on Devuan as is.  Probably because they're both based on glibc.  Anyhow, that's handy.  But I'm still getting up to speed compiling things in the Devuan chroot.  So far I've built a working version of the ziptuner, but not much else.

Meanwhile there's a few new tidbits for the bleeding edge openwrt.  Here's a picture of the new wavemon package running on the zipit with the 5x8 font. 


The Fn keys shown on the botton don't exist on the zipit, but you can still get to the other screens by pressing the first letter of the screen name.  So the keyboard support seems good enough for me on the zipit.  However, a few strings in the messages could possibly be shortened to make it all fit.  Maybe I'll whip up a patch for that.  I'd also like to make a patch to build it with libnl-tiny to make it smaller, but that's not really a priority

What else is there?  About the only bits I remember are a small update to the ebindkeys package to make the stop button work with the default gmu shift-esc key combo.  Maybe I did some more work on the unfinished stppc puzzles package?


Part 2.  The Long Lost Holiday Special.

As you can see above, somehow despite a personal record, due to procrastination, of 2.5 weeks off for Christmas and another full week for Thanksgiving, I managed to accomplish next to nothing during the holiday season of 2017.  Well, maybe I got caught up on some classic science fiction reading from the 50's, 60's, and 70's.  But nothing worth mentioning here.  So instead I decided to relive some former glory and attempt to recollect the events that transpired near the end of 2016.  Around that time I had a really nice burst of energy and enthusiasm that has gone undocumented here for far too long.  I need to sort it out and finally start tidying up some of the loose ends before I forget it all completely.

 At the very least I'd like to rediscover my recipe for building an iwmmxt enhanced mplayer executable for openwrt.  I'm almost 99% certain that a zipit running bleeding edge openwrt was publicly demonstrated to play video streams (with proper lipsync) that were located with the links browser through mozzwalds zipit friendly youtube search portal, then fetched with movegrab and piped into an iwmmxt enhanced mplayer for a seamless streaming experience.  For now I might be happy if I could simply recover enough notes to make an iwmmxt howtobuild.txt file and check it into the files directory of the openwrt mplayer github project.  Unfortunately it turns out the whole sequence that culminated in that public demo involved more cheating and hackery than I care to remember.  The bleeding edge movgrab package was even more challenging to put together than the iwmmxt enhanced mplayer, but we'll get to that later.

Anyhow, I'd also like figure out what sort of loose ends I left when I created the openwrt rockbox package around the same time, so can pick up the slack and clean it up.  Right now I'm thinking the battery monitor code was unfinished and maybe I need to borrow some eq files from the iz2s build?  This could turn out to be really important to me.  Here's why.  After 10 years in the same old car I finally gave up and got a new one.  Apparently the new car can play music off a usb stick, or an iphone, or whatever else you might have via the aux input jack.  But the software is a total mess.  The USB interface only recognizes mp3 files and presents them on screen in a confusing mishmash of unrecognizable numbered folders.  I mean who in the world thought that listing random numbers for folder names instead of the *actual* folder names from the USB stick was a good idea?  At least the auto maker Honda was nice enough to include an aux port, so the zipit is still golden if I can keep it running for another 10 years or so.  By then I expect to have a robot valet to drive my flying car and manage my music collection.

So, here's the story.  It started in the run up to Christmas 2016, when I managed to put out a few updates to various zipit goodies, mostly for the bleeding edge openwrt.  For example, at some point I made a bleeding edge tinyirc executable.  It's handy for a zipit internal flash installation, if for some reason you can't get an SD card going.  There's better IRC clients in the bleeding edge package repo if you're running from an SD card. Than in May 2016 I finally fixed a rather annoying "feature" of qemacs that had been driving me nuts for some time.  Normally, in full up gnu emacs, whenever you type a close bracket (be it round, squiggly, or square) the electric parenthesis matching function flashes the cursor briefly over the matching opening bracket and then returns to your current position.  I love that feature when developing code.  But the qemacs version of this was failing miserably on the return.  You can probably imagine the confusion that causes when you're feverishly coding, only to realize the text you're typing is inserting itself into the wrong place, and has been for quite a while -- ever since you closed your last parenthesis.  It was especially horrifying pasting a large block of code only to see it crumple in upon itself in slow motion, creating a total jumbled mess of nonsense to clean up.  I finally had enough and patched the code and uploaded a bleeding edge executable.  Eventually I remembered to update the github repositories too, so the current bleeding edge openwrt package should also contain the fix.  I probably ought to upload a new iz2s executable, or maybe even make an update the old uz2s image from 2015, when I find some time.

In October I picked up speed heading into the holiday season and compiled a zgps executable for bleeding edge, and also updated the pspmaps and navit executables for iz2s. Toward the end of October we got a request for opus codec support, so I built libopus and gmu10 to make use of it for the bleeding edge  openwrt.  These might be real packages at this point, but I can't remember.

As the holidays approached I determined to get the video player integrated into bleeding edge openwrt, just like it was in IZ2S and the older openwrt system based on uClibc.  I wanted to browse for music videos on mozzwald's youtube search portal and have them play in realtime, right from the links browser.  We had a working mplayer package, right?  So I figured we just needed to fix up some musl compile issues in the movgrab package and add some configuration glue to the links package.  How naive...

After fixing some minor compile issues with musl header files, I discovered movgrab had a problem with the musl implementation of select or poll.  Been there, done that with gpsd and such.  So I rewrote a FDselect wrapper function in the movgrab libUseful code to add a timeout. otherwise it would block for something like forever when printing out the available video formats, and when fetching the actual video stream url.  Or so I thought... Eventually I got to thinking it was a socket reuse problem in musl, and not actually another problem with select.

Unfortunately I never solved it.  Instead I compiled a cheezy static version movgrab on a zipit with the old openwrt.  That got it built with uclibc instead of musl.  But I didn't have the ssl or crypto libs and include files on the zipit where I did the compiling, so instead I built a really bare bones movgrab.  What a mess, but it seemed to work, even on the bleeding edge zipit. If you look real close at the bleeding edge movegrab package files on github you might notice the static movgrab executable in the files directory.  When you build the package, it goes to all the trouble to compile a musl executable and then slips in the old static executable instead.  :)  Wow.  I am a total cheater.

Sadly it longer seems to work with youtube, probably due to the missing ssl or whatever restrictions fell out of the recent Amazon Google spat over access rights.  But maybe I can finally spend some quality time now and fix up the musl build the right way.  Or else try to compile an up to date static build in the devuan chroot we've been using lately.  Hmm...possibilities.

Anyhow next up was the links config glue.  However while testing various implementations it was revealed that the lipsync was off.  The sound would play at normal speed, but the video would gradually fall further and further behind.  Apparently it was like this in the iz2s and the old openwrt.  We were so close, so we twiddled with all the obscure mplayer mplayer runtime config settings, but it could NOT be convinced to coax it into sync.  So we had to go for some compile
optimization, the tricky iwmmxt code buried deep in the guts of mplayer.

At first I thought, naively again, that it was simply a matter of fixing the openwrt mplayer package makefile to add the mplayer iwmmxt config setting.  But no...  nothing is ever so simple with the zipit.  Openwrt insisted on adding -march=armv5te and -mcpu=armv5te to the compiler switches, overriding my iwmmxt setting.

So I made a script to do a swap in the makefile and then a rebuild.  That almost worked.  But -- and this is where my memory is failing me -- I could swear that I also had some compile problems somewhere in that mess that forced me to turn off iwmmxt for a couple of files.  But I don't remember if I did that by editing the source code, or by recompiling them individually with the armv5te settings.  I also vaguely remember getting it to build and then having to debug some segfaults caused by the iwmmxt code.  Maybe that's what triggered me to rebuild some of it with the armv5te settings.  I need to dig this up from the IRC logs and from my openwrt build area so I can reproduce it.  Anyhow at some point I got it to build.  The lipsync worked, so I stashed the executable and finished up the glue code.

And here's the proof.

High on success, I buried all memory of my sins and moved onto rockbox in an insane attempt to turn that into a viable bleeding edge openwrt package.  Apparently rockbox also had a problem with the musl select function.  I wish I could remember the details of that fix.  I couldn't even remember if I built the plugins.  Anyhow, I got rockbox to work, and got it to build as an openwrt package from a much more recent rockbox source snapshot.  I also managed somehow to include all the plugins in that package.  But I believe the keymaps for those plugins were just some quick and dirty hacks to make them compile, and so they probably still need some serious work.  And there were some changes to the rockbox battery handler code that prevented the zipit battery detection from working. However I abandoned rockbox at this point, and moved on.  A year later, I couldn't remember why.  But most likely the reason I stopped was that openwrt was fighting me whenever I tried to recompile it with the standard openwrt trick:

  make package/rockbox/compile V=99

Normally that would build only the rockbox package, and give me some nice verbose compiler output for it.  But instead of the detailed compiler messages I needed, it was feeding me some useless error message that told me absolutely nothing.  This got to be very frustrating, so I moved on in March (without polishing up the loose ends) when I got a request to help integrate my ancient ldglite project with into LPub3D.


Part 3: Moving Forward


I now suspect my woes with the openwrt build system might've been caused by some extra directories like junk and gitfiles that I'd created inside the rockbox package feed directory to hold some temporary backups and test files.  Weird!  In retrospect, I'm thinking maybe gitfiles was a bad choice on my part. I gotta remember from now on to hide any backup or working directories in the files directory.  That seems to be a safe place to stash temporary junk without breaking the build.

Once the build system was working, I finally felt like I could make some progress again with rockbox.  So examined the android battery support code and fixed up the zipit battery code in a similar way to make it work once again.  Only a year or so late...  Anyhow, the rockbox package has finally been updated with a working battery monitor.  There are some hints in the android code that rockbox could be made to work off the system volume control and also possibly use the system headphone detection, so I may tinker with that.

I also want take another look at movgrab to try and match up socket closes with each and every open.  See if that makes it allocate new sockets properly in musl...  I might also add more calls to fflush(stdout) so musl doesn't block it on printf calls with no linefeed, kinda like I did once upon a time with tinyfiledialogs.

Meanwhile, there's also a few other odds and ends that I'd like to remember here if I can find the time.

I made handy setclock utility for times when I want to edit files with proper timestamps, but the network is down.

I compiled drumtoy but did not make it a full package yet.

I also compiled a very simple game, ativayeben as sort of a turkey day special.

Saturday, June 10, 2017

sdlvnc redux

This time I was really planning to make something useful out of the fgui code and prove to myself that it was good enough for whatever.  But... once again something else came up that captured my attention and I lost focus.  Someday I swear I'll finish.  Just not today.

So what happened was this.  I was minding my own business, lurking on the zipit IRC channel, when someone mentioned how he wanted X11 on the zipit to serve as the remote display for some other gizmo.  And that got me thinking...  Sounds familiar?  Yeah I know, it's the same story every time.  Oh well.  I just roll with it and see where it takes me.  This time it took me back to sdlvnc -- another project I never quite finished.  But maybe things would be different this time.

Anyhow since a modern X server is a bit heavy for the poor little zipit I figured let the remote gizmo do the rendering to a local headless X11vnc server.  Then you can run the less resource hungry sdlvnc client on the zipit if you want to see it and interact with it.  After all, if that other gizmo has the horsepower to run X clients, the it can probably run an instance of the X11vnc server too.   That's a much better use of the available resources.  Of course I've visited this particular problem before, but I never quite finished, and left some serious quick-N-dirty hackery in the sdlvnc zoom code.  Also I never made it  into a real openwrt package.  It was finally time to get serious about it.

First I got the old sdlvnc code working again by compiling it right on the bleeding edge openwrt zipit. In the process I fixed a few bugs with the connection setup code that I'd known about previously, but never bothered to fix.  It felt real good to finally get those out of the way.  Next I created an openwrt project for it and got a real sdlvnc openwrt package built.  That was also quite rewarding. In the process I also fixed the ebindkeys mouse emulation code to make the zipit mouse tracking less jumpy, so there's a new package for that as well. And, since everything was moving right along, I thought I'd step it up and tackle the zoom code.

The problem here was that I'd done a quick paste of the sdl_gfx zoomSurface function into the sdlvnc code the first time around.  That function is really intended for rescaling small sprites and images, and not so much for working with the entire screen.  It worked, but the performance was awful.  That's  mostly because the linear interpolation code is only written for 32 bits per pixel surfaces, so the 16 bpp vnc screen surface had to be converted, zoomed, and then converted back for every refresh.  All of those surface copies were created and destroyed on the fly by zoomSurface, for every screen refresh.  Yikes!  That's a lot of memory, and a lot of copying. It was wasting a third of a second per refresh for a 640x480 screen on the vnc server, and was even more excruciating for bigger screens, when it didn't crash for lack of memory.  So, I decided to add a 16 bpp path through the sdl_gfx zoomSurface function to eliminate all those wasteful copies.

I scribbled lots of notes and pieced it together a tiny bit at a time in the evenings, starting from a copy of the 32 bpp zoomSurfaceRGBA subfunction in sdl_gfx. Surprisingly, two or three weeks later when I tried it on a whim, it actually worked.   That never happens.  So for the next few days I cleaned it up and ran some timing tests.  The 16bit path was running in about one third the time of the 32 bit path -- a tenth of a second or so to zoom the 640x480 screen.  Much better, but I was hoping for more.  What to do next?  I was pretty sure small constant array offsets were essentially free in modern instruction sets, whereas maintaining an extra set of nearly identical pointers was not.  So I worked up some inner loop optimizations and squeezed another 12% speed gain out of it.  I also discovered that the code runs much faster the more you zoom out because it skips over more of the inner loops.  That's a nice bonus.  So converting 640x480 to 320x240 only takes about 0.03 seconds.  I can live with that, so I think I'll call this one finished.  Here's what it looks like.

I love the way the mouse pointer also gets scaled in zoom mode.

It's almost useful at that scale.  But now you can zoom in and out pretty much at will, so that's not such a problem.

Now I just need to find some new project that'd be great to have on the zipit, if only the display fit in the 320x240 pixel zipit screen.  I'm sure I passed up a few of those over the years...

Saturday, April 1, 2017

April Fooling

It's April 1st, and the weather gods have once again played a nasty little joke, dumping a chilly mix of snow and ice onto the lawn.  So I decided to make the best of it, staying inside and tinkering with some zipit software that's just barely past the idea phase.

One such idea that I keep revisiting is how to make the gmenu2x GUI more versatile.  So this time I thought, perhaps I can do it from outside the box.  Maybe I can make some scripted modal dialogs that could launch from gmenu2x, but run outside of gmenu2x and simply display over it temporarily.  Or maybe we could find a use for popup notifications that post themselves over gmenu2x temporarily.


So I grabbed a few small example programs that open /dev/fb0 and write directly to the screen.  And that's where I am right now.  I can save the gmenu2x screen, write over part of it, and then restore it when I'm done.  Not too exciting, but lotsa potential, especially if I pull in the fgui code for some nice looking widgets.  Fgui makes for a nice fit because it's only requirements are a pair of get and put_pixel functions, so it's easy to graft onto any sort of graphical backend.

With any luck, I'll have an actual dialog screenshot before the snow melts.

Update April 2

And there it is...
Check out that shiny new icon for the ziptuner.  Pretty sweet eh?

Ok, it's not an actual dialog, but it is a small chunk of the fgui demo program -- reworked with /dev/fb0 as the backend instead of the original sdl backend.   The new backend  lets me pop it up over the gmenu2x display and tinker with the controls.  There may still be a few patches of snow left in the shadows beneath the trees, so I think I'll call this a success.

It'd be even better if it used the /dev/fb1 overlay screen so I could display the popup with no worries about contention with gmenu2x screen updates.  Unfortunately there appears to be some bugs in the PXA video driver that make the overlay less than optimal for my purposes.    Perhaps I can do a workaround someday for the overlay, but first I want to try and make what I've got do something useful.

Tuesday, March 14, 2017

Back in the Groove

Um... yeah, it's been a while since I wrote much of anything around here. For now I'll simply blame writers block.  I've got lots to say but just haven't found the motivation to say it.  Spending more time doing than talking about it, I suppose.  So, in order to keep this particular train rolling, I selected an encouraging title in the hope that I could somehow get "Back on Track".  Unfortunately I already used that title -- this must be a recurring problem -- so I tweaked it a little.  I hope it works.

To get things started I'm just gonna post a picture or two of my current pet project, the ziptuner -- a tiny internet radio browser program for the zipit.  For just about forever I've wanted something to make it easier to acquire, try, and save internet radio station urls for my playlists on the zipit.  This is what I eventually came up with.  It's uses the nice clean http://www.radio-browser.info json API.

Here's the main screen.

Actually there's a few more choices now, but I'm too lazy to update the picture.

And here's the results of a Tag search for "disco".

Only 43 disco stations on the internet?  I find that hard to believe.

I'm truly impressed that someone -- more than one someone, actually -- found the need to devote a full 320Kbps to stream disco to the teeming masses on the internet.

Anyhow, that's it for now because it's still more fun to work on a project than to write about it.  So I'll try to revisit this page again when I run out of ideas.

Meanwhile openwrt packages are available in the usual place.

And here's an iz2s build:  ziptuner-iz2s.zip



Saturday, September 24, 2016

End of the Road

I think I'm finally gonna wrap up the never ending thread here about the zipit GPS.  Last time I tinkered with it was well over 6 months ago when I rearranged the pins in the zipit end of a Dell Axim cable.  I got a brief respite from lawn duties this summer when both the lawn and the garden shriveled up from the summer drought, leaving me free to play with the zipit for almost an entire weekend.  So I twisted the three wires together on the GPS end of the Axim cable and taped it up.

That's some crafty workmanship there.

I had to break out the kids optic / survival toy again so I could double up the lenses and see what I was doing.  I love that thing.  I swear one of these days I'm getting something just like it for myself, except with a light and a way to strap it on my head.

Yeah, I know.  Who needs a GPS when you got one of these beauties.

Surprisingly, the serial GPS actually worked right away.  Well sorta.  Apparently you have to flip the thing so the antenna side faces up.  That took me much, much longer than you might imagine to figure out.  And it still bites me about every other time I try to use it.  What are the odds of that?  Anyhow, I spent some time off and on over the next few weeks tinkering with the software and made my NMEA parsing code in pspmaps somewhat more robust before taking it out in the car for a road trip to Boston.  I had a brief moment of panic when I laid the GPS on the dash, antenna side down, and the map refused to move.  Darn it.
Antenna side up works better.

Here it is tracking one of those seemingly endless miles we covered on the highway.  You probably can't see it too well due to my shoddy camera work, but the route is mapped out in a blue overlay.

Beware.  Shaky-cam gives me a headache.

Sadly, this is the wife's car so the background music is provided by "Boston's favorite radio station", and not my awesome collection on the zipit.

This GPS runs off the +3.3V line exposed by the zipit expansion connector, so it works just fine on battery power only.  That's a distinct advantage over the USB GPS.  And now that the weather's cooled off a bit, my wife has started agitating to do some local hiking.  So I'm planning to take the zipit along to see how far its ancient battery will go with the GPS active.  Hopefully we won't get lost.

Another advantage the serial GPS over the USB GPS is that it works on an IZ2S SD card with the stock zipit kernel and bootloader, so no flashing is required.  Just pop in a mini SD card loaded up with IZ2S and boot.  No hardware mods are needed either, other than slicing up the Axim cable.  So I left the scary soldering gun in the closet.  You could conceivably do this with an off the shelf zipit, if you could find such a thing, and a mini SD card loaded up with IS2S.  I've got the new pspmaps installed now on the old zipit with rockbox that I keep in the car at all times for music that's never been heard on a ClearChannel playlist.

For the code I reworked my built-in NMEA serial polling module in pspmaps, so now it's configurable by editing a very simple gps.dat file in the pspmaps/data directory.  And it's also now robust enough to handle multiple GPS disconnect / reconnect events.  It'll still try to use gpsd if it finds the gpsdclient shared library, but I wouldn't recommend that unless you really need to multiplex the GPS data to more than one client program for some reason.  The pspmaps sources are updated on github.  And it's also bundled up in a package for the bleeding edge openwrt zipit linux distribution.

Last but not least, I wrangled some example code from the internet into a script so I can quickly set the system clock on the zipit from the GPS.  That might be handy if I were to go on an evening hike away from the wifi and just happened to lose my watch and phone, but not the zipit and GPS dongle.  :-)

Here's the script.  It also saves the fix location to a file in /tmp.  Maybe someday I'll add an option to the nightsky program to look for that file.

gpstime.sh

Here's a new IZ2S pspmaps executable.

pspmaps-2_4_2_2-iz2s.zip 

This is the new "bleeding edge openwrt" pspmaps package

pspmaps_337334a711-2_pxa.ipk

I also have an executable for the older openwrt distribution (built on uclibc instead of musl) but I have to track it down and maybe make a package.  I'm pretty sure I posted a link to it, so you can search for it in the zipit IRC logs.  Or just make the move to the bleeding edge openwrt like everyone else.


Update October 1, 2016:

Did I say "end of the road"?  Oops.  No sooner had the words hit the internet when I was reminded on the zipit IRC channel about zgps, my specially resized version of cgps for the small screen.  So I bumped the patch to match the newer gpsd in the openwrt zipit bleeding edge repository and compiled it.   Mozzwald ran a build, so the tweaked cgps should now be in the gpsd-clients package, and I stashed an executable here for just in case.

zgps-bleeding-wrt-exe.tgz

I was also reminded that I left my Navit port in limbo, only lightly tested and full of potential.  So I dusted it off and fetched a new chunk of map to test it with.  It's still sorta slow, but apparently works better on the zipit than I remembered.  Here's a screen shot advertising the many varied attractions of downtown Springfield.
Plenty of parking, but watch out for that nuclear waste dump.

Is that a soccer ball?  Anyhow, now I'm gonna have to hook this up to the GPS and see what it can do...


Update October 12, 2016:

A few heavy duty road tests later, I can honestly say the performance of navit is not too shabby on the zipit.  I tested the IZ2S build first and had no real complaints.  Maybe the 3D view was a teensy bit laggy at highway speeds, but I can't really say, because my eyes were mostly glued to the road.   Really, I swear!  Safety first...  Next I created a build for the zipit openwrt bleeding edge and tried that out.  No complaints there either, so I made a package and hooked up a gmenu2x launcher for it.

Starting navit from the GUI is so much easier than a command line launch.

The openwrt package is in the usual place.
navit_0.5.0-1_pxa.ipk

I made a new IZ2S package as well, refreshed to the newer source code that I used for the openwrt build. Since I don't use the locales on IZ2S, and they take up a boatload of space, I broke them out into a separate zip file.  The navit package also requires glib if you don't already have it.

navit-0-5-0-iz2s.zip

navit-0-5-0-locales-iz2s.zip


Next, I'm considering borrowing the pspmaps google route fetching code to make navit textfile maps so you can get a route via wifi and then hit the road with navit.  And then if I feel really ambitious I might just try to make it speak.


Update November 31, 2016:

I made some progress on a small pspmaps to navit route converter app for gmenu2x.  You can find a link to it in the IRC logs, but I have to redo it somewhat to work  better with the openwrt flavor of gmenu2x.

Meanwhile mozzwald took the navit package, enabled lots of stuff and took some much cleaner videos than mine.   No shakey-cam.  Since he hasn't blogged about it yet himself, I feel compelled to show one here for now.  It's got the 3D display, OSD elements, Flite text to speech, and on the fly routing enabled. 



Altogether it's a bit of a jumbled mess, but some of it's actually useful in limited situations.  Apparently active routing actually works on short trips. I was a bit surprised by that.  Must be the zram that makes that possible.