AIS over NMEA 2000, concept defended

... written for Panbo by Ben Ellison and posted on Nov 18, 2009

The screen shot above shows MaxSea TimeZero Explorer running on Gizmo this morning, much like I showed last week. In this case you can see how I'm cranking up the radar gain, a neat right click and mouse wheel maneuver, because I'm trying to see the ship coming down the Bay. Which was really asking too much of the superb DRS2D radome because there were so many large obstructions between Gizmo's slip and the Kristen Knutsen. What's really different about this screen is that the FA50 AIS data is finally getting to MaxSea TZ, which should have just happened given that the transponder, like the radar, is plugged into the same Ethernet switch as the MFD and the PC...

The response from Furuno tech support about my AIS problem was: "Sometimes we have a 'setting synchronization' problem between MaxSea TZ and the MFD. Try to go on the MFD and change the AIS filter value (in the Target Menu) from a small number (for example one mile) then back again to the current value (24NM)." Which is kind of a funky fix, even if "FYI, this problem will be corrected in the upcoming v1.8." Plus it took me quite a few filter value changes, and reboots, to get the AIS synchronization to work. But really I'm bringing the whole business up because it's especially ironic given that Furuno is taking the stand that Ethernet is better than NMEA 2000 for AIS. Furuno has made this argument directly to me, but it also came up in a Panbo comment this morning from a tech taking a Furuno training seminar in Maryland this week:

The Furuno product guys have brought up this thread and questioned the advantage of NMEA2000 AIS Data over direct NMEA0183 when their systems will automatically convert the AIS data and pass it over Ethernet at 100 Megabits/second vs. 250 Kilobits/second for NMEA2000. (According to them, the existing Ethernet network has 400 times more bandwidth and can be easily scaled to 4000 times higher in the future). They say that Raymarine has the same capability vs. soaking up a relatively large chunk of NMEA2000 Bandwidth with AIS data that is only needed by the main navigation displays?
They also say that it is much easier to push AIS data and all other navigation data to onboard PCs via Ethernet either wired or wirelessly instead of having to purchase individual NMEA2000 Gateway Hardware for each PC via USB.
My question is what is the advantage of NMEA2000 over NMEA0183 AIS Data Distribution considering AIS data only needs to go to a few select displays on the vessel for monitoring/Alarm purposes? Their point seems valid to me as a technician responsible for installing this stuff on a variety of vessels.

And here's my response, written purely in the spirit of constructive debate (I really like NN3D and MS TZ):

Well, I agree that AIS data is less ideal for NMEA 2000 than what's being passed around by many other sensors. It involves a lot more data and is potentially useful to fewer other devices. BUT...

* By Furuno's own estimate, AIS data might take up 10% of N2K bandwidth. Even if it's 20%, that seems quite affordable on most N2K networks I've experienced or can imagine.

* I've been working with a gentleman who's thinking of putting an MFD12 on his flying bridge with MaxSea TZ Explorer at his lower helm. He wants to know where he stands if the MFD fails. The answer is that if he reboots MS TZ with a Maretron USB100 attached, MS TZ will use most common NMEA 2000 data -- like GPS, depth, and wind -- that's on the yacht's network. I've tried this and it works fine, but AIS is not included unless there's also an 0183 AIS connection to the PC.

* The first NMEA-2000-to-PC Gateway (from Actisense) has been NMEA certified, and I think we'll eventually see PC programs that can directly read all sorts of N2K data, AIS included. The gentleman above might run any of those programs, but if he has a Furuno MFD he'll also need an 0183 AIS connection. (I installed one of those yesterday, for some Raymarine gear, and while it works ok, those dinky wires are looking more and more old fashioned, more and more the weakest link in a system.)

* The latest Navico and Garmin MFDs handle NMEA 2000 AIS data fine, except for a couple of fairly minor glitches that will be fixed soon I think (and, besides, are the fault of NMEA for being slow to write the PGNs). Raymarine plans to support N2K AIS. In other words, it's getting easier to switch out or add MFDs to a boat and have AIS be easy plug and play, not one-to-one 0183 or proprietary Ethernet.

* VHF radios that can understand AIS data, and hence make DSC calls to targets, are coming soon and will eventually do that via NMEA 2000, I think. The relationship between VHF radios, AIS, and MFDs has all sorts of potential features, as Garmin is showing, and N2K seems the right common cabling and protocol to make those happen between even multi brand devices.

* I don't think I'm the only one who'd warm to Furuno's AIS-over-Ethernet preference better if it was more open. I don't understand why, say, Coastal Explorer -- which can understand most Ethernet AIS streams -- is not allowed to see data coming from an FA50 over Ethernet. (I'm also learning that a NN3D Ethernet network won't seem to support a WiFi WAN connection, even though MSTZ can use it to fetch weather data. I haven't checked this out with Furuno, but it looks like I have to shut down the MFD and reboot the system for MSTZ to see the Wave WiFi unit that's on the switch.)

All of which is not to say that doing AIS over Ethernet is a bad thing. In fact, I was semi blown away to discover that the MFD12 interface to the FA50 is exactly the same as what I saw on a Web browser when I first tried the transponder last winter. It's a powerful interface that you'll not see on any other MFD/AIS setup and is probably not possible over NMEA 2000. It also strongly suggests that Furuno NavNet 3D has a Web browser built in, which is very interesting, but also a bit frustrating as it seems like it will never browse anything except other Furuno gear. Isn't it a bit schizophrenic to build an AIS transponder that can be monitored and controlled in great detail by any browser, but won't share the actual AIS data with any other brand over Ethernet?

At any rate, what I'm hoping is that Furuno will decide to also support N2K AIS on its MFDs and in MaxSea, so that users have maximum flexibility in their system designs. For the same reason, I hope they'll consider updating the FA50 so it outputs Ethernet AIS data in a known format. Did I argue these points effectively? Am I nuts?

Posted by Ben E on November 18, 2009 9:39 PM

Comments

Has anyone tried the reverse, i.e. using a NMEA2000 capable AIS transponder or receiver with a Furuno NavNet 3D system? I have two MFD12s and was thinking of getting a Garmin VHF300 AIS that transmits data over NMEA2000. I have seen the output from a Furuno FA-30 on a NavNet display over ethernet and it works very well, but I like the idea of avoiding another "box".

Posted by: Red Tail at November 19, 2009 6:12 AM | Reply

I'm not sure what you mean by "reverse" but no, your MFD 12s will not understand NMEA 2000 AIS information. I've tried it, and I've checked with Furuno about it. However, you could attach the NMEA 0183 output of the Garmin VHF300 to one MFD12 and the other MFD12 would get it over Ethernet.

Posted by: Ben E at November 19, 2009 7:00 AM | Reply

Browser in an MFD, that's a bit daring. Even with severe limitations, they have started down a very slippery slope!

What will be the solution to getting frequently updated security software into the MFD's to protect them from the software and content that browsers are able to load? Running in a virtual machine?

Posted by: Dan Corcoran (b393capt) at November 19, 2009 8:03 AM | Reply

Thanks, Ben. So you have tried non-Furuno AIS sources and the NavNet 3D hardware does display everything with an AIS data source over one of the NMEA 0183 ports at 38,400? Same as it would with an FA30 or FA50 on the network? That makes other hardware such as the Icom AIS receiver a comparable option. Perhaps Icom willstart selling the M604 with integrated AIS in the US soon.

Not much of a commitment to NMEA2000 on Furuno's part but as you note, the are taking the position that ethernet is a better way to communicate AIS data.

Posted by: Red Tail at November 19, 2009 8:38 AM | Reply

I haven't actually tried an NMEA 0183 connection to the MFD12, but am very confident that it works fine. Did try NMEA 0183 to MaxSea TZ PC with success. The latter is easier as most every AIS comes with a serial plug, and serial to USB adaptors now work.

Posted by: Ben E at November 19, 2009 8:58 AM | Reply

1) I believe the CanBus NMEA2000 standard comunications is very different than ethernet standard. The way the header and other parts of the packets are made up. I thought NMEA2000 is much more of a broadcast, while ethernet is a routed/switched packet with specilized tags and MAC / IP addressing through controlled switches. I guess what I am trying to say is that I think while theoretical NMEA2000 bandwidth is much smaller than ethernet, ethernet never seems to be used anywhere close to its full 10,100, or 1000 mbps, while I believe CANBUS can. I think there is also serious latetency differences as well.

2) Now Some thoughts on why SeaTalkHS and Furuno networks / networked devices are having a hard time working on open ethernet networks (like with a WaveWifi).

Public/Private routed ethernet/internet has a huge level of data "manipulation." Muliple protocols, routes, and tags are all read, used, and even modified by the different network devices. Take simple NAT (network address translation) where a router assigns multiple private IP addresses to a single public IP address. So what is the actual IP address of the device on your private network? With NAT it depends on what is asking and where it is (is it on your private network or is it coming in through your router. The best example I ever heard of this is: Every day you pick up your mail, it was all sent to your house, but the bills go to your desk, the movie to your DVD player, the book to your bookshelf, and maybe a letter to your kids. Everything came to your house, by you had to route it to the right places.)

Now lets compare that to the high priority data and network addresses required for real time navigation. From my reading of the manuals of both Furuno and Raymarine, evey ethernet network device is given static IPs. I don't believe there is DNS, WINS, etc. They even limit the devices on the network not to the standard 255 (the number required by a simple 255.255.255.0 subnet), but typically to around 8. This means it is an extremely simple ethernet network.

