OpenCPN Release Candidate Version 3.1.1417 Released

[bdbcat]

Thomas...

TCP transmit errors: There is a slightly new logic here, not well described (nor tested) until now.

If you wish to transmit on TCP, you are in effect going to set up OCPN as a TCP server for the data, which a remote client may or may not connect to.

It is the converse of the case where O is the client to the Frisco or Sweden TCP AIS data feed server.

In the case where O is the server, you probably want to set the transmit connection address to 0.0.0.0. This implies that the O TCP server will accept a connection from any TCP client, and provide the NMEA stream without further prompting.

So, the errors simply mean that there is no client connected to the present O server. Since TCP is connection oriented, O has nowhere to send the data. Hence the errors.

The errors in the Debug window log are a bit ugly, but maybe a reminder that an active server with no client still consumes resources, and should be disabled if not really in use....

Dave

[bdbcat]

Gilletarom....

Thanks for the crash report. Can't get too much from the log, but I suspect the problem is with one or more of the PlugIns. I have never seen a log with so many PlugIns loaded at once

20:39:45: PlugInManager searching for PlugIns in location C:\Program Files\OpenCPN\plugins
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/bsb4_win32_pi15_v12_pi.dll
20:39:45:   C:\Program Files\OpenCPN\plugins/bsb4_win32_pi15_v12_pi.dll Version detected: 105
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/CALCULATOR_win32_pi18_v11_pi.dll
20:39:45:   C:\Program Files\OpenCPN\plugins/CALCULATOR_win32_pi18_v11_pi.dll Version detected: 108
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/dashboard_pi.dll
20:39:45:   C:\Program Files\OpenCPN\plugins/dashboard_pi.dll Version detected: 106
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/findit_pi.dll
20:39:45:   C:\Program Files\OpenCPN\plugins/findit_pi.dll Version detected: 106
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/ge2kap_pi.dll
20:39:45:   C:\Program Files\OpenCPN\plugins/ge2kap_pi.dll Version detected: 107
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/gecomapi_win32_pi16_v09_pi.dll
20:39:45:   C:\Program Files\OpenCPN\plugins/gecomapi_win32_pi16_v09_pi.dll Version detected: 106
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/gradar_pi.dll
20:39:45:   C:\Program Files\OpenCPN\plugins/gradar_pi.dll Version detected: 108
20:39:45: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/grib_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/grib_pi.dll Version detected: 107
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/kmloverlay-test_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/kmloverlay-test_pi.dll Version detected: 107
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/logbookkonni_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/logbookkonni_pi.dll Version detected: 107
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/logbook_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/logbook_pi.dll Version detected: 106
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/nvc_win32_pi15_v13_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/nvc_win32_pi15_v13_pi.dll Version detected: 105
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/ocpndebugger_win32_pi18_v01_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/ocpndebugger_win32_pi18_v01_pi.dll Version detected: 108
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/ROUTE_win32_pi18_v10_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/ROUTE_win32_pi18_v10_pi.dll Version detected: 108
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/SAR_win32_pi18_v07_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/SAR_win32_pi18_v07_pi.dll Version detected: 108
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/survey_v01_pi17_pi.dll
20:39:47: Error: Failed to load shared library 'C:\Program Files\OpenCPN\plugins/survey_v01_pi17_pi.dll' (error 126: le module spécifié est introuvable.)
20:39:47:    PlugInManager: Cannot load library: C:\Program Files\OpenCPN\plugins/survey_v01_pi17_pi.dll
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/vdr_win32_pi16_v03_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/vdr_win32_pi16_v03_pi.dll Version detected: 106
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/wmm_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/wmm_pi.dll Version detected: 108
20:39:47: Warning: WMM model data file C:\Program Files\OpenCPN/plugins/WMM.COF can't be loaded, using the bundled data.
20:39:47: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/wmm_win32_pi18_v06_pi.dll
20:39:47:   C:\Program Files\OpenCPN\plugins/wmm_win32_pi18_v06_pi.dll Version detected: 108
20:39:47: Warning: WMM model data file C:\Program Files\OpenCPN/plugins/WMM.COF can't be loaded, using the bundled data.

But of course this is a great stress test.

I know it takes a lot of time, but it would be useful to systematically try to isolate failures to specific PlugIns, if possible.

Thanks
Dave

[nohal]

Originally Posted by Gilletarom

Hello Dave, hello Pavel,

One thing that should get new users confused. It is the diversity dates compilations plugins download page.

I do not know if you have plans to update this page on the website. But I think it would give a good signal to new users during the next stable release.

B.R. Gilletarom.

Don't worry, it will get some loving touches as during every release in the past. Of course I can't wait to do all those builds on my "superfast" virtual machines once again

Pavel

[reflectionsv37]

Ahoy Dave!!

I tested everything I could think of this morning and was unable to make the upload fail within the limitations of those high tech Furuno GPS's! I tested with both the right click and Route Manager and both worked flawlessly. I tested routes with varying numbers of waypoints paying particular attention to issues we had in the past. I just can't make it fail!!

I see that you are sending out 7 waypoints per route segment and it worked perfectly. A route with 29 waypoints failed, as expected, due to 5 route segments being sent. 28 waypoints is the upper limit OpenCPN can successfully send. If you ever want to run a test with 8 segments per line. I'll be happy to give it a try, but I think 28 waypoints is great. Of course, I'm sure that every route I layout now will contain 29 waypoints.

I did notice 2 minor issues that did not affect the upload but thought I would let you know as they make comparing waypoints on the GPS more difficult to what is shown in OpenCPN.

1) When waypoint names are less that 6 characters, you are padding the remaining characters with zeros(0). The Furuno will accept trailing spaces and I verified this by changing a waypoint name to TST with 3 trailing spaces and it worked perfectly.

