NMEA 2000 quandry

[colemj]

OCPN does not output NMEA2000 PGN's, so I don't see how a direct connection will work.

We have both Actisense NGW-1 and Maretron USB100 0183-2000 gateways.

Both work fine with our Simrad AC42 AP using Coastal Explorer. Neither works with OCPN.

Using OCPN, the AP recognizes the Nav data source (OCPN) and our Tritons show all of the navigation data just fine, but the AP claims that nav data are missing.

Mark

[rgleason]

Maybe Hakan's approach using Simrad AP will give you some ideas.
http://www.cruisersforum.com/forums/...ml#post1349480

[Tugwit]

Originally Posted by colemj

OCPN does not output NMEA2000 PGN's, so I don't see how a direct connection will work.

We have both Actisense NGW-1 and Maretron USB100 0183-2000 gateways.

Both work fine with our Simrad AC42 AP using Coastal Explorer. Neither works with OCPN.

Using OCPN, the AP recognizes the Nav data source (OCPN) and our Tritons show all of the navigation data just fine, but the AP claims that nav data are missing.

Mark

Thanks, Mark, for your report.

You are right, OCPN only outputs 0183 sentences. I also have an NGW-1-ISO and supply the OCPN output (sending APB and RMB as a NMEA 0183 "talker") to both the AP and the NGW (two "listeners"). The NGW then translates APB and RMB to the NMEA 2000 PGN 129283—XTE and 129284--Nav Data.

I can see these PGN appear on the N2k network when I activate a route in OCPN--and they disappear when the route is deactivated. Moreover, these PGN cause my Raymarine ST70 to display "bearing to waypoint" and "distance to waypoint"--since the ST70 is only connected by N2K, it must be getting this data from these PGN. This data display, too, disappears when the route is deactivated.

Now my AP (Simrad TP32) can connect to both N2K and 0183 data sources--and I have mine connected both ways. In my last post, I speculated that the AP might work with PolarCOM even if the 0183 data source were disconnected--i.e. using only N2K data (the two PGN above) to follow a route.

I tested that today and, amazingly enough, it DOES work.

As reported earlier, PolarCOM ouputs APB using MAGnetic bearings; as a result the NGW outputs two 129284 PGN nearly simultaneously--one with True bearings and one with Magnetic. (I don't know why the NGW firmware does this, but I'm not complaining!). OCPN only causes one PGN with True bearings to be output.

So this provides additional evidence to support the theory that the AP (TP32) requires bearings in Magnetic and refuses to operate ("nav data missing"?) when provided bearings only in True. This seems to be true with some other autopilots, as well.

I also tried the "disconnected 0183 input" mode with OCPN. No Joy--the AP refuses to work.

The good news is that, using PolarView and PolarCOM I can now run the AP in purely N2K mode (no connection to 0183). That is certainly simpler and more robust. This may also apply, perhaps, to the use of Coastal Explorer, Nobletec, and other programs that I suspect output bearings in Magnetic (or both True and Magnetic).

Meanwhile, I'll open a Feature Request, as suggested above, for a future version of OCPN to offer the option to output Magnetic Bearings in the APB sentence. Probably a more immediately feasible option than to output N2K PGNs!!

[DotDun]

Originally Posted by Tugwit

Thanks, Mark, for your report.

You are right, OCPN only outputs 0183 sentences. I also have an NGW-1-ISO and supply the OCPN output (sending APB and RMB as a NMEA 0183 "talker") to both the AP and the NGW (two "listeners"). The NGW then translates APB and RMB to the NMEA 2000 PGN 129283—XTE and 129284--Nav Data.

I can see these PGN appear on the N2k network when I activate a route in OCPN--and they disappear when the route is deactivated. Moreover, these PGN cause my Raymarine ST70 to display "bearing to waypoint" and "distance to waypoint"--since the ST70 is only connected by N2K, it must be getting this data from these PGN. This data display, too, disappears when the route is deactivated.

Now my AP (Simrad TP32) can connect to both N2K and 0183 data sources--and I have mine connected both ways. In my last post, I speculated that the AP might work with PolarCOM even if the 0183 data source were disconnected--i.e. using only N2K data (the two PGN above) to follow a route.