Yet now we ask the question, wouldn't it be great to add some cool intenet and other data features onto the Navigation network? Sure. But lets think of the problems.

First, those devices would have to support at least very basic ethernet/internet standards (TCP/IP protocol and all of its info[DNS,WINS,etc.]). Many modern PDA Cellphones do this, but I don't think it is simple.

Second, once you got ethernet standards, you have got to process it, and accept it on your network. Who cares about the email from Mom where there is 250,000 DWT Oil tanker in the fog ahead and the ethernet radar image needs to wait for the 4 attached photos to stream through. You could piority tag the Nav data, like VoIP phone calls, but now you are manipulating it, which is complex and can lead to problems.

Third, and this is what would scare me the most, is security. The more data I get from the internet. The more ports I open in my router, the bigger footprint I have to be attacked by a virus or trojan horse. I can just picture it, downloading Anti-Virus updates eveytime I want to go sailing for the weekend. Lets not even get started with 802.11x WIFI distributed navigation data and its security / interferance possibilities. Just picture your MFD data changing all because of some interference.

Ultimately for me, while I think the possibilities are cool, I think Furuno and Raymarine have it right, use the ethernet standard, because it is easy and cheap to by CAT cable and ethernet NICs and interface with a computer, but keep the nav data and network seperate from any ethernet/internet network. Use a well designed Windows computer with multiple NICs to translate between the two for required updates and other data downloads (wind/weather).

PS: In a marine industry that takes years to define a AIS NMEA2000 PGN ... I can only imagine how long it would take to support complex TCP/IP communications, and security related concerns. Let them focus on broadband radar, ultrsonic wind, reliable tank monitoring, and lighter cheaper smaller batteries ... the leave the internet interface to the millions of choices of products from Cell phones, to laptops, to desktops, and to TVs.

PPS: As for Garmin talking to Raymarine talking to Furuno via ethernet ... NMEA2000 seems the rightway to do it.

Posted by: Matt S. at November 19, 2009 9:41 AM | Reply

The existence of this discussion shows the total ineffectiveness of NMEA. What a sorry state the marine electronics industry is in that when wired 1Gb ethernet is a commodity and 54Mb wireless is available on everything from camera memory cards to telephones, the standard for connectivity on a boat is a 38Kb point to point serial connection.

NMEA should be disbanded; whomever is funding it is wasting their money.

One of these days, one of these manufacturers will realize that their proprietary protocols and cabling schemes are NOT a competitive advantage, but a barrier to adoption. They'll open up their protocol and create the de facto industry standard, making it clear that they are the industry leader.

How many times do we have to relive the Sony beta VCR or IBM token ring story? Manufacturers, look at the history, VHS and ethernet won because they were open. It reduced manufacturing cost, lowered the number of SKUs in the channel, and accelerated consumer adoption. Can anyone imagine a world where Dell computers use one networking standard and HP computers use another? This is insanity.

Posted by: Russ at November 19, 2009 9:55 AM | Reply

It's quite ok with me if they keep all their proprietary physical cabling (some good innovation going on there folks) and the MFD remaining closed like an appliance is really ok also, but hey ... the data is ours, don't keep us from it !!

I have come to enjoy that my MFD needs no weekly security patches, etc. like my PC's at home and work, I prefer that the PC and operating system is hidden from me on my boat's MFD and is what us IT people call a specialized "appliance."

I do have a dedicated laptop on board, and have found it an effective way to configure NMEA-2000 devices, use it at home and on the water to run cartography to do voyage planning, and other tasks at the dock.

Rather than see openness on the MFD itself (browsers, open source, etc.), I would rather keep that closed like an applicance and have the protocols open so my laptop (or better yet my cell/PDA) is able to download innovative applications that can easily interoperate with my transducers and MFD.

NMEA could be more effective we will all agree in meeting consumer needs, some things that come to the top of my mind for NMEA-2000:
- Work out a standard for how any connected transducer can be a mini web server (like our routers and printers at home) so we can configure them with a browser from our PC's.
- Work out a PGN that would enable an XML to be encapsulated so additional data types can be defined and used on NMEA-2000 without a multi year committee effort.
- For MFD and instrument displays, allow them to be configured by the user to map XML data to data boxes and visual representations on our displays, as well as alarm on target values.
- Work out a standard for a protocol bridge that would allow NMEA-2000 / ethernet / bluetooth / wi-fi to come together so that cell/PDA applications and PC applications on our boat can obtain data from boats transducers and pass processed information back to our displays (e.g. sailboat target boat speed, list of AIS targets that have an MMSI that match a contact in our cell phone address book, etc.)
- For the above, put out free client code for use on cell/PDA to marshal/unmarshal (sorry for the IT terms) data to/from XML to PGN's to ease the creation of software for iphones, etc. to use boat data.

As I wrote earlier, it's quite ok with me if they keep all their proprietary physical cabling and the MFD remains closed, but hey ... the data is ours, don't keep us from it !!

Posted by: Dan Corcoran (b393capt) at November 19, 2009 10:45 AM | Reply

What I would really like to see is a NMEA 2000 Gateway that instead of connecting directly to the PC via USB, just connects to Ethernet and repeats all the NMEA data on to the network. That way, if you don't want to run your main PC, your iPhone and other devices can still access the data.

Posted by: kenyon at November 19, 2009 12:03 PM | Reply

I can confirm that the Furuno MFD-8 works just fine with AIS data from the NMEA-0183 port. Thats how I've got my ACR Class-B transponder connected.

Posted by: Paul at November 19, 2009 12:19 PM | Reply

As a computer professional who worked on data interoperability standards, it has been frustrating to watch this process. TCP/IP is for good or ill is the standard of the computer world. All development energy in the big industries goes there, and by insisting on walking a different path NMEA has ensured that marine technology will lag behind the rest of the electronics industry. You are unlikely to see a cheap wireless CANbus system any time soon, nor is it likely that you will see significant speed improvements from that technology. The boating industry is too small to drive the improvements that would be needed to make NMEA 2000 as capable as existing ethernet systems.

Any Computer Science grad nowdays could write a two-page XML specification that would completely specify all of the data currently supported by NMEA 2000. Make it five pages and they could add radar and chart information.

I worked for a long time for a company that insisted on reinventing the wheel, so I am not surprised by the way things have turned out -- just disappointed.

However the decision was made and we have to live with it. For AIS data to take up %10 of the bandwidth of the network is not acceptable (and is a surprising claim, frankly) given that the product is not released yet. Who knows what bandwidth will be required later? However with clever programming you should be able to reduce it by a lot if you acknowledge that you have a problem and tackle it head-on.

Posted by: George at November 19, 2009 3:18 PM | Reply

I see no future for nmea2K , its technically obsolete, about 8 years to late and not capable of really being scaled up. Was at a connectfest thing run by NMEA at METS. very relucant to discuss 2K problems.

Posted by: Dave at November 19, 2009 4:10 PM | Reply

George & Dave, have you actually used it?

There really is no wired alternative to NMEA-2000 except to stay stuck in the past and continuing to use NMEA-0183. Install even a little NMEA-2000 on your boat, and your not likely to object to more as you start to view your 0183 wiring as unreliable.

No future, I disagree.

One thing almost insuring a future for nmea2k if nothing else, is that the wireless protocols under development make it hardly likely there will be demand in the near term to exclusively adopt an appropriate form of wired ethernet on boats, and as long as we need to run +12v to components, the adoption of exclusively wireless protocols into boats will be slow as well.

Posted by: Dan Corcoran (b393capt) at November 19, 2009 4:55 PM | Reply

I suspect that most Panbots would agree that in the abstract N2K is crap:

- it's bandwidth-limited
- it's encoded for compactness so writing apps is a pain
- it's proprietary
- NMEA is exceptionally slow to extend the protocol for new data types

But it's also here to stay, and certainly offers major improvements over 0183.

The real question is: where do we go from here? Furuno has demonstrated that twisted pair, Ethernet, and TCP/IP are perfectly viable cabling, link and transport layers for use in the marine environment. The fact that Furuno encrypt the data they send over that twisted pair is a shame, but seems to be par for the course in an industry which is apparently the last bastion of 70s-style attitudes about software and hardware development.

So I disagree with Dan about wired ethernet not being viable. (I also disagree that wireless is not viable due to power requirements, given the number of battery-powered handheld devices that incorporate wi-fi. Interference concerns are a different story.)

Indeed, an N2K-like (but extensible) data stream in a human readable format (JSON or XML, if you must) running over IP -- call it marine-data-over-IP or MDOIP -- would be well suited for marine use. I suspect that such an approach would first be used in PC- and wireless device-based monitoring and logging apps, and extend to systems control in time. The Actisense NGT-1 and it's attendant SDK offer a cheap bridge between an MDOIP environment and N2K. (Does Maretron have a USB100 SDK?)

Would MDOIP ever make it into sensors, comms, and MFD hardware -- the expensive stuff? Certainly ethernet and wifi chipsets are and will always be cheaper and faster than CANBus because of their ubiquity in consumer and data center equipment. And writing an application that supports human-readable data is easier than decoding NMEA strings. But if you already have the N2K stack built, reusing it on new hardware is pretty cheap. So maybe the question is whether MDOIP would attract startups who demand the same rapid development that has brought down costs in web and handheld device applications -- rapid development that's impossible today. If these startups can make inroads on the hardware side perhaps N2K will wither (or perhaps NMEA will open it up in an attempt to co-opt the changing market).

