I apologize in advance for my complete ignorance in coding, but an observation I've made in the Skytraq specification is that it has a COCOM limit of -

Altitude <18000m or Velocity <515m/s. Either may be exceeded but not both.

515m/s = 1854km/hr = 1001kts

Could it be that a 10-Bit value is sufficient to store the maximum value allowable in knots?

COCOM -

http://en.wikipedia.org/wiki/CoCom




Message: 3
Date: Thu, 15 Dec 2011 09:23:41 +0100
From: Josef Reisinger <datafabdriver@aol.com>
Subject: Re: [Gpsbabel-misc] MiniHomer: Problems downloading tracks
    [SOLVED]
To: Robert Lipe <robertlipe@gmail.com>
Cc: m.adam@adamis.de, gpsbabel-misc@lists.sourceforge.net,    ZNEX |
    Juergen Heinz <j.heinz@znex.de>,    jean-christophe.haessig@dianosis.org
Message-ID: <4EE9AE8D.7040103@aol.com>
Content-Type: text/plain; charset="iso-8859-1"

Robert,

there may be indeed another change necessary to reflect the behavior of
the miniHomer device (which is based on syktraq chip set). According to
the specification, the speed is stored as a 10-Bit value, resulting into
a maximum speed of 1023 km/h in the recording. I had one occasion where
a plane exceeded the speed. Looking at the low-level data in the
protocol, it seems as if at least  miniHomer correctly uses 11 bits to
recording the speed. I don't know whether this is miniHomer specific.
The three bits "above" the 10 for speed are marked as reserved in the
specification.
I own another skytraq-based device (as you might remember from a
previous discussion quite a time ago), but I won't travel at a speed >
1023km/h in the next couple of weeks, so I cannot compare the behaviour
of miniHomer with the other device.

I would anyway assume that logging is part of the core skytraq software
and any skytraq based device will use eleven bits for speed.
Therefor I would propose to change the skytraq.c module.

To correctly record speeds exceeding 1023km/h, the following change
would be necessary:

In line 622 of skytraq.c , the 0x0F mask needs to be changed to 0x1F
Old:
#define ITEM_SPEED(item) (item->type_and_speed[1] |
((item->type_and_speed[0] & 0x0F) << 8))
New:
#define ITEM_SPEED(item) (item->type_and_speed[1] |
((item->type_and_speed[0] & 0x1F) << 8))

Let me know about your view.

Kind regards
Josef Reisinger


From: "gpsbabel-misc-request@lists.sourceforge.net" <gpsbabel-misc-request@lists.sourceforge.net>
To: gpsbabel-misc@lists.sourceforge.net
Sent: Thursday, 15 December 2011 4:26 PM
Subject: Gpsbabel-misc Digest, Vol 67, Issue 10

Send Gpsbabel-misc mailing list submissions to
    gpsbabel-misc@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
or, via email, send a message with subject or body 'help' to
    gpsbabel-misc-request@lists.sourceforge.net

You can reach the person managing the list at
    gpsbabel-misc-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gpsbabel-misc digest..."


Today's Topics:

  1. Re: MiniHomer: Problems downloading tracks [SOLVED] (Mathias Adam)
  2. part of exported tracklog is repeated (Evan Thoms)
  3. Re: MiniHomer: Problems downloading tracks [SOLVED]
      (Josef Reisinger)


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

Message: 1
Date: Tue, 13 Dec 2011 00:42:31 +0100
From: Mathias Adam <m.adam@adamis.de>
Subject: Re: [Gpsbabel-misc] MiniHomer: Problems downloading tracks
    [SOLVED]
To: Robert Lipe <robertlipe@gmail.com>
Cc: gpsbabel-misc@lists.sourceforge.net, ZNEX | Juergen Heinz
    <j.heinz@znex.de>,    jean-christophe.haessig@dianosis.org
Message-ID: <4EE69167.4050502@adamis.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

