Won't detect a Garmin

Dec 1, 2010 at 9:08 AM

I have several pieces of hardware and I've made a small application that is using the GPS.NET libraries to log the GPS data.

I use the GSP.NET diagnostic tool to check if the GPS.NET library can connect with my GPS receivers.

I have a TabletPC with an internal GPS on COM8, this one is correctly detected and my application is working beautifully.

I also have a laptop with a Garmin, when connecting it with a serial port the diagnostic tool only detects the Garmin after repeatedly hitting the Detect button. It is detected on COM2.
When this Garmin is connected with USB, the diagnostic tool can't find it at all.

I have a second set of hardware. A laptop with a different model of Garmin. With the same results. It is not properly detected.

Is anybody aware of problems with Garmin receivers? Should the detecting process be different or should I change some settings in the Garmin?

Thanks,

Paul
The Netherlands

Dec 3, 2010 at 3:43 AM

Hello Paul of MapWindow fame ;)

FYI: A refactored and more up to date version of GPS .NET is being merged with DotSpatial as DotSpatial.Positioning. The merged version isn't working right now but if you look in the repo folder DotSpatial\DotSpatial.Positioning\DotSpatial.Positioning.Compact you will find the most up to date version refactored into the DotSpatial.Positioning namespace - apart from the refactor it still works pretty much the same.

In answer to your question: Garmin GPS by default generally use their own proprietry phase-interlock protocol. This protocol has been changed by Garmin so many times that Jon Pearson (GeoFrameworks) paused development of support for the Garmin protocol some time ago. I have had some success in connecting to some early Garmin models (e.g. GPS Pilot, GPS Map series) but more recent models seem to have changed the comms protocol yet again :(

If you just want to use the Garmin GPS as a "normal" NMEA GPS you can do so with most Garmin models by going to the Setup screen and changing the Serial Data Format option to NMEA In/NMEA Out (see your specific GPS manual for more detail). Operating in this mode your serial (RS232) connected Garmin should detect just fine regardless of baud rates and other config options.

Garmin USB is a different matter - the Garmin USB driver is proprietary for use with Garmin software see this article for a rant on the topic: http://www.oreillynet.com/xml/blog/2004/10/garmin_gps_goes_more_proprieta.html they definitely haven’t been making a lot of friends with their current stance on interfacing and 3rd party software support.

If you really want to use your Garmin GPS via USB you can consider products like http://gpsgate.com/products/gpsgate_client to interpret the proprietary data and supply NMEA data to your applications via a virtual comm port.

With the cost of excellent quality USB interfaced/powered GPS units plummeting the question is: Do you really want to use your Garmin at all? If your interfacing to a PC then you’re possibly running some kind of software that makes the Garmin map display etc. redundant though this is a bit of an assumption….

Dec 3, 2010 at 7:20 AM

Thanks Tidyup for your answer.

I already thought Garmin would use a propriety protocol, I just hoped I was wrong ;)

I don't own the Garmins myself. They are used by clients that have bought a MapWindow GPS plug-in from me that is using the GPS.Framework and Geoframework libraries.

I'll try your suggestion about the NMEA In/NMEA Out settings.

[offtopic]
Will the development of GPS.NET be stopped when DotSpatial.Positioning is stable? Or will both stay? If DotSpatial.Positioning is stable I'll change my plug-in to use that library instead.
[/offtopic]

Thanks,

Paul

Dec 8, 2010 at 4:44 AM

It should be announced very soon that development of both the GPS.NET 3.0 and GeFrameworks 2.0 projects has already been unofficially frozen as of the last commited version and is moving to DotSpatial. 

For some time now BigStickCarpet has been the only active developer remaining on these projects and as he doesn't have the rights to perform basic project admin tasks on the codeplex sites (like add developers ;) he has been the sole conduit of all activity. Contributions had to be emailed to him as patches that he had to merge and add to the repo manually - he's a busy guy and doesn't have the time to do this! To keep these great projects going we considered forking them but decided it was best to merge them into DotSpatial. BigStickCarpet will be joining the DotSpatial development team (when he gets the time) and he and I would like to invite people who have been contributing to GPS.NET 3.0 with code or helping out in the discussion forums to come join us at DotSpatial.

FYI: The last working committed versions of GPS.NET 3.0 and GeFrameworks 2.0 including some minor bug fixes has been refactored to the DotSpatial.Positioning namespace has been added to the DotSpatial repository under DotSpatial\DotSpatial.Positioning\DotSpatial.Positioning.Compact.  As DotSpatial doesn’t support the compact framework (and there is quite a bit of uncertainty about its future) this version will be retained at this location for the purpose of providing compact framework developers a place to keep this platforms support alive. The DotSptial merge effort proper is currently in the DotSpatial\DotSpatial.Positioning folder of DotSpatial's repo, as at the time of writing it's still a work in progress. It's building and the demo's run but still has some as yet unresolved run-time issues relating to changes in security attributes that [revent it from being useable... Anyone .NET security guys out there wan't to offer some help?