Thread: [Gpsbabel-code] [PATCH] SkyTraq GPS Logger Support
Brought to you by:
robertl
From: Mathias A. <m....@ad...> - 2008-10-16 21:56:52
Attachments:
skytraq.patch
|
Hello, as mentioned before I'm working on a module to download tracks from Skytraq GPS loggers. Finally, a first patch (against 1.3.6-beta20081006) is attached. The "skytraq" module should work with any device using either Venus 5 or Venus 6 chipsets, e.g. Navilock BT-455PDL. I'm using a "3-in-1" GPS logger made by SJA: <http://www.sja.com.tw/prog/pro5286A3S.htm>. This is the only device I'm testing against, so other devices might require some (hopefully minor) changes... Currently there are two options: * dlbaud: selects the baud rate at which downloads are to be carried out (4800-115200, default 115200) * erase: erase device after read (sorry, not yet implemented) On startup, the device is probed for at each supported baud rate, until found. If dlbaud specifies another speed, the auto-detected initial setting will be restored after the download completes. I'm able to read logs via both USB and bluetooth. USB works at up to 115200 baud. Unfortunately the bluetooth module within the SJA logger seems to be fixed at 9600 baud: via bluetooth, even NMEA output is delivered only if the Skytraq chip is configured to 9600 (so use dlbaud=9600). I'd be glad to hear about if you found a way to speed up bluetooth transfers... What I'll do next: * clean up code, especially process_data_item() and the functions/structs that it uses (still have to make them big-endian-safe...) * provide test data, look at testo. Btw: should I add functions to write/read raw binary data to files? * examine how to deal with the buffer after a roll-over in fifo mode * implement erasing Some notes/questions: * gbser_deinit() restores the baud rate which was active before the last call to gbser_set_port() - is this the intended behaviour? (I expected the settings which were valid before gbser_init() to be restored) * is the automatic initialization to 4800 baud required by other modules? (if gbser_init wouldn't do that I could simply try the current baud rate first when auto-probing devices, as that would mostly be the device's internal setting) Any comments appreciated! Have fun ;-) Regards Mathias |
From: Robert L. <rob...@gm...> - 2008-11-19 04:25:28
|
Hi, and apologies for the delay. I have a backlog of GPSBabel stuff that requires/deserves actual thought. :-) On Thu, Oct 16, 2008 at 3:56 PM, Mathias Adam <m....@ad...> wrote: as mentioned before I'm working on a module to download tracks from > Skytraq GPS loggers. Finally, a first patch (against 1.3.6-beta20081006) > This looks promising. > The "skytraq" module should work with any device using either Venus 5 or > Venus 6 chipsets, e.g. Navilock BT-455PDL. I'm using a "3-in-1" GPS logger > made by SJA: <http://www.sja.com.tw/prog/pro5286A3S.htm>. This is the only > device I'm testing against, so other devices might require some (hopefully > minor) changes... > Please capture the above in the doc when you write it. If docbook isn't your thing, just provide the words and one of us can do the markup. * dlbaud: selects the baud rate at which downloads are to be carried out > For consistency with others let's call it "baud". (Yes, I know that's technically the wrong term, but that's what the world uses...) > 115200 baud. Unfortunately the bluetooth module within the SJA logger > seems to be fixed at 9600 baud: via bluetooth, even NMEA output is > That's very common. Most BT implementations are fast enough for real time positioning, but pretty painful for transferring tracks in bulk. * clean up code, especially process_data_item() and the functions/structs > that it uses (still have to make them big-endian-safe...) > The code seems pretty reasonable for a first pass. + sleep(1); /* allow UART to settle. TODO: is there a better way?? */ use gb_sleep - it knows how to deal with the myriad of insomnia forms. #pragma pack(push, 1) No Microsoft-isms in the code. If you need log_wr_ptr to snuggle up after id, it has to be a char array of 4 bytes to ensure the alignment is right. Historically, this is where Olaf pokes his head in, scolding us for using structures to start with, and suggesting we just gb_(get|put)TYPE and let that code worry about endianness and freeing us of alignment problems... Bitfield structs can get interesting when designing for endian independence, too. Be careful. +static void reorder_bytes(unsigned char *lp) { We already have an army of these functions. + sprintf(wp_name, "TP%04d", ++st->tpn); This can be xasprintf which eliminates the staticly sized buffer and the need to copy it before shoving it into wpt->shortname. + /* TODO: make leap second compensation more general GPS receivers know about the offset between UTC and GPS time (leap seconds are related, but different) because it's transmitted from the satellites. Somewhere in the data stream of what you get from the unit, it should be there. + gbuint8 MSG_LOG_SECTOR_READ_CONTROL[6] = { 0x1D, 0, sector, 0, 1, 0 }; it's minor, but if you make that a static const, it won't have to do a memcpy upon every entry into that function. > * provide test data, look at testo. Btw: should I add functions to > write/read raw binary data to files? Several of the recent data logger contributions have done that. It does help with testability. But it's not really required. If there's some kind of program for these models that already does that and you don't end up inventing a large pile of code just to do that, it gets easier to justify. > Some notes/questions: > * gbser_deinit() restores the baud rate which was active before the last > call to gbser_set_port() - is this the intended behaviour? (I expected the > settings which were valid before gbser_init() to be restored) > I don't think the baud rate after a deinit but before an init is likely to be well defined. It seems like good taste to put it back like we found it, but if we're spinning through combinations of configurations, it would not shock me if we don't get it put back. > * is the automatic initialization to 4800 baud required by other modules? > (if gbser_init wouldn't do that I could simply try the current baud rate > first when auto-probing devices, as that would mostly be the device's > internal setting) > I suspect it was just picked to be a common value and it was better to pick *something* than to just let it be random. > Any comments appreciated! Have fun ;-) > It looks promising and I look forward to seeing the next version. Thanx, RJL |