De-noise filter?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

De-noise filter?

Nicolas Boullis
Hi,

Thanks to my DG-200 datalogger and gpsbabel, I have some GPX tracks with
2-second interval between points which show a high noise, especially
when I carry the datalogger on my chest and stay still for a long time.
I thought I might implement some low-pass filtering to reduce the noise.
I gave this idea a try with a short program in Python. With a 31-tap
low-pass FIR filter, the filtering improves the data, but not as good as
I expected…

Do you think it would be worth the effort to implement such low-pass
filtering (perhaps something as simple as a moving average) in gpsbabel?
Or does anyone have an idea of a better way to de-noise GPS tracks?


Cheers,

--
Nicolas Boullis

------------------------------------------------------------------------------
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Robert Lipe-4
See http://www.gpsbabel.org/htmldoc-development/filter_simplify.html

Adam's page actually does a better job explaining how it works than we do. http://www.gpsvisualizer.com/tutorials/track_filters.html


If you have some formula that works better than either of ours, open up
https://github.com/gpsbabel/gpsbabel/blob/master/gpsbabel/smplrout.cc
and have a go.

On Sat, Aug 22, 2015 at 1:39 PM, Nicolas Boullis <[hidden email]> wrote:
Hi,

Thanks to my DG-200 datalogger and gpsbabel, I have some GPX tracks with
2-second interval between points which show a high noise, especially
when I carry the datalogger on my chest and stay still for a long time.
I thought I might implement some low-pass filtering to reduce the noise.
I gave this idea a try with a short program in Python. With a 31-tap
low-pass FIR filter, the filtering improves the data, but not as good as
I expected…

Do you think it would be worth the effort to implement such low-pass
filtering (perhaps something as simple as a moving average) in gpsbabel?
Or does anyone have an idea of a better way to de-noise GPS tracks?


Cheers,

--
Nicolas Boullis

------------------------------------------------------------------------------
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code


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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Nicolas Boullis
Hi,

On Sat, Aug 22, 2015 at 05:25:40PM -0500, Robert Lipe wrote:
> See http://www.gpsbabel.org/htmldoc-development/filter_simplify.html
>
> Adam's page actually does a better job explaining how it works than we do.
> http://www.gpsvisualizer.com/tutorials/track_filters.html
>
>
> If you have some formula that works better than either of ours, open up
> https://github.com/gpsbabel/gpsbabel/blob/master/gpsbabel/smplrout.cc
> and have a go.

Thanks for the answer.
In my track, I have a long period where I stayed still, with much noise.
The simplify filter does not really help here, because the “useful” part
of the track is over-simplified long before the break.
I also tried the position filter, but as far as I can see, it is not
efficient to de-noise the elevation, where I get the most noise
(unsurprisingly for a forest-walk).
Moreover I get a huge (436m) hole in the track, while I only requested
to remove points within 30m. As I understand it, it looks like a bug.
For what it’s worth, I attached the initial and filtered gpx
(xz-compressed), and here is the gpsbabel command I used:
  gpsbabel -i gpx -f initial.gpx -x position,distance=30m,time=3600s -o gpx -F filtered.gpx

I thought that some prior low-pass filtering might both reduce the
elevation noise and improve the efficiency of the position filter.

Ideas and comments welcome.


Cheers,

--
Nicolas Boullis

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

initial.gpx.xz (132K) Download Attachment
filtered.gpx.xz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Robert Lipe-4
The position filter isn't intended for tracks.