Am 12.12.2011 03:17, schrieb Robert Lipe:
>
>
> On Fri, Dec 9, 2011 at 4:57 AM, Josef Reisinger <datafabdriver@aol.com
> <mailto:datafabdriver@aol.com>> wrote:
>
>    Folks,
>
>    there seems to be a lot of "embellishment" in the source code which
>    might have broken one line. Robert, you are right, it is line 247
>    (SECTOR_READ_END[] vs. SECTOR_READ_END[13]) which breaks the code.
>    Could you revert the line to have the [13] specified?
>
>
> I had a bad feeling that was it.  The code actually is doing something
> odd - it's defining S_R_E as a buffer of 13 bytes but using an
> initializer of 14 bytes.  (Remember that C strings always have a
> terminating NUL.)    In C++, that's simply not legal.

indeed, that's no proper C++... though it's ok in C (if I remember
correctly, the compiler doesn't add a trailing \0 if the initializer
otherwise fits exactly into the array?). However in this case I'd avoid
that syntax even in C as I suspect that the \0 embedded in the string
would cause trouble sometime (as it did now; after all it worked ok for
more than 2 years now ;-) ).

> So I'll revert this for now, but we probably need to go back to the []
> notation and use sizeof(blah)-1 in the various loops that use it that
> don't want to see a terminator.  But release cycles as they are (esp. as
> I don't have the affected hardware) we'll go with low risk for now.

Because, with the embedded \0, it in fact isn't a string but rather an
array of chars, I'd suggest to change it like this:

--- 02_checkout-rev4135/gpsbabel/skytraq.c    2011-12-12 03:58:40.000000000
+0100
+++ 03_02-make/gpsbabel/skytraq.c    2011-12-13 00:04:40.000000000 +0100
@@ -244,7 +244,7 @@

  gbuint8 NL[2] = { 0x0D, 0x0A };
  gbuint8 MSG_START[2] = { 0xA0, 0xA1 };
-gbuint8 SECTOR_READ_END[13] = "END\0CHECKSUM=";
+gbuint8 SECTOR_READ_END[] = { 'E','N','D', 0,
'C','H','E','C','K','S','U','M','=' };

  static int
  skytraq_calc_checksum(const unsigned char *buf, int len)

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

btw Robert, why'd you remove the length specifier there? should this be
done with NL and MSG_START too?


Regards,
Mathias

