• Home
• Forum
• Classifieds

Previous Entry
« More SPOT, & a Globalstar class action suit

Next Entry
More SimNet, plus the handy AT10 »

ActiveCaptain: Data delivery changing, but free access assured
Ben Stein said: Kim, I can't remember where but I know I read that Gar...

Furuno MIBS 2018: from TZT2BB megaMFD to GP-1x71F plotter fishfinders
Nigel Spork said: Ian This has annoyed me as well. Not a lot of benefit...

AIS issues: Garmin, Navico, McMurdo, AMEC and SRT
Simon - SRT CEO said: Hi Jim, TUV SUD and BSH are the gold standard of test ...

Simrad RS35 VHF & HS35 wireless handset, testing pretty well
Ben E said: Navico says that there's no meaning to the RS-35 being ...

Nautic-On, Brunswick's smart take on boat monitoring
Hartley said: Hi BenS, 10 mw at 1.9 GHz - doesn't sound like it sho...

Sonar wars flare: Humminbird Mega, Garmin UHD, Lowrance FishReveal & more
Ben E said: Sure enough, Simrad just put up their NOS 59 update, ve...

NMEA OneNet 2013, already ahead of the curve?
Ben E said: NMEA has posted the OneNet presentation given at METS l...

Airmar 2018 part 2: Ultrasonic and EM speedo mysteries unraveled, plus new UDST800
LarryR said: Hi All, We have two DX900+ units on our 60' cat and we ...

Lowrance MotorGuide Xi5 SmartSteer trolling control, life changing
Ben E said: Lowrance is out with a NOS59 software update for many o...

Beta testing FloatHub boat monitoring, and the wonders of marine WiFi
tulsi chowdhury said: as marine electronics have gained a lot of popularity, ...

"My" magazines:
Power & Motoryacht
Sail Magazine
PassageMaker
Soundings
Soundings Trade
Yachts International
Maine Boats, Homes…
Marine Electronics

Electronics favs:
The Marine Installer's Rant
Compass Marine
SailBits
Signal K Google Group
Pacific Yacht Systems
Ed's Boat Tips
i-Marine Apps
Navigation Mac
gCaptain
Alan Spicer Marine
Equipped to Survive
GPS Tracklog
…forums:
The Hull Truth
Cruisers & Sailing Forums
SSCA Discussion Boards
Continuous Wave
macsaililing.net
BoaterEd
…companies:
Garmin On the Water Blog
FurunoUSA Support Forum
Raymarine Support Forum
Digital Yacht Net
Victron Energy

Other favorites:
MV Dirona
Wave Train
Indigenous Boats
SetSail
Attainable Adventure Cruising
Three Sheets Northwest
Waggoner Guide
Scuttlebutt
Sailing Anarchy
Corke’s DIY
Sea Fever
VOJ (Ibsailn)
Ken’s Blog
Megayacht News
Power Cat World
Marine Cafe
Kennebec Captain

Suggest a link or story

This work is licensed under a Creative Commons Attribution, NonCommercial, NoDerivs 2.5 License.

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.

Everyone, I Just got back from vacation, enjoyed reading your comments.

I am especially excited that my first guest entry in Panbo received so much feedback.

Take my replies below as either supportive of a future Ethernet “for marine” standard as either complimenting or replacing N2K ..

George & others
--------------------
Power over Ethernet isn’t helpful as the high voltage level (needed to transport enough useful current over a thin wire) would lead to inefficiencies stepping it up/down at each end of the circuit.

However, no worries.
1) Most all of us would gladly trade away having power and data combined in a single cable, to get access to a proven, versatile, high-speed and cheap standard as Ethernet that we are already familiar with in our homes/offices.

2) The lack of a good power over Ethernet standard isn’t a big deal looking forward as distributed power systems such as the Moritz Octoplex will revolutionize how we power devices on our boats.

3) Even with N2K many devices, such as color instrument displays, have separate power connections to prevent overloading the N2K bus or just to give the user the ability to turn power on/off from their DC panel.

4) Maybe power over Ethernet could be adapted for marine use, by running 12vdc instead, and just having very low expectations for how it used. For example, powering the hub/communication element of a component separate from a components main power that would be switched on/off at a DC-panel or distribution power system. (See my previous posts as to why this is helpful)

