satellite signal strengths
Yeah, I'm just about ready to connect a trimble sv6 (thanks again dbrashear), and noticed that without a signal strength display it is kind of hard to figure out where a good place to mount the the antenna would be.

waypoint logic gets confused
Noticed it as well, it screws up on just about any route that 'backtracks' or has an interesting twist. I guess part of the problem is how I pick the next waypoint, it suffers from things like locking on to a local minimum. I could change it to something that tries to keep track of exactly where we are and refuses to jump to a completely different point in the route. Adding something to select to the prev/next waypoints should work nicely with that.

toggle the textual instruction
Long press the down button (something like 2-3 seconds), or do you mean disabling the popup route description?

scale marker
Interesting, I just added that for debugging, hadn't even though about whether it would actually be useful. I can move it over to the other side, that's not a problem at all.

rotate the map
Guess I am too much of a boyscout. I like maps, always have, and probably always will. So I typically have a pretty good perception of where north is, and I can easily look at the small route on the empeg screen and match it up with an actual paper map.

There are a couple of problems with rotating. First of all we need to do a transformation, involving sines and cosines for the rotation. These floating point operations are impressively slow on an empeg, and I was trying to keep CPU usage low enough so that the main application (player/visual) doesn't really notice anything else running at the same time
Then the screen is only 32 pixels high, we can move the 'center' down a bit, but what we just drove might be useful in figuring out what kind of a turn we're in and such. So there isn't much we can really see in the remaining ~24 pixels worth of screen. And then we also get largely useless 48 pixels on each side, since most routes will hopefully approximate a straight line between point A and B. But still, it might be worth a try.
And last, but probably not least, as ellweber remarked earlier as soon as the speed drops below something like 1-2km/h the direction reading is useless. The next version will jsut lock the bearing to the last measurement before we dropped below some speed value. I guess it will be ok most of the time, but when making a slow turn the map might not follow in that case.

NMEA over IRDA
Shoudn't be too hard at all, depending on whether the kernel was prebuilt with irda/ircomm it is just opening /dev/ircomm0 and spitting out NMEA sentences (empeg as gpsd?).

Setting the clock
That's an area I really would like to avoid, at least for now. First of all, I managed to figure out that even when linking /etc/localtime to the right timezone file, mktime and friends are not able to give me the right local time from UTC time (it seems to be off by about 2x the timezone offset). I haven't used 'date' on the empeg yet, but I'm assuming it's not ticking UTC, but rather local time, and because it isn't using the timezone files it is a real pain to get the mapping from UTC to whatever we need right (along with the various daylight saving time rules etc.)

And then the quality of the received time. Ofcourse GPS time is almost perfect, but a lot of error is introduced after that point, the fact that I only read buffered serial data 10 times per second. The fact that the timestamp we get is from the last fix, and not when the message was sent over serial. So 'time' as gpsapp sees it is probably going to be off by at least a second. I can just as well set the time with about the same accuracy once a week by hand.