I've put that in my config.ini - no difference.
Interesting thing is that the GPS menu entry is still there *although* HJ says 'removed menu entry: "GPS"'.
Only if that problem with source switching appears and I re-enter HJ, the GPS entry has really gone.

Hijack always 'removes' any application that is not waiting in the WAITMENU ioctl from the menu. So as long as gpsapp is 'running' it won't be in the menu, as soon as you put it back to sleep on the ioctl you can see the entry again.

You don't see the gps menu entry because gpsapp is still running in it's main loop and hasn't returned to waiting. Hijack forgot about the active overlay and removed/overwrite the button and screen redirections.

I figured it would be something like this.Well, when I go out again I guess I'll play around some more. Right now I'm in the middle of 60gb->80gb my player

Short explanation:

I don't know anything about your bug, but i'm pretty sure the thing about hijack removing a menu entry is nothing to worry about. It is hijack functioning "normally".

Long explaination:

ISTR that the text's main purpose was actually as debug code for something Mark implemented so that a program could change the menu entries during the course of the program. This was implemented in vertions 268-271 of hijack. Before then, any call to WAITMENU would insert the entry into the menu for the entire life of the program, such that if one program wanted to insert a new menu title after inserting an old one, a phantom entry remained. Now the menus only exist for the life of the WAITMENU call, a much better solution.

In other words ignore that. For those not familiar with the programming aspect, it just means the entry has been selected and it's the programs turn to do stuff. (That is, until another WAITMENU call.) I'm sure mark could explain the technical aspects much more clearly.

John

P.S. I recall there was still one minor bug with the dynamic menus in hijack feature, but i forgot what it was. I was writing a program that needed to dynamically change the menus but then I got a full time job and forgot what it was.

wow, i type slowly.

BG Micro has a Motorla 8-channel GPS unit for sale now for $14.95, it's got NMEA output so it's just what we need for GPS on empeg. (he says after he's ordered his 10 units)

Except for the bit where you need to find an antenna for it. I posted about it when they became available.

hmm wonder if you could use your car antenna as an antenna... probably not but I've got an antenna I can steal out of my rand mcnally gps for the palm anyways.

No, the Motorola wants an active antenna.

Dude, if you have a Rand McNally, it's got a 12 channel receiver in it. Why bother with the Oncores at all?

I could never get the module in the rand mcnally to work because it doesn't output rs232-level signal I think was the problem.. it was CMOS or TTL or whatever signal is incompatbile with rs232.. any idea where to get an active antenna?

I could never get the module in the rand mcnally to work because it doesn't output rs232-level signal I think was the problem

It would surprise me if the Oncore weren't the same. Build a circuit with a Maxim IC to deal and be done.

I thought we were just talking about how the Palm units we just bought were RS-232 since it just used the Palm connector (which is RS-232). Was that incorrect?

jaharkes, anything new about the source cycling issue? could you verify your idea about the HJ 'cycle to the nextsrc code when the knob is held down for more than 2 seconds'?
Here's another thread where someone describes similar problems but with pacman.

Edit: Oops, I've noticed that you already knew about the thread - you did a post there... Anyway!

Well, note that in v299, if it does nuts it should start fast forwarding through your songs instead

I'll give v299 a try tomorrow.
But are you sure the changes mark has made will result in that behaviour? AFAIK, he changed the function of knob rotation, not of holding it down?

Man, at those times it's hard to keep up with the HJ releases!

Not in the slightest; I just updated my player and haven't tried it yet.

I looked through the hijack diffs, only saw some suspicious things, but haven't been able to put my finger on any specific problem yet. Considering the other report it is either a hijack bug, or something that is easy to get wrong. Maybe there is some race (f.i. between being taken out of the menu and registering the buttons).

On the bright side, I've added initialization of the map center when no route is loaded so that the map isn't as distorted, and used ellweber's suggestion to basically ignore bearings when our speed is below some threshold.

Right now I'm experimenting with routing and map drawing based on tiger/line files. Pretty tough to get right while avoiding using up too much CPU or memory. And to actually get the planned route to end up where you're going

It is great to see so much progress, so quickly. I am now motivated to see if I can get to where I can compile!

I have a couple of questions about the UI. Could you briefly explain what the "Toggle Absolue/Relative" function is doing. I have been unable to figure this out.

It would be nice to be able to save the configuration from one session to the next so that all of the set up doesn't have to be re-entered each time. I 'm guessing this is a significant undertaking that would involve writing to a disk file. Is this perhaps on your todo list anywhere. I think it is way over my head!

Lynn

Toggle Absolue/Relative
Ehh, when we're displaying time, relative is ETE, while absolute tries to give ETA, but I haven't been able to get the right local timezone offset on the empeg. It looks like it picks UTC + double the actual timezone offset as localtime, not sure why.

When displaying distances to waypoints, it doesn't make any difference for the next waypoint or the final destination, but it matters for the ones after the next, it should be obvious when you have a route loaded and are in the text display.

For a lot of these options I'm assuming that they'll just at some point get obsoleted or fixed to some default value. Possibly read from config.ini. I really don't want to add anything that writes to the disk unless absolutely 100% necessary. Another advantage of that is that it should be virtually impossible to get into a wedged state that isn't recoverable by simply pulling the plug and rebooting.

Good point regarding robustness. Perhaps parameters in the preinit.d script or a section in config.ini could be used for English/Metric, rubberband on/off and things that don't change for an individual user. Resuming the same route after a gas stop (power cycle) and retaining some of the recent track data could be helpful, however. I know this is a tradeoff!

No help on the local time offset in the Empeg. I do now realize that it has a thorough database of timezones and DST rules but that is no help here. I haven't used the text display enough to see this yet. I tend to focus on the map graphic. In the traffic we have around here the time predictions are not very meaningful

Lynn

Right now I'm experimenting with routing and map drawing based on tiger/line files.

Suspend the player while computing routes? As long as you compute a whole route one time, this doesn't seem like a huge or unjustified sacrifice.

Hmm, possibly, right now I'm routing from the destination back to our current position, considering extending the best 8 routes out of a set of 32. Ofcourse here it depends on what the scoring criteria are. But it is doing a pretty exhaustive search

It sometimes has a problem converging, especially when several routes 'bump' into each other, and looking at the speed, my guess is that most routing application probably use a more heuristical approach. Something more similar to find the quickest way between these two point over interstates, then from the found exits, do the same over highways, etc. and finish up by finding 'shortcuts'.

The current code will give at least entertaining route that although not obvious will eventually get you to where you're going Right now everything is still python based mockups, so don't expect anything soon.

(Attached is a gnuplot dump of a routing 'attempt' in progress)

It's RS232 but it may not output the voltage required for a communication over a PC serial Port. You may have to make a circuit with a MAX233 to convert the voltages. I don't remeber the acronyms for the voltages but I think a PC runs off 12V signals and most gps units run off 5V.

This GPS runs off of 12 volts. Dunno if that's what's present on the serial line, but this thing takes direct 12 volt power in its AC adapter jack.

the 5v is "TTL level" and the 12v is 'RS232 level"

I've just finished interfacing my new Oncore board to my empeg - and Wow. This rocks.

I have a couple of comments/requests;

1) Can we get the satellite signal strengths available in a display? Bargraphs would be nice - but I'd settle for textual.