Aaron - Dec 20 post
----------------
1. I strongly believe clock sync is necessary. Messages would just need to be tagged with a time reference. E.g. If I am a heading sensor, I should tag each message with what time I think it is when I took heading measurement, so that an element reading my messages can accurately deduce rate of turn by reading multiple messages from me that might not arrive as timely as I sent them.

2. IPv6, yep

3. QoS , nope lets omit this complexity. Segregated Ethernet segments, optional support, fine. I think for most of us both are unnecessary.

4. Capacity regulated, nope, let cheap $30 routers do the heavy lifting if the need arises.

5. Multicasting / Broadcasting … hmm, this is where a future standard would need to have some work done to find a tradeoff between redundancy, complexity, and using off the shelf components.

6. Heartbeat messages … yes, absolutely

7. Signed messages, yes, absolutely

George – Dec 22
-----------------
Right on … we can do without the worries of time synchronization.

Awboater- Dec 24
-------------
No wait … I want my TCP/IP … need browser access to configure devices, since a slick protocol has yet to be invented to standardize configuration of devices on a network.

I agreed with Aaron’s posts in favor of IPv6

Aaron – Dec 24
--------

Right on !

1) Debate the merits of Ethernet here? I am game if Ben doesn’t mind!

2) Ethernet not appropriate for sensors? … how about if it was Ethernet over USB cabling, or better yet wireless? I like the USB cabling from the standpoint of being cheap, standard, easy to snake thru the boat, and I believe the 5 volt power is just right for achieving low power consumption for sensor devices maintaining a communication element of a device powered while the primary function of the device is powered off. I am not familiar with, but see that there are standards for Ethernet over USB (see wikipedia). I like the idea of a future where every sensor is browser accessible for purposes of configuration / diagnostics, and with mass produced single chip solutions available any device can cheaply have a usb port and be browser capable. Maybe some single chip solutions include support for digital signatures?

Possibly the usb wiring is entirely unnecessary. A recent tour of some advanced projects at Stonybrook University in regards to sensor networks convinces me that we can reliably have a wireless sensor network in our boats, with the communication element being extremely cheap (under $10) for vendors to incorporate into their sensors.

3) IPv6. Big agreement also

4) Not sure if I want my boat connected to the global network, but my wife and daughter might. Either way, the same benefits of security would apply if my boat systems were exposed using wireless communications as I promote.

5) USB – chintzy, distance sensitive, and hierarchical; Hmm, maybe. But just like we don’t run Ethernet to every device connected to our desktop computers, usb can similarly compliment Ethernet on boats. By using the Ethernet protocol over the usb physical layer, we can overcome the hierarchical issue. Better yet, make communication wireless for most of the devices on our boats that are non-critical.

Happy New Year!

Is there anything (in support of this dream) that might already be happening in the automobile industry, e.g. an Ethernet replacement for Canbus ?

Is there no interest in continuing this thread?

e.g. debate the merits of ethernet, debate if thoughts about time-syncronization and power-over-ethernet are necessary requirements for ethernet to be a worthy base from which to build a future nmea-2000 replacement ?

NMEA 2000 is a nice concept, but I wonder if they made the right decision to base it on the CAN bus. That was around 1994 I think. If they were making that decision today it might be different.
Ethernet has not stood still. Boeing and Airbus have decided to use Ethernet for the avionics network in their planes. ("AFDX")
http://www.dedicated-systems.com/vpr/layout/display/pr.asp?PRID=10587
http://www.aviationtoday.com/av/categories/commercial/12652.html

Thanks for the links, Norse, but I didn't see anything in there about using Ethernet for low bandwidth sensors like wind and depth transducers, fuel levels, etc.

In fact, it sounds like they're using Ethernet just like we are -- i.e. NavNet, MarineNet, etc. hooking together high bandwidth multifunction displays, radars, black box fishfinders, satellite weather receivers, and so on.

I hesitate to say too much -- so it doesn't sound like a rant. NMEA 0183 was flawed, but it was useful and simple. It's flaws were mainly problems when it was used for more than it was designed for. That was 1980 - 1983, so we can't really complain that they aimed too low or lacked vision. NMEA 2000 was meant to fix the problems with 0183 and was more backward-looking than forward-looking. That's my opinion from reading NMEA's website. People now want to do things beyond the scope of the standard. Sound familiar? I do fault NMEA for lack of vision. Except this time it is not simple and not cheap. Conceptually it is, but why does it take 8 or 9 volumes at about $1000 each to explain it? For comparison, they sell the 0183 documentation for US$270. Part of the reason for CAN bus was that parts were cheap. But Ethernet components are cheap now too, and they can certainly handle low bandwidth sensors. For being a replacement for 0183, one thing 2000 has certainly not done (and shows little sign of doing soon) is replacing 0183!
So 2000 is too expensive for the low end and too limited for the high end. And it lacks the PGN support to make it interoperable. That will be the key to success.