>
>
>    As you touch the sources anyway, could you replace line 646
>    f.gps_week = ts & 0x00000FFF;
>    by
>    f.gps_week = ts & 0x00000 *3* FF;
>
>    (replace mask 0xfff by 0x3ff)
>
>
> Done.
> Thanx for checking it out.
>
> You said you had some other changes pending.  Was that it, or are now
> now clear for takeoff for 1.4.3 from you?
>
> RJL
>
>
>
>    Kind regards
>    /jr
>
>    Am 07.12.2011 17:52, schrieb Robert Lipe:
>>
>>    Could you please experiment with for foo[] vs foo[13]) change at
>>    the top? That was the only thing that caught my eye as potentially
>>    suspicious when I reviewed it yesterday. The changes are small and
>>    I think I broke it.
>>
>>    Like me,  Mathias is traveling right now and said he'd help
>>    investigate when he's back.
>>
>>    On Dec 7, 2011 7:01 AM, "Josef Reisinger" <datafabdriver@aol.com
>>    <mailto:datafabdriver@aol.com>> wrote:
>>
>>        Hi out there,
>>
>>        I can verify the same for 1.4.3 on Windows and Linux. I did a
>>        quick
>>        compare of the sources of the relevant module between 1.4.2
>>        and 1.4.3
>>        and couldn't see changes which immediately would point me to
>>        this issue.
>>        As minihomer and skytraq inputs are broken, this seems not to be
>>        minihomer-specific.
>>
>>        I contributed the miniHomer add-on on top of the skytraq
>>        module and the
>>        changes I made against 1.4.2 work quite a while for me. There
>>        are other
>>        changes in the sources for 1.4.3 which I don't know who
>>        applied them.
>>
>>        Depended on my availability I might do a debug session over
>>        the weekend
>>        - a thing which I would like to avoid :-(
>>
>>        Mathias, Jean-Christophe, any views from your side?
>>
>>        Kind regards
>>        /jr
>>
>>        On 06.12.2011 19:10, Olaf Petersen wrote:
>>        > Hi everyone,
>>        >
>>        > I am facing problems to download data from my MiniHomer
>>        logger, using GPSBabel ver. 1.4.3-beta20111112 on MS Windows 7
>>        Home Premium SP1. The logger was updated to the FNAM Sports 4
>>        - firmware and everything runs fine on nTrip 1.2.14
>>        >
>>        > When I try to invoke GPSBabel with
>>        > "gpsbabel -D3 -i miniHomer,baud=38400,read-at-once=0 -f com3
>>        -x height,wgs84tomsl
>>        > -x track,split=1h,title="TRACK" -o gtm -F
>>        c:\Users\olafpe\Documents\GPS\lasttrack.gtm"
>>        > I get an error message "Error reading sector #0". Same if I
>>        try to dump-file. I have appended a full printout at the end
>>        of this message. Each time, GPSBabel pauses for a few moments
>>        after printing the line "Reading sector #0", on a higher
>>        debug-level it can be seen that the MiniHomer only sends
>>        NMEA-data meanwhile, so I do have the idea that a new binary
>>        command-set is used in the newer firmware-versions.
>>        >
>>        > When I experiment with first-sector and last-sector options,
>>        all I manage is to download the POIs when I force GPSBabel to
>>        read an empty sector by e.g. setting first-sector and
>>        last-sector to 2. Only then a GTM-file is created. It is no
>>        problem to delete the MiniHomer's log using GPSBabel.
>>        >
>>        > Should I return to a previous firmware version? FNAM Sports
>>        3 won't do the job.
>>        >
>>        >
>>        > Thank you in advance!
>>        >
>>        > Olaf
>>        >
>>        >
>>        > Printout follows
>>        > options: module/option=value: miniHomer/baud="38400"
>>        > options: module/option=value: miniHomer/erase="0" (=default)
>>        > options: module/option=value: miniHomer/first-sector="0"
>>        (=default)
>>        > options: module/option=value: miniHomer/initbaud="38400"
>>        (=default)
>>        > options: module/option=value: miniHomer/last-sector="-1"
>>        (=default)
>>        > options: module/option=value: miniHomer/no-output="0" (=default)
>>        > options: module/option=value: miniHomer/read-at-once="0"
>>        > Translated port name: "com3"
>>        > skytraq: Probing SkyTraq Venus at 38400baud...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x02)
>>        > Receiving message with 14 bytes of payload (expected>=14)
>>        > skytraq: Venus device found: Kernel version = 1.4.42, ODM
>>        version = 1.4.41, revision (Y/M/D) = 11/03/23
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x17)
>>        > Receiving message with 37 bytes of payload (expected>=9)
>>        > skytraq: Device status: free sectors: 509 / total sectors:
>>        509 / 0% used / write ptr: 10996
>>        > skytraq: Reading log data from device...
>>        > skytraq: start=0 used=1
>>        > skytraq: opt_last_sector_val=-1
>>        > Reading sector #0...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x1b)
>>        > skytraq: Didn't get sector end tag
>>        > Reading sector #0...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x1b)
>>        > skytraq: Didn't get sector end tag
>>        > Reading sector #0...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x1b)
>>        > skytraq: Didn't get sector end tag
>>        >
>>        >
>>        >
>>        >
>>
>>
>>        ------------------------------------------------------------------------------
>>        Cloud Services Checklist: Pricing and Packaging Optimization
>>        This white paper is intended to serve as a reference,
>>        checklist and point of
>>        discussion for anyone considering optimizing the pricing and
>>        packaging model
>>        of a cloud services business. Read Now!
>>        http://www.accelacomm.com/jaw/sfnl/114/51491232/
>>        _______________________________________________
>>        Gpsbabel-misc mailing list http://www.gpsbabel.org
>>        Gpsbabel-misc@lists.sourceforge.net
>>        <mailto:Gpsbabel-misc@lists.sourceforge.net>
>>        To unsubscribe, change list options, or see archives, visit:
>>        https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>
>
>
>




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

