I'm still a bit miffed about the fact that you guys seem to have hoarded all the trimble GPS's before I had a chance to order one.

But, I've been working on a GPS routing application, and I'm releasing it with source and all, hoping to get some more ideas and feedback.

The documentation is probably a bit sparse, but you can find it here.

Jan

I'll have to give this a gander! You may want to build a sourceforge project for this. Thanks for being the first to release sources to a GPS app on the empeg!!!

I've really enjoyed my Garmin GPS 16 sensor ... pricey but well worth it.

Greg

But, I've been working on a GPS routing application, and I'm releasing it with source and all, hoping to get some more ideas and feedback.

Yes, hat's off for putting this out there. I looked at a few modules like serial and nmea and they made sense to me (and that is saying something given that I am fairly C illiterate).

Once we're pass out of Daylight Savings Time, I may have some extra evening hours (maybe some daytime hours, too, if I join the ranks of the unemployed in November!!) and would like to get working on my long-jawed-about "big digital clock" app. I'd use your work as a base if that's OK and give you anything I come up with.

[edit: I may have missed it, but has there been any progress/resolution on the serial port sharing issue?]

Thanks again,

I'd use your work as a base if that's OK and give you anything I come up with.

If it wasn't ok, I wouldn't have released the source. Ofcourse it is. Something that others might find useful. The 'empeg_ui.[ch]' files basically contain wrappers around the hijack ioctls when compiling for __arm__, but which wrap around Xlib calls otherwise. So you can do most of the development and debugging on your X desktop (cygwin for WinXX users?)

I used things like valgrind to make sure there were no memory leaks, or bad memory references, gdb to do single step debugging, and gprof to shave off a few cpu cycles in the really bad parts.

I may have missed it, but has there been any progress/resolution on the serial port sharing issue?

Sharing with the player? That's what hack_init is for. It copies itself to /empeg/bin/play-s, then copies /bin/init to /bin/init.new, modifies it to start play-s instead of the real player, makes a backup of the original init, and moves the modified init.new over /bin/init.

When it is started as play-s, it checks /proc/empeg_power and when we're on battery (in the car) it execs the player with the -s- flag. If we're on AC it simply execs the player without the extra flag.

The only problem I've seen is than when I'm running on AC, have a gps connected and start gpsapp from the hijack menu. It manages to set the serial port speed so that the player suddenly sees the gps data and the player application invariably crashes/restarts.

Sharing with the player? That's what hack_init is for.

