OpenCPN Release Candidate Version 3.1.1405 Released

[reflectionsv37]

Hi Dave!!

It is very close! Just a few things that need to be corrected and should at least be functional.

Neither of items 1or 2 are important, particularly number 2! If they don't know, they'll figure it out the first time they try to upload.

Another thing I noticed but neglected to mention was that I tried the upload using both the route manage and the right click on the route. In the route manage, a dialog box and progress bar are displayed and there is also an option on that screen to select the COM port you want to upload to. That is why I mentioned having the Furuno upload setting specific to the COM port as I noticed every COM port on my system was show in that list. I thought it might be a good idea to pop that dialog & progress bar up when using the upload from the right click. When I did it from the right click, I had a 20 waypoint route and my first thought was that it didn't do anything. It was working, I just didn't know it.

In regards to renaming waypoints, it won't matter to me which option you choose. I never give a specific name to a waypoint when building a route. I just click, click, click and 1,2,3,4... are fine names for those waypoints. Doing it that way my nav program and GPS always have the same names so it's never been a problem.

In that example I gave with the 7 character waypoint, the upload succeeds, but a waypoint is obviously missing. If that happened to be a waypoint to avoid a reef, you would never know if just using the GPS for navigation, which I do regularly. This is also the reason why uploading to the Furuno is important to me. I build a route on the nav program and then upload to one(or more GPS's). Everything that needs a GPS signal comes from the GPS, so my radar, autopilots, etc. don't depend on the nav program running to continue to function. On long passages, I shut down the computer and the GPS has all the information. Nothing bores me more than watching my boat moving across a solid blue screen. Having a name for a waypoint that doesn't match in the nav program and the GPS is way less important than finding myself parked on a reef. Another option that you might have is to check the list of waypoints before uploading, stripping all of them back to 6 characters and issue a warning message if there are duplicates.

I'm not set up with the source code but I'll buy some more internet time tomorrow and download it. I don't even know what language OpenCPN is written in, but I'm 99% certain I don't have any experience with it. I'm an old guy but still capable of learning new tricks so I'm sure that if I looked at the code for awhile, I could figure out what is going on.

And that old guy comment will lead me right in to your last question. Way back in the mid 1990's, before there was light, I was getting ready to go cruising. Some of the equipment on Reflections is about as old as me. The boat already had a Furuno radar, and it's still working! Connected to it was a Furuno Loran which I upgraded to a GPS and they really look great together! Then I did a bunch of custom woodwork in the nav station and built all this equipment in and if I switch to any other GPS, I'll be in for a major woodworking project that I really don't want to do. And hey, it's still working and I won't replace anything until it's not working anymore. Last year I was helping a friend setup his new Furuno radar and connecting his Garmin GPS to the radar so the waypoint lollipop appeared on the radar screen. Much to my surprise, the Garmin won't send the NEMA sentence that the Furuno expects for waypoint information and the Furuno had no mechanism to change the NEMA sentence to another for waypoint info. I never heard how this finally came out. When he left Garmin was telling him to talk to Furuno and Furuno was telling him to talk to Garmin!

Let me know if you'd like me to do some more testing!

Gene

[reflectionsv37]

I can beat that Garmin 12 of yours! I still have 2 Garmin XL 45's on board. I think I bought those back in 1995 or so. After you have traveled a couple thousand miles without turning them on, it takes them about an hour to acquire a position! And they still have more capabilities than the Furuno. I know lots of people that still have these Furuno's. Why, I'm not sure!!

[Hakan]

Originally Posted by bdbcat

Ahoy, OpenCPN'ers...
191. Remove update of magnetic heading and variation on processing of AIVDO messages.
Dave

Dave...
1)
Updated function task 191. confirmed. Works well. Thanks.

2)
A question about the priority functions just for my own knowledge:
An example: I'm now moored by ropes and ice so speed and course messages from GPS and AIS-GPS is of no relevance although the boat is moving a little inside the hole in the ice. The old GPS is then reporting 0/360 degr course and 0 Kn since the accuracy for that item is one decimal. The AIS' GPS part however offers, for some questionable reason, three decimals. So movements of half a meter is actually reported with course and speed. The result is that the OCPN's heading of the boat is rapidly changing because both NMEA messages regarding course are read and used.
This is of course not a real problem for any one to take care of. When sailing there are accurate speed and course from both GPS'.
But, and this is my question, I thought the priority settings should take care of double messages and only trust the highest order of priority? In this example the old GPS with a constant course (0 degr.) and zero speed.
Apparently I misunderstand the function of priority?

I'll please every lesson. Thanks Håkan

[bdbcat]

reflectionsv37....

1. One more time, the right click context menu upload selection is a two-click graphical shortcut. If you don't like it, use the RouteManager to get full feedback with lots more clicking opportunities. By the way, the confirmation of successful upload is a placebo. There is no way to use NMEA0183 to confirm that an upload really happened at all. At least with Garmin Host Mode we can tell if the unit is powered up or not.... That's the way it is sometimes with legacy interfaces like NMEA0183.