I like to think about how an effort to create a MDOIP framework like this might get started. An ad-hoc group of folks who assemble to clean room reverse-engineering N2K, perhaps, with code released under an open source license? That doesn't seem too ambitious.

/afb

Posted by: Adam at November 19, 2009 5:48 PM | Reply

Good grief, I go off for the day and the Ethernet crazies come out! When Russ, George, and Dave can explain why diesel engine manufacturers and many other developers of mission critical machinery chose CanBus -- not Ethernet! -- for sensor and control networks, we might have something to talk about. And, Russ, how can you say that "the standard for connectivity on a boat is a 38Kb point to point serial connection" (i.e. high speed NMEA 0183)?

NMEA 2000, which is CanBus, is finally, but now rapidly, becoming the standard for many marine sensors and the displays that use them. NMEA could definitely move the standard along faster, but in fact it's working quite well for many common marine network functions, and the only vessel I know of that's had trouble with the bandwith ceiling is a megayacht loaded with N2K systems. And they made it work. NMEA 2000 is going to be around, and getting better, for a long time.

Ethernet has also become a data transmission standard on boats, for high bandwidth needs, but the data it's carrying is obviously not standarized across multiple manufactures. And maybe it shouldn't be open to the Internet, as Dan and Matt argue well, except via some sort of gateway PC (as Furuno envisions, I think).

But my question is whether or not Furuno is on the right track if it does not support AIS over NMEA 2000, as all the other major manufacturers are doing, or planning on doing? Mind you, it's the only manufacturer to make a transponder that outputs AIS via Ethernet, but the data is closed. I'm sure Furuno will squash the little bug I experienced, and its Ethernet AIS will work great with NN3D and MS TZ. But should the company also support N2K AIS so its customers have more choice about their own setup?

Posted by: Ben E at November 19, 2009 5:50 PM | Reply

Ha ha. No real Ethernet Crazy would do this, but I'll happily acknowledge one real benefit that CANBus has over Ethernet: priority. Devices attached to the bus have a signaling hierarchy; if there is contention for bandwidth, the lowest-priority device will pause until higher priority devices have finished sending their messages. That's a very good thing when your car's acceleration sensor needs to get a message to the airbag deployment circuit at the same time you're fiddling with the A/C.

But I don't know that priority carries as much weight on a trawler, especially given the kind of data we're talking about (no helm instructions, for example). And I don't even know if N2K implements priority; is your depth sounder actually a higher priority on the bus than your black water tank monitor? Finally, the benefits of priority shrink when, as in the case of these IP networks, you have a lot of bandwidth to play with.

As to your question, Ben, I surmise that from Furuno's point of view the answer depends on how their devices are typically purchased. If buyers or installers tend to stick to sensors and peripherals made by the same manufacturer as a boat's MFD and radar, N2K compatibility should be a lower priority. If buyers are shopping for AIS boxes independently and choosing solely on features, it's hard to imagine how a non-N2K transponder could be market-competitive. I'm thinking that Furuno's marketing people aren't dumb, which suggests that the former case, whatever the issues with AIS eating up N2K bandwidth.

Posted by: Adam at November 19, 2009 7:48 PM | Reply

I hope that my next AIS device will have both NMEA2000 and 0183 outputs for maximum flexibility. In any case I will not buy an AIS device that outputs data in a form that cannot be used by other manufacturer's equipment or by my own software.

However (going into Ethernet crazy mode), I would certainly rather have all of my data on Ethernet. On Sunday, I did a proof of concept analog wind speed display on my iPhone with the data coming from the N2K output of my E-80. I have a long way to go to catch up with Kees, but my next step is to put all of the N2K data that my boat generates (mostly from the E-80 right now) and put it into a broadcast IP packet so that the iPhone and anything else on the network can grab the data and do whatever it wishes.

I also want to do "other things" with my AIS data, and this topic gave me the idea to broadcast the AIS data in a similar manner. A small Ethernet device near the E-80 can listen for the AIS packets and present them to the 0183 port.

I was going to try Google Protocol Buffers for the decoded sensor data, but will probably use JSON instead so that the data are more Javascript friendly for the iPhone. I'll keep the AIS data intact for easy replay into MFDs (and maybe broadcast a decoded version as well).

Jon

Posted by: JonM at November 19, 2009 7:51 PM | Reply

Adam, NMEA 2000 definitely includes priority messaging, as you can read below. And I believe it was designed to handle shift and throttle, though that's hardly been done yet.

http://www.can-cia.org/index.php?id=490

Posted by: Ben E at November 19, 2009 9:29 PM | Reply

My friend forwarded me the link to this site since we had spoken about this subject at the end of the Summer.

-Who ever said that the Furuno AIS over Ethernet Data is closed or encrypted in some way?

I am a Software Developer who has an older Furuno Navnet vx2 System

Posted by: Sam W.t at November 19, 2009 9:34 PM | Reply

Furuno says, Sam. "The details of the Ethernet output from the FA30/FA50/FA150 are not available. As far as I know, only the serial output is available to our competitors." I checked with them when I wrote this last winter:

https://www.panbo.com/archives/2008/12/furuno_fa-50_class_b_ais_first_impressions.html

I'm hearing now that there is a hack possible using Franson GPSGate, but I haven't tried it.

Please note that the Furuno AIS devices also have conventional NMEA 0183 outputs just like every other AIS receiver and transceiver.

Posted by: Ben E at November 19, 2009 10:25 PM | Reply

Good grief, the CANbus crazies are about!

Now mind you I�m not an Ethernet zealot either but it�s clear that there is more assumption than analysis going on here ;-)

The explicit argument is that the diesel engine manufactures and others know of some reason that CANbus is somehow critical to the performance of their engines and whatever. If you look at it they choose J1939 CANbus because it is a standard for the vehicular industry and that dealing with sensors and actuators is well engrained in the technology. Since N2K is essentially J1939 with different (max) 8 byte payloads it is all downhill for them. Does that make CANbus superior to Ethernet as a general marine network? Lets look at that.

CANbus is intended for the vehicular environment which must balance the demands of low cost and high integrity of data transfer. It meets the low cost objective by having components manufactured in the millions (a CANbus transceiver IC sells for $1.235 in thousand lot quantity at DigiKey). Of course that pales to the billions of Ethernet transceivers manufactured in a much more robustly competitive market but the cost delta isn�t a main reason to choose one over the other. J1939 was standardized many years ago, well before the concept of high data rate multi-media data sources were even thought of. It addressed the narrow objective of defensibly managing a vehicle under all circumstances. That seems like a good foundation for a marine network except that the Internet and all its implications came along afterwards.

Next CANbus is literally a bus, multi-drop at that, which is one of its most appealing attributes for marine use (to some at least). Arguably this is a real consideration and can�t be ignored. The maximum length of the N2K backbone was chosen at 200 meters, that choice limited the maximum bit rate to 250 kb/s since the CANbus arbitration protocol requires that all nodes see the same bit on the bus simultaneously. That may be a bit of overkill for my 15 meter sailboat but it is the N2K standard and is the limiting factor for the N2K the bit rate.

Well, then there is the issue of priority of packets and determinism that CANbus certainly addresses. That is one of the main attributes that NMEA points to on their website in addressing the choice of CANbus over Ethernet. The specter of shifting or throttle adjustments being covered up by e.g., radar data and causing something bad to happen comes to mind. That might happen if an Ethernet network was running at an equivalent speed and there was no prioritizing of packets and no acknowledgment of receipt and retransmission of lost packets (ARQ) by the throttle/shifter quadrant. But that�s unrealistic. Ethernet speeds (100 Mb/s, about 375 times N2K�s CANbus speeds) coupled with layer 2 switching and any reasonable ARQ protocol renders Ethernet at least as robust as CANbus in this application. In essence by substituting massive speed (low network occupancy, even with other streaming protocols extant) and a higher level protocol for CANbus� admirable built-for-purpose low level solution. At worst it�s a dead-heat on robustness.

There are interesting rabbit holes for us to go down regarding the robustness of cabling (insulation displacement connectors, e.g., RJ-45s may be long term more robust than N2K field installed connectors for example). Certainly an argument can be made that on large commercial ships the 100 meter limitation of Ethernet is an issue, but then who in his right mind would extend any mission-critical network backbone to 200 meters! Best to use real proven networking technology to deal with large spans. Then there is the issue that most sensors should be broadcast so any application on the network can use their data, which N2K effectively does, and what about the multi-cast nature of, say, radar, data? Life isn�t without challenges and choices have to be made at a point in time. Thus, NMEA�s choice of CANbus; but times change and it begins to look like they missed the wave of high-bandwidth ship-borne applications coming over the horizon.

So... do we just accept two parallel networks? Or do we adopt what the rest of the data industry from home networks to MetroEthernet enterprise networks have embraced? Maybe it depends on vendor preferences for closed and proprietary networks, eh?

Cheers,

Richard D. s/v RED

Posted by: RED at November 20, 2009 12:42 AM | Reply

