“Sorry Breeze Pleeze”, a yuletide N2K rant!
I like to think that one function of Panbo is to be a place where marine electronics enthusiasts can share their thoughts—rants included—with each other, and with the many industry folks who read the site. That usually happens via comments but guest blog entries are also welcome. Hence we have the following bitter sweet Christmas tale from Dan Corcoran (aka commenter “b393capt”). Thanks, Dan!
Sorry Breeze Pleeze, no marine electronics in your stocking this year …
My wife wants me to get something on the Christmas list for Breeze Pleeze. Cool, I would really like that. I already had a solid plan to spend the winter storage period wiring a new N2K backbone into my 39’ foot sailboat Breeze Pleeze and her two N2K capable chart-plotters. So for Christmas I would, err .. I mean, Breeze Pleeze would potentially get her first N2K component.
Maybe an AIS receiver? Not any AIS, but one that uses N2K to pass info that identifies which contacts are my buddies. Or, maybe a new VHF that can use MMSI to contact another boat that appears on my chartplotter. Or, an ultrasonic masthead wind sensor would be really wonderful. I could get Breeze some accurate wind direction to steer by at those low wind velocities that prevail in the summer months, and all with no moving parts at the top of the sailboat mast !
However, in our house, Christmas lists need to include part numbers for Santa. And, when thinking through those details, my brain begins to hurt. In fact, I have given up for now. Combining products from multiple vendors on N2K would require a Crystal Ball to determine who’s current and future products will give me the least integration hassle, as clearly, I can’t call up and ask sales support in advance.
Don’t get me wrong, if I bought my boat this year rather than 2005, I would definitely wire for N2K. Or more precisely … I would today pick a single suite of marine instruments, give preference to which makes the best use of N2K, and for those components for which I had a choice, I would use the N2K protocol. But … to wire my boat now and to make it easy to plug in new N2K components next season, this isn’t a standard I can count on at all.
In fact, N2K looks like it’s getting less standard every day based on the slew of continuous product announcements! For example, where are the standards for:
* AIS products – e.g. message sets for new features coming into the market place such as buddy lists (ability to flag AIS targets that are buddies to be noticeable on a chartplotter).
* VHF Radios – enable a user to initiate a call against an AIS target without typing in the MMSI number.
* Ultrasonic weather stations – enhanced PGNs to carry more weather data and standard PGNs to configure these devices? (or maybe an HTTP over N2K capability, so a standard browser interface can be used to configure any device from any browser based capable display).
A lack of standards in all the above, seems to dilute the promise of N2K and create a situation where I must still standardize on a specific vendors suite of products to get advanced features (e.g. need to buy a Maretron display to get full weather station info and for configuration; need a Simrad chart-plotter to use features in a Simrad VHF, use only Furuno products if I want N2K PGNs to pass through the N2K hub port on a new Furuno radar through to an ultrasonic masthead weather station). Even if I put off the decision of the specific electronics components, how can I even decide what wiring product to use this winter for an N2K backbone?
Sorry Breeze…due to vendor circumstances beyond his control, Santa ‘missed the boat’ and won’t be coming through with a big, marine electronics gift for you this year. You will remain alone in storage this Christmas and I, instead of happily receiving and installing cool, new parts on you, will be at home opening ties and eating fruitcake.
Well said!
And to which I will add the perspective of a consumer in a different situation. I’m building a new boat and don’t have the luxury to “just say no” to N2K like our B393capt. I have to put some cabling and electronics in this boat.
With 183 we had two things we valued: 1) standardized cabling and 2) interoperability. It wasn’t pretty, but all the 183 devices used the same ugly pairs of wires that could be purchased anywhere, and pretty much any two devices that supported 183 could be interconnected if you were careful about your wiring.
Next we wanted to simplify the wiring and add bandwidth. N2K bumps the bandwidth a bit, but Ethernet had to take the video content, N2K could never address it. So that leaves N2K to carry the text data a little faster and simplify the wiring, that’s all it had to do. Get rid of matching up all those talker/listener/power wires. N2K, before it was bastardized by many (though not all) vendors, could deliver that.
Now we’ve got a proliferation of “N2K like” products, that will only interconnect if you buy all the appropriate proprietary connectors (which create way more obscure SKUs than your local marine supply shop is ever going to stock). So to get simplified wiring, we have to give up interoperability?
I spent a lot of years in high tech marketing and I don’t see why any product manager thinks that less interoperability will increase sales. Nor do I understand why NMEA thinks keeping the standards a secret from consumers will promote adoption. I cannot think of an industry where this type of marketing has led to growth. and I can think of many companies that died with their proprietary solution held close to their chest (DEC’s VMS, Texas Instrument PCs, Sony Beta, etc. etc.)
I’ve spent a lot of money on a new custom boat and my expectation is that it will have a much longer life cycle than any of the electronics that I install, and many of the electronics vendors themselves. I’m going to spend $20K – $30K on electronics in the next four months. I’m not here to promote any particular vendor, but after a lot of thinking I put two stakes in the ground: a) I’m not installing any proprietary cabling, and b) I’m not cutting any big holes in the fiberglass to fit the product du jour’s “flush mount”.
Today’s Panbo has exposed at least two frustrated consumers. We want to spend money! We like electronics! Why is the industry doing it’s best to make it so difficult?
I must confess that I am still puzzled why NMEA didn’t choose ethernet for their physical layer. There is even a standard for power over ethernet, which would supply power just like N2K did. They somewhat reinvented the wheel for the cable when they could have been spending the time working on more communications protocols.
I think the driver must have been the ability to read Canbus data from engines — which is a little sad because you can do that already with an ethernet-to-CAN conversion box. I know the argument about throttle controls and all, but I’m not even sure that I want the guys who install my electronics to be messing around with anything that is at all related to my throttles!
Of course N2K is getting on in years now and is really an old standard. Things are moving very quickly in marine electronics and the hardware is leaving the infrastructure behind.
The new N2K+ will be a wireless open standard and much better/faster than ethernet and much easier to install. I think I’ll wait.
Merry Christmas and a Happy New Year to Ben et al.
I might have to disagree somewhat. I have been successful in interconnecting N2K equipment from several vendors. I have interconnected two displays from different vendors, as well as tank level and trim tab sensors from other vendors.
I plan on adding rudder and fuel flow sensors from yet two additional vendors in the near future.
One limiting factor as I see it is the ability to configure the various sensors from different manufacturers.
For instance, I am adding a rudder sensor to my N2K capable display (different brands), but the display only recognizes instance 1 of the rudder sensor. The rudder sensor ships with a default of instance 0. The display is not capable of programming sensors.
No problem, I contacted the sensor manufacturer, and they have indicated they are willing to configure a sensor to my specifications.
Same thing happened when I added the tank sensors. One display would not recognize the sensors until I programmed them with a different display that would recognize them. Again, the sensors shipped with instance 0, but as soon as I configured them for instance 1 and 2 (for the two fuel tanks), both displays recognized the sensors.
As far as ethernet, you have to remember that it is bursty in nature; which could result in an erratic reading of constant output sensors like RPM.
True, a lot of ills can be fixed by going to 100M or 1Gb ethernet, but the basic problem as I see it is that there is no guaranteed class-of-service.
That is fine for things like store-and-forward, file-transfers, and the like, but not so good for process-control systems.
I have only studied the CAN data link layer from a casual point of view, but I believe it is capable of class-of-service.
I should also state that the particular display unit must have the capability of displaying the desired PGN in the first place, and as tightly controlled as this information sometimes is, it may be difficult to pry this information from your display manufacturer.
And I also had to standardize all of the connectors. I installed a standard network from components purchased by Maretron, and each time I buy a new sensor, if it does not have a standard connector, I simply whack off the non-standard one and replace it.
Some of these things may not be suitable for the faint-of-heart, but I don’t think it cannot be accomplished.
1) I think the success is going to go down once you are using non-traditional types of sensors and displays, if there will be no standard PGN’s on AIS, VHF, ultrasonic weather station messages, etc.
Interestingly, the competing power providers are working together on a standard N2K PGN within the NMEA, why not others ?
But Dan, there are lots of standard N2K AIS and weather PGNs, as you can see on the list available at nmea.org. I think every data message coming out of the Maretron WS is standard, and is understood by a Raymarine E Series.
Calibrating the Weather Station is another matter, and has to be done with either a Maretron display or their software and a Gateway.
The AIS-to-VHF PGNs are more problematic as discussed in the Simrad AI50 entry, but so far there is only one N2K AIS and one N2K VHF (shipping), both by Simrad.
And there already is a multi manufacturer committee discussing navigation PGNs. Has been for a long time.
AIS — opps, I meant the AIS-VHF.
Weather – I am confused, Maretron technical support was pretty explicit that the E-80 won’t display the additional data beyond true and apparent wind speed and wind direction, eg barometric pressure, etc, requires I purchase the Maretron display. They also said I would need a Maretron display to configure or a PC with their software.
Maybe awboater has part of my solution, he wrote that he uses maretron cabling, and whacks off the connectors of non standard vendor components.
Is that a promissing solution for me to build a vendor nuetral backbone to support my (2) Raymarine E-80 charplotters, a maretron weather station, and unknown products I might pick and choose in the future ? Any particular vendor that approach would certainly support or certainly exclude ?
Thanks
awboater has some good points about the shortcomings of Ethernet. Additionally, if anyone thinks getting N2k devices from different vendors to read each other’s messages is difficult, imagine what we’d be faced with if every vendor had an open invitation to write their own protocol. At least CAN was designed for process control and promulgates some standards in that arena. Garmin and Furuno products use Ethernet, but I don’t think anyone is going to hold their breath for interoperability between their products. There would basically need to be a standards body anyway to develop the protocol if it were to be of any use to anyone.
As for the issue of burstiness and unpredictable latency, it should be possible to make Ethernet suitable for a marine electronics environment, but to do it right it might end up being more expensive than anyone would care for:
1.) It would be critical to achieve system clock synchronization for every device on the network, and for all messaging to be time stamped and UDP. (that way, the messages can expire, and if a message has expired, we don’t often care if it gets dropped)
2.) All sensors and controlled devices should be speaking IPv6. This would allow for better autoconfiguration and to some extent mitigate comment points of failure like DHCP servers. Of course, DHCPv6 should also be supported for those who feel they really need it.
3.) All latency-sensitive communications should be either on a segregated Ethernet segment or connected to a switch with QoS capabilities. (critical vessel communications have highest priority for access to the switching fabric, then stuff like VoIP, then your email, youtube, and web surfing) GigE is great and all, until your daughter starts transferring a large video file to the boat’s NAS and saturates the capacity of your LAN.
4.) Device communications should be regulated (though not forwarded through) by a master host to prevent any one device from using more throughput capacity than is available. The master host needs to know that each device is not going to exceed more than the number of UDP packets it has been given permission to send each second.
5.) Multicasting or broadcasting should be utilized for message passing from sensors. If your boat management software/workstation goes down, the backup workstation needs to be getting the same sensor data and needs to be able to take the con.
6.) Heartbeat messages should also be a part of the standard. (ex. An engine should rev down and go into neutral if it doesn’t hear from the throttle controller at a specified interval. It should probably even shut off.)
7.) Sensor readings and control messages need to be signed for authentication. If our sensor network is potentially a globally-routable IP subnet, or even if you have the given yourself the false sense of security of making it unroutable, we still don’t wanting Bad People on the Internet (TM) sending engine and steering control messages to our megayachts.
So yeah, such a system would be truly open, flexible, and awesome, but would also require the devices to be a lot more complex and draw a lot more power. Do you really want your “N2K-E”-enabled navigation lights having to support all of this stuff, or would you prefer a simple, application-specific serial bus with one or more PCs/Multifunction Displays sitting netween it and the Ethernet. All I really want to be able to turn the light on or off and get some indication when the it has burned out or isn’t working.
The real problem here seems to be not N2K as a standard, but NMEA as a standards body. They’ve singlehandedly proved that even if you make membership very exclusive, deny the public access to the documentation, and make device certification outrageously expensive, you can still end up with abysmal interoperability.
Here’s what I’d like to see:
1.) Open documentation for hackers and tinkerers
2.) An N2K interoperability logo program that requires anything transmitted or received over N2K be in an appropriate message standard, and that if an appropriate standard does not exist, a new one be promulgated or an existing one extended.
3.) A user-updateable database of machine-readable message descriptions for interpreting and displaying simple sensor information on any vendor’s multifunction display. NMEA should maintain such a database for all message types in their standard, and all logo-certified multifunction display/control devices should be required to support it.
Okay.. Enough dreaming for now..
Well said !
Aaron wrote “The real problem here seems to be not N2K as a standard, but NMEA as a standards body.” … are others in agreement here ?
My thougths:
Clearly The physical layer isn’t at fault for the problems here. The same standards problems could happen just as easily over another physical layer.
Continuing on Arron’s dream:
I would love a standard based on XML. When a sensor needs to pass more information due to innovation then products that proceeded it, invent an XML tag and register it with the standards committee. If a user wants anoter vendors display to pick up data it wasn’t configured for, then specify the XML tag to use as a data souce and the dashboard component (bar, bar chart, gauge, pointer, numic, etc.) and position on the display for it to appear. For the displays, allow us to use a familiar tool (like microsoft excel with a plug in with controls) to design the display, output a file, and upload into the display via a usb chip, or share with other boaters.
HTTP support: XML tags for configuring a sensor or display isn’t so straightforward. Here it would help if a vendor would expose their configuration requirements in HTML, and chartplotters could include a browser to configure devices on the network. HTTP support is cheap, as shown today with vendors that offer sophisticated $20 routers that are http configurable and with security features.
I disagree that NMEA 2000 interoperability is “abysmal”; “confusing” would be more accurate. But I agree that while the Standard itself is pretty darn good, NMEA could really move things along by being more forthcoming with message information.
My boat came with a very rusty RDF and a Sailor VHF, so I’m starting with a pretty blank canvas.
I’ve just ordered a Maretron DST100 N2K transducer to fill the hole in the hull. Next will come the matching Maretron GPS and display. Their displays may be a little clunky, but they look to most robustly support device integration and calibration. My hope is that N2K will “stick” enough that the future choice of plotter will be eased by having an existing N2K network in place.
N2K may not be the ideal solution for high-end power users looking for total integration, but it looks great for a small boat like mine with modest aspirations, looking for greater purchasing flexibility.
Additional thoughts:
1) With ethernet and N2K each having their place on our boats, perhaps we will see an evolution away from a single N2K backbone, to having multiple small segments of N2K (e.g. engine controls, hull sensors, masthead sensors, power distribution, and cockpit displays), with each N2K segment, gateway connected to the others and the chartplotters via ethernet. Each gateway could provide the clock sycronization over ethernet and other future standards support such that the N2K devices themselves can stay simple and oblivious to the use of ethernet.
2) There is some pretty nifty distributed power offerings in the aircraft world that are just starting to mature in the marine industry. These offerings have their own backbone that can pump lots of watts between nodes that can power devices even as hungry as a windlass. Some use a redundant N2K communication path to allow power control panels to remotely control these nodes ( banks of circuit breakers ), eliminating thousands of feet of wire from each boat.
Perhaps with distributed power, the value of having power over xyx protocol will be mostly lost.
In such a world, maybe each device will get it’s own power seperatly since the power runs become much shorter to each node rather than a central 12v panel.
In this scenario perhaps USB becomes the preference for running a single network for high and low speed data. Imagine each boat component, sensor or display, has a tiny 3 port hub. Imagine how easy it would be to run the small size usb wiring thru your boat and either daisy change or ad-hoc branch devices together.
Yes, USB has power as part of the physical layer, either 100 or 500mw, but that would best be used for powering the mini-hubs in each component seperate from the primary component power that comes from the distribution node. In this way the components continue to participate in the network while even when the component is powered down at the node.
Just a thought.
Happy Holidays everyone!
You want IPv6? Just how many devices are you intending to put onto the boat? The main feature of IPv6 is that it has a much larger address space — the internet was not originally designed with the idea that everybody would have ten or twenty devices hooked up to it. Autoconfiguration is nice — and exists today with v4.
Realize (and this is something for the next standard) that boats are almost trivially easy to handle from the network’s point of view. It is hard to imagine even the largest megayacht having more than 50 devices that need to talk to each other. That is one techie’s desk at an Intel lab. All of the issues with bursting, latency, and syncronized time have nothing to do with such a tiny isolated network. Yes, time syncronization is an interesting and difficult problem — if you need sub-millisecond accuracy between New York and Tokyo.
I’d wager that this webpage has more data on it than any realistic boat would transmit in the about three seconds that it took to load on my machine — retransmitted across six routers from the xcore server in Boston(?) that hosts it to my Verizon provider in Seattle.
Ah well, Merry Christmas all (or Happy Holidays if you prefer.)
IPv6, DHCP? No need to go anywhere near that complexity. Those are network and transport level protocols that are not needed at all.
A little-known fact is that in reality, all devices on an ethernet network only communicate in MAC addresses, and at the data link layer, even those that use TCP/IP or any other network level protocol.
Protocols, such as TCP/IP and so on are software layers above the data link layer that are only useful in networks that connect to other networks, or require routers to separate networks.
Even if one wanted to connect to the internet, all that would be needed is a gateway that had the upper level protocols.
For instance ethernet can be used on the RayMarine E-Series display to connect two displays in a point-to-point configuration. Since it is point-to-point (and probably full-duplex), there are no latency or collision issues. I’ll bet there are only MAC addresses being used.
I have not put a network sniffer on so I don’t know this for sure, but I can see no reason to have any higher level overhead.
At present, I still believe that Ethernet is not the answer for the more trivial sensor and control network applications on a boat, but I never wanted it to seem like I was ruling out the appropriateness of Ethernet and IP as a gateway to those sensor/control networks or as data-link and network layers for higher-bandwidth connections between MFDs, radar arrays, high-definition SONAR, black-box radiotelephone transceivers and control points, etc.
While Panbo doesn’t exactly seem like the most appropriate blog on which to debate the merits or necessity of various networking technologies, it seems to be happening here whether we like it or not, so it is with that in mind that I will now reluctantly address some of the comments recently made.
IPv6 has far more to offer than just a much larger address space, and even if that were the sole benefit of IPv6 I can’t imagine why anyone would want to base a new standard around IPv4 – a protocol which we will slowly but surely see phased out, by necessity. There may be some resistance from IT managers and software engineers who feel lazy about learning new tricks, but the fact remains that on a planet of 6 billion people, we need a lot more than 4.3 billion addresses in our internetworking protocol. I’m also going to preemptively disallow any suggestion that NAT represents a valid or appropriate workaround. Anyone who has had the pleasure of remotely reconfiguring a device as simple as a print server residing on a NAT’d LAN can tell you how much NAT is impeding innovation, convenience and expression on the Internet.
Are we to be expected to set up VPNs or GRE tunnels every time we want to remotely tweak our autopilot’s settings or upload new routes, waypoints and cartography to our MFD without having to drive down to the dock?
Also, don’t let anyone make you believe that unroutable networks have much of any security benefit. In the late 90s it was considered fashionable to merely firewall a network. Anyone worth their salt will now tell you that only a single internal host needs to be compromised by some virus, trojan, adware or OS flaw to bring an entire NAT’d subnet wide open to malicious parties. In modern operating systems and applications, the emphasis is on securing individual hosts, programs, and protocols, not in assuming the wire to be secure. All NAT and the IPv4 address shortage do is make things difficult for legitimate users.
As history has shown, once a standard is in place, it is very difficult and/or expensive to update. I would hate to be advocating yet another IPv4-centric standard that will need to be rewritten before an IPv6 Internet becomes viable, and our marine electronics don’t become obsolete fast enough as it is, imagine the thrill of having to throw every IPv4 device out when IPv6-only marine electronics hit the market and vendors don’t see much incentive in providing you with a v6 firmware update for their older products. Linksys/Netgear/et. al. would rather you pollute some landfill with their older, but generally functional “routers” and buy something new with IPv6 support compiled in than provide you with a simple update, and I wouldn’t put it past the marine electronics manufacturers to employ similar revenue-generating tactics, even at the expense of Earth’s natural resources.
The fact that most of the devices we’re talking about are to be fairly dumb (transducers, tank level sensors, engine controls) is precisely the reason that it would be so easy to mandate IPv6. (that is, if you’re using Ethernet in the first place) All the device needs to do is speak the protocol with other compliant devices and talk to centralized (hopefully redundant) vessel device management server(s). Apart from that, and supporting some form of autoconfiguration, there wouldn’t be any other protocols to implement to meet the minimum requirements of the spec, and as such, no legacy IPv4-only protocol implementations to interfere with our goals.
Perhaps the fact that one can run other network-layer protocols atop Ethernet or the fact that Ethernet uses 48-bit MAC addresses is little known in some circles, but it isn’t around here. But just as I find it a pain to create a VPN tunnel every time grandma’s NAT’d digital picture frame needs to be reconfigured (and hope that we’re not both using the same RFC1982 prefix) I’m not going to want to tunnel Ethernet over the Internet every time I want to run some diagnostic tool or firmware updater on my autopilot from the comfort of my home. Properly secured, globally routable network layers really improve the quality of one’s life! :] I suppose this could be done through a gateway, but if you’re going to share an Ethernet LAN, make your life easier and have the devices do IP.
On a potentially shared Ethernet LAN, it is very important, no matter what network layer protocol is in use (yours or IP) that the application layer be secure. This means signed, if not encrypted control and sensor messages. We already have off the shelf tools for achieving this in the IP ecosystem. Why reinvent the wheel? We also have existing SCADA and object exchange protocols in that ecosystem to adopt, adapt, or learn from.
Finally, the suggestion that a control/sensor network would only realistically consist of around 50 nodes may be somewhat short-sighted. I don’t know about everyone else here, but in the connected and automated future I am anticipating, it will be perfectly commonplace for every light switch, light fixture, water heater, door lock, air conditioner, circuit breaker, etc, to have some sort of network address, and we’d better hope that by that point we will have long since fired any IT consultant who suggested that there was no need for IPv6.
If I haven’t yet persuaded everyone as to the necessity and benefits of IPv6, considder the fact that mobile carriers developing their 4G networks are planning for IPv6-based cell handover implementations because IPv6 Mobility solves the problem of triangular routing. The cellular data card in your boat’s router will have an IPv6 address (even if they will have to offer IPv4 tunneled over that while it gets phased out) and thus, the dream of globally-routable, persistent addressing for our boat networks becomes a reality.
Anyway.. Didn’t want to go off on a tangent/rant, and I’m sure some people will continually refuse to agree that we might want all networked devices to have globally routable addresses (even on a boat with spotty connectivity!) but I see these kinds of attitudes everywhere and try to persuade people otherwise where I can.
I also hope that nobody takes this the wrong way. I tend to get a little fired up about network engineering issues, but I don’t mean any personal offense to anyone and hope the debate can remain civil.
Merry Christmas/Whatever to all! Need to head up to my parents’ place for dinner now! All of these discussions are somewhat hypothetical for me, of course, because I don’t see myself as being able to afford a big enough, liveaboard sailboat on which to test these ideas any time in the near future. Hooray for armchair cruising!
Ps. b393capt: Your talk of XML, etc, is exactly what I was getting at – I just try to avoid naming specific technologies and speak of things conceptually instead. Also looking forward to distributed/redundant power architectures and remote control of panels, etc. Not so keen on using a chintzy, distance-sensitive and hierarchical architecture like USB for my low-bitrate sensors and controls, but I think we share the opinion that the kinds of “dumb” devices that reside in bilges, atop masts, or in anchor lockers should probably be connected back to the “decision making systems” over some sort of simple, electrically and mechanically robust bus, even if it all eventually goes through an IP gateway of some sort.