If the imagery in Earth is to be believed (and since the road layer and the imagery match, experience says that's wise) and you were actually biking on the trail, it looks like your GPS returned data that's just slightly wrong for many minutes at a time while you were moving.

gpsbabel -i gpx -f  ~/Downloads/initial.gpx  -x simplify,error=.017k -o gpx -F /tmp/xxx.gpx
gpsbabel -i gpx -f  ~/Downloads/initial.gpx  -x simplify,count=800 -o gpx -F /tmp/xxx.gpx

return similar results.  

Frankly, given the difference in the hiking speed in this terrain and the thousands of points that the GPS confidently recorded points 3 meters away every two seconds (which would have been about walking speed...) it's pretty hard for our filters to distinguish them and we don't do a great job on them.  It's even worse that your GPS is confidently reporting "zingers" where you traveled 1.5 to 3 meters/sec  (a brisk jog, which seems unlikely in this terrain) Since that GPS didn't report DOP data and you didn't start or stop the GPS and its noise level while you were still isn't _that_ different than your speed when you were hiking, the s/n isn't very awesome.  These filters work better for discerning stops in a bike, car, or plane.

We could apply lots of math to it, but editing out the "blobs" by hand or maybe even just inserting track breaks at those points would help a lot.





On Sun, Aug 23, 2015 at 4:57 AM, Nicolas Boullis <[hidden email]> wrote:
Hi,

On Sat, Aug 22, 2015 at 05:25:40PM -0500, Robert Lipe wrote:
> See http://www.gpsbabel.org/htmldoc-development/filter_simplify.html
>
> Adam's page actually does a better job explaining how it works than we do.
> http://www.gpsvisualizer.com/tutorials/track_filters.html
>
>
> If you have some formula that works better than either of ours, open up
> https://github.com/gpsbabel/gpsbabel/blob/master/gpsbabel/smplrout.cc
> and have a go.

Thanks for the answer.
In my track, I have a long period where I stayed still, with much noise.
The simplify filter does not really help here, because the “useful” part
of the track is over-simplified long before the break.
I also tried the position filter, but as far as I can see, it is not
efficient to de-noise the elevation, where I get the most noise
(unsurprisingly for a forest-walk).
Moreover I get a huge (436m) hole in the track, while I only requested
to remove points within 30m. As I understand it, it looks like a bug.
For what it’s worth, I attached the initial and filtered gpx
(xz-compressed), and here is the gpsbabel command I used:
  gpsbabel -i gpx -f initial.gpx -x position,distance=30m,time=3600s -o gpx -F filtered.gpx

I thought that some prior low-pass filtering might both reduce the
elevation noise and improve the efficiency of the position filter.

Ideas and comments welcome.


Cheers,

--
Nicolas Boullis

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code



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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Nicolas Boullis
Hi,

Disclaimer: I am no native speaker, sorry if I misunderstood something
or if is somtimes seem to be offensive, that’s unintended.

On Sun, Aug 23, 2015 at 03:18:57PM -0500, Robert Lipe wrote:
> The position filter isn't intended for tracks.

Hmmm? The position filter isn’t intended to “simplify” GPS tracks by
removing stops? What is it meant for, then?

Was something obviously wrong with my “-x
position,distance=30m,time=3600s” tentative filtering? Would it explain
the 436m gap I see in the filtered data?


> If the imagery in Earth is to be believed (and since the road layer and the
> imagery match, experience says that's wise) and you were actually biking on
> the trail, it looks like your GPS returned data that's just slightly wrong
> for many minutes at a time while you were moving.

Did you mean “hiking” instead of “biking”?


> gpsbabel -i gpx -f  ~/Downloads/initial.gpx  -x simplify,error=.017k -o gpx
> -F /tmp/xxx.gpx
> gpsbabel -i gpx -f  ~/Downloads/initial.gpx  -x simplify,count=800 -o gpx
> -F /tmp/xxx.gpx
>
> return similar results.
>
> Frankly, given the difference in the hiking speed in this terrain and the
> thousands of points that the GPS confidently recorded points 3 meters away
> every two seconds (which would have been about walking speed...) it's
> pretty hard for our filters to distinguish them and we don't do a great job
> on them.  It's even worse that your GPS is confidently reporting "zingers"
> where you traveled 1.5 to 3 meters/sec  (a brisk jog, which seems unlikely
> in this terrain)

Sorry, but I have no idea what “zingers” or “brisk jog” mean.
Anyway, I was hiking with kids (2 of them being 4 years old), so I
certainly never walked anything near 3 meters/sec.
As I understand it, my GPS units synthetises the speeds and headings by
comparing succesive points. (I was told that some GPS units used the
doppler effect to compute the speed and heading; it looks like this is
not true for mine.) Then, with high noise, I am not that surprised to
read such speeds. Synthetising the speed over longer periods would
certainly show more realistic results.


> Since that GPS didn't report DOP data and you didn't start
> or stop the GPS and its noise level while you were still isn't _that_
> different than your speed when you were hiking, the s/n isn't very
> awesome.  These filters work better for discerning stops in a bike, car, or
> plane.

I agree with you that it would be nice if the DOP data could be logged.
The logging condition certainly was awful, which probably explains the
high noise level (forest + antenna close to my body).

I once thought that short interval between points would make it possible
to improve the data with low-pass filtering, because I expected the
noise to be white noise. But now, it seems to me that I was plain
wrong since there is very little “high” frequency noise (read < 0.1Hz)
and much low frequency noise…


> We could apply lots of math to it, but editing out the "blobs" by hand or
> maybe even just inserting track breaks at those points would help a lot.

I could certainly edit out the “blobs” when we stopped, but how would
that help? I can imagine that it would help the “simplify” filter, but
anything else?


Cheers,

--
Nicolas Boullis

------------------------------------------------------------------------------
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Robert Lipe-4


On Sun, Aug 23, 2015 at 5:33 PM, Nicolas Boullis <[hidden email]> wrote:
Hi,

Disclaimer: I am no native speaker, sorry if I misunderstood something
or if is somtimes seem to be offensive, that’s unintended.

That's OK. Your English is better than my non-existent French (?).  I'll just be more careful about uncommon terms.
 
On Sun, Aug 23, 2015 at 03:18:57PM -0500, Robert Lipe wrote:
> The position filter isn't intended for tracks.

Hmmm? The position filter isn’t intended to “simplify” GPS tracks by
removing stops? What is it meant for, then?

You're right.  That page does need clarification and what I thought it did, what the doc says it does, and what the code actually does don't really match.
 
Was something obviously wrong with my “-x
position,distance=30m,time=3600s” tentative filtering? Would it explain
the 436m gap I see in the filtered data?

You want the simplify filter, not the position filter.   


 


> If the imagery in Earth is to be believed (and since the road layer and the
> imagery match, experience says that's wise) and you were actually biking on
> the trail, it looks like your GPS returned data that's just slightly wrong
> for many minutes at a time while you were moving.

Did you mean “hiking” instead of “biking”?

Yes.  From your speed, you were clearly walking.  Unfortunate typo.
 

> Frankly, given the difference in the hiking speed in this terrain and the
> thousands of points that the GPS confidently recorded points 3 meters away
> every two seconds (which would have been about walking speed...) it's
> pretty hard for our filters to distinguish them and we don't do a great job
> on them.  It's even worse that your GPS is confidently reporting "zingers"
> where you traveled 1.5 to 3 meters/sec  (a brisk jog, which seems unlikely
> in this terrain)

Sorry, but I have no idea what “zingers” or “brisk jog” mean.

A "zinger" in GPS parlance is when a point is recorded that's pretty clearly errant.  For example, if I'm recording a walking track and have one track point here and the next track point is in Switzerland and the following track point is 2m from where I started, that middle point is a zinger.  GPSes that record such points but that don't filter points or provide reliability data are not good...but very common in the logger space.  Yours doesn't do large zingers; it looks like it's doing some kind of weighted averaging and drifting.





A brisk (quick) jog might also be called a slow run.  I was trying to express something faster than even a fast walk in that terrain.
 
Anyway, I was hiking with kids (2 of them being 4 years old), so I
certainly never walked anything near 3 meters/sec.

It looked like a challenging hike on its own.  Doing it with kids that age is heroic. :-)

 
As I understand it, my GPS units synthetises the speeds and headings by
comparing succesive points. (I was told that some GPS units used the

That's a very common thing to do.  I was using speed as a metric because it's in your source file and is easier to machine process than doing the great circle math to compute actual distances.   For example, if you 
$ grep speed ~/Downloads/initial.gpx  | sort | uniq -c
you'll see there are a fair number of outlying points that are not typical walking speeds.

You'll also find that the unit isn't reporting fractional seconds or doing a very good job of keeping to the "every two seconds" goal.

  <time>2015-08-07T16:01:53Z</time>
  <time>2015-08-07T16:01:54Z</time>
  <time>2015-08-07T16:01:57Z</time>
  <time>2015-08-07T16:01:59Z</time>
  <time>2015-08-07T16:02:00Z</time>

 
doppler effect to compute the speed and heading; it looks like this is
not true for mine.) Then, with high noise, I am not that surprised to
read such speeds. Synthetising the speed over longer periods would
certainly show more realistic results.

Certainly.  This is why lots of GPSes have options to drop points every N units of distance instead of every T units of time.


 
I agree with you that it would be nice if the DOP data could be logged.

I looked in our DG-[12]00 reader and if DOP is logged by the devices at all, we don't know how to read it.

 
I once thought that short interval between points would make it possible
to improve the data with low-pass filtering, because I expected the
noise to be white noise. But now, it seems to me that I was plain
wrong since there is very little “high” frequency noise (read < 0.1Hz)
and much low frequency noise…

I'm afraid so.   For many of these points, the "jitter" is more significant than the actual motion.  You can see this to the east of Grenoble, for example.


The position filter makes a bit of a mess of this track because it's *almost* loops back onto itself, allowing it to coalesce points from the inbound and outbound hikes together - except where you took different paths around Reserve Naturelle du Lac Luitel which leaves it with strange lobes that it can't reconnect.  You can see this by contrasting

gpsbabel -i gpx -f  ~/Downloads/initial.gpx  -x  position,distance=137m,time=360000s -o gpx -F /tmp/xxx.gpx && open -a Google\ Earth /tmp/xxx.gpx

and repeating it with 138m instead of 137 - getting rid of that one wayward point gives us something we have to loop back to connect.   That's a more extreme case of your provided example.  30m and 3600s gives a "hole" because we're able to collapse into one path on the way in, but not the way out.  If you turn on trackpoints, you can see that here:





 


> We could apply lots of math to it, but editing out the "blobs" by hand or
> maybe even just inserting track breaks at those points would help a lot.

I could certainly edit out the “blobs” when we stopped, but how would
that help? I can imagine that it would help the “simplify” filter, but
anything else?

 Yes, the simplify filter was the goal.   It knows better how to deal with tracks and keeps a sense of order in the points.

RJL

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Nicolas Boullis
Hi,

On Sun, Aug 23, 2015 at 07:30:58PM -0500, Robert Lipe wrote:
>
> That's OK. Your English is better than my non-existent French (?).  I'll
> just be more careful about uncommon terms.

Thanks for your effort. And you guessed correctly, I am french.


> You're right.  That page does need clarification and what I thought it did,
> what the doc says it does, and what the code actually does don't really
> match.

I finally read the source code again, and now I understand why it does
not behave as I thought it would.

For what it’s worth, I hacked the position filter to make it behave as I
thought it would. My quick & dirty patch (for gpsbabel 1.4.3) is
attached. Please tell me if you would be interested by a cleaner patch
(probably with an option, not to change the default behavior) for git
head.


> A "zinger" in GPS parlance is when a point is recorded that's pretty
> clearly errant.  For example, if I'm recording a walking track and have one
> track point here and the next track point is in Switzerland and the
> following track point is 2m from where I started, that middle point is a
> zinger.  GPSes that record such points but that don't filter points or
> provide reliability data are not good...but very common in the logger
> space.  Yours doesn't do large zingers; it looks like it's doing some kind
> of weighted averaging and drifting.

Thanks for explaining the word “zinger”.
Just curious, do such extreme “zingers” really happen?
I am not sure, but I would have thought that my GPS unit (and most of
them) would use some Kalman-like filtering to merge the data from many
satellites, and that the offset drifts whenever a new satellite is
considered.

BTW, I thing it would be nice if it was possible to log the raw
low-level per-satellite data, because I think it would make it possible
to do a great post-processing job. (GPS modules may be doing a great job
already, but they are somewhat restricted by their need to do real-time
processing; using also future data might help a lot.) But I don’t know
any GPS module that provides such low-level data (not to say any GPS
datalogger that logs it)… :-(


> A brisk (quick) jog might also be called a slow run.  I was trying to
> express something faster than even a fast walk in that terrain.

Ok, thanks for the explanation.


> > Anyway, I was hiking with kids (2 of them being 4 years old), so I
> > certainly never walked anything near 3 meters/sec.
> >
>
> It looked like a challenging hike on its own.  Doing it with kids that age
> is heroic. :-)

Do you mean the “real” hike or the hypothetic one with 3 meters/sec
speed?
The real hike was not that challenging, even for 4-year-old kids.


> That's a very common thing to do.  I was using speed as a metric because
> it's in your source file and is easier to machine process than doing the
> great circle math to compute actual distances.   For example, if you
> $ grep speed ~/Downloads/initial.gpx  | sort | uniq -c
> you'll see there are a fair number of outlying points that are not typical
> walking speeds.

Yes, I saw that as well (altough with different commands).


> You'll also find that the unit isn't reporting fractional seconds or doing
> a very good job of keeping to the "every two seconds" goal.
>
>   <time>2015-08-07T16:01:53Z</time>
>   <time>2015-08-07T16:01:54Z</time>
>   <time>2015-08-07T16:01:57Z</time>
>   <time>2015-08-07T16:01:59Z</time>
>   <time>2015-08-07T16:02:00Z</time>

Yes, the logged timestamps are clearly rounded to a 1-second resolution.
That datalogger may be used as a real-time GPS unit and event then it
provides NMEA sentences where timestamps have a 1-second resolution… :-(

However, the high speed do not seem to be related with 1-second
intervals.


> Certainly.  This is why lots of GPSes have options to drop points every N
> units of distance instead of every T units of time.

The DG-200 has this option, but as I understand it, it is not different
from what I get with my patched position filter.


> I looked in our DG-[12]00 reader and if DOP is logged by the devices at
> all, we don't know how to read it.

It does not show up in the specification I got from GlobalSat.


Cheers,

--
Nicolas Boullis

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

gpsbabel_position_filter.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Robert Lipe-4


On Tue, Aug 25, 2015 at 6:54 AM, Nicolas Boullis <[hidden email]> wrote:
Hi,

On Sun, Aug 23, 2015 at 07:30:58PM -0500, Robert Lipe wrote:
>
> That's OK. Your English is better than my non-existent French (?).  I'll
> just be more careful about uncommon terms.

Thanks for your effort. And you guessed correctly, I am french.

Swiss-French was my second guess, but I understand how tricky those nuances can be.
 
For what it’s worth, I hacked the position filter to make it behave as I
thought it would. My quick & dirty patch (for gpsbabel 1.4.3) is
attached. Please tell me if you would be interested by a cleaner patch
(probably with an option, not to change the default behavior) for git
head.

This idea has merit.  Without patching it in, I'm guessing this solves the problem when the track loops back onto itself (return route) and we start merging the two directions together.  We do have to handle the case of not having times in tracks (it's stupid) and it's OK to just make that a Fatal().

In development head, your waypoint_time_compare looks more like trackfilter_merge_qsort_qb() from trackfilter.cc (enough so that perhaps it goes into util.cc and shared) and it needs a paragraph of doc and to be wrapped in a switch, but I could go for that.

Just curious, do such extreme “zingers” really happen?

Yes.  Invariably its when they actually lose fix but don't tell you they lose fix, they just record nonsense.
 
I am not sure, but I would have thought that my GPS unit (and most of
them) would use some Kalman-like filtering to merge the data from many
satellites, and that the offset drifts whenever a new satellite is
considered.

Most of the ones that front-end the raw correlators with Real Processors do exactly that.  In a $200 handheld with a nice powerful ARM core, that kind of processing is common.  The $40 data loggers (which probably means a $8 bill of materials cost) that are pretty much plucking data from MTK or Sirf or whatever and jamming it into flash rarely do.  Interestingly, that very post-processing gets the "real" GPS guys in trouble sometimes as it's the cause of things like Magellan's famed "overshoot" problem in their older models because it bases your next location based on your past location and motion so when navigating to a point, it'll take you past the point and then loop you back.  

Implementing a Kalman filter in GPSBabel has been on my back burner for a long time.
 
BTW, I thing it would be nice if it was possible to log the raw
low-level per-satellite data, because I think it would make it possible
to do a great post-processing job. (GPS modules may be doing a great job
already, but they are somewhat restricted by their need to do real-time
processing; using also future data might help a lot.) But I don’t know
any GPS module that provides such low-level data (not to say any GPS
datalogger that logs it)… :-(

Most of the chipsets provide the equivalent of the GPGSV data giving your the number of SV's in view, their elevation and azimuth, and relative SNR and the GPGSA to get the [PHV]DOP. Few consumer units expose that data in a useful way in their tracks.

There was one logger in my testing (I think it was the AMOD 3080 but it's been a long time...) that provided it and I remember finding it interesting when I was studying spikes in the DOP data that it was actually able to detect driving under an overpass at interstate speed.  (~110Km/h)


If this really is an interesting field for you, there has never been a better time to be an experimenter in this field.  Places like Sparkfun and Adafruit make available the bare GPS module that are pretty easy to interface to a device of your choosing for you to program and record as you like.  (This is also why the low end of the logger market is such a mess - take these chips, add a battery, flash memory, and some plastic and you have that aforementioned $40 data logger...and if you can make it a buck cheaper than the company down the street, you'll sell thousands.)
 

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

_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: De-noise filter?

Ron Parker-2
In reply to this post by Nicolas Boullis
On 8/25/2015 7:54 AM, Nicolas Boullis wrote:
>  BTW, I thing it would be nice if it was possible to log the raw
> low-level per-satellite data, because I think it would make it
> possible to do a great post-processing job. (GPS modules may be doing
> a great job already, but they are somewhat restricted by their need to
> do real-time processing; using also future data might help a lot.) But
> I don’t know any GPS module that provides such low-level data (not to
> say any GPS datalogger that logs it)… :-(

Way, way back in the 20th century, there did exist GPS loggers that
logged pseudorange data rather than computed fixes. That was necessary
because Selective Availability was still a thing at the time, so your
options for eliminating the induced errors were either realtime
differential GPS (which would have required some sort of radio network)
or postprocessing with a second pseudorange log taken at a known, fixed
location.

I don't know if any of those receivers are still sold. I doubt it, as
their specs were significantly worse than even the cheapest GPS module
of today.


------------------------------------------------------------------------------
_______________________________________________
Gpsbabel-code mailing list  http://www.gpsbabel.org
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code