Open Gps

[tossedsalad]

I will be working on a GPSr for work and I wondered if there was any interest in an open source effort to design a GPS receiver. I know this will not be cost effective or even remotely practical compared to buying a commercial receiver. But it would be an interesting project and could provide a highly customizable user interface rather than the standard four screens. Personally, I have found a lot of quirks with the UI on all of the units I have used and would like to be able to layout my own. I also would like to be able to use a larger display, perhaps 6" diagonal rather than the standard less than 3" display.

 

Maybe this is way more than anyone needs or wants or maybe there is a better way to do this than designing custom hardware. I just thought I would ask for intelligent comments.

[robertlipe]

If only there were a programmer sufficiently infuriated with current GPS firmware...

[+Tervas]

One example of a home made GPSr: Ghetto-GPS

[+RumJungle]

There has been lots of work on an Open Source GPS. Take a look at Cliff's web site:

 

Open Source GPS

 

Have fun!

[tossedsalad]

I looked at Cliff's site. He seems to be working on a receiver that uses a 10 year old chip set and a PC. I am interested in using one of the very latest modules which are around $25 in quantity and $100 in small volumes. Combine one of these with one of the new ARM MCUs and an LCD keypad and you have a GPS receiver that will rock!

 

My main reason for wanting an open-gps receiver is the frustration with the UI on my current GPS. Some things are clumsy to do and the map updates so sloooowly. I also want to have flexibility in displays. I want to use it as a handheld when I am in the field. But when I am in the car, I want to plug it into a larger display and have it operate like a car GPSr.

 

None of this is expensive in hardware. But the software work would be large, especially integrating a geo-database... or even finding a database that doesn't cost an arm and a leg.

 

I am researching GPS modules for work and they are so tiny and so easy on the batteries and work so well. Seems like we ought to be able to build something with them.

[+trippy1976]

Here's a thread from the wayback machine about something similar.

 

http://forums.Groundspeak.com/GC/index.php...topic=45433&hl=

 

I think someone with enough engineering gumption could make a really interesting run at an independant open source GPS.

 

Heck, the internals wouldn't even have to be open source, but if you could put together a receiver with basic function running on something that could support XP embedded or some such (or embedded linux) and then provide an SDK to developers... I think you'd have a spitfire idea.

 

Put a USB port in it and an IR port and you'd then enable developers like Clyde, etc. to build applets for it that either integrate to GSAK or perhaps someday even to GC.com. The IR port is a common feature request I hear a lot these days as people cache in groups more and more. They want to be able to "beam" waypoints to each other so you can quickly swag and add waypoints.

 

I don't think you'd even need a color screen. And in fact, I think this could be a very competitive GPS to the major guys if built rugged and with expandable memory of some sort.

[+RheS]

There are a couple of separate components in a GPSr system. Some are reasonable to consider redeveloping... and others are not.

 

(1) There's the receiver. That's the component that "Open Source GPS" replaces. Since this module is now commonly available as a single integrated unit, I don't believe this is worth doing... let the RF chipmakers sell them to you. Or buy an old one, like a Radio Shack sensor, on eBay for under $20. All you need is an NMEA interface out. Yes, there are some other proprietary interfaces, but NMEA is the standard... and if you have it, you can talk to just about all available software.

 

(2) There's the user interface / display software. This doesn't need much, and there are several cheap examples available. A nice (and free) example is Cetus GPS which runs on Palm OS. Most of the available freeware does not include mapping, although it does include such features as sorting waypoints by distance. The "Ghetto-GPS" effort is to do this part on custom hardware... although I like the Palm solution myself. But the input should be the NMEA stream from (1), plus waypoint database and user interface.

 

(3) Map display. This isn't hard, although compact storage of maps presents interesting challenges. Subsystem inputs are position (from (2)), plus map database.

 

