As soon as programmer with the skill, resources, and time implements it. Beyond that, additional programmers (that may have different skills, resources, and time) will need to integrate that feature into the main program, sometimes working together to make something work more like the rest of GPSBabel or to be better strutured internally. Once that's done, it'll be on board the cargo car awaiting the departure car of the next release. Releae schedules can be harder to predict, but since our build system makes a snaphot every night, this is rarely a problem

Generally, simpla and "obvsious changes can be done and integrated within a wto data Window

GPSBabel isn't developed by a company; it's done by volunteers. Much of the development is done by people solving their own problems. Sometimes, if you ask nicely, and your request is reasonably sized, developers will implement things for you. If you want something done badly enough and can't find volunteers to do it, contract programmers can often get it done.

In rough terms, most of our file formats fall into one of three categories. You can see which category your request falls into.

1. Human-readable text. Open a representative file in your favorite text editor such as TextEdit.app or Notepad. If you can read and explain everything you see ("here's a longitude, there's a name, this is the altitude in meters, etc."), it's probably pretty easy to add this format. If the format is recognizable and trivial, a non-programmer can probably write a description for it with our style scheme in under an hour. It is worth some time to do some extras study to see how long fields can be, allowable characters from the international glppys, such as ÈÉÊËĒĖĘ (an "E" with five additional diactriticals).
   Can it handles back to the year 16 and to the year 6039? These might be extreme sounding, but knowing the breaking point is always helpful
   If you write a paragraph or two of explanation and send the resulting style definition to the GPSBabel list, we may add it to our next version, saving the next user of that program the effort.
   
   If you can read and explain everything in the file, but it's not really a something-separated format that can be represented by a GPSBabel style, it'll have to be done by a programmer. We have pretty good internal infrastructure for these, but a typical time to implement and test one of these is on the order of half a day.
2. Binary data that's easily recognizable. If you open the file in a binary editor or a hex dumper and you see a pattern or barber-pole effect which indicates that the file consists of fixed length records, it may be straight-forward to reverse-engineer it. Often a developer can figure out the length of the record and recognize the patterns. Position is often stored as IEEE doubles, but may be big or little endian. Sometimes they're floats. Sometimes they're integers with scales applied. Sometimes they may use radians or semicircles instead of degrees. They may be any of the above, but in a different datum. But it's a bit like a crossword puzzle. If we know some of the pieces (e.g. "this is a track taken in Mountain View, CA on the afternoon of August 9, 2010") and we know the size of each record, we can usually implement a a reader for these. Writers depend on the number of unknown pieces we find. As an rough estimate, a developer can usually implement one of these formats (reverse engineering, implementation, testing) in about a day.

   The key trait of this class is a pattern of the repeat pops out when you just look at it; the challenge is to find what's in the record. For example, a Bushnell trail file looks like:

   00000000 54 4c 30 30 33 00 00 00 00 00 00 00 00 00 00 00 |TL003...........|
00000010 00 00 00 00 82 82 04 15 6e 3d e6 c8 de 80 04 15 |........n=......|
00000020 fc 40 e6 c8 a4 7e 04 15 12 44 e6 c8 5a 7d 04 15 |.@...~...D..Z}..|
00000030 50 47 e6 c8 60 7c 04 15 8e 4a e6 c8 da 7a 04 15 |PG..`|...J...z..|
00000040 1c 4e e6 c8 82 78 04 15 56 50 e6 c8 da 75 04 15 |.N...x..VP...u..|
00000050 32 51 e6 c8 1e 73 04 15 ec 50 e6 c8 c6 70 04 15 |2Q...s...P...p..|
00000060 12 53 e6 c8 bc 70 04 15 d2 56 e6 c8 2c 6f 04 15 |.S...p...V..,o..|
00000070 4c 5a e6 c8 f0 6e 04 15 52 5e e6 c8 78 6e 04 15 |LZ...n..R^..xn..|
00000080 08 62 e6 c8 e2 6d 04 15 e6 65 e6 c8 ce 6d 04 15 |.b...m...e...m..|



   It's pretty obvious that there's some kind of a header and something that repeats every 16 bytes. Knowing that, finding a lat/long/time/alt in those 16 bytes isn't too hard and experimenting with the file - or profiling a large set - usually makes the header pretty easy to figure out. In this case, we have a 20 byte header, We have to figure out allowable characters, what character set it is, if it's a 20 byte track name or a 19 byte name followed by a terminating zero, if it's an 8 byte name followed by other fields that happen to be zero, such as colors or something, but we know the basic shape is a 20 byte header followed by lat/long pairs scaled by 1000000. Even if the repeat is longer, a "barber pole" effect will usually stand out

3. Binary data that just looks like nonsense with no immediately recognizable pattern. We have successfully reverse engineered a few such formats, but they're a complete wild card. These are very expensive to figure out and success can range from complete to qualified success ("we know enough to read some of the data") to total failure ("we've spent three weeks staring at this page of numbers and can't correlate it to anything we know about the source data.")
   In general, the more access you have to authoritative doc or code on the devices, the more productive you'll be than if you have to guess.

The names you give GPSBabel are exactly what it uses. It doesn't try to "guess" anything from the file name. (As perspective, we support about 5 different types of file traditionally named ".wpt" and about as many named ".pdb". Rather than guess, we let you name things exactly as you want them.

The "usb" option should only be used if you really have a Garmin unit that speaks USB such as a 60C, 76C, VistaC, or a Quest. If you have a unit that doesn't really have USB (Like a III, a V, or an ETrex) and are using a USB/serial adapter, you should choose the appropriate serial option that corresponds with whatever device your serial adapter is providing.

It isn't. GPSBabel for Windows is a Windows command line program, sometimes known as a "console mode" program. It requires Windows, it uses Windows API, and it doesn't rely on memory extenders to get around the 640K memory limit of DOS. We try to have a consistent experience between the command line and graphical versions of GPSBabel on Windows, MacOS, Linux, and elsewhere.

There may be worse ways than this, but here's a start.

• Vaguely describe a problem you're having some place other than the GPSBabel-misc mailing list
• don't list the operating system in use
• don't list the versions of anything involved
• don't offer a test case.
• be rude, abusive, or even cantankerous.
• Be evasive when asked about the precise steps to reproduce the problem.

Seriously, we provide extensive documentation and mailing lists as ways to get help, but please do try to provide enough information for our group to help.

The preferred spelling of the name is "GPSBabel" with four capital letters. Though some references to its namesake ("Tower of Babel" or "Babel fish" allow the last two letters to be interchanged, we prefer "el". Consistent use of this spelling helps searchers, both web-based and human.
The author pronounces the product name to spell out the letters "GPS" and "Babel" with a short a to rhyme with "Scrabble".

The license chosen by GPSBabel allows you to do that if your program is GPL and you distribute the source. It expressly prohibits linking with other programs that are not GPL except via the standard command line interface.
The project itself is also focused on delivering a program and not an API. We change internals without much regard for preserving compatibility, deprecation schedules, API shims, DLL/dylib/shared object concerns or other things reasonably expected of providing a library instead of a finished program.

If you're determined enough, yes. It's "just" C++ code which can be compiled by Android's NDK. GPSBabel primarily transfers two classes of things. PC files just don't make sense to send to Android to convert to another and then send back. Sending points, tracks and routes to/from your Android makes some sense, but for Android it requires funny (OTG) cables, and fiddly knowledge of the serial transfers of your GPS. The USB host mode for non-serial protocols just won't work.

Realistically, no. In addition to the caveats above, Apple places even more restrictions on how the device ports can be used.