Garmin Communicator Plugin replacement / Chrome USB API

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Garmin Communicator Plugin replacement / Chrome USB API

Tom Grundy
Hello - we're trying to develop a replacement for Garmin Communicator Plugin which is basically at end-of-life due to the web browser NPAPI plugin end-of-life.

We've tried several things and are most interested in making a Chrome extension using the Chrome USB API.  On Mac it connects just fine to a Garmin 60 CSx, but, on Windows, it won't open the connection until you replace the grmnusb driver with the WinUSB driver, using a program like zadig. On linux, the similar problem is documented here:  https://www.gpsbabel.org/os/Linux_Hotplug.html

Question: how does gpsbabel on Windows talk with the Garmin even though the grmnusb driver is in place?  Did the gpsbabel developers find out the right code to talk with the grmnusb driver itself?  Or, are there some permissions or such to change to allow gpsbabel to talk directly to the Garmin device, over the native USB, bypassing the grmnusb driver?

Or, bringing the question back to a broader level, what would folks recommend as a replacement for GCP?  It seems Garmin just plain does not want to make one.

Thanks

------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Garmin Communicator Plugin replacement / Chrome USB API

Robert Lipe-4


On Thu, Jun 18, 2015 at 7:34 PM, Tom Grundy <[hidden email]> wrote:
Hello - we're trying to develop a replacement for Garmin Communicator Plugin which is basically at end-of-life due to the web browser NPAPI plugin end-of-life.

Describing "we" might be helpful.
 
We've tried several things and are most interested in making a Chrome extension using the Chrome USB API.  On Mac it connects just fine to a Garmin 60 CSx, but, on Windows, it won't open the connection until you replace the grmnusb driver with the WinUSB driver, using a program like zadig. On linux, the similar problem is documented here:  https://www.gpsbabel.org/os/Linux_Hotplug.html

So this isn't a GPSBabel bugreport/question, but rather a "how do I create my own GPSBabel-like program", right?  That's kind of OK - I just want to be sure I understand the questions.  (It's more OK with me if you're creating an open source or free app than if you're creating a commercial app and using my knowledge for your profit - and this specific knowledge was probably the most expensive in all of GPSBabel to develop.)
 
Question: how does gpsbabel on Windows talk with the Garmin even though the grmnusb driver is in place?  Did the gpsbabel developers find out the right code to talk with the grmnusb driver itself?  Or, are there some permissions or such to change to allow gpsbabel to talk directly to the Garmin device, over the native USB, bypassing the grmnusb driver?

GPSBabel is open source - there are no secrets how we do anything.  That's kind of the point of the project...

On Windows, the Garmin USB driver handles the host horrible aspects of the protocol devices.  We talk to (and therefore, require)  that driver and use an interface to it that was documented by Garmin.  Citation: https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpsusbwin.cc

For OSes where there is no driver (Windows, Mac, FreeBSD, NetBSD, etc.) we use a library called libusb which basically brings "raw" USB out to user space. libusb makes all of these OSes look the same to us, but little else.  (OS/X does provide a native raw interface via IOKit, but we use libusb everywhere for simplicity.) This leaves us bit-banging the devices ourselves and makes us responsible for a lot of device-specific bugs.  Note the screaming horror in comments and device-specific gunk in https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpslibusb.cc

At a glance at chrome.usb, it (unsurprisingly) provides an interface that's quite similar to the libusb layer (pretty much the raw USB as described in the USB spec and what's on the wire), so porting GPSBabel to use the Chrome runtime and plumbing chrome.usb as a new bottom end isn't the craziest talk ever.  If you even think about that, you need to read and understand our license, the GNU Public License.   I'd likely accept patches to add that to our build.


It's worth saying that most of the Garmin USB protocol work was done in a time when USB was actually my day job, so I had ready access to a USB protocol analyzer and specifications and knew a crazy amount of USB esoterica.  GPSBabel was the first non-Garmin app to implement Garmin USB protocol, was the only one for a long time, and even today supports combinations that Garmin themselves won't support in their GCP.