2. Don't spend a lot of time or effort getting a build environment set up if not already set. I just thought it might save a step. We will do another RC to verify the Furuno code (and some other stuff) before release.


Thanks again
Dave

[bdbcat]

Hakan.....

The NEMA priority scheme works on the basis of message type, not content. So, for composite messages that contain may types of data, there is still some ambiguity.

Specifically, GPRMC and AIVDO contain similar data (i.e. COG, SOG). But since they are different message types, their contents do not prioritize. Both are used, in the order received.

We thought about a two-level priority scheme, considering message type and contents. We concluded that the 2 dimensional hash-map lookup required would impact performance too much. Thus, the current priority scheme is useful mostly for fail-safe GPS backup setups, where the messages coming from two sources are the same.

I have a similar situation onboard. My GPS sends RMC and GLL, at different precisions (i.e. decimal points). I choose to ignore the GLL using a filter, in order to keep my boat from jumping around at anchor.


Hope this helps
Dave

[Hakan]

Dave..
Thanks for the explanation. Yes it helped. As plain.....

[Gilletarom]

Hello Thomas Cagney,
Here some new files for layers gpx files. There is also some files that I update.
If I do not err, I'm done. But if you cut areas seems inappropriate, let me know.
Please, if you see an error, send me a message.
B.R Gilletarom

[sbfreddie]

Originally Posted by 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

Dave:
The problem is with the options, waypoints, and route properties dialogs. The about Opencpn dialog is fine.
There are four different color schemes bright, less bright,dim, very dim, I assume the two lower settings are for night vision.
The options, route manager windows work fine in the lower two settings (dim, very dim).
The route properties does not work in any color scheme (See attached screen shot).
Strange eh?
Any Ideas?

Thanks,
Freddie

[bdbcat]

Hello all GPS users....

We are having some trouble, I think, with generic NMEA Route and Waypoint uploads. I think Furuno is understood, as well as Garmin Host mode. But there may not have been as much testing on other generic devices as we might want.

So, if you have a GPS connected to O, please try some waypoint and route uploads. We need to know the following:
1. Gps Make/Model
2. Success/failure
3. Datastream log. This is most easily captured from the O logfile, and will look something like this:

14:50:14 EST: Opening NMEA Datastream Serial:/dev/ttyS0
14:50:14 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2857.023,N,08055.518,W,001*74
14:50:14 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2858.140,N,08049.916,W,002*73
14:50:14 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2857.521,N,08044.845,W,003*74
14:50:14 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2856.008,N,08041.602,W,004*74
14:50:15 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2853.754,N,08040.953,W,005*74
14:50:15 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2851.430,N,08040.992,W,006*79
14:50:15 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2850.070,N,08039.970,W,007*7B
14:50:15 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2848.486,N,08039.774,W,008*7A
14:50:15 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECWPL,2847.986,N,08038.575,W,009*7B
14:50:16 EST: -->GPS Port:Serial:/dev/ttyS0 Sentence: $ECRTE,1,1,c,1,001,002,003,004,005,006,007,008,009*0A
14:50:16 EST: Closing NMEA Datastream Serial:/dev/ttyS0

Thanks
Dave

[bdbcat]

Freddie....

Something wrong with the dimmer code, I think.

Please try the following as a SWAG:

chcanv.cpp (15953)