Ben wrote: Russ, how can you say that "the standard for connectivity on a boat is a 38Kb point to point serial connection" (i.e. high speed NMEA 0183)?

I can say it because it is the standard TODAY. You wrote above that N2K is "rapidly becoming", that's a projection into the future and speculation about what might come to pass.

Much of this thread is about the fact that the FA-50 has a 183 interface, and a proprietary Ethernet interface, but not an N2K interface. If a state of the art device from a major marine supplier can blow off N2K, then it is definitely not "the standard for connectivity".

If you want to connect different vendors marine equipment, since N2K is "rapidly becoming", and there are no data standards for interchange with Ethernet, then TODAY the standard is NMEA 183. Quite a sorry state.

If NMEA was in charge of data networking we'd all be accessing the internet with dial up modems.

Posted by: Russ at November 20, 2009 7:44 AM | Reply

You were going along great for a while there, Richard! Of course we accept two parallel networks; we already have. That's exactly what's happening on most boats right now, and it makes sense. Boats have characteristics of large vehicles AND of homes and offices, so CanBus/N2K and Ethernet networks each have their place.

But let's please go back to the installer question that prompted this entry. And let's remember that AIS receivers were designed from the get go to output at 38.4K baud (HS NMEA 0183).

"Technician's" question was this: "what is the advantage of NMEA2000 over NMEA0183 AIS Data Distribution considering AIS data only needs to go to a few select displays on the vessel for monitoring/Alarm purposes?" And the Furuno argument was that running AIS via 0183 to an MFD that distributes it via Ethernet works fine. Which it does, as long as all the Ethernet devices are the same brand.

I tried to make an argument about why AIS works well over NMEA 2000. And I hardly even mentioned how much more robust the N2K connection is versus 0183, or how much easier it is to make. Nor did I mention how easily a Class B transponder can pick up heading info off an N2K backbone. I know more and more astute boaters who want to reduce 0183 connections and increase 2000 connections, and I think they're on the right track.

Posted by: Ben E at November 20, 2009 7:49 AM | Reply

Russ, HS 0183 is actually fairly rare, just AIS and some heading sensors. I have four different major brands MFD systems on Gizmo right now all sharing NMEA 2000 GPS, depth, wind, heading, air and water temps, go-to-waypoints and more (and one more I could add).

I also have six brands of instrument displays that I can plug right into the same backbone. 3 out of the 5 MFDs are sharing N2K AIS and DSC info now, and a 4th promises to soon. If I could get the electronic info out of my Volvo engine (I'm trying), it would appear to one degree or another on all 5 MFDs.

I can now get most of this data to numerous PC charting programs (albeit via translation, but that's about to change). These are not projections, these are facts. And, really, I've just gotten started; there are all sorts of system sensors I look forward to adding to Gizmo's N2K network, which has plenty of room for them. And have you noticed how all the small MFDs that go on outboards, and many outboards themselves, have adopted NMEA 2000?

PS Hard core marine electronics is simply not like consumer electronics, and I doubt it ever will be. Applying the expectations of the latter to the realities of the former will result in endless dissatisfaction.

Posted by: Ben E at November 20, 2009 8:12 AM | Reply

Adam wrote "So I disagree with Dan about wired ethernet not being viable. (I also disagree that wireless is not viable due to power requirements, given the number of battery-powered handheld devices that incorporate wi-fi. Interference concerns are a different story.)"

Viable? I believe the words I used are "exclusively adopt" and "slow", but not viable fits for 2009 I guess.

Wired ethernet: not viable to exclusively adopt because of a lack of ethernet marine transducers (speed, depth, wind, etc.), autopilot, etc. Probably not going to be demand since NMEA-2000 (combined data and power) is a much better fit given the tiny issue that even powered ethernet is not +12v, so seperate power is needed for each transducer.

Wireless: slow adoption because some of the benefit of wireless is negated when you need to run wire to power transducers, and I don't think people can get their minds around some critical controls ever being wirless, like between a throttle and an engine. Batteries are not the solution in many cases, although Tack Tick is clever with their solar powered approach.

Posted by: Dan Corcoran (b393capt) at November 20, 2009 8:59 AM | Reply

I interpret most fo the posts here as asking for ease of interoperability and access to the data being produced by the devices we've installed on our boats.

I'm not arguing a specific technology, many others make a more compelling case regarding technology. I'm arguing that the approaches taken by these companies is bad for their business; just like token ring, beta VCRs and SCSI disk drives in a Macintosh were bad business decisions by their respective companies.

I believe we would all buy more equipment if we were confident that it would be interoperate with our existing equipment. And we would buy even more if the data was opened up to third party applications.

You seem to be making an argument to justify why making interoperability as difficult as possible by dragging their feet, using proprietary physical connectors and proprietary data formats is a good business plan this industry.

You've opened the door, please tell us what makes marine electronics "hard core", and why is is "simply not like consumer electronics". What is so special about marine electronics that the best business plan for Navico, Raymarine, Furuno, Garmin, etc is proprietary cabling, connectors, protocols and data formats, each with it's own intellectual property protection?

Posted by: Russ at November 20, 2009 2:54 PM | Reply

Justify feet dragging, physical connectors, proprietary data formats. Me ? Not at all !

Not to be defensive (I am enjoying this thread) but let me expand on that answer,

I want my data, in a standard way, in the hands of any talented software iphone / google android / blackberry developer (althought I have Jeff Siegel (Active Captain) and Craig Summers (SailTimer) specifically in mind), and have them able to return the results to my network so they can display on my instruments. Has to be a standard way so when they write applications its applicable to many users.

It's a crying shame that a anchor dragging program for example can't just use the GPS on my own boat (1-way access), or a sailing applicaton can't behave as a second boat speed source so I can display target boat speed on my Raymarine displays (2-way access), Active Captain running on my PC can't narrow the data it's getting to 50 miles from my current GPS position to show me anchorages for tonight, or Craig Summers can't get a variety of information from my sailboat to create a polar information. And further more other things can't be invented and just downloaded like an app to an iphone.

If you add up my posts, I am basically saying to the ethernet crazies (I am one also by the way) that (i) The AIS data belongs on N2K, (ii) following the posts that were off topic of AIS, do us crazies really want your boat exclusively RJ45 wired (not viable) or do you really just want your data ? (iii) my thoughts how we can get our data from N2K wired network, although ideally we could get it from a hybrid ethernet/n2k network which is really where we are (at least I am) or are heading in boats over 30 feet.

Posted by: Dan Corcoran (b393capt) at November 20, 2009 4:30 PM | Reply

"You seem to be making an argument to justify why making interoperability as difficult as possible by dragging their feet, using proprietary physical connectors and proprietary data formats is a good business plan this industry."

That's just plain ridiculous, Russ. I'm defending NMEA 2000, which certainly promotes interoperability. I agree that most people here want interoperability but I sure don't see how slagging 2000 or the NMEA itself helps in that direction.

No one, NMEA included, is stopping any of the big brands from, say, giving away their Ethernet radar SDK and hoping that new scanner sales exceed lost MFD sales. I would support interoperability experiments like that with enthusiasm, but it's sure not a trend.

But even if I could mix and match broadband items like radars, sonars, MFDs, PCs, etc., I'd still want as much narrowband data as possible on an N2K backbone, because it offers the best interoperability and reliablility I've seen, despite early glitches and slow developement.

Marine electronics that install into boats and network with a complex set of sensors and other processors are not like consumer electronics because they're built in much, much smaller numbers while having to tolerate much tougher and more diverse environments. If you expect version one of a new system to work perfectly, you will likely be disappointed.

Posted by: Ben E at November 20, 2009 4:32 PM | Reply

PS, Russ: How about addressing the technician's question about whether or not AIS makes sense on NMEA 2000?

Posted by: Ben E at November 20, 2009 4:44 PM | Reply

Stating the fact that N2K has not become the dominant standard is not "slagging", it's just stating the facts. If N2K were the dominant standard you wouldn't be asking about AIS on N2K, it would be impossible for a vendor to sell an AIS without N2K. The reality is that it's impossible for a vendor to sell AIS without 183.

You're preaching to the choir. It's not the readers / consumers who are dragging their feet on N2K, it's the manufacturers! I've got an N2K network, I wish everything would just plug into it. But it doesn't. My new Raymarine pilot comes with a SeaTalk NG cable that won't connect to the NMEA defined standard N2K connector. I see nothing in the marine environment that requires that Raymarine have a different N2K connector than Furuno or Maretron, or how it gives them a competitive advantage. It serves only to make their equipment more difficult to connect in a multi-vendor environment. Why don't you direct your frustration to the source of the problem, not the people who want it solved?

With regard to AIS over N2K, I think Furuno is talking out of both sides of their mouth if they say that it will take 10% of N2K, but works over 183 (since the FA30/50 both have 183 outputs). Clearly 24Kb would swamp a 183 connection when merged with other 183 data sources. But the die is cast, Furuno has decided not to support N2K on AIS so what I'd like to see is for Furuno to open up the data format.

It is products like the FA50 that are hurting N2K, not your readers.

Posted by: Russ at November 20, 2009 6:23 PM | Reply

I agree with everyone. :)

(Though I have to add a particular tip of the angry hat to Russ's comment about SeaTalk NG. The fact that SeaTalk and Simnet are N2K data format compatible but use different physical cables is nuts, and having to buy the $60 N2K adapter cables makes me see red. If they needed to keep those proprietary sockets for compatibility with older equipment, could they not ship their MFD/radio/display with a $3 adapter? I mean, that's what they'd do if they were really committed to N2K's success ... right?)

I posed a question in my long post that didn't get any bites. I'm curious about Panbot's thoughts so I'll try once more: While N2K's data format is closed and copyrighted, reverse-engineering a communications protocol is demonstrably legal. And though Maretron withdrew their USB100 API, Actisense could perhaps galvanize a latent community of marine electronics engineers with their NGT-1 SDK. Various people are already exploring its potential, so my question to you all is: Waste of time? Hobbyist's toy? Or does unlocking N2K inside the PC offer a bridge to some interesting new products?

Posted by: Adam at November 20, 2009 8:07 PM | Reply

Hi Russ,

RE Furuno opening up the data format, only the radar / sounder data formats in NavNet are propertary.

The FA-30 i have here and NavNet 3D system installed on a local boat we have interfaced other software packages using wired and wiress nmea data from NavNet.

Simply install GPS Gate and set it to read UDP Reciever from port 10021 this will give you access to all of NavNets NMEA data.

FYI if you need in a NMEA 0183 GPS into a NavNet port that data is transmitted around the network on that port along with everything the navnet has on it.

Our the vessel we take NMEA2000 wind data, NMEA2000 GPS, NMEA 2000 Depth, Furuno Depth (DFF1), NMEA 0183 Depth, Waypoint / Cross Track Error data all via NavNet and a wireless router box to the customers wireless tablet pc.

Very simple Furuno doesnt use a closed format for transfering the data around there ethernet system it just requires a little bit of digging..

Andy

Posted by: Andy Murray at November 20, 2009 8:09 PM | Reply

Since I helped start this debate, I felt I would like to add some more.

1) Most of Yanmar's new (past 3 or 4 years) ECC engines above 150 HP are J1939 with direct N2K connections. Working with Teleflex Electronics, they have N2K throttle, N2K engine data, and even N2K ignition I believe. I was working on a proposal for the design of a fleet of high speed 50ft patrol boats, and tried to get more technical info out of Mack Boring, but it is pretty tuff. But needless to say, there are an IN MARKET engine controls which should have extremely high N2K network priority.

