OpenCPN Release Candidate Version 3.1.1405 Released

[bdbcat]

Ahoy, OpenCPN'ers...

OpenCPN Version 3.1 Release Candidate 1405 will soon be available for download from opencpn.org.

Monitor the opencpn.org Downloads page to find and download the latest Beta version binaries.....

Source is available now on github at:
https://github.com/OpenCPN/OpenCPN
Branch: beta31_stable




Changelog

183. Update some translatable strings
184. Improve Dashboard graphics for linux systems
185. Correct Route/Waypoint upload timing logic.
186. Implement NMEA0183 APB sentence for autopilot output.
187. Improve performance of "Export all visible" objects.
188. Deactivate some controls ("Delete All") on multiobject selection in RMD
189. Add Garmin Host Mode status to auto-upgrade of connections parameters.
190. Dashboard depth: Use DPT rather than DBT for depth ; add transducer offset to depth value if available.
191. Remove update of magnetic heading and variation on processing of AIVDO messages.
192. Improve Garmin serial port usability.
193. Add Progress bars to some potentially long GPX and track operations.
194. Correct update of Satellites in View instrument.
195. Documentation update. Thanks, Thomas (cagney)

Release 3.1.1405

Notes:

I have no known critical bugs or omissions in this Release Candidate. Nothing that would prevent a comfortable Release. Please remind me if I have missed anything.

Please test heavily, check your Flyspray tasks, and let me know if any previous thread comments/bugs were accidentally overlooked.

Thanks
Dave

[Gilletarom]

Hello Thomas,
I will be away from home for a few days, maybe two weeks. I'm going to maintain my boat. I have not finished making gpx file pours layers but I'll finish it as soon as possible.
B.R. Gilletarom

[NEVERMIND]

Hi,
Vhere is the link to download the new version?
Thanks.
JP

[SethDart]

Originally Posted by bdbcat

OpenCPN Version 3.1 Release Candidate 1405 will soon be available for download from opencpn.org.

Monitor the opencpn.org Downloads page to find and download the latest Beta version binaries.....

Please be patient. Builders may be sleeping, or working, whatever.
I uploaded rpms for Fedora a few hours ago, I'm sure others will follow very soon... stay tuned!

[nohal]

Slept well, thanks
The Windows build is available for download now and the Launchpad packages are baking - the i386 builds are mostly ready now, but amd64 will take a few hours to make it to the front of the build queue.

Happy testing

Pavel

[sailorF54]

O crashes when closing (W7)
Here is the log
Will try to investigate...

ADDED 1: no crash when removing all plugins except dashboard and grib

ADDED 2: GE2KAP (at least) is to blame
I keep testing...

ADDED3 : the following plugins are OK (see pic)
Checked: all activated

ADDED4: disabling GE2KAP: no crash

ADDED5: a second crash log: all plugins (see list above) activated, including G2KAP