Message: 2
Date: Wed, 14 Dec 2011 15:36:55 -0900
From: Evan Thoms <ethoms@usgs.gov>
Subject: [Gpsbabel-misc] part of exported tracklog is repeated
To: gpsbabel-misc@lists.sourceforge.net
Message-ID: <4EE94127.2070106@usgs.gov>
Content-Type: text/plain; charset="iso-8859-1"

Hello there,
I use a Canmore USB thumbdrive data logger (GT-730FL-S) with GPS
Babel. I wrote the python script below for extraction:
(the main thing to notice is the switches)

It works fine except that the tracklogs always have a section that is
repeated. For example, in a particular gpx file, the vertices from
1530 ~ 2038 are exactly the same as the vertices from ~ 1020 ~ 1529.

Can anyone suggest what might be going on here?

Thanks
Evan

I can send a gpx or kml file; I just thought not to clog the pipe
unless someone wants to see it.


*****************************
import os
import time


path = r'C:\Workspace\misc\GPStracks'

kmlname = time.strftime("%b_%d_%y.kml", time.localtime())
gpxname = time.strftime("%b_%d_%y.gpx", time.localtime())
csvname = time.strftime("%b_%d_%y.csv", time.localtime())

gpxpath = os.path.join(path, gpxname)
kmlpath = os.path.join(path, kmlname)
csvpath = os.path.join(path, csvname)

switches = []
switches.append('gpsbabel')
switches.append('-t')
switches.append('-i
skytraq,erase,baud=0,initbaud=4800,read-at-once=0,first-sector=0')
switches.append('-f COM3')
switches.append('-o kml,lines,trackdata,labels')
switches.append('-F ' + kmlpath)
switches.append('-o gpx,lines,trackdata,labels')
switches.append('-F ' + gpxpath)
#switches.append('-o csv,lines,trackdata,labels')
#switches.append('-F ' + csvpath)

print 'Calling gpsbabel'
os.system(' '.join(switches))
print 'Opening ', kmlpath
os.system(kmlpath)
***********************************************************
-------------- next part --------------
An HTML attachment was scrubbed...

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

Message: 3
Date: Thu, 15 Dec 2011 09:23:41 +0100
From: Josef Reisinger <datafabdriver@aol.com>
Subject: Re: [Gpsbabel-misc] MiniHomer: Problems downloading tracks
    [SOLVED]
To: Robert Lipe <robertlipe@gmail.com>
Cc: m.adam@adamis.de, gpsbabel-misc@lists.sourceforge.net,    ZNEX |
    Juergen Heinz <j.heinz@znex.de>,    jean-christophe.haessig@dianosis.org
Message-ID: <4EE9AE8D.7040103@aol.com>
Content-Type: text/plain; charset="iso-8859-1"

Robert,

there may be indeed another change necessary to reflect the behavior of
the miniHomer device (which is based on syktraq chip set). According to
the specification, the speed is stored as a 10-Bit value, resulting into
a maximum speed of 1023 km/h in the recording. I had one occasion where
a plane exceeded the speed. Looking at the low-level data in the
protocol, it seems as if at least  miniHomer correctly uses 11 bits to
recording the speed. I don't know whether this is miniHomer specific.
The three bits "above" the 10 for speed are marked as reserved in the
specification.
I own another skytraq-based device (as you might remember from a
previous discussion quite a time ago), but I won't travel at a speed >
1023km/h in the next couple of weeks, so I cannot compare the behaviour
of miniHomer with the other device.

I would anyway assume that logging is part of the core skytraq software
and any skytraq based device will use eleven bits for speed.
Therefor I would propose to change the skytraq.c module.

To correctly record speeds exceeding 1023km/h, the following change
would be necessary:

In line 622 of skytraq.c , the 0x0F mask needs to be changed to 0x1F
Old:
#define ITEM_SPEED(item) (item->type_and_speed[1] |
((item->type_and_speed[0] & 0x0F) << 8))
New:
#define ITEM_SPEED(item) (item->type_and_speed[1] |
((item->type_and_speed[0] & 0x1F) << 8))

