In my case, all my instrument data is on my NMEA 2000 bus (N2K), so this had a number of significant implications:
1) All interfacing is via NMEA 0183, not NMEA2000: N2K is not an allowed interface for IMO certified devices. Maybe someday it will be, but not currently. And based on my experience with N2K, I know why. Up until now, all the navigation data on my boat has been on N2K, so these new devices meant the addition of 0183, and some degree of conversion to get my N2K instrument data over to these 0183-only devices. So, short of changing out all my instruments to be 0183, the use of N2K to 0183 data converts was the obvious solution, and is the main subject of this article.
2) True Heading in the form of HDT: These IMO devices have another interesting requirement. Both require that you feed it ship's heading info, and they both require that you provide True Heading, not Magnetic Heading, and they require it in the form of the 0183 HDT sentence.
3) Fast Heading (10hz or more): Autopilots and radars require a fast heading source to perform well. 10hz is really the minimum, but some products can accept up to 40hz. Without fast heading, radar overlay is imprecise, and the radar's ARPA function won't work well. And without fast heading, your autopilot will not steer the boat as well.
4) NMEA 0183 running at 38,400 baud: The fast heading rate described above is important, but the increased data rate can become a problem on 0183, overloading its normal 4800 baud data speed. The HDT sentence alone at 10hz will consume about half of an 0183 channel capacity, leaving room for perhaps one other sentence. And if you want to provide HDT at 20hz or 40hz, it will overload the channel. As a result, it's preferable to run 0183nchannels that carry any form of fast data (heading, rate of turn, position) at 38,400 baud rather than 4800 baud. In fact, the FAR-2117 requires that you run at that speed when operating in IMO mode. In addition to the fast heading, AIS data is guaranteed to overload a 4800 baud channel, so all 0183 AIS data is always run at 38,400 baud.
5) Ability to select data sources: I have equipped my boat with a number of redundant components where I feel the device is essential to safe travel. As a result, I have a satellite compass/GPS that provides high precision heading and position data. It is my primary heading sensor and my primary GPS. As backup, I have a conventional GPS sensor and a magnetic rate compass. If any part of the sat compass/gps fails, I can keep running with the backup device.
Interfacing the radars and AIS requires more data than just the items above, but it turned out to be the hardest part of the puzzle.
In my efforts to put together something that worked as desired, I tried 5 different N2k to 0183 converters. These were:
AMEC NK-80
AMEC NK-80 |
Simrad AT10 & AT10HD
Simrad AT10 and AT10HD |
Furuno IF-NMEA2K2
Furuno IF-NMEA2K2 |
Actisense NGW
Actisense NGW |
The only other N2k to 0183 convert that I know of on the market is the Furuno IF-NMEASC which is designed to work in conjunction with their SC-30 sat compass. It has quite a few capabilities, but is large and significantly more expensive that all the others, so I did not pursue it very far.
Here are the challenges that I ran into:
Source Selection
None of the converters have controllable N2K data source selection. So with two GPS sources on the N2K bus, there is no way to tell any of the converters to use the Sat Compass instead of the backup GPS, and no way to force a switch over to the backup. The converters will all pick a source on their own and you have no control over it. And it's up to them to switch to a backup source if the primary fails, including whether they switch over at all. Only Actisensse documents that they select the highest priority (lowest node address) N2K source, so at least you know how it will behave. For everything else you just need to test and see how it works, make sure it does what you want, and hope it continues to do so consistently. Through experimentation, I confirmed that the Furuno converter works the same way as the NGW.
The NK80 doesn't do source selection at all, but rather translates everything on the N2K bus regardless of who it comes from, and sends it to the 0183 side. At first I really liked this device until I discovered what it was doing, or not doing in this case. This is extremely broken and creates all sorts of crazy problem if you have multiple sources of data on the N2K side. For example, say you have two heading sensors. They will never read exactly the same value, and could easily differ by a couple of degrees. The NK80 will generate 0183 heading sentences for both sensors as the N2K data comes in, creating 0183 sentences that reflect one sensor's value, then the other, then back again, etc. And device listening to the data on 0183 will think your boat is twisting back and forth when it isn't. Just imagine how your auto pilot might respond to this. The same is true with GPS data, and everything else. And, not only does it produce seemingly erratic data on the 0183 side, but it generates double the traffic for every pair of devices that you have. Once I figured this out, the NK80 went from the top of my list to off the list, and I returned it for a refund.
HDT at 10hz, 38,400 baud
The Simrad AT10 only operates at 4800 baud, and only transmits heading at 1 hz, so it was off the list.
The Simrad AT10HD is specifically designed for fast heading, so will produce data at 10hz. But the only data is produces is heading - nothing else. This is partly because it also only operates at 4800 baud so don't have the bandwidth to send anything else. I need 38,400 baud, so this device was out too.
The Actisense NGW is attractive because you have some control over what data it translates and what data it doesn't. So rather than blasting everything over to 0183, you can filter out and only send what you want. It can also operate at 38,400 baud, so seemed pretty interesting. But what I discovered is that it will only send heading at 1 hz, and can't do it at 10hz. That was a killer. Also, it won't send HDT, only other forms of heading sentences. That was a second killer.
That left me with a single device - the Furuno IF-NMEA2K2. It supports HDT, does so at 10hz, and can operate at 38,400 baud. You can't control or filter which data gets sent, but it is the one and only converter that meets the basic needs.
True Heading
On N2K vessel heading info is carried in PGN 127250, Vessel Heading. It includes the heading reading and a flag that tells you whether it's magnetic or true. It also optionally includes the current magnetic variation.
A sat compass or a gyro compass outputs true heading, so when sent on N2K this would be indicated in the PGN. All the 0183 converters that are able to product HDT (regardless of speed) will only do so if they receive a true heading in the Vessel Heading PGN. If they receive a magnetic heading, even if it includes variation information, they all produce HDG. I was told by one NMEA committee member that it's considered bad form to ever take one form of data, convert it, and re-transmit as another form. I suppose it makes sense to preserve the source and accuracy of the original data. Apparently it's fine for a display device to combine data when presenting, so when you switch your plotter heading between true and magnetic heading, it's just the presentation than is changing. Or when you display ground wind vs apparent wind, you are just changing the presentation. The raw data on the bus is still represented faithfully in its original form.
The upshot of this is that the converter will only generate HDT using my Sat Compass which outputs true heading. It will not product HDT from my rate compass since it reports magnetic heading. And none of the converters will combine magnetic heading and variation to create HDT, even though technically they could. This left me with no way to use a rate compass as a backup heading device.
True Heading (HDT) from a rate compass?
To me it's essential to have a backup heading source and to be able to switch to it easily. And it wasn't looking like any N2K rate compass would work. And I also wasn't about to buy a second sat compass. So I started researching rate compasses that also have 0183 interfaces and I found something interesting. The Furuno PG500R is 0183-only, and if you feed it GPS info that includes Variation data, it will put out HDT. And I also found the Maretron SSC200 which is a bit of a hydrid. It has an N2K interface, and if there is a source of Variations on N2K as presented in PGN 127258 Magnetic Variation, then the SSC200 can be configured to output HDT on its 0183 port. Since all my GPS data is on N2K, the SSC200 was a perfect fit. No matter which GPS was in use, Variation would be present on the N2K bus, and the SSC200 would be my second source of HDT. And it can run at 38,400 baud. Perfect!
As a little aside, there was some debate about True vs Magnetic Heading in the comments section after this article on Panbo, and they continued in the comments for this article here on MVTanglewood.com. My comments there were a direct result of my experience as reported in this article, and I still think what I said about True Heading on N2K is correct; The only N2K device I've found that will transmit True Heading in the Vessel Heading PGN is a Sat Compass. All forms of magnetic compasses that I have seen and in all the literature that I can find report Magnetic Heading, not True Heading. Many of those devices also include a GPS (like the Airmar 200WX mentioned by Ben Ellison in one of the comments, as well as the GH2183) or can be fed GPS data (like the SSC200) and will consequently also include Variation is the Vessel Heading PGN thereby allowing a recipient to calculate True Heading. But the heading value itself is Magnetic. As a result, none of the 0183 converter will generate HDT from that data. With no HDT, you can't satisfy the data feed requirements of a Class A AIS device. You can get HDT from various 0183 sources, but the only way to get it from N2K via a converter is from a sat compass. But..... if anyone has an example to the contrary, by all means speak up.
Controlling Data Source Selection
At this point I had all the requisite data, but unlike N2K, you can't just connect up one port for all the data and call it a day. The radars and AIS have restrictions on which data can be paced on which ports. Heading is generally segregated out on a dedicated port. Then another port or two are available for other data like GPS, Nav data, etc. Then another for AIS.
Where this really comes into play is with data source selection for heading and GPS.
For heading, the sat compass heading info gets converted from N2K to 0183 by an IF-NMEA2K2. The Sat compass puts out true heading on N2K, so the converter produces HDT as desired. Because there is only one source for true heading on N2K, I don't have to worry about the converter selecting the wrong N2K source.
My second heading source originates as 0183 coming from the SSC200 compass. To control which of the two gets fed to the radars and AIS, I just used a good old fashion switch.
For GPS source selection, I relied on the automatic source selection in the IF-NMEA2K2. I confirmed that my sat compass always takes on a lower address (higher priority) than the standard GPS, so the converter always selects the sat compass, and fails over to the GPS if the sat compass fails. I have tested this by disconnected and reconnecting sensors to confirm everything switches as expected.
That's quite a twisting and winding road, isn't it? Here's a table that attempts to summarize the various converters. Hopefully it will make it easier to pick an appropriate on for whatever needs you have.
N2K Source selection | 38,400 Baud | HDT output | 10hz Heading | Selectable translation | AIS Support | ||
AMEC NK-80 | none (1) | yes | yes | yes (2) | yes | yes | |
Simrad AT10 | automatic | no | yes | no | no | no | |
Simrad AT10HD | automatic | no | yes | yes (3) | no (3) | no | |
Furuno IF-NMEA2K2 | automatic | yes | yes | yes | no | yes (4) | |
Actisense NGW | automatic | yes | no | no | yes | yes (4) | |
Notes: | |||||||
1) | Indiscriminately translates PGNs from all sources creating a mixture of data | ||||||
from all sources on 0183. | |||||||
2) | Actual data rate is the sum of the data from all sources, so two 10hz N2K heading | ||||||
sources will result in 20hz of mixed heading data on 0183 | |||||||
3) | AT10HD only translated heading and noting else. | ||||||
4) | Supports a specific AIS mode and only translates AIS data in that mode |
And if anyone is a real glutton for punishment, here's the schematic for Electronics 2.0. Note that it includes all the nav equipment, not just what's covered in this article. It's also a continuous work in progress, so might be slightly out of date in one area or another.
ShipModul has the miniplex-3 which claims to support converting HDG into HDT
ReplyDeletehttp://www.shipmodul.com/en/index.html
http://www.shipmodul.com/downloads/manuals/MiniPlex-3_EN.pdf
I think you are right, though I can't quite tell how it behaves with N2K in the mix. I remember looking at the Shipmodul products a while back and being impressed, but can't quite remember why I didn't pursue them further as in buying one. It might just be that I didn't have the appetite for taking on a new products at the time.
ReplyDeleteThe clearly say they convert between HDG and HDT given a source for variance. That's a piece of the problem, and perhaps the whole problem if you are running NMEA 0183 only.
But I can't really tell how it works with N2K in the mix. My specific case was magnetic heading on N2K (I can't remember the PGN off the top of my head), and converting that to HDT for an 0183 device that requires true heading. Perhaps the Shipmodul can convert the N2K PGN to HDG, then convert that to HDT? It's not clear whether it can convert sentences that it created as opposed to sentences that others have created. Any chance you have tried this?
I haven't tried one - the manual seems to indicate that everything from the n2k is converted to 0183 sentences before going into the filtering/routing engine.
ReplyDeleteConversions happen post filtering and get fed back into the filtering/routing engine.
I've learned lots reading your blog - any chance you are going to post about your dual autopilot setup?
I'm glad you find the blog helpful, and yes, I promise to write about the dual auto pilots. As usual I'm way behind and have a good half dozen technical articles in the backlog.
ReplyDelete