(4) Auto routing. A serious effort, which requires data beyond just a picture of a road map. Or maybe that's enough, but that's more challenging than if you have decent routing data ala Navtech or similar. These are commercial databases which are not cheap to license. No open source effort that I am aware of is attacking this part of the system. Subsystem inputs are position (from (2)), plus routing database (maybe from (3)'s maps).

 

There are some obvious component solutions available right now, made from COTS (commercial off the shelf) hardware and software:

 

(I) Any sensor package with NMEA output, plus a Palm OS device with serial port, or Pocket PC device with serial port. There are free software packages for both which include at least (1), (2), and maybe (3) above. Function (4) is only available in commercial software that I am aware of... I'd love to hear about freeware/shareware that does either (3) or (4).

 

(II) Any sensor package plus any PC plus Microsoft Streets and Trips (or Microsoft Autoroute, if you're European) or similar software by DeLorean and others. Microsoft sells this, sans PC, in a box for less than $100. Implements all of (1-4) above, but the laptop is kind of large to carry along. MS S&T comes on a two CD set, so there's substantial disk data storage needed... but consider what's being packed into an MP3 player these days. It's just a metter of making the PC really small, and you've got everything you could want.

 

(II-a) OK, you want topographic maps, too. I guess I do too much urban caching! So spend $200 on PC software (the additional money is mostly paying for the map data).

 

(III) Full custom hardware and/or software. You can do it... but is it worth the effort? Yes, I know... programming is fun! As is building up display hardware and making it shockproof....

 

I currently do most of my caching with a Palm IIIxe running Cetus GPS, connected to a cheap GPS receiver by a serial cable... this is essentially COTS solution (I). Total cost less than $50, but then I had the cable parts in my junk box already. Still, it would be easy enough for you to build up similar. Or, if you aren't as cheap as I am, get a Bluetooth-capable GPS module, and some handheld device that can talk Bluetooth to it... and pin the module to your hat.. then there are no cables to get caught in the brush as you cache.

 

I am an embedded software developer, with a little grey hair and a lot of experience. I'd be happy to do this kind of work (and if your company is hiring people to develop any component of this, please contact me!)... but I don't think that there's a lot of benefit to the community to come from redeveloping most of it, unless you can keep the components simple. Redoing the user interface/display ought to be fairly easy, and there are several existing programs to model from. Doing map display, and especially routing, is much harder. I'm convinced that doing receiver design isn't worth it, unless you get your jollies from playing with fussy microwave hardware.

 

Hope this division into subsystems helps move the discussion forward. Which piece is it that you want to do?

 

Dick "RheS" Smith

[tossedsalad]

There are a couple of separate components in a GPSr system.  Some are reasonable to consider redeveloping... and others are not.

 

(1) There's the receiver.  That's the component that "Open Source GPS" replaces.  Since this module is now commonly available as a single integrated unit, I don't believe this is worth doing... let the RF chipmakers sell them to you.  Or buy an old one, like a Radio Shack sensor, on eBay for under $20.  All you need is an NMEA interface out.  Yes, there are some other proprietary interfaces, but NMEA is the standard... and if you have it, you can talk to just about all available software.

 

Yes, you can get the entire GPSr front end in a single package the size of a quarter. I have pricing under $25 in large quantity or closer to $100 in small quantity. I have not seen anything for quite $20 though. These units are state of the art with power consumption around 100 mW and very good sensitivity. The interface is typically a serial port in NMEA format or with proprietary extensions. It is very easy to interface with any available embedded processor.

 

(2) There's the user interface / display software.  This doesn't need much, and there are several cheap examples available.  A nice (and free) example is Cetus GPS which runs on Palm OS.  Most of the available freeware does not include mapping, although it does include such features as sorting waypoints by distance.  The "Ghetto-GPS" effort is to do this part on custom hardware... although I like the Palm solution myself.  But the input should be the NMEA stream from (1), plus waypoint database and user interface.

 

I am sure there are lots of ways to solve this issue. I don't think there is an easy way to get Palm OS up and running on an open source project. I guess I had not given a lot of thought to an open source embedded GUI. Might be worth a search.

 

(3) Map display.  This isn't hard, although compact storage of maps presents interesting challenges. Subsystem inputs are position (from (2)), plus map database.

 

With the current state of Flash storage, it may not require "compact" storage. One chip can store half a GB of data, or roughly a CD. Detachable storage grows continuously. I think it will be more important to identify a source of map data and to develop storage structures that allow efficient searching and display. My Merigold is very, very slow updating the display.

 

(4) Auto routing.  A serious effort, which requires data beyond just a picture of a road map.  Or maybe that's enough, but that's more challenging than if you have decent routing data ala Navtech or similar.  These are commercial databases which are not cheap to license.  No open source effort that I am aware of is attacking this part of the system. Subsystem inputs are position (from (2)), plus routing database (maybe from (3)'s maps).

 

Personally, I am not so interested in "auto" routing. I am happy having a good map display so *I* can figure it out. But certainly others will be very interested.

 

There are some obvious component solutions available right now, made from COTS (commercial off the shelf) hardware and software:

 

(I) Any sensor package with NMEA output, plus a Palm OS device with serial port, or Pocket PC device with serial port.  There are free software packages for both which include at least (1), (2), and maybe (3) above.  Function (4) is only available in commercial software that I am aware of... I'd love to hear about freeware/shareware that does either (3) or (4).

 

(II) Any sensor package plus any PC plus Microsoft Streets and Trips (or Microsoft Autoroute, if you're European) or similar software by DeLorean and others.  Microsoft sells this, sans PC, in a box for less than $100.  Implements all of (1-4) above, but the laptop is kind of large to carry along.  MS S&T comes on a two CD set, so there's substantial disk data storage needed... but consider what's being packed into an MP3 player these days.  It's just a metter of making the PC really small, and you've got everything you could want.

 

(II-a) OK, you want topographic maps, too.  I guess I do too much urban caching!  So spend $200 on PC software (the additional money is mostly paying for the map data).

 

Will this really buy me a map that I can download to my GPSr and display in a non-proprietary format? I have not done much with my Merigold except to use Map Send which is from Magellan.

 

(III) Full custom hardware and/or software.  You can do it... but is it worth the effort?  Yes, I know... programming is fun!  As is building up display hardware and making it shockproof....

 

The electrical part is not so hard. I don't know if the mechanical is much of an issue. We are talking about surviving a 3 foot fall, not 20 feet. At least that is what I am looking for. The programming is a long term PITA to get it all right. But I do have a few tricks in my bag there.

 

I currently do most of my caching with a Palm IIIxe running Cetus GPS, connected to a cheap GPS receiver by a serial cable... this is essentially COTS solution (I).  Total cost less than $50, but then I had the cable parts in my junk box already.  Still, it would be easy enough for you to build up similar.  Or, if you aren't as cheap as I am, get a Bluetooth-capable GPS module, and some handheld device that can talk Bluetooth to it... and pin the module to your hat.. then there are no cables to get caught in the brush as you cache.

 

That is an interesting idea. But any handheld you can buy will not be very ruggedized or watertight. One of my big requirements is that I can hook it up to a larger car display. But that does give me ideas.

 

I am an embedded software developer, with a little grey hair and a lot of experience.  I'd be happy to do this kind of work (and if your company is hiring people to develop any component of this, please contact me!)... but I don't think that there's a lot of benefit to the community to come from redeveloping most of it, unless you can keep the components simple.  Redoing the user interface/display ought to be fairly easy, and there are several existing programs to model  from.  Doing map display, and especially routing, is much harder. I'm convinced that doing receiver design isn't worth it, unless you get your jollies from playing with fussy microwave hardware.

 

I agree that there is *NO* point trying to design a "receiver". But that is only part of a GPSr handheld. Typically there is a separate processor for the display and database management. But you have some good points about using existing hardware.

 

I am an embedded hardware engineer with a lot of grey hair to go with my experience.

 

Hope this division into subsystems helps move the discussion forward.  Which piece is it that you want to do?

 

Dick "RheS" Smith

 

Good question. I'm not sure it is smart to jump into a full development without some initial work with existing hardware. One of the easier parts would be a receiver front end with antenna. Bluetooth would be very useful for the connection. But these exist, right?

[+HugoBear]

One example of a home made GPSr: Ghetto-GPS

Before I click the link, I envision a compass, taped to a map, taped to an etch-a-sketch...

[+user13371]

Just an observation... you're really describing a GPS unit that already exists. For a a rugged handheld with a big screen and a good UI, look to any of Trimbe's handheld units.

 

Of course, these aren't "cost effective" but the OP said his project wouldn't be either I'm not saying you should go BUY a Trimble instead of rolling your own - but maybe look there for ideas on form factor, ruggedization, UI, and oher features to borrow in your own design.