I tested that today and, amazingly enough, it DOES work.

As reported earlier, PolarCOM ouputs APB using MAGnetic bearings; as a result the NGW outputs two 129284 PGN nearly simultaneously--one with True bearings and one with Magnetic. (I don't know why the NGW firmware does this, but I'm not complaining!). OCPN only causes one PGN with True bearings to be output.

So this provides additional evidence to support the theory that the AP (TP32) requires bearings in Magnetic and refuses to operate ("nav data missing"?) when provided bearings only in True. This seems to be true with some other autopilots, as well.

I also tried the "disconnected 0183 input" mode with OCPN. No Joy--the AP refuses to work.

The good news is that, using PolarView and PolarCOM I can now run the AP in purely N2K mode (no connection to 0183). That is certainly simpler and more robust. This may also apply, perhaps, to the use of Coastal Explorer, Nobletec, and other programs that I suspect output bearings in Magnetic (or both True and Magnetic).

Meanwhile, I'll open a Feature Request, as suggested above, for a future version of OCPN to offer the option to output Magnetic Bearings in the APB sentence. Probably a more immediately feasible option than to output N2K PGNs!!

Good Job! I surmised that a magnetic BTW would work across the NGW-1 and Colemj and you proved it. So the issue with OCPN is the lack of magnetic BTW as the NGW-1 is operating as expected.

[bdbcat]

Folks...

Interesting discussion.

AFAIK, only Simrad refuses to extract the Variation from RMC, and use it to internally calculate the required Magnetic bearing from the True bearing provided by OpenCPN's APB sentence.

Too bad, but it does what it does, and Simrad got to the party first....

I wonder which (if any) other APs would be broken if we just simply switch APB to Magnetic exclusively? This would be an easy change, and eliminate one more infrequently used Options tick-box.

I'll check my Raytheon gear when I get a moment to spare.

Comments, anyone?

Dave

[DotDun]

Originally Posted by bdbcat

Folks...

Interesting discussion.

AFAIK, only Simrad refuses to extract the Variation from RMC, and use it to internally calculate the required Magnetic bearing from the True bearing provided by OpenCPN's APB sentence.

Too bad, but it does what it does, and Simrad got to the party first....

I wonder which (if any) other APs would be broken if we just simply switch APB to Magnetic exclusively? This would be an easy change, and eliminate one more infrequently used Options tick-box.

I'll check my Raytheon gear when I get a moment to spare.

Comments, anyone?

Dave

The RM X-10 won't accept true BTW on N2k even though magnetic variation is present on the N2k network. I have not tested the 0183 side of the X-10.

This brings up a question of where does OCPN get variation? Does it calculate it internally?

The reason for asking is the trend for N2k is for magnetic variation to be supplied by the chart plotter as some N2k vendors (Simrad) have taken it out of the gps.

[bdbcat]

OPCN gets internal variation from one of several places, in increasing priority:

a. User entry (in upcoming new versions, currently in Pre-Beta)
b. WMM PlugIn
c. RMC, etc from connected GPS receiver.

So, I guess in future NMEA200-only systems, the preferred method will be to use the WMM PlugIn as an independent, always available source of variation. Presumably, this is the same algorithm/model that current NMEA0183 GPS receivers use to calculate the value emitted in RMC, if they actually do that.

Dave

[DotDun]

Originally Posted by bdbcat

OPCN gets internal variation from one of several places, in increasing priority:

a. User entry (in upcoming new versions, currently in Pre-Beta)
b. WMM PlugIn
c. RMC, etc from connected GPS receiver.

So, I guess in future NMEA200-only systems, the preferred method will be to use the WMM PlugIn as an independent, always available source of variation. Presumably, this is the same algorithm/model that current NMEA0183 GPS receivers use to calculate the value emitted in RMC, if they actually do that.

Dave

An issue with GPS supplied variation, it never updates, it's a snapshot in time. One would assume that a chartplotter/WMM Plugin would get software updates in a timely fashion such that variation would stay current.

[bdbcat]

DotDun....

Normally, the models cover a time span (5 years? Pavel, help me out here.)
In fact I just read something on Panbo about WMM cycles.

