*This doubles as a "Wish List" entry too*

Just curious if anyone is undertaking a GPS project. I have an Earthmate receiver kicking around and would LOVE to put it to use on something other than my Palm.

I'm not thinking huge navigation project... I am just thinking some information on the bottom line of the display... speed, altitude, heading, maybe an odometer/tripmeter. Then growing into perhaps Lat/Long waypoints and distance/bearing info, and on and on.

Hey! With Lat/Long waypoints, perhaps there would be a way to cue the empeg to play a file once you'e within a distance of it. Record your directions to a file, when you near the waypoint, the player interrupts your music to bring you a prerecorded note.

Imagine inputting your in-law's or ex's house as a "waypoint", and when the player senses you're within 200 feet of it, have it start playing the Imperial March from Star Wars (or something equally sinister)

If I had any programming experience whatsoever, I would debate tackling it, but when it comes to code, I simply use the end results, I don't make it.

Of course, I could be speaking the (almost) impossible.

Can't wait to see what the independant developers and enthusiasts will come up with next!

-Germ

---- - --- - --- - -- -- - - - - - -
greggerm 09000991

Some of the things you just described are part of Kim Salo's GPS project. Link at the geek site.

___________
Tony Fabris

I take that back. Kim's stuff is mentioned at the geek site, but without a link. Kim?

___________
Tony Fabris

I take that back. Kim's stuff is mentioned at the geek site, but without a link. Kim?

Yes, the project doesn't really have a home page. Rob has put up some info about it into the geek site, although some of it might be currently a bit outdated. I can try to cover some status of the project here. You'll also probably realize that this is not such "small" GPS project that greggerm was initially asking

To begin with -- the project has gone through a lot of experiments. It started off with a Palm Vx interface using IrDA to transfer raster map data from empeg to the handheld. Recently the interface was upgraded to use Compaq iPaq as a handheld which naturally provided full color map browsing and other neat features which were impossible to achieve with Palm due to the slow CPU (iPaq's SA1110 @ 206MHz CPU being 10x more powerful than Palm's DragonBall @ ~20MHz).

However, after a lot of experimenting and trying to find the most practical implementation, the handheld interfaces has proven to be more a cool/geek factor thing than a simple and effective way of interacting with empeg. Therefore the current direction would seem to be to embed all that interaction stuff directly into empeg and using the existing front panel buttons and remote as an interface.

On the navigation side, most of the stuff is based on vector maps which enables real route planning and navigation based on actual street names and locations. This part has been working for a while now - although - trying to find the right patterns for proper navigation controlled by speech is a challenge, taking the input data restrictions into account.

I've also spent a great amout of time to make the navigation module to run in background with the player fluently. In practice, this means kernel modifications to share audio, display and input parts with the player. This is quite essential bit, because you still want to mainly listen music in car and presume the navigation to be a background task. As along other things, this has been a challenge too, but has proven to work better than I thought it would.

While all this sounds nice, it's currently not easily portable to other environments. Even the software installation procedure (including custom kernels, certain requirements on permanently RW mounted scratch partitions, etc) makes it rather nasty to play with. Although, the biggest bottleneck probably still being the vectorized street level maps. As there hasn't been really a global standard for such data, it mainly works with a one dataset unless specific conversion is provided. I'm also aware of SDAL format, which is an attempt to uniform the "standards", but it'll still take time for bigger companies to adopt it internationally. Also, the availability of proper vector maps greatly depends on geographical location, making the situation quite a bit different to US and Europe, for example.

However, it's an interesting project that I'll keep working on, but unfortunately it won't be something that I could give out publicly at this point, partially due to the reasons above.

Kim

I´m currently working on a java-based GPS-Project for the empeg.
I´ll post details in a few weeks on my homepage.

bobo

Interesting. Are you actually running a JVM on the empeg? It does not seem like there would be enought memory to do much, particularly if the player is running at the same time.

-Mike

yepp, I got te jdk-arm port from blackdown.org.

there is enough memory if the JVM is running.
But It hink it´ll be a big problem (impossible !?)
to let it run with the player at the same time.. so Kim´s solution is better for that.

bobo

Interesting, but what I would like to see is a simple application that could be used with the player. Something that took over a small portion of the screen to show the current location every few minutes would be neat.

-Mike

The empeg really needs an abstracted display manager that could handle multiple client requests, rather than the player only managing the screen directly during operation. This way, with the player as a screen manager client as well as other background apps, the screen could be co-operatively managed. How this would tie in with control access at the same time is another thing altogether ("another thing!" shouts the crowd).

One of the few remaining Mk1 owners... #00015

The trick would be to let every application have it's own virtual framebuffer, where only one at a time get's mapped to the real framebuffer. We could use a hotkey for switching between different framebuffers.
I suppose this wasn't implemented in the empeg due to the decrease in performance it will bring. The visuals need maximum performance and an extra framebuffer-layer would damage performance drastically

Frank van Gestel

The trick would be to let every application have it's own virtual framebuffer, where only one at a time get's mapped to the real framebuffer. We could use a hotkey for switching between different framebuffers.
I suppose this wasn't implemented in the empeg due to the decrease in performance it will bring. The visuals need maximum performance and an extra framebuffer-layer would damage performance drastically

That shouldn't be the case. The display driver already copies every frame from the framebuffer to a queue of frames. With multiple framebuffers it'd just copy from a different source - no slowdown at all.

Borislav

Something interesting I noticed here in Germany recently. The local automobile club (ADAC) did a comparison of a heap of different navigation systems, and almost all the ones that did well had displays with as similar size and resolution to the one on the empeg! Most of the flash colour displays were rated much worse! So there you go, having a pretty display doesn't necessarily make a good navigation system.
Personally, I can't wait to see something like this running on a empeg. Due to other commitments I can't really help with development, but I would be more than happy to help with testing, and would definitely be interested in buying such a system should someone get it running!

Keep at it guys.

Derek

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 6GB blue)

I confess, I have been puzzled why the emphasis has been on map display so far; the CARIN system simply uses the GPS sensor to do dead reckoning on a vector map (publically available) and then just displays an arrow pointing the direction you have to take, along with a synthesised voice warning. You don't even see a map even when you enter your route - it works on Postcodes.

One of the few remaining Mk1 owners... #00015

I might be wrong but, there is one thing I am kind of wondering about. I have an Earthmate too but I am sorry to say it does not use the NMEA 0183 format but rather a proprietary one (well yeah, not what most GPS receivers seem to output). From their FAQ :


Earthmate outputs Rockwell binary protocol and was designed specifically to work with DeLorme mapping software only (Street Atlas USA® 6.0, 7.0 and 8.0; Street Atlas USA Road Warrior Edition; Topo USA® 1.0, 2.0, and 3.0; AAA Map'n'Go® 5.0, 6.0 and 7.0; 3-D TopoQuads®; Golf Digest Places to Play Travel Planner; Topo USA: Fly-Fishing Edition; Eartha Global Explorer®; and Solus® Pro software). With a free update, Earthmate also works with Street Atlas USA 5.0, AAA Map'n'Go 4.0 and GPS MapKit®.


Not quite sure if there is any information on this Rockwell protocol but it is one thing to bear in mind if you go out to buy GPS enabled software and receivers.

I also have a Garmin GPS35PC and that outputs some fairly easy to interpret messages in the NMEA 0183 format (with some Garmin extentions for controlling extra features). From a programming point of view that is.

Defenitly something that would have to be taken into account in any nav-project.

Hans

Mk2 - Blue - 080000431