Upload to GPS Problems with 3.3.1606

[fgd3]

I'm running OpenCPN 3.3.1606 with Ubuntu Linux 12.04, Windows Vista, and Windows 8.1. When I upload routes to my Garmin GPS 72 all the waypoints have an elevation of 98422 feet.

The GPX files are badly formatted on Windows although they look OK on Linux (the venerable CR-LF problem, I suppose). Version 3.2.2 (and earlier) produced GPX files that looked good on Windows.

I didn't find any instances of the <ele></ele> element (elevation) in the GPX files created by OpenCPN. Where it was present in files created by another program OpenCPN threw it away. Shouldn't OpenCPN preserve elevation data if it is present?

I transferred the same GPX files to the Garmin using EasyGPS and the elevation field was filled with dashes. I don't know what OpenCPN is doing different. Could someone take a look at it?

Fabbian

[nohal]

Fabbian...
Could you post some example GPX files, please? To be honest I got a bit lost in the description.

Thanks

Pavel

[fgd3]

Originally Posted by nohal

Fabbian...
Could you post some example GPX files, please? To be honest I got a bit lost in the description.

Thanks

Pavel

Sure. Here are a couple of short ones. The problem with the files is they don't start new lines so they are hard to read and edit by hand. The more important problem is the 98422-foot elevation that OpenCPN sends to the GPS. Since the elevation isn't in the GPX file I don't think they will shed much light on that issue. Let me know if you want to look at more (or longer) files.

Fabbian

[nohal]

Fabbian...
Still lost... Both the files you posted are perfectly valid and not even on a single line.
http://www.topografix.com/GPX/1/1/gpx.xsd says clearly that the elevation element is optional and does not have to be part of the GPX file. Every decent application I have seen handles this case as if elevation was 0 in case it is relevant for it (it is not for OpenCPN)

I suppose that in the rest of your post you talk about the Garmin route upload over serial/SSB (nothing to do with GPX), right?

From a brief look at the code, it looks like we are sending a very high number, originating from garmin/jeeps/gpsmem.c:273 which the GPS then treats as (it's most likely maximum value of) 29999 meters (=98422 ft).
I don't have any Garmin unit to test this, but the following one line patch should solve it

diff --git a/src/garmin/jeeps/garmin_wrapper.cpp b/src/garmin/jeeps/garmin_wrapper.cpp
index 4f4e587..ccc41e2 100644
--- a/src/garmin/jeeps/garmin_wrapper.cpp
+++ b/src/garmin/jeeps/garmin_wrapper.cpp
@@ -123,6 +123,7 @@ int Garmin_GPS_SendWaypoints( wxString &port_name, RoutePointList *wplist)
 
             pway->lat = prp->m_lat;
             pway->lon = prp->m_lon;
+            pway->alt = 0.0;
             strncpy(pway->ident, (prp->GetName().Truncate ( 6 )).mb_str(), 6);
 
       }

BTW, anybody knows what the alt_is_unknown property value should be when it's true?

Pavel

[fgd3]

Originally Posted by nohal

Fabbian...
Still lost...

No, I think you've got it figured out pretty well. Sorry I wasn't more clear in my description of the problem. Thanks for looking into it so quickly.

I don't know how to compile OpenCPN from source but it looks like the change you made will plug zero into the elevation field. I like that, as I normally use OpenCPN at sea level. By my calculation, 98422 feet is 30283.6923 meters (98422 * 12 / 39) but we're just guessing what Garmin does with an arbitrarily large number in that field. It would be nice if we knew what would cause the Garmin to recognize the elevation is unspecified but Garmin doesn't make that information easy to find. If I come across the answer I'll shoot it to you.

In the meantime, is there any way you can send me a 32-bit Windows binary with your change so I can confirm that it works? If not I'll just wait until it appears in the next beta.