2) Call me crazy, but with the current state of the industry I could easily see a boat with 6 or 7 independent networks onboard. 1 = N2K navigation network, 2 & 3 = Octiplex N2K power distribution and control network, 4 = Navigation ethernet network (SeatalkHS, Furuno Ethernet, etc.), 5 = private standard ethernet internet network (probably with WIFI), 6 = crazy custom power network like Masterlink or Xanbus ... and this doesn't even include the fact that SeaTalkNG and Maretron N2K cabling could be joined on the same N2K navigation network.

However you slice it ... 6 or 7 different networks is really starting to sound like a Raytheon or Lockheed Martin designed destroyer/cruiser with a billion dollar price tag, not a yacht with $25,000 to $100,000 in marine electronics. I think atleast one of the real arguements here is atleast to maybe try to simplify this number, with our without open standards.

3) As a joke ... but who here knows of Mastervolt's Masterlink network or Xantrex Xanbus? It is a CANBUS network made not with N2K like cable, but ethernet cable ... ultimately outside of the ethernet SPEC though, I believe. But it is sure one strange monkey wrench in this whole debate.

4) Ultimately, about BEN's question about FURUNO AIS only having ethernet and not N2K ... I think it is crazy. Unless it seriously effects the price point and power consumption, I think the goal of every marine device is to have as many different connections as possible. I think Raymarine AIS500 is a better product than the Furuno simply because it includes the N2K network connection. All of these connections make me think of modern HDTVs or a multimedia surround reciever from somebody like Denon. I wouldn't buy an HDTV without HDMI, component video, and an ATSC tunner ... so why would I buy an MFD, AIS, or Autopilot without N2K and 0183 inputs?

I think it is crazy, if it true that Furuno has made the business decision to not put N2K in future AIS releases ... as for the past, maybe they weren't sure the AIS PGN would be passed or some other reason.

Posted by: Matt S. at November 20, 2009 8:34 PM | Reply

Let's see if I got this right, Russ:

1.) You're all for NMEA 2000, but you want the NMEA itself disbanded.

2.) Your proof that N2K has not become the dominant standard for narrowband data is that one AIS transponder doesn't have it, even though:
a) All transponders were mandated by the IMO to use 0183 back in the late 90's.
b) 4 out 5 of the latest MFD systems support N2K AIS, and 3 out 4 of the major manufacturers are offering N2K transponders.
c) All this even though AIS does fit the N2K sensor profile quite as well as many other sensors -- more data, less clients, needs separate power -- which is the subject of this figgin entry!

Let's put it another way: In the last few years have you seen many new designs for GPSs, Wind Vanes, Speed logs, etc. that favor 0183? Didn't think so.

As for picking on Raymarine, instead of you, check out this entry I wrote before SeaTalkNG even shipped:

https://www.panbo.com/archives/2007/10/seatalkng_an_n2k_parallel_universe.html

And notice that first commenter who got to use the Panbo bully-pit to rant about proprietary networks was you.

Posted by: Ben E at November 20, 2009 11:20 PM | Reply

Ben - I don't think this needs to cross over into personal vilification. There was what seems to me to be a pretty healthy exchange of ideas and perspectives in a public forum.

Posted by: Russ at November 21, 2009 6:28 AM | Reply

It already did, Russ; don't you realize that?

You accused me of justifying "making interoperability as difficult as possible", and of taking my "frustrations" out on my readers, and of not knowing the facts of marine electronics. All the charges are pretty much preposterous, but irritating nonetheless. You also vilified the NMEA, who are a few real persons to me, and don't deserve such harsh condemnation.

I love to see healthy exchange of ideas on Panbo, Russ, but I don't see how the blanket negativity you seem to slip into fairly easily is healthy.

Posted by: Ben E at November 21, 2009 10:43 AM | Reply

George: "For AIS data to take up %10 of the bandwidth of the network is not acceptable (and is a surprising claim, frankly) given that the product is not released yet. Who knows what bandwidth will be required later?"

Huh? There are thousands of ships and boats around the world outputting AIS data in 38.4K 0183 format. There are no bandwidth restriction complaints I've heard. In fact, the USCG claims to have successfully simulated 1,000 vessels within a Class A AIS range of about 30 miles. The whole system was designed around that 38.4K maximum, and it surely won't get changed soon.

There's some math involved converting an average mix of 0183 AIS to 2000 PGNs, but AIS bandwidth is a pretty known quantity. Meanwhile, many typical N2K networks are working at only 10-20% of their bandwidth. Garmin is supporting not only AIS on N2K but also satellite weather data. That surprised me, but I'll bet the Garmin engineers did the bandwidth math.

We live in Internet times where rapid bandwidth improvements have made big differences in our day-to-day lives. But that does not mean that every network type has to be judged in terms of how fast it can scale up.

Adam: "Waste of time? Hobbyist's toy? Or does unlocking N2K inside the PC offer a bridge to some interesting new products?"

I think the Third Party Gateway concept is great, and could lead to all sorts of interesting products, but am a little worried about how hard it will be for developers to pass the Gateway testing.

Posted by: Ben E at November 21, 2009 11:15 AM | Reply

Ben:

