OpenCPN Beta Version 3.3.814 Released

[Gilletarom]

Hello Dave,

ASUS 1015 10' W 7 start with 3.3.814

here two screen shot.

First with route manager. You can see that the file manager window that I use for save my screen shot, is upper the route properties window.

Second, with tracks manager. You can see that the track manager window is upper the file manager window. And if I use an other software like firefox by example, idem. The track manager window is upper the firefox window.

B.R. Gilletarom

[bdbcat]

Gilletarom...

Thanks, very clear now. Easy fix.

New Beta coming soon now...
Dave

[sinbad7]

Dave..

Finally,European tidal stream data is also available in the old .grib version,parallel with the new advanced .grib2 version,BUT,the latest version of OCPN does not seem able to display the colored sea temperature,nor the direction and velocity of the streams in the ´Grib data at cursor´boxes. Only the stream arrows are displayed,no matter what settings I am using. Could you PLEASE correct this in the upcoming version of OCPN?

See the conversion .grb2 to .grb here: ftp://ftp.bsh.de/Stroemungsvorhersagen/grib1/
NOTE. The files must be re-named from .grb1 to just .grb to work.

As you see from the attached,the converted .grb2 to .grb version works perfectly with v. 3.2.2 of OCPN

Hoping .grb2 format will shortly be readable in one of the new versions.

Tore

[bfloyd4445]

This is all greek to me but I have been playing with the last version for about a year and have finally got it to talk to my garmin gps. Just would like to say, thank you, you all have done a fantastic job and made my boating eaiser. I have trouble reading the little screens of chartplotters and because of you all I can now use my 19 inch monitor. Really makes it easy!
Any plans for an auto update feature?

[bdbcat]

Hi folks...

I am looking through some of the emailed Crash Reports, and getting some very useful information on unexpected code paths, leading to crashes. Most are easy to figure out and fix, but some are not.

Here is one that is a puzzle.
There are some crashes that happen when the user deletes a waypoint that is part of a route. It may be part of a route that has only two points, or maybe even an orphan one-point route. Seems that the crash happens when the last point of a route is being deleted. Happens mostly in France, by the screenshots

If this sounds familiar to you, I would like to get more information. Is it a repeatable crash? Any other notable information?

Thanks
Dave

[sinbad7]

This is how the old version of tidal stream .grb files SHOULD be displayed in OCPN v. 3.3.814. Instead all the color coded stream velocity is missing.

The new,converted .grb2 to .grb does not work at all,showing only what appears to be arrows of wind direction and force??

Perhaps we´d better wait for OCPN to be compatible with the latest .grb2 version?

Tore

[sinbad7]

FYI the converted .grb files from ftp://ftp.bsh.de/Stroemungsvorhersagen/grib1/
no longer work in either qtVlm or OCPN with the following messages attached.

The developers of qtVlm tells me that they are very shortly going to have a new release compatible with .grb2 so that is good news. From here we just copy/paste the Optimized Route in .kml format to OCPN.

Tore

[sinbad7]

Sorry.. forgot to add the error message attachments:

Tore

[George64]

Originally Posted by sinbad7

The developers of qtVlm tells me that they are very shortly going to have a new release compatible with .grb2 so that is good news. From here we just copy/paste the Optimized Route in .kml format to OCPN.

Tore

This seems quite some work if one only wants to know the tidal stream in a certain area... Hope O will have Grb2 in place very soon

[rgleason]

Hope O will have Grb2 in place very soon

VOTE for it in Tracker.

[Gilletarom]

Hello Dave, Hello All,

For information:

This summer, I opened a thread on NMEA DSC and DSE. You changed OpenCPN for an alert window opens when these sentences appear in the NMEA stream.

I tried O 33814 with the test file that you provide. It worked.

During the second part of my navigation, with O 33814, I've never seen this window open on the PC. Yet my VHF announced alerts (1-3 alerts per day)

My VHF is Navicom RT 550. I asked the manufacturer of the VHF. In his answer, he was told that the radio does not transmit the DSC and DSE sentences kind in the NMEA stream.

So, unfortunately, with these VHF RT 550, we can not use this new functionality OpenCPN.

[rgleason]

Since Gilletarom's VHF (Navicom RT 550 ) does not transmit the DSC and DSE sentences in the NMEA stream, can anyone else test and confirm the operation of Item #90?

