Re: [Gpsbabel-misc] Garmin GPS Live Data Velocity

[Robert L. <rob...@gp...>]

On Wed, Nov 18, 2009 at 12:01 PM, Jeff McFadden <jef...@gm...>wrote:

> Robert,
>
> Thanks so much. I had just stumbled onto that section of the code after my
> last email. I've made the change and it's working for me. As you noted, the
> "wandering" gives you a constantly changing heading when you're stationary,
> which is both expected and acceptable to me. I can choose how to handle that
> in the code where I'm storing the VPT data into my database.
>

There are a number of filtering solutions you can do to dampen that.  What I
did for Google Earth was to just plain not record any motion under 50
meters.   As the typical use there is in a car, this simple approach gave
reasonable point resolution and eliminated the clutter and overzoom when you
were at a stop light.

There's all kinds of nerdy filtering you can do.  What works well for a
bicyclist works poorly for a geocacher.   Since it sounds like you control
the software and you know the rules of whatever it is that you're
collecting, you should be able to pick thresholds an moving averages that
make sense for your case.





> I really appreciate your help! Thank you!
>
> -- Jeff
>
>
> On Wed, Nov 18, 2009 at 10:00 AM, Robert Lipe <rob...@gp...>wrote:
>
>>
>>
>> On Wed, Nov 18, 2009 at 10:30 AM, Jeff McFadden <jef...@gm...>wrote:
>>
>>> What I'm trying to do is use the nmea sentences that GPSBabel is
>>> generating to pipe into another application that will handle the data
>>> logging.
>>>
>>> The connection looks something like this: /Applications/gpsbabelfe-bin.app/Contents/MacOS/gpsbabel
>>> -T -i garmin,get_posn -f usb: -o kml -F - | my_data_logger.rb
>>>
>>
>> OK, so you're using -T.  the get_posn is just extraneous.   I don't know
>> how NMEA figures into the above command, but I do now understand what's
>> going on.  The problem you're seeing is on the read side, not hte write
>> side, so you mixing NMEA and KML on the write side is a distraction. There
>> was some code sketched into the Garmin PVT reader to address this, but it
>> was never turned on.
>>
>> #if 0
>>         /* velocity in m/s */
>>         wpt->speed = sqrt(pvt->north*pvt->north + pvt->east*pvt->east);
>>         wpt->vs = pvt->up;
>> #endif
>>
>> If you want to experiment with it in garmin.c, replace that block with
>> something like:
>>     WAYPT_SET(wpt, speed,  sqrt(pvt->north*pvt->north +
>> pvt->east*pvt->east);
>>
>> I think for any amount of distance you could move between PVT updates,
>> pythagorean is probably "good enough" but you can experiment with that.
>> It's definitely better than the existing "WAYPT_SET(wpt, speed, 1);" that's
>> there now and is the source of the one meter that you're seeing.   I've
>> looked in the code history to try to find some justificatio for this
>> underachievement and don't know why this was put in but left disabled.
>> It's very likely that it had something to do with the "speed of sound while
>> sitting 'still'" problem I'd mentioned before.
>>
>>
>>
>>
>>
>>> 1) Based on my example above, am I using GPSBabel in the best way to try
>>> to get at that data, or is there a better way to get at it?
>>>
>>
>> I know you said you didn't want to do this, but if you were reading a
>> track from the device instead of doing it in real-time and writing to a KML
>> file, we'd compute instantaneous velocity.
>>
>>
>>
>>> 4) Am I just out of my mind on this whole thing and I should go back to
>>> using GPSd because this isn't what GPSBabel is trying to do?
>>>
>>
>> Does GPSD support Garmin USB in the absence of a kernel driver that
>> converts Garmin PVT to "serial", as the Linux guys do?
>>
>> If you can't find joy in the above line of code, consider a "puck" or
>> Bluetooth GPS.   Either easily hooks to a Mac (the former will often need
>> drivers for the serial/usb converter that's internal to them but they're
>> almost always something like a Prolific or FTDI part so commodity Mac
>> drivers work) and hocks up "real" NMEA for under $50.
>>
>>
>>> Thanks for all the work you have all put into his product. I've been
>>> using it to read/write data from my eTrex (waypoints, tracks, routes) for a
>>> few years now and it's the only tool that I've used that "just works." I
>>> couldn't be happier with it.
>>>
>>
>> Always good to hear from users...espeically when it doesn't end in "you
>> suck". :-)
>>
>> RJL
>>
>>
>>
>>> -- Jeff
>>>
>>>
>>>
>>>
>>> On Wed, Nov 18, 2009 at 7:22 AM, Robert Lipe <rob...@gp...>wrote:
>>>
>>>> Between your example and your textual description, you're mixing some
>>>> combination of two different input paths with two different output paths, so
>>>> it's really hard to say what's going on with authority.
>>>>
>>>> Generically, there has been a long running battle in three camps of
>>>> GPSBabel consumers and I've never really figured out how to please any
>>>> reasonable combination of of them with a price I'm willing to pay.
>>>>
>>>> 1) How can you not report the instantaneous speed every time you know
>>>> it?  You have time, you have position, you know how to do Haversine, but you
>>>> didn't report speed.  You suck.
>>>>
>>>> 2) I am walking and collecting GPS tracks at 1Hz.  I know that GPS has a
>>>> fantasy precision around 30 feet and I know a typical walking speed is only
>>>> about 6 feet per second but your stupid program said I walked 600 miles per
>>>> hour this second and .0004 miles per hour on the subsequent second.   You
>>>> suck.
>>>>
>>>> 3) I'm on a boat and I know that my GPS tracks says I'm moving from here
>>>> to there, but I have external sensor data that I'm using to collect Velocity
>>>> Made Good and I want that in my speed.  How dare you compute speed from the
>>>> GPS location data.  You suck.
>>>>
>>>> In particular, our writers don't know how "real" any given data is from
>>>> our reader.   We've taken criticism for recomputing speed from timestamped
>>>> position and we've been beaten up for not synthesizing it when we don't have
>>>> it.
>>>>
>>>>
>>>> If you're trying to use GPSBabel's tracking mode (not get_posn) to
>>>> synthesize NMEA (not KML) from a Garmin that doesn't support NMEA and have
>>>> strong ideas about how the NMEA should look, you're likely to be
>>>> disappointed.
>>>>
>>>> RJL
>>>>
>>>>
>>>>
>>>> On Tue, Nov 17, 2009 at 11:18 PM, Jeff McFadden <
>>>> jef...@gm...> wrote:
>>>>
>>>>> I've been using the live position update feature (-T) with good
>>>>> success. The only problem I'm having is with the velocity output. I have a
>>>>> constant 3.6kph (1 m/s) value for the velocity output, no matter what the
>>>>> output format is.
>>>>>
>>>>> The lat/lon/heading are all updating properly.
>>>>>
>>>>> I searched the archives back a ways and didn't find a mention of this.
>>>>> Is this a known issue? A known limitation?
>>>>>
>>>>> I can work around this with my own distance/time calculation, but it
>>>>> would be great to just get the data in the output.
>>>>>
>>>>> Here's the command I'm executing (Mac OSX):
>>>>> /Applications/gpsbabelfe-bin.app/Contents/MacOS/gpsbabel -T -i
>>>>> garmin,get_posn -f usb: -o kml -F -
>>>>>
>>>>> Here's some sample output:
>>>>>
>>>>> $GPRMC,050028.999,A,3441.500,N,11413.856,W,1.94,144.70,181109,,*17
>>>>> $GPGGA,050028.999,3441.500,N,11413.856,W,1,00,0.0,355.646,M,0.0,M,,*75
>>>>> $GPVTG,144.701,T,0,M,1.944,N,*3.600*,K*5A
>>>>> $GPGSA,A,3,,,,,,,,,,,,,0.0,0.0,0.0*32
>>>>> $GPRMC,050029.999,A,3340.500,N,11413.856,W,1.94,116.03,181109,,*15
>>>>> $GPGGA,050029.999,3441.500,N,11413.856,W,1,00,0.0,355.646,M,0.0,M,,*74
>>>>> $GPVTG,116.029,T,0,M,1.944,N,*3.600*,K*50
>>>>> $GPGSA,A,3,,,,,,,,,,,,,0.0,0.0,0.0*32
>>>>> $GPRMC,050030.999,A,3340.500,N,11413.856,W,1.94,103.39,181109,,*10
>>>>> $GPGGA,050030.999,3441.500,N,11413.856,W,1,00,0.0,355.646,M,0.0,M,,*7C
>>>>> $GPVTG,103.389,T,0,M,1.944,N,*3.600*,K*5D
>>>>> $GPGSA,A,3,,,,,,,,,,,,,0.0,0.0,0.0*32
>>>>>
>>>>> I'm using a Garmin eTrex Venture HC connected via USB
>>>>>
>>>>> -- Jeff
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>>> 30-Day
>>>>> trial. Simplify your report design, integration and deployment - and
>>>>> focus on
>>>>> what you do best, core application coding. Discover what's new with
>>>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>>>> _______________________________________________
>>>>> Gpsbabel-misc mailing list http://www.gpsbabel.org
>>>>> Gps...@li...
>>>>> To unsubscribe, change list options, or see archives, visit:
>>>>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>>>>
>>>>>
>>>>
>>>
>>
>