Norse, if, say, an Ethernet transducer were such a good idea, why wouldn't Furuno, Garmin, Northstar, or someone similar make one to work with their existing Ethernet systems? And what would be the advantage?

Look, I've been very critical of the industry for confusing consumers by rebranding NMEA 2000, making proprietary cables, and so forth. But we're moving past that, and I can guarantee that you will see lots of N2K replacing normal 0183 sensors this year and beyond. There's a good deal of interoperability, too -- I've seen it first hand often -- but there are some glitches.

At any rate, I've got my test NMEA 2000 network back in operation, already have an Ray ST70 and a basic SeaTalkNG network in the lab, and am hoping to also try Garmin, Furuno, and Simrad instruments, and SimNet, alongside each other and together.

I looked at prices of a few marine products which are available with a choice of interfaces and that doesn't affect the price very much. The main hardware difference would be in the cabling and hubs the user would need. NMEA cabling does have its advantages. But the biggest difference is compatibility -- NMEA offers that. I'm sure Garmin and Furuno would rather focus on big-ticket items and let companies like Airmar make the transducers.

When I look at the Furuno FL50 instrument, apparently the wind transducer still connects analog right to the back of the wind instrument.

I imagine another approach would have been to have the analog wire of the wind transducer run to a converter that would then connect to the NMEA bus more local to the wind transducer, or place it on the wind trasducer itself.

That they run the analog all the way to the instrument display ... is that because configuration or remote calibration of such a transducer isn't supported over N2K ?

Would it have mattered if NMEA-2000 was ethernet based instead ? Maybe with the converter supporting a browser based connection to a calibration screen ?