Let me know about your view.

Kind regards
Josef Reisinger

On 12.12.2011 03:17, Robert Lipe wrote:
>
>
> On Fri, Dec 9, 2011 at 4:57 AM, Josef Reisinger <datafabdriver@aol.com
> <mailto:datafabdriver@aol.com>> wrote:
>
>    Folks,
>
>    there seems to be a lot of "embellishment" in the source code
>    which might have broken one line. Robert, you are right, it is
>    line 247 (SECTOR_READ_END[] vs. SECTOR_READ_END[13]) which breaks
>    the code.
>    Could you revert the line to have the [13] specified?
>
>
> I had a bad feeling that was it.  The code actually is doing something
> odd - it's defining S_R_E as a buffer of 13 bytes but using an
> initializer of 14 bytes.  (Remember that C strings always have a
> terminating NUL.)    In C++, that's simply not legal.
>
> So I'll revert this for now, but we probably need to go back to the []
> notation and use sizeof(blah)-1 in the various loops that use it that
> don't want to see a terminator.  But release cycles as they are (esp.
> as I don't have the affected hardware) we'll go with low risk for now.
>
>
>    As you touch the sources anyway, could you replace line 646
>    f.gps_week = ts & 0x00000FFF;
>    by
>    f.gps_week = ts & 0x00000_*3*_FF;
>
>    (replace mask 0xfff by 0x3ff)
>
>
> Done.
> Thanx for checking it out.
>
> You said you had some other changes pending.  Was that it, or are now
> now clear for takeoff for 1.4.3 from you?
>
> RJL
>
>
>
>    Kind regards
>    /jr
>
>    Am 07.12.2011 17:52, schrieb Robert Lipe:
>>
>>    Could you please experiment with for foo[] vs foo[13]) change at
>>    the top? That was the only thing that caught my eye as
>>    potentially suspicious when I reviewed it yesterday. The changes
>>    are small and I think I broke it.
>>
>>    Like me,  Mathias is traveling right now and said he'd help
>>    investigate when he's back.
>>
>>    On Dec 7, 2011 7:01 AM, "Josef Reisinger" <datafabdriver@aol.com
>>    <mailto:datafabdriver@aol.com>> wrote:
>>
>>        Hi out there,
>>
>>        I can verify the same for 1.4.3 on Windows and Linux. I did a
>>        quick
>>        compare of the sources of the relevant module between 1.4.2
>>        and 1.4.3
>>        and couldn't see changes which immediately would point me to
>>        this issue.
>>        As minihomer and skytraq inputs are broken, this seems not to be
>>        minihomer-specific.
>>
>>        I contributed the miniHomer add-on on top of the skytraq
>>        module and the
>>        changes I made against 1.4.2 work quite a while for me. There
>>        are other
>>        changes in the sources for 1.4.3 which I don't know who
>>        applied them.
>>
>>        Depended on my availability I might do a debug session over
>>        the weekend
>>        - a thing which I would like to avoid :-(
>>
>>        Mathias, Jean-Christophe, any views from your side?
>>
>>        Kind regards
>>        /jr
>>
>>        On 06.12.2011 19:10, Olaf Petersen wrote:
>>        > Hi everyone,
>>        >
>>        > I am facing problems to download data from my MiniHomer
>>        logger, using GPSBabel ver. 1.4.3-beta20111112 on MS Windows
>>        7 Home Premium SP1. The logger was updated to the FNAM Sports
>>        4 - firmware and everything runs fine on nTrip 1.2.14
>>        >
>>        > When I try to invoke GPSBabel with
>>        > "gpsbabel -D3 -i miniHomer,baud=38400,read-at-once=0 -f
>>        com3 -x height,wgs84tomsl
>>        > -x track,split=1h,title="TRACK" -o gtm -F
>>        c:\Users\olafpe\Documents\GPS\lasttrack.gtm"
>>        > I get an error message "Error reading sector #0". Same if I
>>        try to dump-file. I have appended a full printout at the end
>>        of this message. Each time, GPSBabel pauses for a few moments
>>        after printing the line "Reading sector #0", on a higher
>>        debug-level it can be seen that the MiniHomer only sends
>>        NMEA-data meanwhile, so I do have the idea that a new binary
>>        command-set is used in the newer firmware-versions.
>>        >
>>        > When I experiment with first-sector and last-sector
>>        options, all I manage is to download the POIs when I force
>>        GPSBabel to read an empty sector by e.g. setting first-sector
>>        and last-sector to 2. Only then a GTM-file is created. It is
>>        no problem to delete the MiniHomer's log using GPSBabel.
>>        >
>>        > Should I return to a previous firmware version? FNAM Sports
>>        3 won't do the job.
>>        >
>>        >
>>        > Thank you in advance!
>>        >
>>        > Olaf
>>        >
>>        >
>>        > Printout follows
>>        > options: module/option=value: miniHomer/baud="38400"
>>        > options: module/option=value: miniHomer/erase="0" (=default)
>>        > options: module/option=value: miniHomer/first-sector="0"
>>        (=default)
>>        > options: module/option=value: miniHomer/initbaud="38400"
>>        (=default)
>>        > options: module/option=value: miniHomer/last-sector="-1"
>>        (=default)
>>        > options: module/option=value: miniHomer/no-output="0"
>>        (=default)
>>        > options: module/option=value: miniHomer/read-at-once="0"
>>        > Translated port name: "com3"
>>        > skytraq: Probing SkyTraq Venus at 38400baud...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x02)
>>        > Receiving message with 14 bytes of payload (expected>=14)
>>        > skytraq: Venus device found: Kernel version = 1.4.42, ODM
>>        version = 1.4.41, revision (Y/M/D) = 11/03/23
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x17)
>>        > Receiving message with 37 bytes of payload (expected>=9)
>>        > skytraq: Device status: free sectors: 509 / total sectors:
>>        509 / 0% used / write ptr: 10996
>>        > skytraq: Reading log data from device...
>>        > skytraq: start=0 used=1
>>        > skytraq: opt_last_sector_val=-1
>>        > Reading sector #0...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x1b)
>>        > skytraq: Didn't get sector end tag
>>        > Reading sector #0...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x1b)
>>        > skytraq: Didn't get sector end tag
>>        > Reading sector #0...
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Receiving message with 2 bytes of payload (expected>=2)
>>        > Got ACK (id=0x1b)
>>        > skytraq: Didn't get sector end tag
>>        >
>>        >
>>        >
>>        >
>>
>>
>>        ------------------------------------------------------------------------------
>>        Cloud Services Checklist: Pricing and Packaging Optimization
>>        This white paper is intended to serve as a reference,
>>        checklist and point of
>>        discussion for anyone considering optimizing the pricing and
>>        packaging model
>>        of a cloud services business. Read Now!
>>        http://www.accelacomm.com/jaw/sfnl/114/51491232/
>>        _______________________________________________
>>        Gpsbabel-misc mailing list http://www.gpsbabel.org
>>        Gpsbabel-misc@lists.sourceforge.net
>>        <mailto:Gpsbabel-misc@lists.sourceforge.net>
>>        To unsubscribe, change list options, or see archives, visit:
>>        https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...

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

------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs. 
But none more important than the need to reduce IT complexity
while improving strategic productivity.  Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/

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

_______________________________________________
Gpsbabel-misc mailing list
Gpsbabel-misc@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc


End of Gpsbabel-misc Digest, Vol 67, Issue 10
*********************************************