Panbo: The Marine Electronics Hub: A World Magnetic Model reminder, courtesy Maretron

Dave

[DotDun]

Originally Posted by bdbcat

DotDun....

Normally, the models cover a time span (5 years? Pavel, help me out here.)
In fact I just read something on Panbo about WMM cycles.

Panbo: The Marine Electronics Hub: A World Magnetic Model reminder, courtesy Maretron

Dave

Agree, but my point is a GPS may have a 10+ year service life, no chance to update the table/model.

[bdbcat]

DotDun...

No technical argument here.

As you might have noticed, I am passionate about adequate and accurate functionality "fresh out of the box", so that novice users don't get swamped by config options and mysterious PlugIn requirements. That's why I prefer the GPS supplied variation, if available.

Dave

[bcn]

Originally Posted by bdbcat

DotDun....

Normally, the models cover a time span (5 years? Pavel, help me out here.)
In fact I just read something on Panbo about WMM cycles.

Panbo: The Marine Electronics Hub: A World Magnetic Model reminder, courtesy Maretron

Dave

From the NOAA site:
The model is produced at 5-year intervals, with the current model expiring on December 31, 2014.

World Magnetic Model - Home Page

[rgleason]

This thread has worked its way through lots of terrritory: Autopilots, AP Equipment, Nmea2000, Nmea0183, Specific Nmea sentences, Magnetic, WMM , (a wobbly earth). The title should probably have "Autopilot" and "Magnetic" in it. ...watching this movie waiting for the outcome. Thanks to everyone who is contributing.

I hope there is working (but technically solid) Tracker Feature Request that comes out of this... Hakan has responded to Tugwit in a companion Autopilot thread

[colemj]

Originally Posted by Tugwit

The good news is that, using PolarView and PolarCOM I can now run the AP in purely N2K mode (no connection to 0183). That is certainly simpler and more robust. This may also apply, perhaps, to the use of Coastal Explorer, Nobletec, and other programs that I suspect output bearings in Magnetic (or both True and Magnetic).

I can confirm that both Coastal Explorer and Nobeltec work just fine that way through both the NGW1 and the Maretron gateways.

Mark

[Tugwit]

Originally Posted by bdbcat

Folks...

I wonder which (if any) other APs would be broken if we just simply switch APB to Magnetic exclusively? This would be an easy change, and eliminate one more infrequently used Options tick-box.

Comments, anyone?

Dave

To cut to the chase, I think that it would be wise to support both True and Magnetic bearings in the APB sentence—Magnetic for legacy and (some) current designs, True for more sophisticated current equipment and designs going forward.

In 1980, the original purpose of developing the 0180 (later 0183) protocol was to make LORAN and autopilots work together. I suspect that a preference for magnetic bearings may be a legacy of early autopilot hardware with an internal fluxgate compass for (magnetic) direction sensing and no ready access to data on local magnetic variation to make conversion to/from True.

Magnetic variation data requires an internal table (e.g. within a nav receiver) and a periodic table update capability to accommodate local changes in variation over time—a comparatively sophisticated support capability and not commercially practical in the days when you had to send a device (LORAN/GPS) to its manufacturer to flash its EEPROM. As a result, I suspect that older integrated AP systems principally relied on magnetic bearings in the 0183 sentences.

Newer GPS receivers like my Maretron (NMEA 2000) GPS100 have a WMM built in and therefore can output accurate local magnetic variation. With Maretron’s N2KAnalyzer software (and the Internet), I download and apply routine firmware updates which update the internal WMM tables (and other microcode).

This is how Maretron, at least, addresses DotDun's valid point regarding the useful lifetime of products we purchase. But firmware updates tend to be an area where proprietary methods are the rule--and not all manufacturers make it as easy as Maretron.

Contemporary chartplotters may also contain internal variation tables which can be readily updated—like the OCPN WMM plugin.

Consequently, modern AP systems might reasonably be designed to accept (perhaps even prefer) True bearings. Why my Simrad TP32 doesn’t is a mystery to me; I can only guess that it uses legacy assumptions and/or microcode, despite the fact that the device has evolved to support SimNet (NMEA 2000)—at least minimally.