void DimeControl( wxWindow* ctrl, wxColour col, wxColour col1, wxColour back_color,
                  wxColour text_color, wxColour uitext, wxColour udkrd, wxColour gridline )
{
       return;

We simply add a return; statement so that DimeControl does nothing, and the system default dialog colors are used.

Maybe?
Dave

[sbfreddie]

Originally Posted by bdbcat

Freddie....

Something wrong with the dimmer code, I think.

Please try the following as a SWAG:

chcanv.cpp (15953)

void DimeControl( wxWindow* ctrl, wxColour col, wxColour col1, wxColour back_color,
                  wxColour text_color, wxColour uitext, wxColour udkrd, wxColour gridline )
{
       return;

We simply add a return; statement so that DimeControl does nothing, and the system default dialog colors are used.

Maybe?
Dave

Dave:
That did the trick, now all the windows look fine. However I don't think disabling the dimming capabilities of O is the final answer. I'll let you and the other Masters figure that out.
This version using 64bit code with WxWidgest 2.9.4 is very fast, redraw time is instantaneous, and everything works very quickly.
By the way I noticed you finally got the users manual installed, however how do you select between using the online user manual and the one installed in O. Right now it automatically goes to the Web to see the user manual.

Thanks,
Freddie

[bdbcat]

Freddie...

OK, try this as a real solution:

void DimeControl( wxWindow* ctrl, wxColour col, wxColour col1, wxColour back_color,
                  wxColour text_color, wxColour uitext, wxColour udkrd, wxColour gridline )
{
    ColorScheme cs = cc1->GetColorScheme();
    if( cs != GLOBAL_COLOR_SCHEME_DAY && cs != GLOBAL_COLOR_SCHEME_RGB ) ctrl->SetBackgroundColour(
            back_color );
    else
        ctrl->SetBackgroundColour( wxNullColour );

#ifdef __WXMAC__
#if wxCHECK_VERSION(2,9,0)
    if( cs != GLOBAL_COLOR_SCHEME_DAY && cs != GLOBAL_COLOR_SCHEME_RGB )
        ctrl->SetBackgroundColour( back_color );
    else
        ctrl->SetBackgroundColour( wxColour( 0xff, 0xff, 0xff ));
#endif    
#endif
        
    wxWindowList kids = ctrl->GetChildren();
    for( unsigned int i = 0; i < kids.GetCount(); i++ ) {
        wxWindowListNode *node = kids.Item( i );
        wxWindow *win = node->GetData();

Note the special code for building for Mac with wxWidgets 2.9. That's you

It seems that on your system, wxNullColour is black, whereas for all other systems wxNullColour means to use the system default colour. We will probably have to do something else here in future versions, but this patch will be OK for the 3.2 Release.

On the documentation:
The embedded doc file is used automatically if found. It is found in the application bundle, in Contents->SharedSupport->Doc. Do you have that?

Dave

[reflectionsv37]

Hi Dave,

I am aware that there is no way to tell if the NEMA upload is successful. My observation was only to indicate that when I clicked on the send via the right click, that there was nothing that confirmed that the upload was actually in progress.

Since the route manager upload already has a dialog box involved, and allows you to select the COM port you wish to upload to, why not also include an option on that dialog box to select the upload format? It could default to the setting in the connection setup. The right click option could be left as is using the default setting.

[sbfreddie]

Originally Posted by bdbcat

Freddie...

OK, try this as a real solution:

void DimeControl( wxWindow* ctrl, wxColour col, wxColour col1, wxColour back_color,
                  wxColour text_color, wxColour uitext, wxColour udkrd, wxColour gridline )
{
    ColorScheme cs = cc1->GetColorScheme();
    if( cs != GLOBAL_COLOR_SCHEME_DAY && cs != GLOBAL_COLOR_SCHEME_RGB ) ctrl->SetBackgroundColour(
            back_color );
    else
        ctrl->SetBackgroundColour( wxNullColour );

#ifdef __WXMAC__
#if wxCHECK_VERSION(2,9,0)
    if( cs != GLOBAL_COLOR_SCHEME_DAY && cs != GLOBAL_COLOR_SCHEME_RGB )
        ctrl->SetBackgroundColour( back_color );
    else
        ctrl->SetBackgroundColour( wxColour( 0xff, 0xff, 0xff ));
#endif    
#endif
        
    wxWindowList kids = ctrl->GetChildren();
    for( unsigned int i = 0; i < kids.GetCount(); i++ ) {
        wxWindowListNode *node = kids.Item( i );
        wxWindow *win = node->GetData();

Note the special code for building for Mac with wxWidgets 2.9. That's you

It seems that on your system, wxNullColour is black, whereas for all other systems wxNullColour means to use the system default colour. We will probably have to do something else here in future versions, but this patch will be OK for the 3.2 Release.

On the documentation:
The embedded doc file is used automatically if found. It is found in the application bundle, in Contents->SharedSupport->Doc. Do you have that?

Dave

Dave:
That does the trick, now I can see the text in all the four different dim settings.

On the documentation:
It works as it should, I was not looking at the url bar in Safari. All is well.

Now for the final problem concerning the two different .app bundles being built, one in the build dir and one in the build/bin directory. More to come tomorrow.

Thanks,
Freddie

[Hakan]

Hi
My friend is here with a win7 using last beta. And we can confirm the shut down hang when using GE2KAP. (Ref #6) Thus when GE2Kap is loaded but not acticated OCPN skuts down without problem. Next test with GE2KAP activated and shut down OPCN hangs and windows has too take care of it.
The last rows of logfile is here but it's strange since it seems to stop on grib plugin instead?

18:06:14: opencpn::MyFrame exiting cleanly.
18:06:14: Chart cache purge
18:06:14: PlugInManager: UnLoading PlugIn: C:\Program Files (x86)\OpenCPN\plugins/dashboard_pi.dll
18:06:14: PlugInManager: UnLoading PlugIn: C:\Program Files (x86)\OpenCPN\plugins/ge2kap_pi.dll
18:06:14: PlugInManager: UnLoading PlugIn: C:\Program Files (x86)\OpenCPN\plugins/gecomapi_win32_pi16_v09_pi.dll
18:06:14: PlugInManager: UnLoading PlugIn: C:\Program Files (x86)\OpenCPN\plugins/grib_pi.dll

/Håkan