Good point, though Actisense seems to be saying that software written to their SDK (once certified if it isn't already) will be able to easily pass certifications of their own. They seem to be saying that since the NGT-1 is so good at protecting the network the barrier to certification for PC software using the NGT-1 interface is lower. Not sure if that's true or not.

But I guess my question was really about what happens if people start writing apps or building tools for my "MDOIP" network that do not even *seek* NMEA certification. Yes they consume N2K data, but that compatibility has been achieved through reverse engineering, and the NMEA seal isn't a goal. Call it "MDOIP-compliant", or something. Really I am talking about a different, open format running over IP. The fact that there is a N2K translator (probably an NGT-1 today) in the mix somewhere is a side effect of where we are in the market's development.

Does that make sense?

Posted by: Adam at November 21, 2009 1:05 PM | Reply

Wow. Amazing thread, lots of great comments, and I think we mostly agree.

0183 was very successful and refuses to die because it is simple and it is open. Both of those advantages need to be qualified. It's only simple for doing simple things and I think it is open despite NMEA and not because of it.

2000 was a good successor to 0183, but was not implemented in consumer products by NMEA members until after the technology should have been obsolete. And the interoperability principle has still not been endorsed by NMEA members. If the NMEA members who designed the cables (etc) can't even produce cables according to the standard, does this standard really have any future? The NMEA members (manufacturers) are still stuck in proprietary-land. I want to buy product X and configure it with product Y and use it with product Z. The NMEA members are dragging their feet. Customers are waiting for N2K products.

NMEA's operating model is old fashioned and would doom N2K if N2K were not the only game in town.

Ethernet has been around forever but it just keeps getting better. NMEA had its reasons for choosing CANbus over Ethernet at the time. That time has past. We can only live with that decision now the best we can. That will mean multiple networks. Use N2K as a simple to install bus for low speed data. The devices which don't fit there will have to use something else, probably Ethernet. The real problem isn't CANbus or Ethernet, the problem is proprietary versus open and interoperable.

The IMO might have something to say about AIS over Ethernet eventually. Furuno should lead on this. If they do not want to output AIS data on N2K they should allow someone else to translate their AIS data from Ethernet to N2K.

What the world needs now is a cheap little box to convert 0183 strings from one transducer and put that info on Ethernet. The box would be configurable to take data from any transducer, and cheap enough to put one on each transducer, making a virtual 0183 bus. Then see what the programming community would do with it. While we wait for NMEA.

In the computing world "commodity" wins. Cheap commodity parts can be used to build systems which compete very well against proprietary systems. Maybe this is why marine manufacturers cling to proprietary attitudes.

Posted by: norse at November 21, 2009 3:58 PM | Reply

Norse,

In my experience N2K has advantages and disadvantages.

If your rewiring everything for NMEA 2000 then it works well its when you start throing NMEA 2000 / 0183 into the mix (mainly because products like the Actisense gateway were not avalable when they should have been)

regarding furuno ais to n2k would a Actisense gateway not do this job? or anyone elses translator using the inbuilt 0183 output?

Furuno seems serious about the ethernet for AIS as there Class A FA-150 also has an ethernet upgrade kit you can put into it.

if people are serious like Russ saying disband NMEA etc the only way is to gather enough technical people and create an open standard.

My vote after installing electronics for years would be ethernet everything as it provides a robust easy to install system but you have the issue of a centeral hub.

Ideas guys?

Posted by: Andy Murray at November 21, 2009 6:04 PM | Reply

Andy, when you say that Ethernet is "robust easy", aren't you talking about 3-6 high bandwidth devices all made by the same company and designed to easily connect together via Ethernet? How is that comparable to a multi manufacturer NMEA 2000 network? Do you really expect to see, say, Ethernet rudder angle sensors, etc.? If so, where are similar small, weeny band Ethernet devices in other vehicle/industrial settings?

Norse, sorry, I disagree with almost every point you made, but, Lordy, I'm tired of arguing about it. Those serial-ethernet converters already exist, by the way, and are sometimes used on megayachts. They're hard to picture on a regular size yacht, though, because they add complexity without gain. All MFDs will already bridge 0183 inputs to Ethernet, but of course their proprietary Ethernet only delivers the bridged data to same brand gear. NMEA 2000 is the independent network that can deliver data to all MFDs, PCs, etc. without dependence on a single MFD.

Posted by: Ben E at November 21, 2009 8:01 PM | Reply

When choosing what network to put the AIS on, think about what devices need to communicate with the AIS.

1) MFDs
2) VHFs (but only after the data is interpreted on the MFD)

That's it. Why burden the N2k Network with the AIS data, when most N2k devices don't need it? Putting the AIS on the N2k network would be like adding the Radar or Sounder to it.

Posted by: AaronH at November 21, 2009 9:49 PM | Reply

Right now, all AIS devices do the same thing, so there is no need, except for price competition to use brand X AIS over brand Y. So even if the manufacturers keep their ethernet proprietary, then we really don't loose anything.

N2k's open architecture is great because there many ways to say, for example, acquire wind data or depth data, and N2k allows the best application (transducer) for the vessel to be used. With AIS, data is data, so it doesn't fit with the N2k philosophy.

Posted by: AaronH at November 21, 2009 9:54 PM | Reply

Ben,

Correct but there is no technical reason SeaTalkHS, Garmin Marine Network, Koden / Nobeltec Radars & Sounders, Navico networks (lowrance simrad etc) and not forgetting computers fleetbroadband etc all exist on a single 100/1000MB network link.

Yes NMEA 2000 has an advantage with it meaning each brnad will recieve data because the format is 'open' to the manurfactures if you pay the price.

If NMEA had setout open ethernet standard when they should have we would not have a different ethernet standard for each brand. (come on its 2009 and were just adopting NMEA2000, NMEA guys add 10 / 15 years to the date of your next standard at least the name will be right)

NMEA0183,
If NMEA2000 is the format to end all formats why are we still so reliant on NMEA0183?

Because NMEA0183 is easy and it works, if you mess up the wires it doesnt work, if you install NMEA2000 and happen to have a duff terminator or get a terminatior in the wrong place it will randomly lockup and can be a nightmare to find a customer of mine had a terminator that was faulty when we did a resistance test on it it was reading 30 ohms not 120ohms this caused so many lock ups affecting only some of the network, now with mention of NMEA2000 throttle controls there is NO way i would feel safe installing critical applications such as throttles on a can bus after seeing some of the data lockup even if it was just once. NMEA 2000 throttles if i was to install them would have a dedicated bus.

Now with more movment towards computers and software NMEA have made of overly hard to get canbus onto a laptop, even back when they were writing the standard they couldnt have been so blind as to realise this was not the way things were going to do, every laptop & computer has an ethernet port ?

I guess what Norse myself and others are trying to say is NMEA have made a monumental mess up and if there was competition on the standard front they would all be bankrupt.

Unfortunatly as i see it now i dont see any ethernet standard ever catching on due to the ammount of R&D that Furuno, Raymarine, Navico, Nobeltec and others have put into there own ethernet systems why would they throw that out in the idea of open formats.

My 2p.

Posted by: Andy Murray at November 21, 2009 10:03 PM | Reply

"If NMEA had set out an open Ethernet standard when they should have we would not have a different Ethernet standard for each brand."

That made me laugh, Andy. I think you have a wildly exaggerated notion of NMEA's power. It's just an organization of installer/dealers and manufacturers with the authority to mandate almost nothing.

In fact, there are so few brands using Ethernet that they could agree on standards without the NMEA at all, if they wanted to. Even if just two or three did, it would probably force the others to follow. But they haven't even agreed on a standard marine Ethernet cable. (I wonder how many of the E zealots realize that?)

And there's a good argument that it was the big manufacturers who slowed down the adoption of NMEA 2000, either not using it or reconfiguring it into proprietary cable forms like SimNet and SeaTalkNG. They took a little NMEA loop hole and made a big confusing thing out of it.

I'm curious, by the way, if the N2K network you had trouble with was composed of all NMEA 2000 certified cables and connectors? This is another area where some of the major manufacturers have gone astray.

Also, the use of NMEA 0183 does not mean N2K failed. From the beginning the NMEA 2000 concept included 0183 being used alongside for certain 1-to-1 tasks, and Ethernet being used for broadband tasks, just like is happening on many boats. NMEA has even been updating the 0183 standard.

Posted by: Ben E at November 22, 2009 10:08 AM | Reply

If there was a standard for Ethernet the manufactures would not spend tens of thousands on developing their own packet protocols for everything when you could program one off the shelf.

The reason all our big makers have made their own formats and the rest as they say is history.

So few brands using Ethernet by terms of makes i can think of the entire Navico range, Furuno, Garmin, Raymarine, Nobeltec / Koden, that accounts for nearly all the big MFDs where high speed links are needed.

Connectors.
Furuno, Raymarine HS and Garmin all use standard RJ45 cables and connectors. It�s the waterproof surrounds each make as their own take on but in a non-fly bridge installation you can use your own standard cat6e cables.

NMEA 2000 issues.
Yes this was all made of airmar (LTW) or maretron cables.

Apart from the power advantages of (some) devices running off the NMEA2000 bus i really don�t see the point of it, basically on most installations you can do nearly everything with NMEA 0183 and Ethernet.

The leisure / recreational market in the UK is slowly adopting NMEA2000 but this is adding lots to the install costs with one boat i work on having a seatalk network, navnet network, nmea 2000 network and nmea 0183 network the converter boxes required to make it work is silly. If we took out the NMEA 2000 network the install costs would have been significantly reduced.

The commercial market has not even heard of NMEA 2000 let alone starting to adopt it.

Maybe IMO should make the Ethernet standard and this could then be back ported to the recreational market.

I guess we will never all agree, the decisions that have been taken are now set and we have to make best of what we have..

Posted by: Andy Murray at November 22, 2009 11:15 AM | Reply

OR the manufacturers think the tens of thousands of dollars are worth it to have proprietary Ethernet devices that no one else can mess with.

I don't know what the set up on that boat was, Andy, but there are plenty over here that are saving money on initial install using NMEA 2000. And they'll probably save more when gear is eventually replaced.

Posted by: Ben E at November 22, 2009 3:40 PM | Reply

It seems to me that in the NMEA2000 world NMEA has extreme power. When I buy a NMEA2000 sensor the manual provides only the supported PGN numbers and titles. I am not told what data fields are included, the range, number of bits, or anything. Even if I did not need to decode the data for my own applications I want to know the details of the data stream being fed to "official" displays and instruments.

On the other hand, NMEA 0183 is widely used for many non-marine applications (at least GPS sentences for mapping and timing) because it is openly documented (and is simple enough that documentation is often not even needed).

Jon

Posted by: JonM at November 22, 2009 10:46 PM | Reply

Jon, both the NMEA-2000 and -0183 specs are available from the NMEA. Unfortunately, they cost a lot (especially -2000), and they are covered by a license so you are not allowed to make the specs public.

Thr reason that -0183 is openly documented is that it was reverse-engineered, or in some cases manufacturers published their particular data formats. Reverse-engineering was pretty simple, since the language is standard ASCII over a standard serial connection. Still, it did take a while.