Over and out (I know it's not correct ;-) )

[rooiedirk]

Re 184
Something weird in the windhistory.
Background is drawn, and the scale figures are updated, but no foreground drawings visible.
Dirk

[sbfreddie]

Dave:
Freddie here, your Mac nightmare. I just tried to build O 3.1.1405 on Mac Sys 10.7.5 with 64bit build and wxwidgets 2.9.4 here is the build command:

cmake -DCMAKE_OSX_64=ON -DPREFIX=/Users/freddie/Desktop/OpenCPN3.1.1405/buildmac -DGETTEXT_MSGFMT_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt -DGETTEXT_MSGMERGE_EXECUTABLE=/usr/local/Cellar/gettext/0.18.1.1/bin/msgmerge -DCMAKE_C_COMPILER=/usr/bin/gcc -DCMAKE_CXX_COMPILER=/usr/bin/g++ ..
make

I get errors in compiling O, specifically routeprintout.cpp. Here are the errors:

Scanning dependencies of target OpenCPN
[ 45%] Building CXX object CMakeFiles/OpenCPN.dir/src/chart1.cpp.o
[ 45%] Building CXX object CMakeFiles/OpenCPN.dir/src/bbox.cpp.o
[ 45%] Building CXX object CMakeFiles/OpenCPN.dir/src/ocpn_pixel.cpp.o
[ 46%] Building CXX object CMakeFiles/OpenCPN.dir/src/ocpndc.cpp.o
[ 46%] Building CXX object CMakeFiles/OpenCPN.dir/src/chartdb.cpp.o
[ 46%] Building CXX object CMakeFiles/OpenCPN.dir/src/chartdbs.cpp.o
[ 48%] Building CXX object CMakeFiles/OpenCPN.dir/src/chartimg.cpp.o
[ 48%] Building CXX object CMakeFiles/OpenCPN.dir/src/chcanv.cpp.o
[ 48%] Building CXX object CMakeFiles/OpenCPN.dir/src/concanv.cpp.o
[ 49%] Building C object CMakeFiles/OpenCPN.dir/src/cutil.c.o
[ 49%] Building C object CMakeFiles/OpenCPN.dir/src/georef.c.o
[ 49%] Building CXX object CMakeFiles/OpenCPN.dir/src/navutil.cpp.o
[ 50%] Building CXX object CMakeFiles/OpenCPN.dir/src/routeman.cpp.o
[ 50%] Building CXX object CMakeFiles/OpenCPN.dir/src/routemanagerdialog.cpp.o
[ 50%] Building CXX object CMakeFiles/OpenCPN.dir/src/routeprop.cpp.o
[ 51%] Building CXX object CMakeFiles/OpenCPN.dir/src/routeprintout.cpp.o
/Users/freddie/Desktop/OpenCPN3.1.1405/src/routeprintout.cpp: In constructor ‘MyRoutePrintout::MyRoutePrintout(std::vector<bool, std::allocator<bool> >, Route*, const wxChar*)’:
/Users/freddie/Desktop/OpenCPN3.1.1405/src/routeprintout.cpp:104: error: invalid cast from type ‘const wxString’ to type ‘char*’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/routeprintout.cpp:107: error: invalid cast from type ‘const wxString’ to type ‘char*’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/routeprintout.cpp:110: error: invalid cast from type ‘const wxString’ to type ‘char*’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/routeprintout.cpp:113: error: invalid cast from type ‘const wxString’ to type ‘char*’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/routeprintout.cpp:116: error: invalid cast from type ‘const wxString’ to type ‘char*’
make[2]: *** [CMakeFiles/OpenCPN.dir/src/routeprintout.cpp.o] Error 1
make[1]: *** [CMakeFiles/OpenCPN.dir/all] Error 2
make: *** [all] Error 2

Any idea what to do next?

Thanks,
Freddie

[bdbcat]

sbfreddie....
Life would not be complete without Mac nightmares...

Some compilers are picky.

As a quick test before I commit changes to github, please try the following:
routeprintout.cpp, line 104

currently:

        table << (char *)::wxGetTranslation ((const wxChar *)"Name");

Please change to:

         table << (const char *)wxString(_("Name")).mb_str();

This should fix the error on that line (104). If it does, you may make similar changes to the other 4 trouble lines nearby. Let me know the result, and I'll commit the fix to github master.

Other source builders may like to check this as well....

Thanks
Dave

[sbfreddie]

Originally Posted by bdbcat

sbfreddie....
Life would not be complete without Mac nightmares...

Some compilers are picky.

As a quick test before I commit changes to github, please try the following:
routeprintout.cpp, line 104

currently:

        table << (char *)::wxGetTranslation ((const wxChar *)"Name");

Please change to:

         table << (const char *)wxString(_("Name")).mb_str();

This should fix the error on that line (104). If it does, you may make similar changes to the other 4 trouble lines nearby. Let me know the result, and I'll commit the fix to github master.

Other source builders may like to check this as well....

Thanks
Dave

Dave:
With the exception of these warnings in tcmgr.cpp:

Scanning dependencies of target OpenCPN
[ 45%] Building CXX object CMakeFiles/OpenCPN.dir/src/chart1.cpp.o
[ 45%] Building CXX object CMakeFiles/OpenCPN.dir/src/bbox.cpp.o
[ 45%] Building CXX object CMakeFiles/OpenCPN.dir/src/ocpn_pixel.cpp.o
[ 46%] Building CXX object CMakeFiles/OpenCPN.dir/src/ocpndc.cpp.o
[ 46%] Building CXX object CMakeFiles/OpenCPN.dir/src/chartdb.cpp.o
[ 46%] Building CXX object CMakeFiles/OpenCPN.dir/src/chartdbs.cpp.o
[ 48%] Building CXX object CMakeFiles/OpenCPN.dir/src/chartimg.cpp.o
[ 48%] Building CXX object CMakeFiles/OpenCPN.dir/src/chcanv.cpp.o
[ 48%] Building CXX object CMakeFiles/OpenCPN.dir/src/concanv.cpp.o
[ 49%] Building C object CMakeFiles/OpenCPN.dir/src/cutil.c.o
[ 49%] Building C object CMakeFiles/OpenCPN.dir/src/georef.c.o
[ 49%] Building CXX object CMakeFiles/OpenCPN.dir/src/navutil.cpp.o
[ 50%] Building CXX object CMakeFiles/OpenCPN.dir/src/routeman.cpp.o
[ 50%] Building CXX object CMakeFiles/OpenCPN.dir/src/routemanagerdialog.cpp.o
[ 50%] Building CXX object CMakeFiles/OpenCPN.dir/src/routeprop.cpp.o
[ 51%] Building CXX object CMakeFiles/OpenCPN.dir/src/routeprintout.cpp.o
[ 51%] Building CXX object CMakeFiles/OpenCPN.dir/src/printtable.cpp.o
[ 51%] Building CXX object CMakeFiles/OpenCPN.dir/src/statwin.cpp.o
[ 53%] Building CXX object CMakeFiles/OpenCPN.dir/src/tcmgr.cpp.o
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp: In function ‘void chk_fread(void*, size_t, size_t, FILE*)’:
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2686: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2686: warning: format ‘%u’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2686: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2686: warning: format ‘%u’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp: In function ‘void chk_fwrite(const void*, size_t, size_t, FILE*)’:
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2697: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2697: warning: format ‘%u’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2697: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:2697: warning: format ‘%u’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp: In function ‘void boundscheck_monologue(const char*)’:
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:3474: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:3474: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp: In function ‘void boundscheck_oneliner(const char*)’:
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:3491: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
/Users/freddie/Desktop/OpenCPN3.1.1405/src/tcmgr.cpp:3491: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’
[ 53%] Building CXX object CMakeFile

This is now a completely clean compile. Now on with the rest of the show.

Thanks,
Freddie

[sbfreddie]

Dave or anybody:
Can you point me to the right source that paints these windows from the options window?

Its seems that none of the text in the body of the window is showing.

Where do I start to look?

Thanks,
Freddie

[reflectionsv37]

Hi Dave!

The good news is we survived the tsunami and I was able to make the upload work. But there are many issues that need to be resolved. I'll try and be as detailed as possible.

Waypoint Names

Waypoint names in the Furuno can be a maximum of 6 characters and can contain uppercase letters and digits. I was only able to successfully upload a route if all waypoint names were 6 digits. For testing purposes, I named them TST001, TST002... I tried lowercase letters and they did come across, but showed up as special characters rather than lowercase letters.

I know the Maxsea program could upload waypoint names that were less than 6 characters in length. I changed on of the waypoint names to TST1 with 2 following spaces(OpenCPN let me do this) and tried the upload again and it was successful. In reviewing the NEMA stream, the trailing paces were passed along in both PFEC and GPRTE sentences. Appending trailing spaces to waypoint names that are less that 6 characters would solve this problem.

I also wondered what would happen if a waypoint name contained more than 6 characters. I setup a route that contained waypoints named TST018 and TST018A. Much to my surprise the upload was successful! But when I went to check the waypoints in the GPS to see what was uploaded, there was only a waypoint for TST018. This waypoint contained the lat/long from waypoint TST018A. It appears that the Furuno completely ignored the 7th character and simply overlaid the lat/long with the data from TST018A. I checked the route and it showed TST018 twice. But the upload still worked!!

GPRTE Sentences(Route upload sentences)

There are a number of issues with these sentences.

There is a difference in the way these sentences are being created depending on whether the route has been given a name or if it is an "Unnamed Route". I was not able to successfully upload an unnamed route. It appears that the route number in Segment 4 of the GPRTE sentence is "0" or "1" for unnamed routes and "01" for named routes. My manual, dated June of 1998, indicates that this segment must be a number from 01 to 30 and that 2 digits are required. Since Furuno GPS's clear all existing routes and waypoints in the GPS when an upload takes place, this could simply be hardcoded to have a value of "01".

When uploading a named route with more than 6 waypoints, the waypoints are report in groups of 5 in each sentence. If a route has 7 waypoints, the first GPRTE sentence contains the first 5 waypoints and the second sentence contains the remaining 2. When a route contains 6 or less, all the waypoints are sent in a single GPRTE sentence. This behavior is different when working with an (Unnamed Route). With an unnamed route the waypoints are grouped 6 per sentence. I don't believe that this should be a problem as my documentation indicates that 8 waypoints can be reported in each GPRTE sentence and as my testing showed, 6 waypoints can successfully be uploaded in a single sentence when the route only contains 6 waypoints. I suspect this is a problem with the route number as described above, but I am not certain about this.

Another issue occurs with named routes that contain 11, 16 or 21 waypoints. With a route with 16 waypoints, we would expect that 4 GPRTE sentences would be created. The first 3 would contain 5 waypoints and the 4th would contain the last waypoint. There is a counting error in the program. Segment 1 of the GPRTE sentence represents the number of sentences that will be sent to to complete the entire route. In this example, Segment 4 had the correct value of 4, but only 3 sentences were transmitted. The 4th sentence that contained the final waypoint was not created and so the upload fails in these case. It works fine if there are 12, but not when there is only 1 waypoint to report in the final sentence.

If there are more than 20 waypoints in a route, the program attempts to create 5 sentences to report all waypoints. Since the Furuno limits this to 4 sentences, the update fails for routes with more than 20 waypoints.

Suggestions

Since the Furuno GPS has the little quirk of erasing all waypoint and route data when you perform an upload, it might be a good idea to include a warning box when you first check the box in the Toolbox>connections screen indicating you want to "uploads in Furuno GP3X". Most Furuno users are aware of this but it may save you from a few nasty emails from the guy who just spent the last 2 weeks manually entering waypoints into his GPS. I also think this option should apply to an individual COM port rather than globally. I'd like to connect a Garmin handheld GPS to another COM port and have the option of uploading a route to either GPS.

Waypoint names are a problem with the Furuno. Padding names shorter than 6 characters would solve that particular problem but still leaves a potentially dangerous situation as I described about with waypoints named TST018 and TST018A. I don't think you would want to limit the waypoint names to just 6 characters in OpenCPN. Many, many years ago I used the program The Cap'n as my navigation program. Uploads to the Furuno GPS using that program were simply named CAP001, CAP002... I think that would be an acceptable way to name the waypoints in OpenCPN. They may not match the names in OpenCPN, but it is still much better than risking the situation where a duplicate name may cause a waypoint to omitted from an upload.

Since the Furuno allows for up to 30 waypoints in a single route, it would be nice if we can try to put 8 waypoints in each GPRTE sentence. If we use the current 5 waypoints per sentence we will be limiting a route that can be successfully uploaded to only 20 waypoints. I'm not sure why, but the Maxsea program limits uploads of routes to 20 waypoints. Perhaps there is a reason I don't know about that requires they be done only 5 per sentence.

I think that's all I have! I'll be more than happy to assist in testing this and any other feature that's within my area of expertise in the future. I was a software developer for 35 years, so I might be able to be of some help in the future!

[bdbcat]

reflectionsv37....

Thanks for the test, I'll take a look at some of this. Should mostly be fixable, or at least made functional.

The things that won't be changed in 3.2:
1. The global option for Furuno upload formats will be retained.
Reason: The selected GPS upload port is not related to the active Connections datastream(s). The upload port does not even need to be in the Datastreams list. So we have no clean mechanism for associating upload protocol with arbitrary port. Would require yet another layer of dialog....
2. We won't try to teach Furuno users how their GPS receiver works regarding Route and Waypoint overwrite on upload. I get an occasional "WTF" email on this subject already, and I point to the Furuno Users Manual.

I don't know if I like the idea of renaming the upload waypoints to OCPN01, OCPN02, etc. After upload, there will be no way for the user to associate a waypoint on the OCPN screen with a waypoint on the GPS, except by tedious lat/lon comparisons. Are you sure about this idea?

Are you on linux, or Windows? Are you set up to build from source for testing?

But, before I start working, I have to ask....
"You like Furuno GPS why?"

Again, thanks
Dave

[bdbcat]

sbfreddie....

Do all of the dialogs look black, or just the options dialog?
Does it change at all if you change the color scheme using the toolbar "sun" icon?

Dave

[HappySeagull]

...maybe a special plugin is needed for "special-needs" gps. That Furuno sounds even stupider than my Garmin12....