Thread: [Gpsbabel-code] Documentation for etrex Hcx?
Brought to you by:
robertl
From: linux n. <fir...@ya...> - 2008-05-07 23:50:43
|
Hi all, I recently got a Garmin etrex Vista Hcx and was delighted to see that it is perfectly recognised by gpsbabel. Thanks everyone! I wanted to ask how you figured out the interface, is there documentation from Garmin somewhere about all the codes? For my old etrex Vista (grey lcd version) I use a much simpler app called garble to download tracks and waypoints from the unit, as it uses a simple text format including altitudes, something I wasn't able to get gpsbabel to do. Another thing I'd like to do is use garble's screenshot feature, to get a snapshot of the receiver's screen. However garble chokes on the new Hcx as it seems the packet ids etc are all different - so I was wondering if you managed to find some Garmin documentation on the interfaces? Then maybe I can tweak the garble code to handle it too. Or alternatively is there any way gpsbabel can make screenshots of the receiver's display? Or any way to make a simple delimited text file including altitudes? Thanks! --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. |
From: Robert L. <rob...@gp...> - 2008-05-08 02:06:09
|
On Wed, May 7, 2008 at 6:50 PM, linux newbie <fir...@ya...> wrote: > Hi all, > I recently got a Garmin etrex Vista Hcx and was delighted to see that it > is perfectly recognised by gpsbabel. Thanks everyone! I wanted to ask how > you figured out the interface, is there documentation from Garmin somewhere > about all the codes? > That's actually two different questions. In the early days, Garmin was, uuuh, less than forthcoming with accurate developer info. I had reverse engineered their USB protocol and had it working (admittedly with some excuses) and released for a couple of months before they released their USB specs. After a couple of iterations of that doc, it eventually matched reallity. :-) These days, developer.garmin.com has reasonably complete and accurate specs for the pieces they choose to document. > For my old etrex Vista (grey lcd version) I use a much simpler app called > garble to download tracks and waypoints from the unit, as it uses a simple > text format including altitudes, something I wasn't able to get GPSBabel has a number of formats that include alt. If you want a simple one that includes, it look at gpsutil or pcx, for example. sportsim and garmin301 are others that come to mind, but there are surely others. And if you don't like any of those, creating new ones is trivial via our style scheme. http://www.gpsbabel.org/htmldoc-1.3.5/Styles.html gpsbabel to do. Another thing I'd like to do is use garble's screenshot > feature, to get a snapshot of the receiver's screen. However garble chokes > on the new Hcx as it seems the packet ids etc are all different - so I was > wondering if you managed to find some Garmin documentation on the > interfaces? Then maybe I can tweak the I haven't heard of Garble. Garmin's screen dump protocol isn't documented and it's not something I (or apparently) anyone else has wanted badly enough to reverse engineer and implement in GPSBabel. It's a bit out of GPSBabel's charter, but I'd probably let it in as it's probably not *that* complicated to implement. [1] The work would surely be in figuring out the protocol. I doubt it's even a couple hundred lines of code as the device surely ships it to the host in something that maps to a bmp or a gif pretty easily. Patches welcome. :-) RJL [1] I know how much I like being told things are simple by people that aren't doing the work, so I thought I'd see how it feels on the other end of the stick. |
From: linux n. <fir...@ya...> - 2008-05-08 15:37:09
|
Wow, that makes it even more impressive what you lot have done if you've even done it without documentation! :O hats off. The only doc I found on developer.garmin.com was called the device interface sdk, unfortunately it was from 2006 and the only mention of Vista was a sidenote about version 2.12 of the software (my Vista is running version 3.60). Given that garble understands my Vista but not my Vista HCx I'm assuming that the interfaces have changed since May 2006. I can have another look at that pdf though if you're saying you got accurate information from there. It looks like I need to dig into the Protocol Capability Protocol as a starter, because this is where it starts to look funny. Shame the pdf doesn't even _mention_ the screenshot function though :( About the other gpsbabel formats, that's interesting, but not at all easy to find. At least it confused me so much originally that I assumed gpsbabel couldn't do it. It would be great if the list of formats included a one-line example, that way it would be much easier to spot which of the pagefuls of formats to experiment with. I'll try the ones you suggested, thanks. The program I use to post-process the tracks is not too fussy about field order, delimiters etc so that should be no problem. About the screendumps yes I agree it doesn't fit too beautifully into gpsbabel, and I've no idea how much fun the integration would be, making it fit with the other functions. And I have no clue how many models support such a feature or how standard their behaviours are - I just know that garble generates 4-colour bitmap files from my etrex Vista and I assume it worked for the author's receivers (I tweaked the code a little but didn't write it myself). It's certainly much much less than a couple hundred lines of code by itself but maybe by the time it's made generic and multi-receiver then it would grow... All I know for sure is that the output from the HCx model is different and the values which garble expect to mean height and width of the image, don't (at all). I mean, I know the format of the data must be different because the bit depth is higher but still. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. |
From: Robert L. <rob...@gp...> - 2008-05-08 18:15:58
|
On Thu, May 8, 2008 at 10:36 AM, linux newbie <fir...@ya...> wrote: > > > > The only doc I found on developer.garmin.com was called the device > interface sdk, unfortunately it was from 2006 and the only mention of Vista > was a sidenote about version 2.12 of the software (my Vista is running > That seems about right. They haven't introduced any *new* devices speaking Garmin protocol (the new ones are all file-based GPX models) in a long time. The days of firmware version X and firmware version X+1 in the same model speaking different packet types for trackpoints seem to be behind us. Shame the pdf doesn't even _mention_ the screenshot function though :( > I said it wasn't documented. :-) > About the other gpsbabel formats, that's interesting, but not at all easy > to find. At least it confused me so much originally that I assumed gpsbabel > couldn't do it. It would be great if the list of formats included a > one-line example, that way it would be much easier to spot which of the > pagefuls of formats to experiment with. I'll try the > I've considered that from time to time and haven't ruled it out. The reality, though, is that most users want "a file that works with [program]" and not "a file that contains the following fields". > About the screendumps yes I agree it doesn't fit too beautifully into > gpsbabel, and I've no idea how much fun the integration would be, making it > fit with the other functions. And I have no clue how many models support > such a > Most support it. Garmin's 'ximage' page lists a couple dozen models. We don't know how much variance there is in the protocols used across the line. The fact that it's not documented means each unit probably has to be tested and potentially reverse engineered individually, though my guess is that there is substantial "clumping" in the models, perhaps with variations for screen resolution and color depth, etc. RJL |
From: linux n. <fir...@ya...> - 2008-05-09 14:16:21
|
Wow, that's cool, thanks _very_ much for your help! :) You gave me just the right shove in just the right direction - I was under the impression that the interfaces had changed and that that document was old. (Adding to the confusion was that my old version of gpsbabel couldn't talk to the HCx either, until I upgraded to the newer version)... but anyway you were right, the document was right, and now it works! The problem, if you're interested, was just a stupid one on my part - the garble code didn't take into account all of the specifications in that document (I did say it was much simpler than gpsbabel!) - and in particular didn't take any notice of the extended product data packets. My old Vista never sends them so that's no problem but the HCx does, and that was screwing around with what garble was expecting to receive... A second problem was that the Vista was sending waypoints as D108 (which garble understands) and the HCx sends them as D110 (which it didn't) - but now it's working for both tracks and waypoints, thanks for the help! About the screenshot, I checked out that ximage program you mentioned (had to find a Windows machine first and for some reason install extra USB drivers?!) - but indeed that program can save bmp files from both units. So it is kind of a supported function on both receivers, even if it isn't documented anywhere. With the ext_product_data packets now understood, garble now gets as far as reading the dimensions of the image properly, but there's still lots of hacking around to do there with the data format. First problem is to figure out the way the structure and sequence of the data, the second problem is that during getting the packets for the display data, it usually locks up the receiver (at random stages of the download) and gets a timeout - I guess maybe both sides are waiting for the other to respond. Or something like that. Anyway, just wanted to say thanks, and if I figure it out I'll send you what I found. Cheers, firsttimelinux. Robert Lipe <rob...@gp...> wrote: On Thu, May 8, 2008 at 10:36 AM, linux newbie <fir...@ya...> wrote: The only doc I found on developer.garmin.com was called the device interface sdk, unfortunately it was from 2006 and the only mention of Vista was a sidenote about version 2.12 of the software (my Vista is running That seems about right. They haven't introduced any *new* devices speaking Garmin protocol (the new ones are all file-based GPX models) in a long time. The days of firmware version X and firmware version X+1 in the same model speaking different packet types for trackpoints seem to be behind us. Shame the pdf doesn't even _mention_ the screenshot function though :( I said it wasn't documented. :-) About the other gpsbabel formats, that's interesting, but not at all easy to find. At least it confused me so much originally that I assumed gpsbabel couldn't do it. It would be great if the list of formats included a one-line example, that way it would be much easier to spot which of the pagefuls of formats to experiment with. I'll try the I've considered that from time to time and haven't ruled it out. The reality, though, is that most users want "a file that works with [program]" and not "a file that contains the following fields". About the screendumps yes I agree it doesn't fit too beautifully into gpsbabel, and I've no idea how much fun the integration would be, making it fit with the other functions. And I have no clue how many models support such a Most support it. Garmin's 'ximage' page lists a couple dozen models. We don't know how much variance there is in the protocols used across the line. The fact that it's not documented means each unit probably has to be tested and potentially reverse engineered individually, though my guess is that there is substantial "clumping" in the models, perhaps with variations for screen resolution and color depth, etc. RJL --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. |
From: Oliver E. <oli...@ds...> - 2008-05-09 14:50:56
|
> > > About the screendumps yes I agree it doesn't fit too beautifully > into gpsbabel, and I've no idea how much fun the integration > would be, making it fit with the other functions. And I have no > clue how many models support such a > Sorry if I hijacking the gpsbabel list but you might consider using QLandkarte for doing screenshots. As a GUI app this fits much nicer there :) just my 2 cent Oliver |
From: Robert L. <rob...@gm...> - 2008-05-11 04:31:05
|
On Fri, May 9, 2008 at 9:50 AM, Oliver Eichler < oli...@ds...> wrote: > > > > > > About the screendumps yes I agree it doesn't fit too beautifully > > into gpsbabel, and I've no idea how much fun the integration > > would be, making it fit with the other functions. And I have no > > clue how many models support such a > > > > Sorry if I hijacking the gpsbabel list but you might consider using > QLandkarte for doing screenshots. As a GUI app this fits much nicer there > :) > Does QLandkarte do screenshots? |
From: linux n. <fir...@ya...> - 2008-07-02 13:36:54
|
> the second problem is that during getting the packets for the display > data, it usually locks up the receiver (at random stages of the > download) and gets a timeout I think I found the reason for this. I was using /dev/ttyUSB0 and this was working fine for waypoints and small track files, so I assumed this was the right thing to do. It wasn't until I stumbled over another post somewhere else (from Robert) talking about the garmin_gps module, that I tried blacklisting garmin_gps and using the usb: device (this is with Mandriva) and now the trackpoint retrieval (from gpsbabel and also using Prune as the gui to gpsbabel) works every time instead of 1 in 10. The thing is that I was using garble also with the device /dev/ttyUSB0, and from what I understand the usb: device is internal to gpsbabel, right? So I'd have to reimplement all that code in garble if I wanted to access it there too? Or just bin garble for now if it has to rely on the garmin_gps module :( |
From: Robert L. <rob...@gm...> - 2008-07-03 05:10:12
|
> I think I found the reason for this. I was using /dev/ttyUSB0 and this was > working fine for waypoints and small track files, so I assumed this was the > right thing to do. It wasn't until I stumbled over another post somewhere > else (from Robert) talking about the garmin_gps module, that I tried > blacklisting garmin_gps and using the usb: device (this is with Mandriva) > and now the trackpoint retrieval (from gpsbabel and also using Prune as the > gui to gpsbabel) works every time instead of 1 in 10. > I've typed variations of that so often (including in our own doc) that I may not catch every time I didn't type it. The Garmin "tty driver" that ships with most Linux works intermittently. See http://www.gpsbabel.org/os/Linux_Hotplug.html > > The thing is that I was using garble also with the device /dev/ttyUSB0, and > from what I understand the usb: device is internal to gpsbabel, right? So > I'd have to reimplement all that code in garble if I wanted to access it > there too? Or just bin garble for now if it has to rely on the garmin_gps > module :( "usb:" bypasses the (broken) Linux kernel driver and uses our own protocol implementation via libusb. I don't know what garble does that entices you, but since the two functions you've mentioned (screen capture and wpt/trk/rte xfer) are handled very well by other programs, I'll just say good luck. (And be conscious of licensing issues if you decide to copy code...) RJL |
From: linux n. <fir...@ya...> - 2008-07-03 16:45:34
|
> I've typed variations of that so often (including in > our own doc) that I may > not catch every time I didn't type it. The Garmin > "tty driver" that ships > with most Linux works intermittently. See > http://www.gpsbabel.org/os/Linux_Hotplug.html Yeah, that's exactly the page that your other post linked to. Helped a lot! And works with Mandriva too. > "usb:" bypasses the (broken) Linux kernel driver > and uses our own protocol implementation via libusb. Aha, then that sounds like more effort than it's worth to duplicate the implementation. Maybe I'll just have to stop using garble then. > I don't know what garble does that entices > you, but since the two functions you've mentioned > (screen capture and > wpt/trk/rte xfer) are handled very well by other programs, > I'll just say good luck. Yes, those are the only two things I use garble for. I don't know of another linux program which can do screen capture (correct me if I'm wrong?) and I very much like garble's ability to just output a comma-separated text file rather than xml. However now that Prune can act as a frontend to gpsbabel, that's no longer an issue - I don't have to save the xml. So the only thing left is the screen capture - if you know of other programs which can handle this "very well" then I'm sorted! |
From: Robert L. <rob...@gm...> - 2008-07-04 05:20:38
|
> Yes, those are the only two things I use garble for. I don't know of > another linux program which can do screen capture (correct me if I'm wrong?) > and I very much like garble's ability to just Oliver responded earlier in this very thread that QLandcarte does screen capture. output a comma-separated text file rather than xml. However now that Prune > can act as a frontend to gpsbabel, that's no longer an issue - I don't have > to save the xml. GPSBabel handles a zillion comma-separated formats and makes it trivial to add more. Never heard of Prune before now. Interesting. RJL |
From: linux n. <fir...@ya...> - 2008-07-04 09:14:56
|
(Sorry for double posting!) > Oliver responded earlier in this very thread that QLandcarte does screen > capture. Oops, my apologies, I misunderstood that first response. I thought it meant that the feature would fit better if it were added to QLandkarte rather than added to gpsbabel. I didn't realise it was already there! My mistake, sorry. I'll try it out asap. > GPSBabel handles a zillion comma-separated formats and > makes it trivial to add more. True, but a program with one simple format is easier to use than one with a zillion different ones. No offence but I tried to find a suitable format inamongst the zillion other ones and it wasn't a great deal of fun. True, I could get into the documentation and figure out how to define yet another format (trivial for you, and probably easier than it appears), but in this case the massive power and flexibility of gpsbabel wasn't what I needed, I just needed a simple output and that is what garble had been giving me. Anyway, like I said this problem is now solved, and I'll be using gpsbabel full-time from now on, via the frontend. Thanks for a great program and thanks for the patient support! |
From: linux n. <fir...@ya...> - 2008-07-07 07:55:44
|
> > Oliver responded earlier in this very thread that > QLandcarte does screen > > capture. Hi again, Thanks for the QLandkarte tip, that's an interesting program! I couldn't find a binary for Mandriva but managed to get version 0.7.2 compiled ok and it runs. The good news: it does indeed understand my etrex vista hcx and gets screengrabs no problem :) For my older etrex vista (with a serial cable) it downloads waypoints ok but says that the screenshot funtion is not implemented. If you did want to support this I can show you the relevant bits of the garble code, it's quite simple. In order to get it to compile I had to comment out four lines in ui_IToolViewRoute.h, where it calls setLeftMargin(1), setTopMargin(1) and so on on the box layout. qmake tells me I've got "Qt version 4.2.3" but maybe those four methods were added later? Also, I noticed a few typos in the english, maybe these are helpful? potocol protocol favorit favorite where rectified were rectified failes fails (sorry for the list hijack!) Anyway, that sounds like the death knell for garble - now I can do everything I want with gpsbabel and QLandkarte :) |
From: Oliver E. <oli...@ds...> - 2008-07-04 05:28:51
|
>> I don't know what garble does that entices >> you, but since the two functions you've mentioned >> (screen capture and >> wpt/trk/rte xfer) are handled very well by other programs, >> I'll just say good luck. > Yes, those are the only two things I use garble for. I don't know of another linux program which can do screen capture (correct me if I'm wrong?) and I very much like garble's ability to just output a comma-separated text file rather than xml. However now that Prune can act as a frontend to gpsbabel, that's no longer an issue - I don't have to save the xml. > So the only thing left is the screen capture - if you know of other programs which can handle this "very well" then I'm sorted! Shhh, try QLandkarte ;) Oliver |