Thread: Re: [Gpsbabel-misc] Adding support for GPS based on MTK chip
Brought to you by:
robertl
From: John D. <e4b...@ya...> - 2007-11-21 21:19:32
|
Hello, I created a gpsbabel module for MTK loggers (tested with i-Blue 747) a while back. I had a few problems with getting the erase functionality to work correctly which kept me from including my source. Current functions: - Read MTK datalog from USB/NMEA packets - decode MTK binary to gpsbabel trackppint - output raw data.bin file - output MTK compatible CSV file (as optional part of decode process) Current issues: - Erase doesn't work - will corrupt the memory... - Uses temporary data.bin file - which may be problematic on some OS ? - Outputs somewhat to much debug ....probably more...it was a few months ago I had a look at it last time. Which is the preferred way for inclusion ? code-mailing list or CVS ? Regards Devlin --------------------------------- Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. |
From: Robert L. <rob...@gm...> - 2007-11-22 05:23:15
|
> I created a gpsbabel module for MTK loggers (tested with i-Blue 747) a > while > back. I had a few problems with getting the erase functionality to work > correctly > which kept me from including my source. > I wouldn't consider the absence of erase a deal-breaker. If you have a module that's otherwise ready to go (esp if you and Niccolo are willing to work together to iterate through details) bring it on. > > Which is the preferred way for inclusion ? code-mailing list or CVS ? Patches to -code . We'll work with you on portability, doc, test cases, etc. RJL |
From: Niccolo R. <os...@ri...> - 2007-11-22 10:04:13
|
> Current issues: > - Erase doesn't work - will corrupt the memory... Strange, It is just one command! can you try my Perl program? It has also a lot of debug with option '-d7': http://www.rigacci.org/wiki/doku.php/doc/appunti/hardware/gps_logger_i_blue_747 > - Uses temporary data.bin file - which may be problematic on some OS ? I save the .bin file too, then parse it to produce the GPX. I don't want to load everything in ram. Is it possible to have a look at the code? Just to start understanding GPSBabel internals. -- Niccolo Rigacci Firenze - Italy |
From: Didier A. <dar...@gm...> - 2008-01-01 16:03:55
|
Hello, I also would like to help adding support to MTK loggers to gpsbabel. I have a NavGear DL-3200BT (which seems to be a clone of the i-Blue PS-747), and lack support for Mac OS X. I have fetched the latest source code via anonymous CVS, but it seems nothing has been integrated yet. Is there anything I can do to help? There are two functions that need to be achieved for a complete support : 1) Setup of the GPS : format of the log, what to include in it, and when to log (seconds, meters, speed). 2) retrieval of the log from the device to a file. Function 2) can obviously be accomplished via gpsbabel after having written the dedicated code; but I was wondering if the community considers 1) as a role of GPSBabel, or should it be done separately? Regards, Didier. |
From: John D. <e4b...@ya...> - 2008-01-03 17:49:03
|
Hello, As you may have noticed I sent a patch to the -code list a few weeks ago - unfortunately it seems to have been in HTML format which might explain why the MTK logger patch hasn't been integrated. As gpsbabel primary function is format conversion rather than GPS specific configuration I would say 'function 2' is appropriate now. There is a bt747 project on sourceforge which is an improved/fixed version for the MTK loggers - it's written in java and should work on Mac OS. /devlin > > I also would like to help adding support to MTK > loggers to gpsbabel. I > have a NavGear DL-3200BT (which seems to be a clone > of the i-Blue > PS-747), and lack support for Mac OS X. > > I have fetched the latest source code via anonymous > CVS, but it seems > nothing has been integrated yet. Is there anything I > can do to help? > > There are two functions that need to be achieved for > a complete support : > 1) Setup of the GPS : format of the log, what to > include in it, and > when to log (seconds, meters, speed). > 2) retrieval of the log from the device to a file. > > Function 2) can obviously be accomplished via > gpsbabel after having > written the dedicated code; but I was wondering if > the community > considers 1) as a role of GPSBabel, or should it be > done separately? > ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ |
From: Andy A. <an...@he...> - 2008-01-01 16:13:32
|
On 1 Jan 2008, at 16:03, Didier Arenzana wrote: > Hello, > > I also would like to help adding support to MTK loggers to gpsbabel. I > have a NavGear DL-3200BT (which seems to be a clone of the i-Blue > PS-747), and lack support for Mac OS X. > > I have fetched the latest source code via anonymous CVS, but it seems > nothing has been integrated yet. Is there anything I can do to help? > > There are two functions that need to be achieved for a complete > support : > 1) Setup of the GPS : format of the log, what to include in it, and > when to log (seconds, meters, speed). > 2) retrieval of the log from the device to a file. > > Function 2) can obviously be accomplished via gpsbabel after having > written the dedicated code; but I was wondering if the community > considers 1) as a role of GPSBabel, or should it be done separately? There's a precedent here - although I'm not sure it's a good one. I added support for Wintec GPS pucks. There's no user interface on the device so all setup is done, conventionally, using the Windows application that comes with the device. I chose not to attempt to add setup to GPSBabel because there isn't - as far as I know - any infrastructure in GPSBabel to support that kind of thing. Make of that what you will :) -- Andy Armstrong, Hexten |
From: Robert L. <rob...@gm...> - 2008-01-01 17:14:34
|
> I also would like to help adding support to MTK loggers to gpsbabel. I > > have a NavGear DL-3200BT (which seems to be a clone of the i-Blue > > PS-747), and lack support for Mac OS X. > > > > I have fetched the latest source code via anonymous CVS, but it seems > > nothing has been integrated yet. Is there anything I can do to help? > John submitted a patch for review on Dec. 13. I was travelling at the time but reviewed it on Dec. 21. With the holidays upon us, and the minor changes needed before we integrated it, I figured he'd get to it soonish. If you have access to the hardware and would like to make those changes and resubmit to gpsbabel-code, I don't see a problem with that. It's not far from being ready, it was just far enough away that it needs a little attention. > I added support for Wintec GPS pucks. There's no user interface on the > device so all setup is done, conventionally, using the Windows > application that comes with the device. I chose not to attempt to add > setup to GPSBabel because there isn't - as far as I know - any > infrastructure in GPSBabel to support that kind of thing. My Wintec has never been attached to anything other that Mac and Linux systems, so I guess I don't really know what kind of setup is needed for them. (BTW, Andy, can you tell us a story about "Wintec" vs. "G-Ray"?) But Andy's punchline matches mine; if you have something with a substantial UI component, we don't have good prior art. It's not that we're really opposed to it, it's the reality that so far we haven't had any real UI jocks on the project that have been able to meet our cross-platform portability requirements. This is why we have different GUIs maintained by different volunteers that are experts in their respective languages/OSes. If you wanted to produce a GUI configurator for MTK that was written to *really* be portable (e.g. Qt, WxWidgets, etc.) that'd be groovy. If you wanted to write one that just solved your own problem (AppleScript, Cocoa, etc.) that wouldn't be terrible. If you wanted to write one that required proprietary tools to build, as our existing GUIs do, you'd be signing up for the maintenance on it. In either case, I'd probably distribute it separately from the GPSBabel itself, but we could certainly hitch it to our infrastructure. Propose specifics. |
From: Andy A. <an...@he...> - 2008-01-01 17:18:39
|
On 1 Jan 2008, at 17:14, Robert Lipe wrote: > My Wintec has never been attached to anything other that Mac and Linux > systems, so I guess I don't really know what kind of setup is needed > for > them. (BTW, Andy, can you tell us a story about "Wintec" vs. "G- > Ray"?) I /think/ it's just a branding difference - possibly for different markets. Not sure :) -- Andy Armstrong, Hexten |
From: Didier A. <dar...@gm...> - 2008-01-01 21:55:57
|
2008/1/1, Robert Lipe <rob...@gm...>: > John submitted a patch for review on Dec. 13. I was travelling at the time > but > reviewed it on Dec. 21. With the holidays upon us, and the minor changes > needed before we integrated it, I figured he'd get to it soonish. > > If you have access to the hardware and would like to make those changes > and resubmit to gpsbabel-code, I don't see a problem with that. It's not > far > from being ready, it was just far enough away that it needs a little > attention. Thanks for your reply. I found the patch in the archive of the -code mailing-list, but did not find your comments on it. What changes are needed? > But Andy's punchline matches mine; if you have something with a substantial > UI component, we don't have good prior art. It's not that we're really > opposed > to it, it's the reality that so far we haven't had any real UI jocks on the > project > that have been able to meet our cross-platform portability requirements. > This > is why we have different GUIs maintained by different volunteers that are > experts > in their respective languages/OSes. > > If you wanted to produce a GUI configurator for MTK that was written to > *really* > be portable (e.g. Qt, WxWidgets, etc.) that'd be groovy. If you wanted to > write > one that just solved your own problem (AppleScript, Cocoa, etc.) that > wouldn't > be terrible. If you wanted to write one that required proprietary tools to > build, as > our existing GUIs do, you'd be signing up for the maintenance on it. Well, I intend to write a GUI for Mac OSX, using this project as a way to learn Xcode, objective-C and Cocoa, so this would be OSX-specific. But I want to make the "non-UI" part of it as portable as possible, so this work could be benefit to other platforms as well. Which is why I'd like to add as much as possible to gpsbabel. Regards, Ddier. |
From: Robert L. <rob...@gm...> - 2008-01-01 22:24:08
|
> Thanks for your reply. I found the patch in the archive of the -code > mailing-list, but did not find your comments on it. What changes are > That's because sourceforge's list archive thingy stinks. Here's another archive: http://www.nabble.com/Support-for-GPS-loggers-with-MTK-chip-to14326057.html#a14326057 Well, I intend to write a GUI for Mac OSX, using this project as a way > to learn Xcode, objective-C and Cocoa, so this would be OSX-specific. That's not a deal-breaker in itself. It does reduce the size of the helper pool. Depending on the degree of separation you need/want, it could be a separate project completely or we can fold it into our source tree. > But I want to make the "non-UI" part of it as portable as possible, so > this work could be benefit to other platforms as well. Which is why > I'd like to add as much as possible to gpsbabel. Once the core protocol and device comms are in place, you can build all kinds of crazy command lines or control files to get the GUI to do GPSBabel to do its bidding. |