The issue I have with the formatting of the files (which began following 3.2.2) will only show up on a Windows machine--maybe only if you open the file with Notepad. I've attached a screen shot showing an old (pre 3.2.2) track file and a current route file (3.3.1606), both opened with Notepad. Both files will be parsed correctly but DOCK-BIGB1.gpx is hard for humans to read. The image on the left (2011-07-03.gpx) is nicely formatted with indents showing the hierarchy of elements. I don't know what changed after 3.2.2 but the fact that DOCK-BIGB1.gpx is formatted nicely on my Linux machine leads me to believe that after 3.2.2 the files written by the Windows versions weren't given the special treatment that Windows requires for line termination. Years back, if I remember right, Unix lines ended with a Line Feed (0xA), Mac lines ended with a Carriage Return (0xD), and Windows used a CR-LF pair (0xD, 0xA). Since the Mac OS is now based on Unix maybe their special case went away, but Windows still requires both codes as far as I know.

Fabbian

[nohal]

Fabbian...
I would say "Get a normal editor" XML Copy Editor is quite fine for editing GPX files, but pretty much anything that is not Notepad will do.
Please try the package from https://drive.google.com/file/d/0B3X...it?usp=sharing and let me know if the elevation problem is fixed so I can commit it to the master if it works...

Pavel

[fgd3]

Originally Posted by nohal

Fabbian...
I would say "Get a normal editor" XML Copy Editor is quite fine for editing GPX files, but pretty much anything that is not Notepad will do.
Please try the package from https://drive.google.com/file/d/0B3X...it?usp=sharing and let me know if the elevation problem is fixed so I can commit it to the master if it works...

Pavel

To my surprise, that did not fix the elevation problem. It looked so simple I was sure it would.

Fabbian

[nohal]

Well, nothing's as simple as it looks... Please try with https://drive.google.com/file/d/0B3X...it?usp=sharing - there are two other code paths that possibly create the waypoints to be sent to Garmin GPS.

Thanks

Pavel

[fgd3]

Originally Posted by nohal

Well, nothing's as simple as it looks... Please try with https://drive.google.com/file/d/0B3X...it?usp=sharing - there are two other code paths that possibly create the waypoints to be sent to Garmin GPS.

Thanks

Pavel

That seems to have done it. I had expected to see a 0 in the elevation field but it was filled with dashes, the Garmin's indicator for an empty field. I think you can mark that item done. Thanks.

Fabbian

[nohal]

Originally Posted by fgd3

That seems to have done it. I had expected to see a 0 in the elevation field but it was filled with dashes, the Garmin's indicator for an empty field. I think you can mark that item done. Thanks.

Fabbian

Yes, the empty value is OK - I'm also setting the "altitude unknown" parameter, which seems more appropriate than just hardcoding the zero there.

Many thanks for testing

Pavel

[fgd3]

Originally Posted by nohal

Yes, the empty value is OK - I'm also setting the "altitude unknown" parameter, which seems more appropriate than just hardcoding the zero there.

Many thanks for testing

Pavel

You might want to set depth to unknown instead of zero at the same time. If you want me to test that for you just let me know.

Fabbian

[nohal]

You have already tested that (https://github.com/OpenCPN/OpenCPN/c...802b5a0fd1e2e3) , we now set the value to zero and say it's unknown at the same time. That should cover all the cases.

Pavel

[fgd3]

Originally Posted by nohal

You have already tested that (https://github.com/OpenCPN/OpenCPN/c...802b5a0fd1e2e3) , we now set the value to zero and say it's unknown at the same time. That should cover all the cases.

Pavel

In the last version I tested (Version 3.3.1715 Build 2014-05-15), the elevation field is filled with dashes (unspecified) while depth is filled with 0.0, not the same as indicating it is unspecified. I wasn't paying attention to the depth figure earlier since it was always set to 0.0.

I need to test with a GPS 12 as well, since I have one, to be sure it works with both models. I'll get back to you shortly.

Fabbian

[fgd3]

The GPS 12 does not have fields for waypoint elevation or depth but the transfer works fine. The waypoint fields the GPS 12 has are correctly filled and routes are transferred properly.

Fabbian