Please Help: Magnetic Course Display in OpenCPN

[Icnoships]

if M = selected check if var is available in NMEA date stream else if wmm plugin is installed / enabled else course = show T
you get my drift.

Mo

[bcn]

Mo,

if the sailor decides that the presentation of bearings shall be M then he has to provide a deviation, either via the WMM-pi, a sensor that provides Magnetic Deviation or entering it manually.
If the actual manual deviation (as entered or forgotten to enter) = 0 then the bearing is still NNN M (even if it happens to be NNN T as well).

In my opinion the program should not change the presentation selected by the user. And it should not suppose that a 0 in the manual entry for deviation implies to switch to T

Hubert

[Icnoships]

bcn
Not sure which end of the stick you have hold of here but WMM_PI does not provide any kind of deviation info, neither does any sensor normally connected to a yachts NMEA network & i think Dave has made it clear he does not intend (at this point) to add a table to allow manual entry of deviation for any particular vessel which would introduce another dimension ....(C) which we are not discussing here.
What i am saying about checking if a var. variable exists is as a safety measure, we have 11.5 degs of variation here and if my var. providing GPS fails and WMM is not enabled i want to know i am looking at T

Mo

[houlejm]

Originally Posted by bdbcat

Folks...

One modification to my proposal:

If a user has a GPS receiver that reports Variation as part of RMC sentence, that value will override the USER_Var. And the WMM PlugIn will be ignored in this case.

Thanks
Dave

Dave

I would use the variation from the WMM PlugIn rather than that from my old GPS. At my position there is 1 degree difference.

I do all my navigation in True, but my autopilot needs to know the variation, which it gets via RMC, actually the RMC of the GPS.

I would like ECRMC sent to the GPS use the variation from WMM instead. If I do not like it, I disable the PlugIn.

Anyway, it is not that bad.

Thanks

Jean-Marie

[bcn]

Originally Posted by Icnoships

bcn
Not sure which end of the stick you have hold of here but WMM_PI does not provide any kind of deviation info, neither does any sensor normally connected to a yachts NMEA network & i think Dave has made it clear he does not intend (at this point) to add a table to allow manual entry of deviation for any particular vessel which would introduce another dimension ....(C) which we are not discussing here.
What i am saying about checking if a var. variable exists is as a safety measure, we have 11.5 degs of variation here and if my var. providing GPS fails and WMM is not enabled i want to know i am looking at T

Mo

Mo, sorry for creating misunderstandings: should read variation instead of deviation of course.

But again: how should the program know in absence of data from a data stream that the value entered as manual variation ("0" for instance) should be ignored?

I can only imagine that a time-out can be checked and then an according message is shown ("No online source for variation. Variation should be entered and updated manually. Or change to T").

Out of curiousity: is there a scenario where you want to use M and the WMM-pi is not running?

[Tugwit]

Originally Posted by bdbcat

Wow...

I knew this one would not be as simple as adding T+V=M.
Thanks for all the feedback. As Pavel notes, my issue is philosophical rather than practical. COG(M) still bothers me, especially for AIS targets.

Anyway, here is my current proposal.

1. There will be a user specified variation entry field (USER_Var). It will be a constant for current instance of OCPN.
2. If user adds the WMM PlugIn, then the variation will be automatically calculated based on own-ship position. This value will override the USER_Var.
3. COG displayed on the bottom status line will be COG(M) (Much as this pains me...)
4. Bearings and Courses in the Route Properties dialog, route leg rollovers, and Active Route console will be (M), corrected for variation.
5. AIS target reports will show target COG(M). sigh....
6. OCPN knows nothing about deviation. If you have a steel boat, I guess you had better learn a little math

After I test this stuff locally, I shall never ever use it. But I hope some will find it improves their OpenCPN experience.

btw, I'm sure all realize that if you have your GPS receiver set to send Magnetic info, you will want to revert to True output, and depend on OCPN to do the math.

Ready for the next round?
Dave

While this thread seems to be principally concerned with the presentation/display of Magnetic bearings (courses, etc.), I would like to add a request to enable OpenCPN to output the autopilot control sentence, APB, with Magnetic Bearings instead of True Bearings (as a user-selectable option).

This would apply to field 8: Bearing Origin to Destination, field 11: Bearing Present Pos to Dest, and field 13: Heading to Steer. Following each of these fields is a field with value {M,T} which specifies if the bearing is Magnetic or True.

I have been unable to get my Simrad TP32 autopilot to accept 0183 output from OCPN and enter "NAV mode" to follow a route. I have succeeded, however, using PolarView/PolarCOM. The only significant difference in output of the two products is the use of True bearings in OCPN APB and the use of Magnetic bearings in PolarCOM.

Note that the format of the RMB and RMC sentence requires the use of True bearings.

Similar issues have been reported in other OCPN support threads with other chartplotter software and other autopilots. I seem to recall that others have reported success with using Coastal Explorer and Nobletec with their autopilots while having trouble with OCPN . And another user reports a similar theory that the Raymarine X-10 autopilot seems to require magnetic bearings (in APB, presumably).

Simrad Technical Support (USA) has been singularly unhelpful to confirm this theory (that the AP requires magnetic bearings in APB), but based on my testing that seems the only explanation....