2) The waypoint logic gets confused. An example - X is the start point. w are other waypoints, z is a point of confusion.

                                  X-----------w

                                                        \ 

                                                         \

                                                          \

     w---------------z---------------w

At point z, gpsapp determines that X is the nearest waypoint and starts to give me directions for the first waypoint again.

3) Can you provide a way to manually switch between waypoints?

4) I'd really like a way to toggle the textual instruction overlay. Given the limited resolution of the screen and the fact that the instructions from maponsys (by their own admission) are sometimes funky, relying on the line representation is sometimes more useful - but the instruction obliterates the bottom 20% of the screen.

5) Can you move the scale marker? - it gets hidden by the fascia bug. I figure that I'm more likely to want to glance at the scale than the co-ordinate, so may swap their positions?

6) I don't know how technically feasible this is, but would it be possible to (optionally) rotate the map so that the perceived direction of travel is up. We'd probably need a bearing indicator too, so that we keep our sanity, and somehow indicate clearly when this mode is selected (for the same reason). I figure that when driving 'by-wire' as opposed to following the text instructions, that this rotated mode may be easier to follow.

7) Is it possible to rebroadcast the NMEA messages over IRDA ?

8) Can we somehow use GPS time to set the empegs clock?


Hmmm..ok, so maybe more than a couple. Anyway...thanks!


Edit: Oh yuck. I've just notice that my lovely ascii art got screwed by the bbs software. Anyway, those lines are supposed to be linked.

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.

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).

The glibc on mine at the time (which was 2.0b11, I think) was doing something weird, like opening files in the wrong place or something.

I wish I remembered what I eventually discovered, but my laptop is at home and just fell over (thank you Dell for the crappy power cable) so even if I have notes, I can't look now.

As to NMEA over IRDA, I think Kim Salo was doing something like that at the beginning of his project, actually.

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


Disabling the popup. But like the long down mode-switch, this is something that would need to be easily toggled. Perhaps a knob-press? I like the popups on the whole, and with well-spaced waypoints (such as interstate driving) they are great. But for city-driving with dense waypoints the popups are pretty much always there, and if you're driving south...


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.


Me too. As a scout leader, one of the first map skills that I used to teach my scouts was how to set a map, ie align map north with magnetic north (taking the magnetic deviation into account of course ) - so that they looked 'across' the map in the sme direction that were travelling in. But I digress.

I wonder if it is possible to integerise some of the math?


I can live without clock support - it's not often that my empeg goes un-powered long enough to lose it's time. I just figured that it's a pain to set it manually when it does, and since GPS can provide it.
(1 second accuracy would be fine - we're not going to get more accurate by hand. But I can use ntpdate when I sync/load routes instead. )

I thought of one other request; Can we get the elevation reported when co-ordinates are displayed?

Well, disabling the popups was trivial, the option was already there, I just didn't have a menu entry to toggle it yet. Same deal for swapping the scale and coordinate locations. And I dumbed down the 'where are we in the route' code significantly, and added knob rotation to skip to the next/previous waypoint in the route.

Also added ellwebers suggestion to drop bearing updates below 1-2km/h, and reinitialize the map center when we get the first location update.

That was all the really simple stuff, so I've put up version 0.7 of gpsapp. btw. There is also a modified hijack-v299 which for me has fixed the "switch back to the player in aux mode" when restarting a userland application.

Now I'll finish up some soldering, and then I can start debugging TSIP and maybe add a satellite info page.