NMEA-2000 is more difficult to reverse-engineer because of the binary format and less-common interface. Still, some people are doing it, and as NMEA-2000/USB interfaces become more common the reverse-engineered specifications will become generally available. This, too, will take a while.

Posted by: Paul at November 23, 2009 2:19 AM | Reply

I usually stay out of these discussions on A versus B, but now I'd like to state my support for Ben's position.

- Ethernet by itself doesn't mean anything. There are thousands of proprietary protocols and software products that use "open" TCP, UDP etc. Heck, even all marine ethernet solutions that do exist are completely closed (as noted by several people above.)
- 100 MBit Ethernet uses a switch, meaning that every link uses between 0,6 and 1,0 W just for the transceivers on both sides and that you need to run separate cables to the switch to/from every device on the network.

To put that into context: if I would design the network for my average sailing boat on ethernet instead of N2K ( 6 sensors (GPS, wind, depth 1, depth 2, compass, rudder), MFD, AIS, PC, VHF 1, VHF 2, autopilot, 4 nav instruments) I'd need a 16 port ethernet switch. That would increase system power use by 65% for no added benefit to me.

Ethernet is NOT a low power or easily expanded solution.

Posted by: Kees at November 23, 2009 3:50 AM | Reply

+1. Exactly.

Still, it would be very useful if a marine ethernet (and bluetooth) standard was defined for sensor information, AIS, etc. using these open protocols (including the security one's) so that even if our sensors won't ever be connected ethernet, their information can be sent over wi-fi or bluetooth to your PC or phone, and vis-a-versa we can configure them (req enhancement of NMEA-2000).

Posted by: Dan Corcoran (b393capt) at November 23, 2009 7:08 AM | Reply

Kees' recent comments present an extremely narrow view and are directed in a way that doesn't address the core arguments of many posters:

For example,

1. How much power does the CAN tranceiver on each product consume, including the mandatory NMEA2000 Isolation requirements? Kees' argument doesn't state the value but, it is not zero. Additionally, how is this data going to get to the PC in his example? It will currently require a 150mA (3 LEN) Adapter Box which is not mentioned.

2. The Furuno method of encapsulating the open NMEA0183 data inside Ethernet UDP Packets is not "Completely Closed". It just isn't supported by Furuno outside of its use in their products.
Any developer with worth his salt can grab and use it.

The same is not true with the expensive NMEA2000 infrastructure.

Other Items I take Issue with:

-NMEA2000 Networks are NOT robust!!! While the protocol itself may be robust, a typical installation using a Bus Topology NMEA2000 Backbone is extremely vulnerable to single point failures.

Let's take some examples using Kees' simple 16 node backbone with 6 navigation data sensors. Unless a boater plans a cruise to Fantasy Island, the sensors in his boat will be exposed to salt-water and/or the environment in some way.

A. What will happen if a single short curcuit occurs on the NMEA2000 power cable in any one of these sensors? The boat will lose every sensor immediately. Further, there is no way to quickly troubleshoot or isolate the the short circuit!! It could be anywhere on the backbone, in any device or the short could be in the cabling itself.

B. What will happen if a short curcuit occurs in a CAN transceiver data IC on one node or in the cable itself? It is also very likely that not just the sensors are lost but, the entire NMEA2000 infrastructure will be rendered useless.
Some may argue that this is not true but, the effects are dependent upon the unique design of each backbone on each boat and are not definable. A network analyzer will not be able to pinpoint the failure if many sensors on the bus are not presented to it.

--
Both above scenarios are the reason why the IEC and IMO have both refused to allow NMEA2000 be used for Commercial vessels without major modifications to the standard. This includes a very expensive, dual bus and isolated architecture where every sensor and node must have two isolated CAN transceivers. Then, they must also contain the underlying protocol stack to automatically switch from one backbone to another in the event of a failure. Needless to say, there is not a single commercial/deep sea marine electronic manufacturer who has chosen to develop this type of special NMEA2000 system at this time.
At the same time, virtually ALL of them use High Speed NMEA0183 (NMEA0183HS) transceivers, as opposed to Ben's suggestion that NMEA0183HS is rare! Furthermore, virtually ALL of them have adopted Ethernet Networking architectures for networking critical navigation information. I submit that EVERY single Deep Sea/IMO vessel constructed in the past few years is in fact using Ethernet for critical Navigation Information Distribution in some way while not a single one is using NMEA2000 in any way!

To be fair, Ethernet has the same single point failure possibility with its star network topology using a switch or hub. However, if any legs of the star are shorted, the hub will automatically isolate that single node on the network. And, if the switch/hub has a problem, even my five year old son knows to look in the closet to see if the lights are blinking on the connector that attaches to his XBOX when he can't play with his friends across town. I have a spare $75 router/switch next to it just in case it ever fails.

This is precisely the reason why Ethernet Network Bus architectures don't exist in office environments any more! Originally, Ethernet was indeed developed as a Bus Architecture!
The problem is that they were almost impossible to troubleshoot when there was a problem.

Now I ask, where is a network problem more important to quickly troubleshoot and isolate?
In an office or on your boat when you just might need to see your depth or position in the middle of a storm?

I would gladly give up a few watts for the same network topology on my boat.

Mantis

Posted by: Mantis at November 23, 2009 7:24 AM | Reply

I tried to piece together what ethernet protocols (open protocols only) would best go together to provide visability and control of NMEA-2000 transducers wirelessly in an environment where multiple boats could be in range of each other (implies need for using authentication) and need to be easily installed and cheap to be widely accepted. It's mind boggling difficult, isn't it !

Posted by: Dan Corcoran (b393capt) at November 23, 2009 8:56 AM | Reply

Perhaps I have to set my sights on bluetooth only? It seems a lot of good work has been done to make it easy for consumers to add and remove devices from a personal network within this protocol.

Posted by: Dan Corcoran (b393capt) at November 23, 2009 8:58 AM | Reply

Righto. Sweet would be a standard way to packetize NMEA 0183 and 2000 data over Ethernet. This seems like a much more doable goal -- that is, easier and less disruptive -- than standardizing broadband marine Ethernet like radar and sonar.

I may have even heard that NMEA is working on such a thing. People need to understand, though, that the NMEA can't pursue ideas like this without explicit co-operation from the manufacturers, or at least a majority of them, and when all is said and done, NMEA has little enforcement power.

Posted by: Ben E at November 23, 2009 9:12 AM | Reply

Mantis, Regarding HS NMEA 0183, I was talking about yachts, not ship level electronics, which I don't know much about. But isn't it true that the IMO requires redundant connections for all critical navigation data, regardless of what cable or data protocol it's running on?

Posted by: Ben E at November 23, 2009 11:05 AM | Reply

Agreed on the usefulness of a standardized wrapping method of transmitting NMEA 2000 over IP.

Posted by: Kees at November 23, 2009 2:54 PM | Reply

Around five years ago I developed a high definition digital camera recorder called CineRAM for uncompressed motion picture production.

For control (TCP) and download (UDP) we used a tiny IBM computer on a chip with 2 x 1 Gigabit (that's 2 billion bits per second!) Ethernet ports running a real time version of Linux.

Today, similar chips are much smaller and cheaper. Tomorrow, they will be more so. Which is why I am convinced that in the not too distant future, virtually all electronic devices (including toasters) will be IP based, and will be configured (likely wireless) through their own web servers (ala Linksys router).

I think Furuno is on the right track. If they choose not to define a marine IP protocol (which would be unfortunate), someone else will.

Posted by: Noel at November 23, 2009 10:06 PM | Reply

Paul - The high cost of the NMEA2000 spec means that it might as well not exist for an individual researcher/hobbyist. I have been fairly successful in decoding NMEA2000 data for the sensors I have on my boat using the limited documentation currently available. In fact, if this information were not available I would not have purchased "extra" electronics and installed a NMEA2000 bus.

I am using an $88.00 EasySync USB to CAN Bus adapter for the interface. This adapter works on Linux and will allow me to use a 4 watt server to decode the NMEA2000 data and place it on the boat's wired / wireless Ethernet network. I wonder if the new commercial gateways will provide that flexibility at the low end?

Jon

Posted by: JonM at November 23, 2009 10:49 PM | Reply

That's a good question, Jon. I hope that you'll pursue it with Actisense, which seems to be spearheading the Third Party Gateway, and that you'll report back. I understand that there's still something about TPG that needs to be voted through the NMEA, which may happen as "soon" as January. So don't expect all the pieces to be fully available yet.

Noel, How many bits per second do you calculate are needed to send, say, rudder angle 10 times a second in one direction on a continuous basis and three points of calibration per second the other way about every year or so?

Posted by: Ben E at November 23, 2009 11:20 PM | Reply

Ben - Not many bits needed for a rudder, but speed does become important when you add AIS, RADAR, HD cameras, Voice over IP, etc. to the overall picture.

As for sending sensor data over IP, I remember logging onto the Coke machine at MIT to check their temperature in the 1970's. Today, MIT streams much more important information: http://bathroom.mit.edu/.

Clearly, the IP vs. (other network) argument won't be resolved soon. But it's worth noting that IP was designed by DARPA to withstand a nuclear attack. And that was before the Internet became ubiquitous.

I have little doubt that if marine electronics manufacturers stuck with their core business (which is really not networking) and embraced an open IP protocol they would sell far more products. It would be logical for NMEA to take the lead and provide us with "NMEA MTP/IP (Marine Transport Protocol)", which would, of course, include NMEA2000 over IP.

Posted by: Noel at November 24, 2009 12:22 PM | Reply

Ben: I guesss I was unclear. It seems that people are missing the difference between the various types of networks. There are strengths and weaknesses of all.

The fact that AIS (currently) works over an 0183 HS connection is not material to the amount of bandwidth that it takes up on an N2K network. 0183 is a serial point-to-point protocol. The model in the "good old days" was that computers had several serial ports. One device was connected to each port. This is a strength of the 0183 model -- bandwidth is infinitely expandable up to the computer's bus speed by adding more serial ports. The minicomputers that I worked on had 50 or more of them. (We also had raised floors and what is now $10000's of dollars worth of copper wires. If only I had hauled them all home when the center was decommissioned!)

N2K and ethernet eliminate all of the point-to-point cables at the expense of making clients and consumers share bandwidth. Ethernet transmission speeds are insanely fast, so you can have tens of thousands of virtual cables in the one physical cable. This is good, but one of those "cables" can now do what was nearly impossible in the "legacy" system -- interfere with other connections. So when you start out with a design that will allegedly eat %10 of the network from the get-go the engineers get worried.

Experience shows that everything takes more bandwidth in production than you can plan for.
I imagine that Coast Guard could start requiring public key encryption on AIS signals in the future as a way of verifying that you are who you say that you are. This might mean that you have to send and recieve both plain text and encrypted signals, perhaps doubling the bandwidth required. (This is by way of an example, I have no idea what might happen to AIS in the future.) Maybe you have to start transmitting your vessel's CANPASS number or a digitized version of your passport. (I think I will stop now before I give anybody too many ideas.)

Posted by: George R at November 24, 2009 10:08 PM | Reply

"The fact that AIS (currently) works over an 0183 HS connection is not material to the amount of bandwidth that it takes up on an N2K network."

Oh, George, you really ought to look into the realities of AIS. The 0183HS 38.4k bandwidth limit is a core specification. To change it, I believe the IMO would have to mandate the replacement of every transponder on earth. It would take decades. And to my knowledge they have no plans to change it.

And neither the USCG nor any other national authority can not just add features to the international AIS specifications. What they can do, and have, is to extent IMO requirements to vessels IMO does not directly regulate.

Posted by: Ben E at November 25, 2009 6:50 AM | Reply

This discussion has been extraordinarily helpful to me. Thanks to all. I've had to rethink the new network I'm putting together.

While I clearly prefer an IP only network, the fact remains that all the necessary components for that do not yet exist. So, like it or not, N2K will be a part of my next system.

However, I do think that Mantis' statement should be repeated: "-NMEA2000 Networks are NOT robust!!! While the protocol itself may be robust, a typical installation using a Bus Topology NMEA2000 Backbone is extremely vulnerable to single point failures."

Frankly, I had forgotten the endless hours I spent tracing down office ring network problems. I'd also forgotten the raised floors and multiple serial ports George mentioned.

But I'm definitely looking for a way to quickly isolate N2K components and wiring for troubleshooting. In my sailboat (43 feet) home run of a few cables to the nav station wouldn't be too messy. Perhaps a Furuno FI-5002 or Acisense QNB-1 as a sort of hub. Any ideas?

Posted by: Noel at November 25, 2009 1:22 PM | Reply

"Use the Spur, Noel!" -- paraphrasing Star Wars here for a moment.

Use the fact that spurs off the main trunk can be 6 m in length. So instead of putting your main trunk down the bilge put it as high up as you can, dropping down to get to your transducers when needed.

I'm planning a central "black box" area where most of the nodes will be that will have a QNB-1 providing power and two Simrad 7 port concentrators. The line going forward has one depth/speed/temp transducer and wind. The spur to the transducers will be 3m. The line going to the rear has GPS.
Everything else is central. There is a 5m spur from this that takes the nav displays.

In case of faults I intend to unplug the rear & front trunk line from the Simrad concentrators to see whether that helps. If it doesn't I unplug the concentrators from the QNB-1 giving me "core stuff" only.

Kees

Posted by: Kees at November 25, 2009 3:35 PM | Reply

Thanks Kees. I think the spur approach makes sense. I plan to add depth/speed/wind instruments in the cockpit (Furuno FI-50 or Simrad IS20) and that could be a spur as well.

Where can I find the Simrad 7 port concentrators you mentioned?

Noel

Posted by: Noel at November 25, 2009 7:14 PM | Reply

Kees, I spoke with Simrad today and while it's not spec legal, you can apparently chain several IS20 displays together as a single "spur". The same appears to be true for Furuno.

Noel

Posted by: Noel at November 25, 2009 7:22 PM | Reply

Noel,

It may not be N2K spec legal but it is Simrad spec legal -- I guess it depends on the input impedance of the N2K transceiver.

The official name (I was quoting from memory) is a Simrad multijoiner.

For more info see the http://www.simrad-yachting.com/Products/Accessories/SimNet/SimNet-Joiners page on their website.

Kees

Posted by: Kees at November 26, 2009 8:12 AM | Reply

Kees has done some good research on Ethernet switch power demands:

http://yachtelectronics.blogspot.com/2009/12/are-eco-ethernet-switches-greener.html

Posted by: Ben E at December 7, 2009 12:05 PM | Reply

"But I'm definitely looking for a way to quickly isolate N2K components and wiring for troubleshooting. "

I'm a Mac guy so I don't know if this is already well known but this
page on the S/V Sarah blog looks promising:

http://www.svsarah.com/Sailing/ewTechniqueOverview.htm

"I have found the HYPERterminal software included with the Windows OS on most PCs a very useful tool when troubleshoot and configuring the NMEA network on Sarah."

Posted by: John K at December 18, 2009 9:58 AM | Reply

John K,

You are confusing NMEA0183 with NMEA2000. Yes, NMEA0183 is quite easy to troubleshoot because it is NOT a network system! Instead, NMEA0183 is a Point-to-Point or Point-to-Multipoint protocol.
Isolating the problem can be quickly determined by looking at the Talking product or the Listening product. It is true that NMEA0183 is a ASCII Serial protocol which is why Hyperterminal is a good tool as described in the link you posted.
NMEA2000 on the other hand is based on a CAN BUS infrastructure combined with non-isolated DC power. Hyperterminal and RS232/422 serial ports are useless with NMEA2000! If and when there is a problem with the NMEA2000 BUS network, troubleshooting will be much more complicated and require special software and hardware in most cases.

This is the argument against a single backbone, multi-sensor NMEA2000 BUS presented by some in the comments of this post.

Posted by: Tech at December 18, 2009 5:59 PM | Reply

Great article, and discussion. Thanks.

So, one point I'm still not clear on:

Can Maxsea Time Zero read this "encrypted" AIS ethernet stream from the Furuno AIS units, with no MFD in the system?

Posted by: Beaver at December 22, 2009 6:46 AM | Reply

Yes, MaxSea TZ understands Furuno's AIS over Ethernet.

Posted by: Ben E at December 22, 2009 7:39 AM | Reply

Beaver

Furunos AIS stream isnt 'encrypted' any software that supports AIS over UDP (seapro etc) can read this data its simply NMEA 0183 over UDP packets.

Many software makers have supported this for quite some time.

No encryption at all

(yet)

Andy

Posted by: Andy at December 22, 2009 11:31 AM | Reply

Andy, Coastal Explorer can use AIS info from many online sources using just an IP address. Is there a way to make it work with Furuno's way of Ethernet broadcasting?

Posted by: Ben E at December 22, 2009 12:19 PM | Reply

Hi Ben,

Provided MaxSea Timezero isnt running (im guessing CE is on your laptop with MXTZ)

In CE if there is an option to read AIS data from UDP ports you can ask it to read UDP data from port 10021

if not if you have Fransom GPS gate installed you can get that to read the UDP port and spit it out a virtual com port.

if you have an MFD in the system this should also give you all the NMEA data flying around NavNet network from the MFD's (n2k inputs 0183 inputs etc)

Andy

Posted by: Andy at December 22, 2009 2:07 PM | Reply

Kees - That is good power consumption info. Any notion of the power consumption of the Raymarine SeaTalkHS E55058 switch? And does anyone know if other Raymarine SeaTalkHS equipment will work with a standard (non-Raymarine) ethernet switch?

The installation guide for that Raymarine switch does not even show a need for external power...but an external power line does show up in the Raymarine chart plotter install manuals.

Bill

Posted by: Bill at January 12, 2010 11:14 AM | Reply

Andy,

Did you really confirm that NMEA-183 datagrams are UDP-broadcasted to Port 10021 by Furuno FP-30/50?

Visit the following site.

http://www.bigresource.com/VB-UDP-Datagram-6wfdgGv1mN.html

This site says ".... Simply waiting for the dataarrival in vb and assigning it to a string then printing it only gives me ascii chars that increment up, such as 1..2..3 and so on."

I myself cannot confirm this because FP-30/50 are unavailable here, but my oversea friend experienced similar thing.

Please comment.
Regards

Posted by: Yuyama in reply to Andy at December 19, 2013 5:11 PM | Reply

Name

Email (private)

URL

Remember personal info?

(Basic HTML text format tags work, and a URL on its own line is automatically turned into a link.)

AIS over NMEA 2000, concept defended

Comments

Leave a comment