Garmin's USB protocol is pretty clearly a layer of paint over their serial protocol.  I made the 60C's work first serially, as compared to other units just before them (Garmin V, Vista) they "merely" added a few fields in existing packets (d108/109/110).  When I learned the USB implementation was still the same protocol, even down to checksums and acks (which is handled by the silicon on USB) and a window size of one, IIRC, it explained a lot about the terrible USB performance.

 

Or, bringing the question back to a broader level, what would folks recommend as a replacement for GCP?  It seems Garmin just plain does not want to make one.

I think Garmin doesn't care too much about the USB Protocol devices.  In hardware years, they're pretty clearly in the past.  The last really "new" product using it was about the 60C/76C which was 11 years ago.  Sure, they got a respin (X) in 2006 when some of the other aging models like Venture and eTrex were retrofitted with USB and less terrible GPS receivers, but we've not seen any actual NEW devices using Garmin protocol in about ten years now.   As annoyed as I can be with Garmin's development process and attention span, when NPAPI went away, I do somewhat understand why they couldn't justify a ton of development for an aging part of their device pool compared to the much less terrible Mass Storage devices.

 

Thanks

------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc



------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Garmin Communicator Plugin replacement / Chrome USB API

Tom Grundy
Hey thanks for the quick and thorough reply.  I'm not the lead developer so can't speak for his long-term plans.  I will ask him to chime in.  I definitely understand the concern.

Right now, this is for caltopo.com, and sartopo.com (and its offline version, sarsoft).  Those are currently free but not open source; the last two are in use by our search and rescue team.

>> So this isn't a GPSBabel bugreport/question, but rather a "how do I create my own GPSBabel-like program", right?
Definitely not a bug report, or a question on using GPSBabel.  The only capability we're trying to create from scratch is a chrome extension to transfer waypoints/tracks/routes with a Garmin (including Garmin-mode models since probably >50% of our 'fleet' is still Garmin 60CSx).  Tomato / temotto.  One option we were looking at (briefly) is using chrome native messaging to talk with gpsbabel (or a wrapper around it, which serves as a native messaging host), but it would be a lot better to only have to rely on chrome and not on any external applications.

You mention the interface to the grmnusb driver that was published by Garmin - are you referring to http://www8.garmin.com/support/pdf/iop_spec.pdf ?  Reviewing that, it looks like maybe section 3.2.4 (Garmin USB Driver for Microsoft Windows) is the key one; I skipped right past that and dove in to the data protocols. 3.2.4 implies that on Windows we should be using the Win32 interface commands, and not the chrome.usb API?  However, it looks like you can't call the native Win32 API from inside chrome, does that sound right to you?