I found an Operator's Manual for the Furuno FI-50 instruments, including installation instructions:
http://www.furuno.fr/Multimedia/om-FI501-2-5-6.pdf
(It's in English, despite the domain)
techie stuff, not marketing!

The wind transducer is indeed direct-connect to either the FI-501 or FI-502, and then the info gets forwarded to other NMEA 2000 devices. The cable has six wires in it. Obviously the smarts is in the display, not in the sensor, and not in a pod at the base of the mast. Why? I can guess. I don't think it's a technical matter.

NMEA 2000 is new. There won't be many boats with an NMEA backbone yet so this makes it easier to get started. Especially with a sailboat. The expected PB200 will provide the NMEA 2000 alternative. They must have something in mind for that NMEA connector on their radar.

Compare the Simrad IS20 wind instruments and the IS20 Wind Vane. This wind vane is NMEA 2000 (SimNet).
http://www.simrad-yachting.com/Products/Leisure/Instruments/IS20-Instruments/

Norse, Yes, I see. Even the depth & speed apparently have the analog-digital converter logic and NMEA-2000 interface right in the transducer. Didn't go deep enough, but it would make sense the transducer is sealed rather than having an nmea connector right on the transducer.

Well no reason this couldn't have been Ethernet, if that had been the standard instead.

Although what would be the benefit of a transducer manufacturer offering an Ethernet at this time?

It would be pointless to offer, until there was a standards organization to define XML sensor data elements tags and other aspects of a marine Ethernet standard, rally the industry, etc. ... vital things the NMEA did for the N2K standard.

Should such a marine Ethernet standard get started tomorrow, who could guess what the result would be? A marine standard looking forward in time may choose not to use CAT6. There might just be an element of a future marine standard that cares for low bandwidth transducers signaling over the a +12 vdc and ground wire running into the transducer, or a variation based on 5 or 48 volts instead, or just be wireless like Tacktick is today but with a security certificate it picks up in a registration process performed during install like the wireless sensor nets in academia being developed now (e.g. Stonybrook University CeWIT)

"what would be the benefit of a transducer manufacturer offering an Ethernet at this time?"
It would be a niche market and I doubt it would appeal to established manufacturers because of that, but it might be an opportunity for a start up, someone who wanted to compete on affordability. That got Bill Gates started.

If such a thing were to start, it would not need a standards organization. One smart player could work out all the details, and if he was really smart he would make them open-source. NMEA is not the first standards organization where you have to wonder if they are helping or hurting. I'm sure their intentions are good, but I think they have more than they can handle. With CAN bus, there must be some extreme testing and validation. It was designed for a closed environment. If BMW uses it in a car, BMW gets to choose all the pieces and make sure they work together. That's not at all like how NMEA 2000 is used on boats.

The other advantage of "Ethernet" that b393capt touches on is that it could utilize fibre optics, wi-fi, etc. In fact having a mesh of wireless sensors is a hot topic. See IEEE 802.15.4 and ZigBee. Sun has made their "Sun Spot" device open source now -- if you've ever wanted to make your own wireless transducer, this would be a very good place to start.

Norse wrote "... but it might be an opportunity for a start up, someone who wanted to compete on affordability. That got Bill Gates started."

Agreed, although I rather like the idea of an open standards committee instead .. I would like to be involved.

In absence of that, if some startup company or the next Bill Gates of marine electronics is out there reading this ... I ask that he/she looks me up, I think I have a lot to contribute.

I discovered this thread too late, sorry, and hope it has not been exhausted. In a sense I’d like to get back to basics and restate a few overall goals, especially from the point of view of a sailboat user.

(1) Cost: Compare the cost of a plotter versus a PC running mapping software and GPS, and you have the most blatant reason for allowing universal IT standards on a boat. Ethernet and Internet are ubiquitous and instantly widen the field of suppliers. Wireless is progressing at an exponential rate.

(2) Cabling: The complexity and weight of cabling is a prime concern in sailboats. It makes a huge difference when devices may be daisy-chained on a “bus” rather than individually wired to a server. The typical Cat6 TCP/IP net found in homes and offices is a star-configuration ill-suited to boats, and we’d face an overload of powered hubs/switches. A backbone bus would be first priority, at least to parts of the installation. Where a combined data/power cable can be used, so much better.

It is for the same reason I mourn the scarcity of 24V installations in pleasure craft; on a 40ft sail yacht the thinner wiring for 24V gives a weight reduction of several hundred pounds.

My wishes are for all the more remote sensors to be wireless, with only a short-run central cabled net securing the essential controllers. Swapping the wind sensor in a 55’ mast for a wireless reduces weight by several pounds along the most critical vector, and removes a major maintenance risk.

(3) Real-time data: I don’t see valid arguments against using Ethernet at the core, and TCP/IP for all but the most time-sensitive data traffic. In fact, I fail to see that “real-time” considerations apply on a boat. To take the example of RPM or Rate of Turn, for example: the issue is not that I (or a device) receive information in real-time, but that the input is time-stamped or smoothed. The processing device can easily smooth inputs to a corrected value on the fly. GPS is a great example of how accurate it can get: Before your GPS displays a position, it has smoothed and averaged climatic conditions, refractions in the atmosphere and sampling errors over huge distances, while your boat was rolling and heaving.
I run a company delivering broadband with VoIP and TV over wireless, and if real-time issues are overcome in systems like ours, handling signals that span the globe over hundreds of relaying servers, a yacht management system is indeed small change.

To say it brutally: Is it not embarrassing that my all-Furuno system has a several-second delay between speed data displayed on the plotter versus on the FI30 instruments? The system was “state-of-the-art” in 2006, albeit one of the most complex Furuno has installed. Nobody can tell me that manufacturers of boat systems are at the forefront of real-time computing.

(4) Higher layer protocols: b393cap is so right in mentioning XML. That, and most of the Internet protocols, would not only be handy but in users’ interest, because they give us a host of tools for free. Browser-based administration and calibration is the beginning, followed hard on its heels by instrument outputs we can import into all kinds of software. I developed for fun a database for my boat, and included of course a captain’s log. The missing bit so far is automatic position stamping of each entry, taken from the GPS. It can be done, but you have to deal with serial feeds, NMEA sentences and hardware issues that seem out of proportion to the simple request: “output a position to me when I press this button, please.” Almost any device in the Internet universe could be queried like that without a fuss.
It seems indeed that N2K is less of an innovation than a last-ditch attempt to keep boat communications within a proprietary circle. I fully agree with Norse on this point, and there is indeed an opportunity for a start-up to crash the party with a full Ethernet/internet application for boat management.

(5) Security, reliability and so forth: I was puzzled that Aron G dislikes VPN for remote management. I would have thought to the contrary that VPN is precisely what we want, and what we get for free if boat systems had an internet-compliant core. You could log on from home and not only check all systems but also stop/start some of them, e.g. an onboard heater or a surveillance cam. Internet gives us far and away the richest set of controls – need I remind anyone that the utterly simplistic NMEA-0183 system works with common technology of the 1950s-1960s?

Internet protocol is where it is all happening, in a huge market compared to boating. We do not require Cisco 3500 switches and SNMP management onboard our boats - they are after all not Fort Knox, but if you wish to individually expand the systems on your boat, you don’t have to plead with Furuno or Raymarine to build it for you.

Take, for example, the neat feature of “subnetting” in TCP/IP nets. With the simple use of subnet masks you can reduce traffic in your net, allow and permit individual devices to talk to each other, and set up clusters that make sense on your particular ship. This combined with the opening and closing of “ports” in the Ethernet universe, can e.g. constrain video traffic to the devices that need it. 1Gb Ethernet would be the minimum standard onboard today, and with that you have ample capacities and only a theoretical risk of overloading your network.

One final and sobering thought: if a PC manufacturer were to launch a PC with the major connectors and protocols for marine use built in, you would soon see an explosion in boat management systems, all in software. My guess is that such a manufacturer would, in turn, step by step persuade the hardware manufacturers of transducers and sensors to transmit in a single protocol. It’s the story of USB, Bluetooth and 802.11a/b/g/n all over again.

To be fair N2K would have been an innovation if it had been real when it was first proposed. It's still an improvement over NMEA-0183 and other proprietary systems.

What I want is to be able to take the data from all the transducers and do whatever I want with it. I would display it differently, since I won't like the choices the manufacturer made for me. I would also like to see past data. For example, on the plot that shows my GPS position, I should also be able to see what the wind direction and wind speed was at that point, or what the engine rpm was. The old instruments showed current value, max, average, etc. The new instruments should be able to show a plot over time.

I saw an ASUS Eee PC recently. I like the direction this niche is going. The manufacturers of marine systems are going to be facing some very tough competition soon.

OsmundL: Thank you for your contribution to the thread. I see we are largely in agreement, and the advances in wireless this year make my posts from 2007 look like a statement of the obvious rather than forward looking.

Norse .. "I want to be able to take the data from all the transducers and do whatever I want with it" ... Yes, as do I, and I see XML as a key way to make that happen. There are numerous free software tools I have seen over the last six months that could take XML data and arrange into the graphical dashboard of your dreams. I see people in my company that have no programming skills do this with commercial software like Business Objects excelcius (generates a flash file) and email these dashboards to each other, and add them to my software product. People in my programming team do the same with free software.

If only our sensors could provide XML data .. and only if you could load those flash files into a smaller display than a chartplotter ... something like a Raymarine ST70 display.

All: This last week Breeze Pleeze got her first N2K network ... the back bone is 3 meters long (well ... actually it's 9 inches wide since the back bone is curled up in a loop with just two devices and power attached). It worked flawlessly, I was so excited ... I had set aside some time to debug it and now had all the extra time on my hands. My excitement was dampened when I desired to look at the data so I could evaluate the output of the new N2K sensor against an old one. I dropped into the trusty diagnostics screen in the chartplotter ... only to see FF A2 EF FF 00 A2, etc. Damn, I was hoping to see deciphered PGN's so I could see the decimal point in the heading of this hot solid state compass I was checking out, too see if it drifts less than my gyro correct flux-gate, but seems I was expecting too much. FF A2 EF FF 00 A2 ... and no manual at hand to convert it ... well, actually there was a work around ... I directed the heading information to a NMEA port on the charplotter and then looked at that on the diagnostic buffer capture ... if only this was in XML life would be so much simpler.

Dan, That PGN gibberish is peculiar to Raymarine E Series (and hopefully will be improved). It is possible for an MFD to show the PGN steam in plain english, though the only ones I recall doing so are the no longer available Simrad CX series. On the other hand, some N2K devices don't show raw PGN data even as well as your Raymarine E. There is no standard.

Thanks for visiting Panbo.com Home | About | Archives | RSS Feed