2) Lower case letters are not recognized on the Furuno. The waypoint is still transferred and the route is still built correctly, but the waypoint name in the Furuno is comprised of special characters and displays as gibberish. If there is an easy way to convert lowercase to uppercase when uploading waypoint names, it might be beneficial.

I noticed one other thing that I'll only mention due to being a former anal retentive programmer. When uploading the waypoints you have 3 decimal places of precision and OpenCPN has 4 digits. The 4th digit is being truncated rather than rounded. This might make a waypoint off by a 1/2 inch or so! LOL!

I've tested everything I can think of and am happy to report that as of today, OpenCPN is the navigation program I will be using from now on!!!

Thanks again for adding this feature!! I've already emailed a few friends with Furuno GPS's to let them know.

If I can be of any further assistance, don't hesitate to ask!

Gene

[bdbcat]

gene...
When I saw your recent posting in the index, I opened the thread with severe trepidation and trembling mouse finger.. Did we get it right finally? YES!!!

I've added your suggestions for improvement to the list already started for the (dare I say it?) Version 3.3 Beta series.

Thanks again for your patience with this one. Glad we got it done.

Dave

[Rapport]

A minor thing I know, but if I press alt s,a,o,l, or t, a change occurs, and I can return by the same key presses. If I press alt D, I have to find the mouse to close the window. Couldn't alt d close it like it does with the others?
Thanks for excellent work

[Gilletarom]

Originally Posted by Rapport

... if I press alt s,a,o,l, or t, a change occurs, and I can return by the same key presses. If I press alt D, I have to find the mouse to close the window. ...
Thanks for excellent work

Note: keyboard shortcuts s, a, o, l, t, d are not listed in the website opencpn.org. It is the same for Alt s, Alt o, Alt l, Alt t, and alt D.
But all these keyboard shortcuts work like A, O, L, T and D.

Is this intentional?

B.R. Gilletarom.

[Hakan]

Originally Posted by Gilletarom

Note: keyboard shortcuts s, a, o, l, t, d are not listed in the website opencpn.org.

Gille...
Actually they are at: Vector Charts | Official OpenCPN Homepage Although the "r" is still there. Not a very big harm with that since the function is disabled. Can surely be fixed soon.

[Alu]

Hello
I would like to test the release Candidate for mac but there
is no mac version to download ?

Sven

[cagney]

Originally Posted by Hakan

Gille...
Actually they are at: Vector Charts | Official OpenCPN Homepage Although the "r" is still there. Not a very big harm with that since the function is disabled. Can surely be fixed soon.

Håkan
Thanks for spotting the "r" hot key. It appeared in 2 places. I know I deleted both earlier. The only explanation I can think of, is that the "r" sneaked back in through a server backup when South Bay had their crash a while ago. This means that there may be other unwanted or missing snippets, in the wiki.
Thomas

[cagney]

Originally Posted by dpons

Thanks, Pavel, I'll check tomorrow, I don't have that machine handy now. What you say is possible, since I loaded from synaptic something that looked right just before compiling.

Diego

Dpons & Nohal

O should compile fine without portaudio. Of course the sound will not work. Maybe it's something else, or something Debian & portaudio specific.

Thomas

[cagney]

Originally Posted by bdbcat

Thomas...

TCP transmit errors: There is a slightly new logic here, not well described (nor tested) until now.

If you wish to transmit on TCP, you are in effect going to set up OCPN as a TCP server for the data, which a remote client may or may not connect to.

It is the converse of the case where O is the client to the Frisco or Sweden TCP AIS data feed server.

In the case where O is the server, you probably want to set the transmit connection address to 0.0.0.0. This implies that the O TCP server will accept a connection from any TCP client, and provide the NMEA stream without further prompting.

So, the errors simply mean that there is no client connected to the present O server. Since TCP is connection oriented, O has nowhere to send the data. Hence the errors.

The errors in the Debug window log are a bit ugly, but maybe a reminder that an active server with no client still consumes resources, and should be disabled if not really in use....

Dave

Dave

Thanks for the explanation.
I tested the tcp server setup with a kubuntu as a server and a XP as a client, and vice versa, without problems.

Thomas

[nohal]

Originally Posted by cagney

Dpons & Nohal

O should compile fine without portaudio. Of course the sound will not work. Maybe it's something else, or something Debian & portaudio specific.

Thomas

Yep, it builds fine without portaudio, but it breaks with the wrong one. At least I think this is the case here...

[Ptizef]

Hi Dave and all

The sizing in plugins works well now with the last API ( GetChartbarHeight() added )
But , in some cases when CTRL B is toggled , the canvas is not refreshed and I found a bit complex to do it in plugin ( through a timer to scrutinise if the port height has changed )
It would be less complex to do it immediately when CTRL B is toggled like this :

""
in chcanv.cpp lines 4041 to 4047
stats->Show();
gFrame->Raise();
}
+ Refresh();
}
break;

""

I understand it is to late for 3.2 but could you think about it for the future version ?

Thanks
Jean Pierre

[muttnik]

Sorry if this is "expected behaviour": wiki wasn't updated with this when last I looked but thought I'd raise it just in case. Using git pulled and re-built 10:00 UTC today.

Testing "server mode" tcp. 2 connections:
- tcp connection from hd-sf.com/9009
- tcp connection 0.0.0.0/10110, output enabled

connect one tcp client to port 10110 on system O is running on: sentences received fine.
Connect second tcp client: sentences to first client stop, but second client now receives transmissions.

Also..seems that tcp connection is one way: sentences transmitted from the client to the O "server" do not appear in the debugging window.