Anyway, if this is on the right track, then it does specifically answer the question of how GPSBabel manages to 'work with' grmnusb instead of requiring that you replace grmnusb with libusb or WinUSB.  (Short answer: 'read section 3.2.4 of the Garmin doc) That was a real head-scratcher, so, thank you.

A lot of the rest of your reply is well over my head as I'm pretty much a newbie and just volunteering some time to help out the lead developer, but I appreciate it.  If you could let me know if this re-interpretation is on the right track, it would be a big help!  Thanks again.


On Fri, Jun 19, 2015 at 5:44 AM, Robert Lipe <[hidden email]> wrote:


On Thu, Jun 18, 2015 at 7:34 PM, Tom Grundy <[hidden email]> wrote:
Hello - we're trying to develop a replacement for Garmin Communicator Plugin which is basically at end-of-life due to the web browser NPAPI plugin end-of-life.

Describing "we" might be helpful.
 
We've tried several things and are most interested in making a Chrome extension using the Chrome USB API.  On Mac it connects just fine to a Garmin 60 CSx, but, on Windows, it won't open the connection until you replace the grmnusb driver with the WinUSB driver, using a program like zadig. On linux, the similar problem is documented here:  https://www.gpsbabel.org/os/Linux_Hotplug.html

So this isn't a GPSBabel bugreport/question, but rather a "how do I create my own GPSBabel-like program", right?  That's kind of OK - I just want to be sure I understand the questions.  (It's more OK with me if you're creating an open source or free app than if you're creating a commercial app and using my knowledge for your profit - and this specific knowledge was probably the most expensive in all of GPSBabel to develop.)
 
Question: how does gpsbabel on Windows talk with the Garmin even though the grmnusb driver is in place?  Did the gpsbabel developers find out the right code to talk with the grmnusb driver itself?  Or, are there some permissions or such to change to allow gpsbabel to talk directly to the Garmin device, over the native USB, bypassing the grmnusb driver?

GPSBabel is open source - there are no secrets how we do anything.  That's kind of the point of the project...

On Windows, the Garmin USB driver handles the host horrible aspects of the protocol devices.  We talk to (and therefore, require)  that driver and use an interface to it that was documented by Garmin.  Citation: https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpsusbwin.cc

For OSes where there is no driver (Windows, Mac, FreeBSD, NetBSD, etc.) we use a library called libusb which basically brings "raw" USB out to user space. libusb makes all of these OSes look the same to us, but little else.  (OS/X does provide a native raw interface via IOKit, but we use libusb everywhere for simplicity.) This leaves us bit-banging the devices ourselves and makes us responsible for a lot of device-specific bugs.  Note the screaming horror in comments and device-specific gunk in https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpslibusb.cc

At a glance at chrome.usb, it (unsurprisingly) provides an interface that's quite similar to the libusb layer (pretty much the raw USB as described in the USB spec and what's on the wire), so porting GPSBabel to use the Chrome runtime and plumbing chrome.usb as a new bottom end isn't the craziest talk ever.  If you even think about that, you need to read and understand our license, the GNU Public License.   I'd likely accept patches to add that to our build.


It's worth saying that most of the Garmin USB protocol work was done in a time when USB was actually my day job, so I had ready access to a USB protocol analyzer and specifications and knew a crazy amount of USB esoterica.  GPSBabel was the first non-Garmin app to implement Garmin USB protocol, was the only one for a long time, and even today supports combinations that Garmin themselves won't support in their GCP.

Garmin's USB protocol is pretty clearly a layer of paint over their serial protocol.  I made the 60C's work first serially, as compared to other units just before them (Garmin V, Vista) they "merely" added a few fields in existing packets (d108/109/110).  When I learned the USB implementation was still the same protocol, even down to checksums and acks (which is handled by the silicon on USB) and a window size of one, IIRC, it explained a lot about the terrible USB performance.

 

Or, bringing the question back to a broader level, what would folks recommend as a replacement for GCP?  It seems Garmin just plain does not want to make one.

I think Garmin doesn't care too much about the USB Protocol devices.  In hardware years, they're pretty clearly in the past.  The last really "new" product using it was about the 60C/76C which was 11 years ago.  Sure, they got a respin (X) in 2006 when some of the other aging models like Venture and eTrex were retrofitted with USB and less terrible GPS receivers, but we've not seen any actual NEW devices using Garmin protocol in about ten years now.   As annoyed as I can be with Garmin's development process and attention span, when NPAPI went away, I do somewhat understand why they couldn't justify a ton of development for an aging part of their device pool compared to the much less terrible Mass Storage devices.

 

Thanks

------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc




------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Garmin Communicator Plugin replacement / Chrome USB API

Robert Lipe-4


On Fri, Jun 19, 2015 at 10:15 AM, Tom Grundy <[hidden email]> wrote:
Hey thanks for the quick and thorough reply.  I'm not the lead developer so can't speak for his long-term plans.  I will ask him to chime in.  I definitely understand the concern.

Right now, this is for caltopo.com, and sartopo.com (and its offline version, sarsoft).  Those are currently free but not open source; the last two are in use by our search and rescue team.

If they (or anyone) use our code or ideas that come from it, GPL applies.

 
>> So this isn't a GPSBabel bugreport/question, but rather a "how do I create my own GPSBabel-like program", right?
Definitely not a bug report, or a question on using GPSBabel.  The only capability we're trying to create from scratch is a chrome extension to transfer waypoints/tracks/routes with a Garmin (including Garmin-mode models since probably >50% of our 'fleet' is still Garmin 60CSx).  Tomato / temotto. 

That 60CSx is a workhorse, no doubt.
 
One option we were looking at (briefly) is using chrome native messaging to talk with gpsbabel (or a wrapper around it, which serves as a native messaging host), but it would be a lot better to only have to rely on chrome and not on any external applications.

You can spend a lot of effort re-implementing GPSBabel or you can just use it.  Certainly if you can just shell out to the existing, tested executable your life will be a lot simpler than if you have to build it.
 
You mention the interface to the grmnusb driver that was published by Garmin - are you referring to http://www8.garmin.com/support/pdf/iop_spec.pdf ? 

Looks familiar.  It was about three years late (I implemented my stuff before this doc existed) and sections of it range between misleading and downright wrong, but that's the doc you need.  ISTR in the early days, there was a serial spec, a USB spec, and a Windows driver spec and that version merged them all together.
 
Reviewing that, it looks like maybe section 3.2.4 (Garmin USB Driver for Microsoft Windows) is the key one; I skipped right past that and dove in to the data protocols. 3.2.4 implies that on Windows we should be using the Win32 interface commands, and not the chrome.usb API?  However, it looks like you can't call the native Win32 API from inside chrome, does that sound right to you?

I'd hope the Chrome API would be independent of the underlying OS (how else would your extension work on OS/X?) so that certainly sounds right.

 
Anyway, if this is on the right track, then it does specifically answer the question of how GPSBabel manages to 'work with' grmnusb instead of requiring that you replace grmnusb with libusb or WinUSB.  (Short answer: 'read section 3.2.4 of the Garmin doc) That was a real head-scratcher, so, thank you.

A lot of the rest of your reply is well over my head as I'm pretty much a newbie and just volunteering some time to help out the lead developer, but I appreciate it.  If you could let me know if this re-interpretation is on the right track, it would be a big help!  Thanks again.

This protocol was hugely expensive for us (me) to develop and it took years. If you'd like a Chrome API version of (a subset of) GPSBabel to handle the protocol stuff and provide you with a sane API, we could consider that as a contract project.

The serial models are too horrible for me to even talk about in a Chrome API context at this point.  I could test pretty much anything from a 276C/60CS/60CSX/i5/Venture HC range and the installed base of several million users.  Way more than that when you consider that implementation is used in everything from various geotaggers to GSAK to Google Earth... 

RJL
 


On Fri, Jun 19, 2015 at 5:44 AM, Robert Lipe <[hidden email]> wrote:


On Thu, Jun 18, 2015 at 7:34 PM, Tom Grundy <[hidden email]> wrote:
Hello - we're trying to develop a replacement for Garmin Communicator Plugin which is basically at end-of-life due to the web browser NPAPI plugin end-of-life.

Describing "we" might be helpful.
 
We've tried several things and are most interested in making a Chrome extension using the Chrome USB API.  On Mac it connects just fine to a Garmin 60 CSx, but, on Windows, it won't open the connection until you replace the grmnusb driver with the WinUSB driver, using a program like zadig. On linux, the similar problem is documented here:  https://www.gpsbabel.org/os/Linux_Hotplug.html

So this isn't a GPSBabel bugreport/question, but rather a "how do I create my own GPSBabel-like program", right?  That's kind of OK - I just want to be sure I understand the questions.  (It's more OK with me if you're creating an open source or free app than if you're creating a commercial app and using my knowledge for your profit - and this specific knowledge was probably the most expensive in all of GPSBabel to develop.)
 
Question: how does gpsbabel on Windows talk with the Garmin even though the grmnusb driver is in place?  Did the gpsbabel developers find out the right code to talk with the grmnusb driver itself?  Or, are there some permissions or such to change to allow gpsbabel to talk directly to the Garmin device, over the native USB, bypassing the grmnusb driver?

GPSBabel is open source - there are no secrets how we do anything.  That's kind of the point of the project...

On Windows, the Garmin USB driver handles the host horrible aspects of the protocol devices.  We talk to (and therefore, require)  that driver and use an interface to it that was documented by Garmin.  Citation: https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpsusbwin.cc

For OSes where there is no driver (Windows, Mac, FreeBSD, NetBSD, etc.) we use a library called libusb which basically brings "raw" USB out to user space. libusb makes all of these OSes look the same to us, but little else.  (OS/X does provide a native raw interface via IOKit, but we use libusb everywhere for simplicity.) This leaves us bit-banging the devices ourselves and makes us responsible for a lot of device-specific bugs.  Note the screaming horror in comments and device-specific gunk in https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpslibusb.cc

At a glance at chrome.usb, it (unsurprisingly) provides an interface that's quite similar to the libusb layer (pretty much the raw USB as described in the USB spec and what's on the wire), so porting GPSBabel to use the Chrome runtime and plumbing chrome.usb as a new bottom end isn't the craziest talk ever.  If you even think about that, you need to read and understand our license, the GNU Public License.   I'd likely accept patches to add that to our build.


It's worth saying that most of the Garmin USB protocol work was done in a time when USB was actually my day job, so I had ready access to a USB protocol analyzer and specifications and knew a crazy amount of USB esoterica.  GPSBabel was the first non-Garmin app to implement Garmin USB protocol, was the only one for a long time, and even today supports combinations that Garmin themselves won't support in their GCP.

Garmin's USB protocol is pretty clearly a layer of paint over their serial protocol.  I made the 60C's work first serially, as compared to other units just before them (Garmin V, Vista) they "merely" added a few fields in existing packets (d108/109/110).  When I learned the USB implementation was still the same protocol, even down to checksums and acks (which is handled by the silicon on USB) and a window size of one, IIRC, it explained a lot about the terrible USB performance.

 

Or, bringing the question back to a broader level, what would folks recommend as a replacement for GCP?  It seems Garmin just plain does not want to make one.

I think Garmin doesn't care too much about the USB Protocol devices.  In hardware years, they're pretty clearly in the past.  The last really "new" product using it was about the 60C/76C which was 11 years ago.  Sure, they got a respin (X) in 2006 when some of the other aging models like Venture and eTrex were retrofitted with USB and less terrible GPS receivers, but we've not seen any actual NEW devices using Garmin protocol in about ten years now.   As annoyed as I can be with Garmin's development process and attention span, when NPAPI went away, I do somewhat understand why they couldn't justify a ton of development for an aging part of their device pool compared to the much less terrible Mass Storage devices.

 

Thanks

------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc





------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Garmin Communicator Plugin replacement / Chrome USB API

Tom Grundy
>> If they (or anyone) use our code or ideas that come from it, GPL applies.

I will reiterate that to the lead developer, though I'm pretty sure he is very diligent about following licenses already.

>> That 60CSx is a workhorse, no doubt.

I'm one of a few teachers of the GPS class for our SAR team.  Many of us still feel the 60CSx user interface is WAY better and more intuitive than the 62 and up.  It's certainly way more teachable.  O well.  Guess we're gettin' old.

>> This protocol was hugely expensive for us (me) to develop and it took years. If you'd like a Chrome API version of (a subset of) GPSBabel to handle the protocol stuff and provide you with a sane API, we could consider that as a contract project.

That sounds intriguing and I will make sure to pass it along; what basic route you would follow?  All of the above, if I understand it correctly (which is a big 'if') indicates that you can't use any chrome API extension or app to talk to the grmnusb driver in Windows, period, (since you can't use chrome to call Win32 (or any native OS) API) and that the only workaround options would be chrome native messaging, or getting the grmnusb driver out of the way and replacing it with something else?

What we've got now is the first steps of a chrome extension and app that goes from the ground up using the chrome usb api.  It works on Mac (i.e. we can read waypoints, and were starting work towards the other GPS data types), and it works on Windows >if< you replace the grmnusb driver with the WinUSB (or probably libusb) driver, similar to the web page on your site about the same topic for linux.  The chrome app uses the Garmin protocols as spelled out in that doc from Garmin, D110 for waypoints, etc, and slices up the return data into the useful components.  The fact that it doesn't work on Windows with grmnusb driver is the root cause of all of this.

Anyway, sorry if I made any implications that we were trying to overreach GPL or trying to ask questions that are more detailed than GPL would allow for.  I am not really versed in the GPL development world so please do cut me off when/where needed.  The map tools sartopo.com and sarsoft have basically been developed as a huge gift to the SAR community.  We were just among the truckloads of users who have been thrown under the bus by the NPAPI end-of-life and have been trying to find the right routes to pursue in order to code our way back from the grave.

By the way, I've had a help ticket open with Garmin about this for a while, and they just confirmed this morning that they don't have (or, won't speak about) any plans to replace the functionality of Garmin Communicator Plugin.  Sigh.



On Fri, Jun 19, 2015 at 8:39 AM, Robert Lipe <[hidden email]> wrote:


On Fri, Jun 19, 2015 at 10:15 AM, Tom Grundy <[hidden email]> wrote:
Hey thanks for the quick and thorough reply.  I'm not the lead developer so can't speak for his long-term plans.  I will ask him to chime in.  I definitely understand the concern.

Right now, this is for caltopo.com, and sartopo.com (and its offline version, sarsoft).  Those are currently free but not open source; the last two are in use by our search and rescue team.

If they (or anyone) use our code or ideas that come from it, GPL applies.

 
>> So this isn't a GPSBabel bugreport/question, but rather a "how do I create my own GPSBabel-like program", right?
Definitely not a bug report, or a question on using GPSBabel.  The only capability we're trying to create from scratch is a chrome extension to transfer waypoints/tracks/routes with a Garmin (including Garmin-mode models since probably >50% of our 'fleet' is still Garmin 60CSx).  Tomato / temotto. 

That 60CSx is a workhorse, no doubt.
 
One option we were looking at (briefly) is using chrome native messaging to talk with gpsbabel (or a wrapper around it, which serves as a native messaging host), but it would be a lot better to only have to rely on chrome and not on any external applications.

You can spend a lot of effort re-implementing GPSBabel or you can just use it.  Certainly if you can just shell out to the existing, tested executable your life will be a lot simpler than if you have to build it.
 
You mention the interface to the grmnusb driver that was published by Garmin - are you referring to http://www8.garmin.com/support/pdf/iop_spec.pdf ? 

Looks familiar.  It was about three years late (I implemented my stuff before this doc existed) and sections of it range between misleading and downright wrong, but that's the doc you need.  ISTR in the early days, there was a serial spec, a USB spec, and a Windows driver spec and that version merged them all together.
 
Reviewing that, it looks like maybe section 3.2.4 (Garmin USB Driver for Microsoft Windows) is the key one; I skipped right past that and dove in to the data protocols. 3.2.4 implies that on Windows we should be using the Win32 interface commands, and not the chrome.usb API?  However, it looks like you can't call the native Win32 API from inside chrome, does that sound right to you?

I'd hope the Chrome API would be independent of the underlying OS (how else would your extension work on OS/X?) so that certainly sounds right.

 
Anyway, if this is on the right track, then it does specifically answer the question of how GPSBabel manages to 'work with' grmnusb instead of requiring that you replace grmnusb with libusb or WinUSB.  (Short answer: 'read section 3.2.4 of the Garmin doc) That was a real head-scratcher, so, thank you.

A lot of the rest of your reply is well over my head as I'm pretty much a newbie and just volunteering some time to help out the lead developer, but I appreciate it.  If you could let me know if this re-interpretation is on the right track, it would be a big help!  Thanks again.

This protocol was hugely expensive for us (me) to develop and it took years. If you'd like a Chrome API version of (a subset of) GPSBabel to handle the protocol stuff and provide you with a sane API, we could consider that as a contract project.

The serial models are too horrible for me to even talk about in a Chrome API context at this point.  I could test pretty much anything from a 276C/60CS/60CSX/i5/Venture HC range and the installed base of several million users.  Way more than that when you consider that implementation is used in everything from various geotaggers to GSAK to Google Earth... 

RJL
 


On Fri, Jun 19, 2015 at 5:44 AM, Robert Lipe <[hidden email]> wrote:


On Thu, Jun 18, 2015 at 7:34 PM, Tom Grundy <[hidden email]> wrote:
Hello - we're trying to develop a replacement for Garmin Communicator Plugin which is basically at end-of-life due to the web browser NPAPI plugin end-of-life.

Describing "we" might be helpful.
 
We've tried several things and are most interested in making a Chrome extension using the Chrome USB API.  On Mac it connects just fine to a Garmin 60 CSx, but, on Windows, it won't open the connection until you replace the grmnusb driver with the WinUSB driver, using a program like zadig. On linux, the similar problem is documented here:  https://www.gpsbabel.org/os/Linux_Hotplug.html

So this isn't a GPSBabel bugreport/question, but rather a "how do I create my own GPSBabel-like program", right?  That's kind of OK - I just want to be sure I understand the questions.  (It's more OK with me if you're creating an open source or free app than if you're creating a commercial app and using my knowledge for your profit - and this specific knowledge was probably the most expensive in all of GPSBabel to develop.)
 
Question: how does gpsbabel on Windows talk with the Garmin even though the grmnusb driver is in place?  Did the gpsbabel developers find out the right code to talk with the grmnusb driver itself?  Or, are there some permissions or such to change to allow gpsbabel to talk directly to the Garmin device, over the native USB, bypassing the grmnusb driver?

GPSBabel is open source - there are no secrets how we do anything.  That's kind of the point of the project...

On Windows, the Garmin USB driver handles the host horrible aspects of the protocol devices.  We talk to (and therefore, require)  that driver and use an interface to it that was documented by Garmin.  Citation: https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpsusbwin.cc

For OSes where there is no driver (Windows, Mac, FreeBSD, NetBSD, etc.) we use a library called libusb which basically brings "raw" USB out to user space. libusb makes all of these OSes look the same to us, but little else.  (OS/X does provide a native raw interface via IOKit, but we use libusb everywhere for simplicity.) This leaves us bit-banging the devices ourselves and makes us responsible for a lot of device-specific bugs.  Note the screaming horror in comments and device-specific gunk in https://code.google.com/p/gpsbabel/source/browse/trunk/gpsbabel/jeeps/gpslibusb.cc

At a glance at chrome.usb, it (unsurprisingly) provides an interface that's quite similar to the libusb layer (pretty much the raw USB as described in the USB spec and what's on the wire), so porting GPSBabel to use the Chrome runtime and plumbing chrome.usb as a new bottom end isn't the craziest talk ever.  If you even think about that, you need to read and understand our license, the GNU Public License.   I'd likely accept patches to add that to our build.


It's worth saying that most of the Garmin USB protocol work was done in a time when USB was actually my day job, so I had ready access to a USB protocol analyzer and specifications and knew a crazy amount of USB esoterica.  GPSBabel was the first non-Garmin app to implement Garmin USB protocol, was the only one for a long time, and even today supports combinations that Garmin themselves won't support in their GCP.

Garmin's USB protocol is pretty clearly a layer of paint over their serial protocol.  I made the 60C's work first serially, as compared to other units just before them (Garmin V, Vista) they "merely" added a few fields in existing packets (d108/109/110).  When I learned the USB implementation was still the same protocol, even down to checksums and acks (which is handled by the silicon on USB) and a window size of one, IIRC, it explained a lot about the terrible USB performance.

 

Or, bringing the question back to a broader level, what would folks recommend as a replacement for GCP?  It seems Garmin just plain does not want to make one.

I think Garmin doesn't care too much about the USB Protocol devices.  In hardware years, they're pretty clearly in the past.  The last really "new" product using it was about the 60C/76C which was 11 years ago.  Sure, they got a respin (X) in 2006 when some of the other aging models like Venture and eTrex were retrofitted with USB and less terrible GPS receivers, but we've not seen any actual NEW devices using Garmin protocol in about ten years now.   As annoyed as I can be with Garmin's development process and attention span, when NPAPI went away, I do somewhat understand why they couldn't justify a ton of development for an aging part of their device pool compared to the much less terrible Mass Storage devices.

 

Thanks

------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc






------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
SRE
Reply | Threaded
Open this post in threaded view
|

Re: Garmin Communicator Plugin replacement / Chrome USB API

SRE
At 10:48 AM 6/19/2015, Tom Grundy wrote:
>he is very diligent about following licenses already

Robert said something rather important that may not have stuck out:
>"You can spend a lot of effort re-implementing GPSBabel or you can just
>use it.  Certainly if you can just shell out to the existing, tested
>executable your life will be a lot simpler than if you have to build it."

Your lead guy will probably know what that means, but basically you
can just call this amazing tool as a sub-process, hopefully giving
credit and allowing others to know about it, instead of mining ideas
and code snippets and then doing a bunch of the same work over.

I'm a late-comer to GPSBabel, but I managed to buff up a small chunk
of the code with some bug fixes and enhancements to solve a big problem
I had (and perhaps convince the developers not to ditch the format I
cared about). Everyone is better off if this tool gets added to instead
of being copied or bypassed.

Steve


------------------------------------------------------------------------------
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Garmin Communicator Plugin replacement / Chrome USB API

Tom Grundy
Thanks, that is looking like a better option.  You can see the appeal of wanting your web page to be self-contained and not rely on any external applications (via chrome native messaging); of course, even 'back in the day' (i.e. today) the end user had to take the step of getting the garmin communicator plugin, so, in that sense, it's not all that different...

PS I think what we were doing was more 'reinventing the wheel' rather than copying it, i.e. we were working ground-up from the Garmin USB spec.  Regardless - a very good point and I'll forward this to the lead as well.
-Tom

On Fri, Jun 19, 2015 at 1:21 PM, SRE <[hidden email]> wrote:
At 10:48 AM 6/19/2015, Tom Grundy wrote:
>he is very diligent about following licenses already

Robert said something rather important that may not have stuck out:
>"You can spend a lot of effort re-implementing GPSBabel or you can just
>use it.  Certainly if you can just shell out to the existing, tested
>executable your life will be a lot simpler than if you have to build it."

Your lead guy will probably know what that means, but basically you
can just call this amazing tool as a sub-process, hopefully giving
credit and allowing others to know about it, instead of mining ideas
and code snippets and then doing a bunch of the same work over.

I'm a late-comer to GPSBabel, but I managed to buff up a small chunk
of the code with some bug fixes and enhancements to solve a big problem
I had (and perhaps convince the developers not to ditch the format I
cared about). Everyone is better off if this tool gets added to instead
of being copied or bypassed.

Steve



------------------------------------------------------------------------------

_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc