OpenCPN Release Candidate Version 3.1.1328 Released

[SethDart]

Originally Posted by hwecken

Hello Thomas,
you are right, in my nmea is no MWD sentence, but there is MWV (Wind Speed and Angle) and HDG (Heading – Deviation & Variation), so TWD could be calculated very easy.

There's a discussion about adding some missing sentence calculation to the dashboard. It's decided not to add it to the dashboard but to a separate plugin. The dashboard is dedicated to displaying data only. Others plugins can manipulate and inject NMEA sentences with appropriate config as required (as does the magnetic variation plugin for example). IIRC, Thomas R has a basic code to do so. I'm willing to help if anyone wants to create such a plugin.

Originally Posted by hwecken

Yes in my case the NMEA sentence is: $IIDPT,001.8,+0.7,*49 , which means:
$--DPT,x.x,y.y*hh
x.x Depth, meters
y.y Offset from transducer;
positive means distance from transducer to water line,
negative means distance from transducer to keel
hh Checksum
So i would expect in the above sample 2,5m in deashboard, not 1,8m as it is now

If you need my NMEA file please send me a PM with your email
vb Hartmut

I've just pushed a commit to use DPT rather than DBT if available and to sum depth and offset. All my samples didn't have offset so I never bothered adding it to the dashboard.
How should the calculation be done for negative values? Right now, they are added thus the value will be water depth for the former and depth under keel for the latter. That might be confusing... Unfortunately we don't know distance from transducer to water line in the latter. Should we use a different unit as in °T or °M for true vs. magnetic to avoid confusion?

Regards,
Jean-Eudes

[nohal]

Howdy...
There are new DEB packages at https://launchpad.net/~nohal/+archive/opencpn
- The portaudio dependency should be corrected now, so everybody should be happily hearing the sound
- Added packages for raring aka. 13.04 (too) early adopters

Keep me posted with feedback so we get as good the packages as we can

Thanks

Pavel

[hwecken]

Originally Posted by SethDart

How should the calculation be done for negative values? Right now, they are added thus the value will be water depth for the former and depth under keel for the latter. That might be confusing... Unfortunately we don't know distance from transducer to water line in the latter. Should we use a different unit as in °T or °M for true vs. magnetic to avoid confusion?

Regards,
Jean-Eudes

Hello Jean-Eudes
the skipper decides with his programming of his depth sensor what he wants to see. If he programms a positive offset ==> he wants to show depth of water messured from surface, or if he programms a negative offset ==> he wants to show depth of water below keel.
So for OPENCPN it is very easy, just add depth and offset.


...........1.... 2.... 3
...........|.... |.... |
$--DPT,x.x,x.x*hh<CR><LF>
Field Number:
1) Depth, meters
2) Offset from transducer,
positive means distance from tansducer to water line
negative means distance from transducer to keel
3) Checksum


Hartmut

[SethDart]

Originally Posted by hwecken

Hello Jean-Eudes
the skipper decides with his programming of his depth sensor what he wants to see. If he programms a positive offset ==> he wants to show depth of water messured from surface, or if he programms a negative offset ==> he wants to show depth of water below keel.
So for OPENCPN it is very easy, just add depth and offset.

Yes, that's what it does now. Your provided all the info and I could do the patch easily. My question was about showing that difference in the display so the user is not confused.

We'll keep it as is. If anyone has a good idea, please raise your voice ;-)

Jean-Eudes

[houlejm]

Originally Posted by SethDart

Yes, that's what it does now. Your provided all the info and I could do the patch easily. My question was about showing that difference in the display so the user is not confused.

We'll keep it as is. If anyone has a good idea, please raise your voice ;-)

Jean-Eudes

Jean-Eudes

I think it is Ok as is. The user (me) expects to see the same thing in OpenCPN as on the real instrument.

Jean-Marie

[hwecken]

Originally Posted by houlejm

Jean-Eudes

I think it is Ok as is. The user (me) expects to see the same thing in OpenCPN as on the real instrument.

Jean-Marie

Hello Jean-Marie
so do i

but please take this example $IIDPT,001.8,+0.7,*49 attached in dpt_nmea.txt and play it in VDR Plugin.
I would expect 2,5m as it is shown on my TackTick instruments and not as it is shown in opencpn (1,8m see screenshot)

in other words: opencpn shows depth below sensor (that doesnt make any sense for me)
i as an user would expect depth below surface or depth below keel,
thats why the offset is programmed in your real instrument. And this offset is the second value in the nmea sentence

Hartmut

[houlejm]

Originally Posted by hwecken

Hello Jean-Marie
so do i

but please take this example $IIDPT,001.8,+0.7,*49 attached in dpt_nmea.txt and play it in VDR Plugin.
I would expect 2,5m as it is shown on my TackTick instruments and not as it is shown in opencpn (1,8m see screenshot)

in other words: opencpn shows depth below sensor (that doesnt make any sense for me)
i as an user would expect depth below surface or depth below keel,
thats why the offset is programmed in your real instrument. And this offset is the second value in the nmea sentence

Hartmut

Hartmut

I agree and I understood that Jean-Eudes has done just that. It should appear in the next release.

I cannot test that since my instruments are in the boat which is out of the water until May. Temperature here is -12°C

Jean-Marie

[Ptizef]

Hi all

I would like to point here a small problem in the Plug-in interface :

The view-port size got in the plugin environnement includes the map bar even when it's shown and the size doesn't change when toggle "CTRL B" to hide/show it.
This could be a problem if a plugin wants to put a window in a precise position at the bottom

Here is a patch who seems to do correctly the job but there is certainty a better way ...

... ... @@ -4041,6 +4041,7 @@ void ChartCanvas::OnKeyDown( wxKeyEvent &event )
4041 4041 stats->Show();
4042 4042 gFrame->Raise();
4043 4043 }
4044 + cc1->Refresh();
4044 4045 }
4045 4046 break;
4046 4047
... ... @@ -10916,8 +10917,13 @@ void ChartCanvas:rawOverlayObjects( ocpnDC &dc, const wxRegion& ru )
10916 10917 GridDraw( dc );
10917 10918
10918 10919 if( g_pi_manager ) {
10919 - g_pi_manager->SendViewPortToRequestingPlugIns( GetVP() );
10920 - g_pi_manager->RenderAllCanvasOverlayPlugIns( dc, GetVP() );
10920 + ViewPort *vp = new ViewPort( GetVP() );
10921 + if( stats && stats->IsShown() ){
10922 + wxSize s = stats->GetSize();
10923 + vp->pix_height -= s.GetHeight();
10924 + }
10925 + g_pi_manager->SendViewPortToRequestingPlugIns( *vp );
10926 + g_pi_manager->RenderAllCanvasOverlayPlugIns( dc, *vp );
10921 10927 }
10922 10928
10923 10929 AISDrawAreaNotices( dc );


regards
Jean Pierre

[Hakan]

Dave..
ECRMC Autopilot outgoing sentence is anomalous.
I've been in the boat to check this beta version. The ECRMC sentences includes sometimes the magnetic variation value and sometimes not. The GPS' output includes a value every time GPRMC is sent but the sending frequency is sometimes slower than the repeated ECRMC. Two ECRMCs can be sent without a new GPRMC i between. The second ECRMC then don't includes the variation value. If this is pointing to the problem I don't know it's just an observation.
Attached print out shows some screen shoots with NMEA flows, configurations and last logs.

Please have look.
Thanks Håkan

[bdbcat]

Gilletarom, et al...

Regarding the troubles with large permanent layer files, exporting and deleting:

Solution to these problems would require some non-trivial redesign of the OCPN internal data structures, and is too risky at this point in the release cycle. We will have to live with what we have. Maybe the super large layer files on the opencpn.org download site should be removed??

But the larger point is this: Using Layer/Tracks to describe static chart overlay features is not very efficient. It bogs down the entire program if those layers contain many densely plotted trackpoints. Think about it: The boundaries of World Economic Exclusion Zones, for instance, are not tracks at all. They are statics line on the globe.

But, I understand that this is all we have available now, and we sometimes need to use what we have at hand.

What we really need, (hint, hint) is a generalized "Markup Overlay PlugIn".
This would allow arbitrary georeferenced markups of any kind, selectively displayed as overlays on the screen. Text, graphics, imagery, etc...

Maybe we can devote some real energy to this idea after 3.2 releases. Volunteers, anyone?

Dave

[bdbcat]

Hakan....

I see the problem. The mag variation is coming from your GPS receiver just fine. However, it is being overwritten by the next AIVDO sentence from your AIS transponder. Of course, AIVDO contains no mag variation information, so we end up with no variation info in the next transmitted ECRMC. Not good logic here.

I think it is a simple one line fix, but I shall have to think about the ramifications elsewhere. We are getting down to the short strokes.

Of course, you could filter out AIVDO from the AIS port. But then you would not get automatic fallback if your primary (priority 1) GPS source fails. Not desired...

Hmmm....thinking

Thanks
Dave

[mrm]

Originally Posted by bdbcat

What we really need, (hint, hint) is a generalized "Markup Overlay PlugIn".
This would allow arbitrary georeferenced markups of any kind, selectively displayed as overlays on the screen. Text, graphics, imagery, etc...

Maybe we can devote some real energy to this idea after 3.2 releases. Volunteers, anyone?

Dave

Dave,

Maybe the optimal thing to do it would be to choose a suitable GIS data format and pick a viewer code from an Open Source implementation as a plugin code base?

Maybe something from GRASS GIS? http://grass.osgeo.org/

Having adopted a known format would allow for use of other viewers, editors etc.

Just an idea. Don't have time to code that.

Marius

[Gilletarom]

Hello Dave,

Originally Posted by bdbcat

Gilletarom, et al...
...
Solution to these problems would require some non-trivial redesign of the OCPN internal data structures, and is too risky at this point in the release cycle. We will have to live with what we have. Maybe the super large layer files on the opencpn.org download site should be removed??
...
Dave

In the short term, if the file gpx "World Economic Exclusion" causes too many problems, do not hesitate to remove it from the website.
It is also the cause of a long startup time of O.
In the short term even if the risk of beginners with OpenCPN rejected because the software would crash occurred because of gpx file too big, you might be banning their use by limiting the size of gpx files.
B.R. Gilletarom.

[Hakan]

Originally Posted by bdbcat

Hakan....
Hmmm....thinking
Thanks
Dave

Please do. I'll for sure trust whatever comes out. If not the AIS filter is of course the method.
But I thought for while that the priorities duty was to take care of this situation?

Håkan

[cagney]

"Export all visible..."

This button is very strict with the "visible" part.
It does not export all possible parts of a layer, only the parts visible in OpenCPN.
For example, in a layer consisting of a number of marks using the extended features to link each mark to a picture, only the marks, not the pictures will be exported. The end result is that the exported gpx file will not work, unless the pictures are copied manually, and all the links in the gpx file are changed.
While not a big problem, it needs to be spelled out in any documentation, to avoid user confusion. This, of course, will only help those who bother to RTFM.

Thomas