Awesome. (I hadn't looked at all the modules yet). For a while I was thinking we'd never run the player during those times (in rallies) where we really wanted the clock, but for some long events, we're thinking otherwise. Also, being able to run the player would let us do stuff like pipe the output of something like a ham rig to the speakers through AUX.

I don't think I have the talents to contribute much, but maybe something that someone, somewhere might use. You've done so much. I'm going to home in on how to display big numerals...

(actually, other than the clock HH:MM:SS display, I'm thinking it would be good to display something like a "quality meter" -- say a 1-5 bar graph on the right hand side of the display that gives some indication of when the time was last successfully set from a GPS signal....basically, how much can you trust the clock?)

I'm going to home in on how to display big numerals...

Thanks to the wonderful vfdlib this is almost trivial

Hmm, just had a thought. I can create some snapshots from the X window.
[this is the screen grab of the previous bignum.c]

And here are some from gpsapp.



I'm really just trying to get a better 'status' than stranger here

Wow, so you are actually doing live routing (looks like it from the screenshot)? What are you using for map data?

-Mike

No, this is offline routing. The route information from mapsonus.switchboard.com is converted into a representation in the correct datum and already projected into rectangular coordinates. These pre-planned routes can then be uploaded to /programs0/routes/ on the empeg and it only has to figure out where in the route we are and draw the thing.

Looks like fun, I can't wait to get my GPS hooked up so I can play with it... I'm a compulsive mapblast user whenever I'm going somewhere I havn't been before, so this would save a lot of trees...

Is there any way for it to overlay sound on top of the music? Verbal directions would be a nice addion if it doesn't have them already. I'm glad someone's actually coding this and leaving it as open source.

Thanks,
Matthew

In reply to:

---

No, this is offline routing.

---

Interesting. Your website seems to be down at the moment or I would download it and check it out. How do you get mapsonus to output the data? I don't see them giving long/lat info anywhere. What happens if you get off route? Anyway, it looks like you have a pretty good start and I am glad to see someone working on this again and actually releasing source.

-Mike

Yes, something is wrong with the wired network in my office. I'm currently on-line using my laptop on the wireless. Because the tarball is still smaller than 200KB, I'll just attach the latest version.

I'm now averaging the reported gps speed so that the ETA/ETE numbers make a little more sense.

How do you get mapsonus to output the data? I don't see them giving long/lat info anywhere.

Use general options and toggle the Show Latitude & Longitude checkbox. You then get a raw route description link at the bottom of the page which contains both the route and the detailed shape information.

Yeah, I'd also like to say thanks alot for posting this source. Maybe it's the much needed kick up the backside I needed to get my OBD project underway - especially that serial bit!

Cheers again!

Don't thank me, thank kirkis. His vfdlib is about 1500 lines of code out of the total of 3700, and I wouldn't have gotten this far without that. And after you're done thanking him, thank mlord for hijack, which gives a really neat and simple way to hook into the display.

And then start thanking the empeg developers for making such a wonderful platform and releasing all the information that makes all of these things possible in the first place. Or no, thank them first.

I've been reading the source code the GPS app.

I must say, very readable code.

Now, I have a question on non-NAD datums and a question on hijack and a suggestion/improvement for the app itself.

1. For folks who are not in the USA we tendnot to use NAD co-ordinates on our GPS - is there much conversion/tweaking of your conversion routines to allow for this in the route files [e.g. for those of us who use WGS84]?

2. My understanding of how the current application works is that once launched from the Hijack menu it takes over your screen [and some key functions] until the program is exited.
Am I correct here in this behaviour - it would look to be consistent with how other apps like Empacman work?

If so, then how much work would be involved to add a "hide" Application menu option to the main "in app" GPS menu, that lets me "un-hook" all those bound/captured keycodes and also relinquish the screen back to the [presumably] Application that is updating the screen before GPS hijacked it [the main Player App?]. While still leaving the GPS app running in background - changing the GPS menu back to just "GPS" when I hide it will let me get to it again while its still running?

This suggestion would let the GPS app continue to record its track, mark off waypoints and do stuff it normally would, and it can still update its "local" copy of the screen in local memory, ready when you activate it again to update the display.

What I'm thinking/would like, is always having the GPS app running, and attached to the Hijack menu ready to be "woken".

Then when I need to do some GPS stuff, I can activate this app in terms of "bringing it to foreground" ala [X]Windows apps.

When I have finished with the App I select the "Hide" Menu option, which now unbinds its main menu from Hijack and replaces it again with the "GPS" only menu.
Then unbinds/releases all those keys it has captured, until I reactivate it next time?

You could even possibly allocate a couple of [hard coded for now] "hot" keys to let you hide and unhide the GPS app quickly from either the IR remote or from say the Sony stalk [there are a few [shifted] buttons e.g. all 10 on the Stalk you could use for this purpose.

[I don't think there are any buttons on the front panel you could hijack for this purpose of acting as application "hotkeys"].

That way you could "hot key" in and out of the GPS app at will. Kind of like those TSR add ins for IBM PCS in the mid-80s [like Borlands Sidekick].

You could even have the GPS app be able to play sounds for certain [user selectable] events [like reaching a waypoint or end of Route] - but thats a future feature I think.

Or even different sounds for directions e.g. One sound for turn left, another sound for Turn Right etc, that way you would not even need to take your eyes off the road to navigate. Simple "WAV file" sounds can be quite effective for this sort of thing.

The current "Quit" program option would still be there to really exit the program.

Any comments on this - when I get some time next month I hope to get this app up and running on my Empeg so I can do some serious hacking. I can see some real useful [user] extensions coming for the GPS app real soon now.

1. For folks who are not in the USA we tendnot to use NAD co-ordinates on our GPS - is there much conversion/tweaking of your conversion routines to allow for this in the route files [e.g. for those of us who use WGS84]?

Once you're in 'empeg space', everything is WGS84. Only the python script that massages the route does datum conversion.

It is trivial to add any other datum, you just need to add the right values of 'a, inv, dx, dy, dz' corresponding to that datum. Typically a google search or a quick look at programs like gpsman and gpstrans will turn up the ones you need. And it shouldn't be too hard to understand how to add it to convert.py (look for Ellipse_Clarke1866 which is where the datums are defined).

However, as far as I know, mapsonus can only route in the US, and somewhere in their site it said that all coordinates are in the NAD27 datum. So for that particular conversion it isn't necessary.

Am I correct here in this behaviour - it would look to be consistent with how other apps like Empacman work?

Yes, pressing the top button 'exits', however this isn't a real application exit, so all the state will still be there. i.e. we still has the same route loaded and preferences set and will immediately try to find our new location in the route when we 'start' the application again.

I don't think I can 'hijack' the display when I haven't officially returned from the WAITMENU ioctl. I did figure out that setting an alarm provides a nice way to get unstuck from the WAITMENU ioctl, so I could have the app do something even when it isn't visibly running (popups/beeps/voiceprompts?). I can re-add that code in 5 seconds flat if you think it would be useful.

I don't think I can 'hijack' the display when I haven't officially returned from the WAITMENU ioctl

Correct, you can't. But what you *can* do is run in overlay mode using the setgeom ioctl and reserve a little window for any output you want to do. Unfortunately this means you interfere with operation of the player depending on what buttons you're trapping, because apps that run in overlay mode still get input focus, there's no way to run multiple overlay apps.

I think once Mark's climbing season comes to an end, we'll have a very good chance of getting improvements made to the userland interface.

For folks who are not in the USA we tendnot to use NAD co-ordinates on our GPS - is there much conversion/tweaking of your conversion routines to allow for this in the route files [e.g. for those of us who use WGS84]?

If you can tell the difference between NAD83 and WGS84, more power to you. The typical GPS receiver you're going to use isn't going to give you that kind of accuracy, unless you drop a lot on one. The "proj.4" library includes everything needed to convert, but you again, you're probably going to not care.

For what it's worth, I use Xastir with NAD83 calibrated data and a GPS receiver set to WGS84. The errors are always either "compromises have to be made when drawing a map" or "GPS receiver can't see enough satellites"

Using aerial photos when doing GPS tracking is way cool, but they're big, data-wise.

In reply to:

---

Once you're in 'empeg space', everything is WGS84.
Only the python script that massages the route does datum conversion.

---

You are only in WGS84 in the Empeg, if your routes are in WGS84 co-ordinates AND your GPS is outputting NMEA data to the WGS84 datum.

But I understand your point, and the conversion in the Python scripts was what I was asking about.

In reply to:

---

Yes, pressing the top button 'exits', however this isn't a real application exit, so all the state will still be there. i.e. we still has the same route loaded and preferences set and will immediately try to find our new location in the route when we 'start' the application again.

---

When you say this, do you mean that the App is still running [in memory], just not actively updating the display or doing anything in particular?

If so, then how much work to have it continue to "navigate" behind the scene, e.g. accepting NMEA sentences, parsing them and updating your co-ordinates - is that just replacing your "Wait buttons" call with a Poll keys? and then continue if none of the keys are actually pressed?

And as mentioned before, when a waypoint is reached possibly make a beep noise or some audible indicator to let you know that the waypoint has been passed?

But If the app exits, then how does it know which route was active when it restarts?
[save its info to disk - but then how does it store this saved route info by mounted the disk rw and then saving - I haven't dug into this code?].

In reply to:

---

I did figure out that setting an alarm provides a nice way to get unstuck from the WAITMENU ioctl, so I could have the app do something even when it isn't visibly running (popups/beeps/voiceprompts?). I can re-add that code in 5 seconds flat if you think it would be useful.

---

Yes, please put it back.

In reply to:

---

_yn0t's post:

In reply to:

---

(Original comment from jaharkes)
I don't think I can 'hijack' the display when I haven't officially returned from the WAITMENU ioctl

---

Correct, you can't. But what you *can* do is run in overlay mode using the setgeom ioctl and reserve a little window for any output you want to do.

Unfortunately this means you interfere with operation of the player depending on what buttons you're trapping, because apps that run in overlay mode still get input focus, there's no way to run multiple overlay apps.

I think once Mark's climbing season comes to an end, we'll have a very good chance of getting improvements made to the userland interface.

---

This all raises some interesting points/possibilities.

1. Can a Userland App have mutilple screen geometries active at once?
[if so, how does the kernel which geometry is to be used - by the file handle passed to the hijack routines by the app (the file handle returned from the open of /dev/display)]

and/or can a Userland app reliquish the current geometriy and request a new one?

[e.g. to switch from full sreen to windowed mode and v.v.].

2. Whats to stop a Userland app, requesting a tiny 1 pixel wide by high window and then using that as a way to "hook" the input focus?, this would result in net zero effect on the resulting display - while getting control of the input focus, then it can use either multiple open "geometries" to select how much of the screen it wants to write over.

3. For keys/buttons that are not hijacked, does the player app still receive them normally?
[this would make sense], or are they simply 'thrown away' by the kernel?

In the former case, what if we dedicated a particular key code sequence as a sort of "attention" button, so that when we press it, we reactivate the userland app [as it is waiting in background for this keycode to appear having done told the kernel it wants this keycode (and this one only)], while the others go to the player app in the meantime. Once this keycode appears, the pap now extends the list of hooked keys to include all those it wants when it has the focus [e.g. all the numeric keys etc, along with say arrows and menu/cancel etc buttons].
Pressing the hotkey again while the app is active, will tell the app to "hide" itself, i.e. unhook all those keys except for the hotkey and stop updating the real display, and carry on doing what you do.

Note: This same hot key, with a little assistance from the kernel in future, could be used to allow multiple background apps to sit there ready to hijack the display window [or their bit of it], and the user can activate them/give them input focus by pressing the hotkey sequence followed by say a numeric code e.g. 1-9, to select app 1, 2 , 3 etc up to 9.
[obviously if that userland app is not running, then it doesn't appear/cannot be "activated" this way, so Hijack simply eats that key sequence].

This selected App is then "given" input focus in Hijack [and possibly woken up somehow - e.g. the kernel sends it a special "wake up" response to the WAITMENU IOCTL].

What I'm thinking of here is a bit like Alt-Tab in Windows, whereby you can "select" a particular app [i.e. there could be more than one app in background], which becomes the "foreground" app [as regards to input focus], while the rest execute in background mode [e.g. they continue to monitor your progress along a route if its a GPS app etc].

And you could consider the Player app to be the "desktop" i.e. its what you see and interact with when no other apps are running/active.

When you say this, do you mean that the App is still running [in memory], just not actively updating the display or doing anything in particular?

Right, it just jumps out of the internal loop where it waits for keypresses and serial input and blocks on the WAITMENU ioctl until we are 'woken up'.

If so, then how much work to have it continue to "navigate" behind the scene, e.g. accepting NMEA sentences, parsing them and updating your co-ordinates - is that just replacing your "Wait buttons" call with a Poll keys? and then continue if none of the keys are actually pressed?

I'm not sure how much hijack likes it, but I can either set an alarm before blocking on WAITMENU, and when the ioctl returns with -1/EINTR we know that we haven't really hijacked the display, in which case we can just drain queued data from the serial point, recalculate position/distance to next waypoint and go back waiting.

If this doesn't work, I'll probably just fork off a thread that handles serial input and deals with location updates, while the main thread waits for hijack and handles the screen updates.

Does anyone have exact instructions on how to install it?
What kind of map data, if any, can we use? If so, how do we get the prog to recognize it?

How do you compile it to run under X windows?

Without having tried, but only looking at the makefile, I'd guess by:

make gpsapp_host

And after building, the "all" target should build that, and it runs for me...

Just type make.

But to see text and such when you run it, you need to copy
the fonts from the empeg to empeg/lib/fonts/

Most of it is documented in the README file in the tarball. Yeah, should have been INSTALL, nobody reads a readme

I put a new version up here.

It has the code to deal with gpsd, but the empeg doesn't have the loopback network interface so it is not active. Also changed serial port handling a bit to allow for other GPS protocols besides NMEA.

Immense thanks to dbrashear for putting a real Trimble on my desk, as soon as I get that serial interface built I can test TSIP and TAIP, the Garmin protocol has been tested already with an Etrex Venture.

First, I want to thank you for making so much progress here! But, of course, I am having a few problems.

I have two Trimble GPS receivers here and your application works with one, just fine (an old ScoutMaster) but the other(SV6 core module a la BGMicro) doesn't seem to put out a compatible form of NMEA.

The ScoutMaster puts out GGA sentances that look like this:

$GPGGA,190423,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M,*78
$GPGGA,190426,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M,*7D
$GPGGA,190429,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M,*72
$GPGGA,190431,3716.920,N,12202.023,W,1,04,2.4,108.6,M,25.9,M, *7B

The SV6 output looks like this:

$GPGGA,190441.0,3716.915,N,12202.080,W,1, 6,001.3,124,M,-026,M,,*68
$GPVTG,000,T,344,M,00.0,N,00.0,K*4D
$GPGGA,190442.0,3716.915,N,12202.079,W,1,6,001.3,125,M,-026,M,,*6C
$GPVTG,000,T,344,M,00.0,N,00.0,K*4D
$GPGGA,190443.0,3716.915,N,12202.079,W,1,6,001.3,125,M,-026,M,,*6D


As far as I can tell the NMEA output is hard coded and the VTG is included. Also, note the decimal content of the time stamp and other differences. It seems the SV6 has added some fields for DGPS status at the end and uses different formats for Time of Fix, HDOP and a sign difference for the Geoid offset.

I am looking forward to trying the TSIP binary protocol as it is far more flexible and useful for troubleshooting.

On another subject, could you give a little more detail on running the Python script. I have not succeeded in getting it to find the raw route file or perhaps I didn't save it in the coorrect format. See attached "raw route" (html).

Thanks,

Lynn