Post #1 from Bdcat lists
90. Implement Alert Dialog for DSC Distress calls. (FS#1051)
Release 3.3.814

Notes:
90. Here is a string for testing DSC distress Alert Popup.
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E* 6D

I tried saving a test file with the above and Playing it with VDR and an alarm appeared, with blank screen and Acknowledge did not seem to stop it. I tried turning off VDR and the alarm continued.

Then I found another file under my nmea directory, called dsc.txt with the following:

!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13
!CDDSC,12,3081234000,,07,00,0354013946,0657,,,S,E*6D
!CDDSE,1,1,A,3081234000,00,60875646*13

When I played that with VDR I did get the MMSI number and message in the window. However hitting Acknowledge and turning off VDR play did not seem to stop it. I do not know if this action is as expected.

It would be helpful if someone would test this function with a VHF/DSC somehow, but how do you do it without sending an emergency call?
--A bit of a problem.

[Ptizef]

When dragging a way point :
- open the mark properties dialogue
- move the mark/way point
- close dialogue by "cancel" : the move is lost , the mark is back to his
first place and is no longer selectable until O is closed.
The same thing when undo move
- move a mark/way point
- open the mark properties dialogue
- undo move
- close the dialogue by easer "OK" or "Cancel : the undo is lost

to correct that , I propose this patch :
---------------------------------------
diff --git a/src/routeprop.cpp b/src/routeprop.cpp
index 4942212..77828b6 100644
--- a/src/routeprop.cpp
+++ b/src/routeprop.cpp
@@ -2112,6 +2112,8 @@ bool MarkInfoImpl::UpdateProperties( bool positionOnly )

m_textLatitude->SetValue( ::toSDMM( 1, m_pRoutePoint->m_lat ) );
m_textLongitude->SetValue( ::toSDMM( 2, m_pRoutePoint->m_lon ) );
+ m_lat_save = m_pRoutePoint->m_lat;
+ m_lon_save = m_pRoutePoint->m_lon;

if( positionOnly ) return true;
------------------------------------------
diff --git a/src/undo.cpp b/src/undo.cpp
index 6acc600..63acff6 100644
--- a/src/undo.cpp
+++ b/src/undo.cpp
@@ -40,6 +40,7 @@
#include "navutil.h"
#include "styles.h"
#include "routeman.h"
+#include "routeprop.h"
#include "routemanagerdialog.h"
#include "tinyxml.h"
#include "undo.h"
@@ -52,6 +53,7 @@ extern RouteManagerDialog *pRouteManagerDialog;
extern WayPointman *pWayPointMan;
extern ChartCanvas *cc1;
extern MyFrame *gFrame;
+extern MarkInfoImpl *pMarkPropDialog;

Undo::Undo()
{
@@ -109,6 +111,10 @@ void doUndoMoveWaypoint( UndoAction* action ) {
selectable->m_slat = currentPoint->m_lat;
selectable->m_slon = currentPoint->m_lon;

+ if( ( NULL != pMarkPropDialog ) && ( pMarkPropDialog->IsShown() ) ){
+ if( currentPoint == pMarkPropDialog->GetRoutePoint() ) pMarkPropDialog->UpdateProperties(true);
+ }
+
wxArrayPtrVoid* routeArray = g_pRouteMan->GetRouteArrayContaining( currentPoint );
if( routeArray ) {
for( unsigned int ir = 0; ir < routeArray->GetCount(); ir++ ) {
-------------------------------------------

I'll post it on flyspray as soon as it'll work ( out of order at the moment )

regards
Jean Pierre

[rgleason]

Could this be related to Dave's post 50 above
Dave:

Here is one that is a puzzle.
There are some crashes that happen when the user deletes a waypoint that is part of a route. It may be part of a route that has only two points, or maybe even an orphan one-point route. Seems that the crash happens when the last point of a route is being deleted. Happens mostly in France, by the screenshots

[rooiedirk]

Hoi,
As already mentioned in a bug report in flyspray, we did encounter some weird behavior in the dailytracks. In NewFoundLand that has a strange 3 1/2 hours timezone the daily tracks did not start at midnight.
Searching the code, I think I did find the problem. (see att patch file)
Under my home linux box with system clock set to UTC it works fine. Unfortunnally I can't test under window with the system clock running on local time.
Could somebody test under windows please? (with timezone set to St Johns NewFoundLand)
Dirk