OneNet, NMEA finally creates a marine Ethernet standard!
Yes, I have known something about this for a while (because I promised not to write about it), but it’s purely coincidental that NMEA is announcing OneNet just after we once again discussed the crying need for a NMEA 2000-to-Ethernet/WiFi standard. OneNet appears to be all that and much more…
Before I go further, though, please note that this is an announcement of a standard that is “scheduled to be operational by late 2014″…so we’re talking about the future of marine electronics, not the present. That said, here is the full press release PDF. One of several things I find interesting is that the top listed goal for OneNet is to “Transport NMEA 2000 network messages on Ethernet in a standardized manner” or as the release’s subtitle says “Think of it as NMEA 2000 on steroids.” That’s because OneNet will break out of N2K’s speed and node limitations big time, like increasing the maximum number of devices from 50 to over 65,000! (Now, that would be quite a vessel.)
Note, though, how NMEA Technical Director Steve Spitzer cautions that “OneNet is not recommended for real-time critical data, because the NMEA 2000 Controller Area Network (CAN) enables prioritization and guarantees that the message transmitted will always get through to certified devices.” And note too that the OneNet committee — a broad group of manufacturers plus concerned organizations like the U.S. Coast Guard — “believes that OneNet will not replace NMEA 2000 or NMEA 0183 within the foreseeable future. Each will have its place on a boat.”
I’m sure that some Panbo readers who know more about Ethernet than I do will have things to say about technical details in that press release, but I sure like the idea of standarized Power over Ethernet (PoE) able to deliver up to 15 watts (per device?) and especially an agreed upon way to pipe audio and video around a boat. But there’s much that’s unsaid too. What will the OneNet standard for connectors and cable look like (assuming there is one)? What about radar and sonar? Will a certified OneNet Gateway be able to support apps that are relatively easy and inexpensive for developers to get approved (as planned for the USB gateways)? What else?
And, finally, is it reasonable to take two and half more years to get OneNet operational? I have never been involved in a standards making process — small town harbor committee doings are hard enough — and certainly wouldn’t venture a dgement on that. (Some of you may have opinions, but please remember how tiny this industry is.) Overall, though, this sure looks like more evidence of what Patrick wrote today: “We’re at a good point in time for boat electronics, and it’s only going to get more interesting!”
“OneNet is not recommended for real-time critical data, because the NMEA 2000 Controller Area Network (CAN) enables prioritization and guarantees that the message transmitted will always get through to certified devices.”
This NMEA notion that Ethernet can not support real-time apps is not correct. For example, see http://en.wikipedia.org/wiki/TTEthernet
Most standards efforts take 3-5 years start to certified product. NMEA has taken much longer.
I hope they take this the whole way up into the IP layer. Addressing, service discovery, streaming video, etc. These are all solved issues in IP land.
Cheers
Great news for users of NMEA 2000 equipment.
Is the OneNet in any way related to IEC61162-450 LWE (bridging NMEA 0183 and ethernet devices) or is it a new parallel development designed specifically to include NMEA 2000 on the ethenet?
Will LWE and OneNet devices be compatible?
http://webstore.iec.ch/preview/info_iec61162-450%7Bed1.0%7Den.pdf
OneNet is not compatible with LWE, because it transmits NMEA 2000 PGNs, not NMEA 0183 sentences.
Casey
I don’t know if it’s germane, Johan, but I did notice a “OneNet/0183 Gateway” in second system diagram.
The NMEA 2000 claim that “NMEA 2000 Controller Area Network (CAN) enables prioritization and guarantees that the message transmitted will always get through to certified devices” is misleading.
There is prioritization, but this can create a situation in which a high priority, high transmission repetition device can prevent lower priority devices from successfully transmitting some of their data. There are major limitations on NMEA 2000 net traffic and software developers are specifically warned to avoid “open ended” device communications as much as is possible.
It is difficult to see how OneNet has any advantage over just using Ethernet. Ethernet is a well established technology that has the capacity of communicating both instrument and video data.
A standard for Ethernet packet representation of NMEA 2000 sentences would certainly be welcome, especially if the data formats are publicly available.
Wait! wait! I’m out of popcorn Can you guys hold off for a half hour? Oh yeah, I’ve got to find my “Ethernet for Dumbies” too.
Where did you see the situation where data was lost on NMEA 2000, Robert? My impression is that NMEA overlaid quite conservative limits on what’s actually possible with CANbus. I think that’s why Maretron was able to build a network extender that can double the available nodes and hence increase the data volume. They are responsible for a lot a large systems out in the field and I don’t think they have much tolerance for data loss.
If you mean free when you say “publicly available” you may well be disappointed. But all the NMEA standards documents are publically available in the same way many other open standards are. We’ve been over that prickly ground a lot on Panbo and I don’t think anything new can be said that wasn’t already argued out here: http://goo.gl/9HraK
I understand that the committee has no intention of altering the physical layer of ethernet, so conventional cables and connectors are presumed. Since marine electronics represents no more than that a single gnat in the swarm its doubtful the market could support the cost of reinventing the wheel.
Water proofing and splash shields are another matter. Is it too much to ask manufacturers to agree on a common type, or provide extension/conversion cables to a common type?
I too have just recently seen the OneNet Press Release and it is the first I have heard of it. As one of few Vendors marketing NMEA 2000 to Ethernet Gateways, I am some what confused by the claims but this may due to the lack of any real information even as a NMEA Member.
However, a few comments. NMEA 2000 is based on the CAN Bus which was an “Open” system. Then NMEA created a specification to describe how data may be exchanged using CAN Frames and thus “closed” it by enforcing license and fees for anyone to use it. In other words, NMEA took an already existing data Transport and found a way to “own” it. Can OneNet be the same all over again?
Ethernet has long been well established with lower layer specifications for data transport and connectivity. TCP is very reliable when data has to reach the destination and is not repeated. UDP is better suited for Live Data if logging is not needed. Perhaps the NMEA statement “OneNet is not recommended for real-time” refers to the TCP side of Ethernet as there may be some delay between when an event happens (Temp Alarm or Throttle Position change) and when a network device sees it but TCP will make sure all the data eventually gets there. However NMEA 2000 does suffer from the same issues just on a smaller scale.
I have to agree with Robert, what is needed is some sort of “SIMPLE” Ethernet Packet representation of NMEA 2000 data and not reinvention of Ethernet just to collect some additional License fees. Ethernet already has device discovery, data transport, error detection/recovery, and security is place. Why not just ride on top of that in the APPLICATION Layer. That’s how the rest of the world does it.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmat.net
Where did you get that understanding, Sandy? There are many places on boats where conventional Ethernet connectors are not suitable, which is why all the majors came up with waterproof connectors, often sourced from industrial suppliers. It seems to me that all NMEA has to do is pick a suitable design already in production, like they did with DeviceNet for NMEA 2000.
A standard for water-resist Ethernet Connections would be high on my list. RJ45 jacks do not cut it in the marine environment. They are not in any way marine-ready.
We use something similar to DeviceNet but I would love to see something that we all can use, especially in a Marine Router.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmat.net
Waterproof RJ45 connectors are available now:
http://www.assmann.us/index.php?main_page=index&cPath=143_147
Besides, some “marine” equipment uses conventional RJ45, eg: Rogue Wave, and Victron Multi inverter/charger.
Those are USB connectors and, besides, the right marine Ethernet connector will be easy to fish through tight runs as well as waterproof. It would also be nice to have a field connectable connector option.
On further reflection, I think both Navico and Raymarine (latest HS connector) are making their own Ethernet cables with connectors that are fairly trim and waterproof. They are not RJ45 with extra protection. Coming up with a standard system may be harder than I thought.
This is a temporary fix for instances in which proper watertight cable connectors are unavailable.
We use polycarbonate watertight boxes to protect the electronics and watertight compression glands for passing cables into the boxes.
there is allready industrial and military weatherproof usb and ethernet connectors. they were made for industrial high chemical, high corrosive environments. i seen them while searching for waterproof cable connectors for my electrical system. it should not take much to pick one that is adequate and robust enough for a marine environment. even the mil spec connectors were not to expensive
Coming up with a standard is easy. Getting everyone to adopt it is the tricky bit 🙂 I really can’t understand why NMEA want to reinvent the wheel. There is a well-proven transport protocol that’s used by industry and the military throughout the world – literally billions of people use it. All they need are the sentences to transmit over it.
This isn’t meant to be an advertisement.
We have done business with L-Com for several years and they are a reliable distributor of quality products.
This link shows some of the weatherproof Ethernet connectors that they stock.
http://www.l-com.com/productfamily.aspx?id=2834
The “Garmin Network” connectors are RJ45 reverse CAT5 STP connectors & cables. The connector and outer jacket protective sleeve and locking ring are one of the best water resistant RG-45 set ups I have come across.
Bill Lentz
MV;WIRELESS ONE
Robert, those ruggedized RJ45 connectors really won’t do. Too bulky. The Garmin connectors Bill references are better because the outer flange is detachable when you run cable. But I don’t think that the ideal marine Ethernet plug will look like RJ45 at all. Check out Navico and current Raymarine c- and e-Series Ethernet cables; slim, waterproof, and no extra parts.
Slim is very important on boats, both for the cable runs and for getting the maximum number of ports on the backs of devices. One of the major complaints I hear from installers and do-it-yourelvers is difficulty running cables.
I have to imagine some folks on the NMEA committee are reading this thread. To them I would like to ask…
1) Is the communication from OneNet Switch to OneNet Switch published/licensed? Does smartphones and tablets north of the OneNet switch (say an iPad over a Wi-Fi) need to have some license and new protocol to reach thru the OneNet Gateway?
2) If yes to (1), is such protocol a 2-way protocol, or is it 1-way only, e.g. boat to PC like current NMEA-2000 gateways?
3) If yes to (1), does the companies that create software on smartphones, and tablets need to be licensed / members of NMEA-2000 ?
4) If the OneNet committee is still working on what the licensed fees are, would they consider putting the fees in the OneNet switch. E.g. once the boat owner pays for a OneNet switch they effectively have paid all the licensing fees once to use NMEA OneNet protocol ?
5)Can a NMEA-2000 network be connected to two OneNet Gateway’s for redundancy?
6) Can a sensor with Wi-Fi wirelessly connect to the OneNet Gateway?
Where do you get this stuff, Dan?
NMEA protocols have never been licensed to end users and I’m 99.99% sure they never will be.
There already is a NMEA 2000 Third Party Gateway (TPG) policy in place whereby apps get tested and N2K Approved on specific gateways for $100 (plus the cost of whatever standards documents the developer needs for his/her particular applications). It’s not done yet, and Actisense is the only player so far, but it seems reasonable to assume the a more standardized N2K-to-Ethernet/Wifi will work similarly (though I still asked the questions above).
The TPG program, which has been covered extensively on Panbo, has always been conceived as bi-directional. It can be argued that app developers who only listen to the network shouldn’t have to jump any hurdles at all, even $100 ones. But there are no signs that NMEA will actually contest such apps. Their primary concern seems to be protecting the integrity of the N2K network, which is not an issue for receive-only apps. A secondary concern is generating revenue to support the standard. Put the two goals together and you get the document fees, certification cost, et al that the developers of gateways and other NMEA 2000 hardware must endure. I imagine there will be similar costs to OneNet.
Anyone who thinks this style of standards creation is wrong ought to review the history of NMEA 0183. At least early on it was not copyrighted, it was unfunded, and there was no certification process. It did not work well over time. If N2K is a bit too tightly controlled in some ways, there’s a primary reason.
PS. Dan (and others), there’s no doubt that some OneNet committee members are reading this thread. But they don’t get to express their individual thoughts about how OneNet should or will end up. It’s easy for us to spout off but it’s hard for a diverse group to actually make policy.
Ben,
The new Raynet cable (Ethernet) as implemented on Raymarine new C and E series has a connector diameter of around 18 mm. This is an initiative by Raymarine to have a more user friendly version of their previous HS (ethernet) network connector.
http://www.outbackmarine.com.au/public/upload/productimage/4549-2364-4.jpg
Let’s not forget the Lowrance/Simrad ethernet connectors,been around for a while and seem to work well.
Haven’t we already had this discussion and been dubbed the “Ethernet crazies”? OK, one more time.
We don’t need NMEA or NMEA 2000 at all, they are not adding value. We just need the manufacturers, the same ones which choose not to honor NMEA 2000 and thus doomed it from day one, to agree to use ethernet and publish their data packet formats. They will ulimately do this because it will save them money; open standards serving huge markets with hundreds of component suppliers are vastly less expensive than proprietary standards and a tiny market served by a handful of suppliers.
iOS and Android destroyed RIM and Nokia, the giants of the industry, because they enabled third parties to build applications within constraints that seem incredibly wide compared with NMEA and NMEA 2000.
As has been previously stated, ALL of these problems that NMEA 2000 “solves” were addressed years ago in ethernet land. Rugged packaging, power distribution, message prioritization etc., etc.
NMEA 2000 is a 250Kb network in a 10Gb world. It serves no purpose and delivers no unique value. Ethernet is technically superior at lower cost for everyone involved. This announcement is the formal beginning of the end of NMEA 2000 and NMEA as a standards body.
The king is dead, long live the king!
Where do I get this. Past experience as a board member, and committee chairman of an industry group of big telephone companies and their vendors in the area of voice mail and messaging technologies.
Not unlike the NMEA, we needed a way to fund our good work.
Going back a bunch of posts, I wondered in a comment if a better way to fund NMEA’s good work in standards creation is to license to the end users, e.g. collecting a small license fee from each boat owner ($100 ?) who wants to open their NMEA-2000 network up to PC’s, smartphones, and tablets. As opposed to a larger membership fee from a small number of members, more funding could be generated for NMEA, and the software developers would have a far lower cost of membership and product certification.
This is a bit late development as there is an open real-time protocol IEC61162-450 that anyone can use for free to create Ethernet or WiFi networks. The packets have a small header plus the same content as there used to be on serial wire. Every sensor is multicasting its data so one talker has multiple listeners. You are allowed to use gigabit-networks if you want as well as optic fibre to get rid of performance problems and corrosion.
Sorry, Dan, I forgot that you suggested user data licensing in a previous post. But, as I recall, your idea didn’t generate any obvious interest, and my opinion is that it’s too complicated and also a fix for a problem that doesn’t really exist.
NMEA 2000 and NMEA are actually doing OK, I think. If there’s a problem it’s the pace of standard making but I don’t see an easy fix to that. I know that some will say that it’s simply a matter of “open sourcing” the standard, but NMEA pretty much tried that with 0183 and it didn’t work out well over time.
Russ, the term of endearment that I coined back in 2010 was “Ethernutters” and I’m glad you reminded me of it. More to come.
OneNet has no advantages over Ethernet. It’s not intended to. It’s intended to keep NMEA as an organization relevant.
If they were serious about this, they would make it an IEEE standard. It remains a closed, proprietary standard with a very small club of investors.
As a result, state of the art will always be many years away.
Sorry. I’ve been involved in standards bodies for years. I’ve seen this before.
Very well put that the NMEA2000 standard could and should be a IEEE standard if it wants to gain momentum or accuire additional funding.
Bill Lentz
MV; WIRELESS ONE
It’s interesting, but it’s too marketing hype at this point to know whether they’ve made some good decisions or have gone overboard. Based on the timeframes, I’m guessing they’ve gone too far.
A couple thoughts about some of the comments which have been made:
“I too have just recently seen the OneNet Press Release and it is the first I have heard of it. As one of few Vendors marketing NMEA 2000 to Ethernet Gateways, I am some what confused by the claims but this may due to the lack of any real information even as a NMEA Member.”
Thank you. Does anyone see this as somewhat frightening that the development is years in the making, is well over a year from completion, and done in somewhat secrecy of its own members (A MEMBER-BASED STANDARD ORGANIZATION) with the “media” (Ben) being asked to hush? NMEA has no business creating hype or keeping things secretive from their members… they should be openly engaging them.
“Where did you see the situation where data was lost on NMEA 2000, Robert? My impression is that NMEA overlaid quite conservative limits on what’s actually possible with CANbus.”
Like UDP, CANbus does not guarantee message delivery to every device that needs it no matter what the priority. Devices need to account for this. But it’s not particularly worrisome nor something most developers have to handle – things like GPS position and engine parameters (rapid update!) are resent frequently. Things with state changes are also sent as “here’s the current state” at intervals, like a switch bank, and not “here’s a state change”. That way no centralized thing needs to store states, when you power up you can see it come in or put out a request for it.
However, with both CANbus AND UDP over Ethernet, a small localized network with no non-functioning devices/cabling/etc. will have nearly 100% packet delivery.
“Let’s not forget the Lowrance/Simrad ethernet connectors, been around for a while and seem to work well.”
What’s great about the Navico connectors is they look VERY inexpensive to manufacture… and if adopted, they’d be even cheaper! They would not support in present form what OneNet is looking to do though – due to the reduced pin count, they would not support gigabit ethernet nor PoE. Easy to change, but won’t be backwards compatible.
“NMEA 2000 is a 250Kb network in a 10Gb world. It serves no purpose and delivers no unique value. Ethernet is technically superior at lower cost for everyone involved. This announcement is the formal beginning of the end of NMEA 2000 and NMEA as a standards body.”
That’s like saying a semi is far superior to a bicycle because it can carry more and move faster so it must be – they serve to very different purposes, and I think NMEA’s selection of both CANbus/J1939 and Ethernet as the TWO busses is perfect.
CANbus is designed for simplicity – a switch/hub is not required, it’s very reliable, and it’s EXTREMELY INEXPENSIVE to implement and require very little processing power. Remember, it was designed to connect very basic sensors, switches, etc. in automobiles – and it serves the same purpose on a boat. It’s somewhat less relevant as the mass production cost savings is not reached on most marine products as it is automobiles, but it’s still very appropriate and it was a great replacement for 0183 for the years to come.
Ethernet makes perfect sense for higher data rates of things like sonar/radar/etc., as well as interfacing with everything we own that already communicates over IP – smart phones, tablets, laptops and more. Combining the two with a simple gateway makes good sense as well.
“Is the communication from OneNet Switch to OneNet Switch published/licensed?”
This is interesting. My hope is that a OneNet Switch will simply be an Ethernet switch that adopts the connector format they choose, if they do so, and provides PoE. There is NO reason for them to develop anything proprietary for the switch. This is not the consumer electronics industry and NMEA has very little value in the marketing department – it’d be great if they had facts and not just some generic press release.
“Sorry, Dan, I forgot that you suggested user data licensing in a previous post. But, as I recall, your idea didn’t generate any obvious interest, and my opinion is that it’s too complicated and also a fix for a problem that doesn’t really exist.
NMEA 2000 and NMEA are actually doing OK, I think. If there’s a problem it’s the pace of standard making but I don’t see an easy fix to that. I know that some will say that it’s simply a matter of “open sourcing” the standard, but NMEA pretty much tried that with 0183 and it didn’t work out well over time.”
I agree. NMA2000 is well-done. For standards like NMEA2000 and OneNet, I think the NMEA is set up very well to build the best outcome – whether they are or aren’t is open to debate. There are apparently some issues which are stifling innovation and time-to-market for these standards, and I think there are pricing tiers missing which prevent hobbyists and extremely small developers from creating products. Most of NMEA’s members (who pay the bills) probably like this as it prevents tiny companies/individuals with no overhead from competing with them.
OneNet is an important standard to “get right” and I hope for all our sake they do.
“OneNet has no advantages over Ethernet. It’s not intended to. It’s intended to keep NMEA as an organization relevant.”
OneNet doesn’t compare to Ethernet, nor does NMEA2000 compare to CAN.
Both NMEA standard directly implement those technologies. But neither technology spells out how a message will be formed so that all devices can exchange data with each other. Nor does either specify a connector format standard so that all devices will plug in with each other and have a weather-resistant connection.
OneNet makes a ton of sense and it’s a necessary standard to be developed, so of course it will keep NMEA relevant and they want to remain relevant. What standards organization has a purpose if it’s not relevant?
Oy vay! There’s some extraordinary blindness on display here. OneNet is no more about Ethernet than NMEA 2000 is about CANbus. The primary thing these standards have created is a library of specific marine data messages that can be added to and fielded without messing up existing installs.
For the most part the marine data in PGNs works across the hardware and software of all participating manufacturers but those manufacturers also have some leeway to innovate with custom messages, still without messing anything else up (usually). It takes a lot to make all that happen on reasonably reliable basis — like documentation and certification and endless meetings!
NMEA is not trying to reinvent Ethernet; they’re trying to spec out a subset of Ethernet features that will expand PGN possibilities on boats as well as standardize the pipelines for A/V etc. I wish they’d done it a decade ago when I first saw 0183/2000/Ethernet diagrams like the ones above, but I suppose that was an opportunity for some other group to create the marine Ethernet standard that some people seem think is so obvious and easy. Where the hell is it?
And sorry to be harsh, Robert, but whenever someone calls NMEA “a very small club of investors” or similar, it is a sure sign that they have no idea what they’re talking about. Come to the annual conference in September, which is shaping up to be the most educational yet. Meet the wide variety of NMEA members you’ll find there — manufacturers, installers, dealers, government agencies, etc — and ask lots of questions. I doubt you’ll ever think of it as a club again — let alone of “investors” — or even a group of people that are all in agreement about anything 😉
PS I meant to add that NMEA 2000 was approved as an international standard by the IEC in 2008, and I imagine OneNet will go that route too. In fact, NMEA will soon be introducing IMEA, the international organization it already is to some degree.
(Also, I missed Patrick’s post when I was writing mine and am glad to have at least a partial ally who’s so well informed and reasonable.)
Until the average Joe can install a system made out of separate components from different vendors that actually works, I’ll consider NMEA a failure.
I appreciate that Ben. What I’m saying is “if devices can send NMEA 2000 sentences over Ethernet, why do you need NMEA 2000 networks – as Ethernet does everything you need”. All instruments, processors and sensors could be connected by Ethernet and simply use NMEA sentences over Ethernet. The argument around prioritisation doesn’t really stack up – Ethernet networks have been segregating and prioritising hosts and traffic for years.
“so easy, a caveman could do it”
Seriously, by this definition NMEA 2000 is already a great success.
Two points regarding Navico ethernet connectors:
First, the yellow ones are proprietary (or at least no one has figured out a source for them) and they have five pins of which only four are used (I know, I cut a cable and put an RJ45 on it). They aren’t as small as an RJ45, but they are rugged and waterproof.
Second, The Navico broadband radar cable uses an ordinary RJ45 connector on the boat end. They supply a rugged waterproof cover for it where it attaches to an RI-10 interface.
Ethernet for low bandwidth marine sensors? Patrick’s long comment lays out the rational for NMEA 2000 over CANbus very well, so I’ll just add the question that always comes to mind: If Ethernet makes sense for such use, how come no manufacturer has ever done it?
Ben while it’s not NMEA2000 that gets transported on Garmins cross over STP shielded CAT5 Garmin has been using this cable on their proprietary backbone starting with it’s 3200 series plotters, port expnder, Sonar, WX reciever and radar since the 3200 series hit the market.
Now with the newer 4200 series through the 7215 series they have a mix and match of STP CAT5, NMEA0183 and NMEA2000 on all of these MFD’s.
Am I wrong? The Garnin Network cable is shielded uses a shielded twisted pairs (STP) grounded CAT5 connectors and uses a crossover CAT5 pinout.
Bill Lentz
MV; WIRELESS ONE
Hi Ben,
The Garmin system that we had several years ago used Ethernet. The connectors were terrible and the switches for the network were very expensive compared with those used outside of the marine environment. The system, however, worked properly. As I remember, at least two other major marine equipment manufacturers have used Ethernet.
NMEA 2000 differs minimally from CAN.
The following is quoted from NMEA 2000 documentation.
According to the National Marine Electronics Association, the “NMEA 2000® standard contains the requirements of a serial data communications network to inter-connect marine electronic equipment on vessels. The standard describes a low-cost moderate capacity bi-directional, multi-transmitter/multi-receiver instrument network to interconnect marine electronic devices.
It is multi-master and self-configuring, and there is no central network controller. Equipment designed to this standard will have the ability to share data, including commands and status with other compatible equipment over a single channel. It is based on CAN (Controller Area Network). Although this standard is 50 times faster than NMEA 0183, it is not intended to support high-bandwidth applications such as video. “ (The maximum NMEA 2000 data rate is 250 kilobits per seconds.)
NMEA 2000® hardware specifications differ from those of CANBus primarily in mandating usage of differential transmitters and receivers and in the requirements of cabling, shielding and grounding.
NMEA 2000 sentences consist of identification and data sections. “The serial data frame has a 29-bit identification field and from zero to eight data bytes. In addition the frame contains start of frame and end of frame bits, reserved bits, frame control bits, a 15-bit CRC error detection field, and acknowledgement bits. “
“Messages that have eight bytes or less of data are sent as a single CAN frame. When more than 8-bytes are to be sent, one of two methods may be used. Multi-packet data up to 1,785 bytes may be sent according to an ISO 11783-3 protocol that places this data in a transport “envelope” and sends it to either a global or specific address. Flow control is provided so that when sending data to a specific address the recipient can start, stop, and control the flow of data. Unfortunately, when data is sent this way its identity is lost until the “envelope” is opened up to find out what data is being received. Because many of the messages defined for use with NMEA 2000 exceed 8-bytes (but do not require the 1,785 bytes capacity of Multi-packet), NMEA 2000 allows use of Fast-packet transmission for sending up to 223 bytes of data with their own identity. This method allows sequential frames to be sent. The first frame uses two data bytes to specify the size of the message, a sequence counter to distinguish separate Fast-packet messages of the same type, and a frame counter. Each additional frame uses a single data byte for the sequence counter and frame counter.”
End of NMEA 2000 descriptions.
Advantages of NMEA 2000 include: moderate cost, single bus system that communicates power and data, message priority, collision avoidance, short reaction times, timely error detection, error recovery and error repair.
Disadvantages include: multiple high sample rate, priority messages may prohibit transmission of lower priority messages, possible radiofrequency interference (RFI) due to cable signal leakage, maximum data rate cannot support video transmissions, connectors require structure openings that are only slightly larger than the cable diameters, but connector/cable curvature limitations result in the frequent necessity of removing connectors when routing cables, at least one manufacturer’s field installable connectors are poorly designed mechanically and are very difficult to use, tiny rubber O rings tend to drop out of the connectors with the resultant loss of waterproof integrity, legal access to details of NMEA 2000 sentences requires costly NMEA membership and NMEA requires their evaluation of both hardware and software prior to NMEA 2000 Certification.
Failure of one connected device or the network backbone can result in loss of data from multiple devices.
It may be important to consider some redundancy including the usage of multiple networks that are bridged together. Bridging has also been reported to be helpful for eliminating poor signal quality in some complex NMEA 2000 networks.
Tee connector failures in which one or more lines are intermittent or become completely disconnected have been reported by multiple users. This problem can be minimized by using manifolds rather than stringing many tee connectors together. Molex and Maretron market a variety of these manifolds. Another issue is providing adequate direct current power for a network that includes many devices. This problem can be reduced by using larger backbone cables and by using more than one power source for the backbone. Power splitting is an option in some of the manifolds. It is also possible to use a special Tee power supply connector; for example, the Actisense NMEA 2000 Micro Power T or the Maretron PowerTap CF-SPW05. Two unfortunate disadvantages of the Maretron device are that the connector orientation differs from that of some other vendors and the backbone connectors are two female rather than the usual male – female configuration.
A final point is that network traffic capability and data processing requirements can be real problems. The NMEA 2000 bus itself has limited traffic capability. Any gateway that is connected to it has limits on the amount of data that can be formatted, organized into packets and otherwise processed. Serial data communication, if used in the system, has definite limitations. For example, the default baud rate for the Actisense NGT-1 is set to 115200, but Actisense is now recommending that the rate be increased to 230400 in order to reduce data loss.
Finally, considerable computer computational capability may be required to process the data. This is particularly important when one computes complex navigational information in “real time”.
Bill, of course Garmin uses Ethernet, as does Raymarine, Furuno, Navico, etc. But they use it for high bandwidth tasks — like radar, sonar, video, and weather — NOT the narrow bandwidth ones that NMEA 2000 and even 0183 handle well. That’s what came up here, the recurring idea that Ethernet should be used for everything. If Ethernet makes senses for a wind sensor why hasn’t any of those manufacturers made one? As noted, they each have their marine Ethernet cabling, switches, etc… and no one is stopping them.
Also, why did Garmin go from piping XM Weather over Ethernet to doing it over NMEA 2000? I questioned that myself but testing showed that N2K handles the traffic fine and I never heard complaints. I wrote about the testing here: http://goo.gl/3nYir The newer Garmin GDL40 cellular weather receiver also uses NMEA 2000 instead of Ethernet. Why?
Robert, I’m forming the impression that you have little practical experience with NMEA 2000 but instead are scouring manuals looking for reasons to put it down. Again, sorry if that’s harsh. But you didn’t even respond to my request for actual examples of data loss or address the fact that the company who likely has the most N2K devices in service (Maretron) is willing to double the size of their networks. If N2K is so bad, how dare Maretron and Garmin (see above) do what do?
As a manufacture of both NMEA 2000 and Ethernet devices and a certified CISCO Networks Instructor, if I could interject a few comments about marine applications.
Modern Ethernet is a STAR topology and NMEA 2000 is linear.
To deploy Ethernet on a vessel requires a CAT5 cable run from each device to a multiport Switch/Router. Wind Sensor, GPS, Bait Well sensor, Engine Temp sensor would all require a separate cable run and a free port on a common Switch/Router. This is something our customers simply do not want to do. I think this is the primary reason you do not see a Wind Instrument with an Ethernet interface.
NMEA 2000 on the other hand uses a single trunk cable with taps for adding in each device which significantly reduces the cable run for each sensor. Which by the way is almost identical to the very early Ethernet topology. This allows sensors in the mast head for example to tie in at one end of the bus and other sensors in the engine room without needing to all run back to a common point/hub. NMEA 2000 is slower Bandwidth and even though it does supply power via common cable, it is minimal and not practical for larger networks. The Power on the NMEA 2000 bus is just for isolating the data interface and not for powering Sensors/equipment.
Now, of course, it is possible to locate several different Ethernet Switch/Hubs at various locations connected via a common WLAN backbone which could shorten/reduce the individual sensor runs (called sub netting). One nice technology for the WLAN cable is fiber optics – no ground loops and inductive noise problems. Something which would be very practical for larger vessels.
We tend to deal with private vessels from 20 to 150 feet and for the most part instrumentation is still limited. Chart plotters, and PC displays at the helm and fly bridge, engine room sensors, weather station and GPS sensors make up most of it, In the engine room we connect up the all the sensors to a gateway and run up to the wheel house with NMEA 2000 (or even old fashion RS232) and tie into the displays with mast head sensors coming down from above maybe only 5-10 devices at max but still covering all that is needed.
So my point is both have their place in the marine world. NMMA 2000 for smaller installations/vessels and Ethernet for much larger commercial vessels with intermixing possible.
But, let’s not lose sight of a very important point – it’s not just necessarily how the data is transported but what we do with it once we get it. The Holy Grail we all are looking for is a common Protocol that describes this traffic and how to access it across different vendors. NMEA 2000 is close if it were more open and can be easily transported over Ethernet. However with Actisense, Maretron, RosePoint, Airmar and others all making gateways with their own “private” protocols – we have a long ways to go.
I hope that any endeavor including possibly OneNet keeps this goal in mind.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmat.net
“Finally, considerable computer computational capability may be required to process the data. This is particularly important when one computes complex navigational information in “real time”.
What does this mean? NMEA2000 is fixed-width packets of binary data and VERY fast to process. Ethernet would be heavier-weight if the TCP stack is running on the same device, about the same if it’s on an external device.
“So my point is both have their place in the marine world. NMMA 2000 for smaller installations/vessels and Ethernet for much larger commercial vessels with intermixing possible.”
Great points overall Joe in the whole comment, however I think both have their place on the same vessels. Perhaps Ethernet won’t be on your typical bowrider and N2k will… but on my 29′ cruiser which is o the small end of geared-up boats, I easily have a need for both, and little reason to have one but not the other.
Hi Patrick,
NMEA 2000 sentences are binary data, but they are not fixed width packets as was outlined in an above excerpt from a public NMEA 2000 document.
My apology for repeating this statement from NMEA:
“Messages that have eight bytes or less of data are sent as a single CAN frame. When more than 8-bytes are to be sent, one of two methods may be used. Multi-packet data up to 1,785 bytes may be sent according to an ISO 11783-3 protocol that places this data in a transport “envelope” and sends it to either a global or specific address. Flow control is provided so that when sending data to a specific address the recipient can start, stop, and control the flow of data. Unfortunately, when data is sent this way its identity is lost until the “envelope” is opened up to find out what data is being received. Because many of the messages defined for use with NMEA 2000 exceed 8-bytes (but do not require the 1,785 bytes capacity of Multi-packet), NMEA 2000 allows use of Fast-packet transmission for sending up to 223 bytes of data with their own identity. This method allows sequential frames to be sent. The first frame uses two data bytes to specify the size of the message, a sequence counter to distinguish separate Fast-packet messages of the same type, and a frame counter.”
The data framing, formatting, transmission and decoding are actually very complicated processes that are handled mostly by specialized integrated circuit modules. The number of data fields and the sizes of individual fields vary with different sentences. Specific details of the field formats are only available from NMEA 2000.
Instrument data formats are based on the International System of Units (SI). This is good in that there is a single standard, but bad in that conversions may be necessary depending on the conventions of one’s country. For example, temperature is in degrees Kelvin which may need to be converted to centigrade or fahrenheit. There are also issues involved in converting binary numbers into decimal numbers with varying degrees of precision.
Finally, “computing complex navigational information” refers to doing something with the instruments data after it has been decoded. For example, keeping track of total and elapsed trip times or computing waypoint distances. The required equations can be complex and may require considerable computational capability. You obviously don’t need to do every computation at the rate at which every data value is received.
Robert,
I’d have to disagree wholeheartedly that NMEA2000 is complicated or resource-intensive to work with, both on a development front and on a hardware/software front.
I have written software in C and C# which decodes and processes both single-part and multi-part NMEA2000 messages… I am very familiar. The size of the frame is included so you do not have to scan to find boundaries like you would with a text protocol. The smallest device I have used is an Atmel AVR, which in quantity is a couple bucks at the very most.
It is not a complex process whatsoever, and is much faster than decoding text data like 0183, or more complicated text protocols used in other applications (XML, JSON, etc.). It’s basically one of the simplest, fastest, and easiest ways to communicate. Values are extracted with basic bit shifting and formatted as necessary. A very small microcontroller has no problem decoding/encoding the messages it needs to integrate with the bus. Most CAN/J1939 stacks allow message filtering so you can specify which PGNs you want to hit the queue to process and which you do not.
CAN/J1939 were developed for vehicle system busses for automobiles/trucks, remember. The whole point is to be VERY CHEAP to implement. On a boat, typically an expensive device has a NMEA2000 interface, so cost is not a huge factor. But on an automobile, very basic things like temperature sensors, level gauges, pressure sensors, etc. all may tie in to the bus, and production cost is very important.
The most expensive part of creating a NMEA2000 device is membership/certification and the Micro-C connector, of course besides development costs which would vary on the complexity of the device. You can build all the hardware you need to put some sort of sensor or sensors on a NMEA2000 bus and output its value/process configuration methods for under 10 bucks as a hobbiest… imagine what production costs in mass are!
I assumed this comment was part of an argument relating to CANbus vs Ethernet… not sure where “refers to doing something with the instruments data after it has been decoded” comes in to play either way. That’s going to be required no matter how the message is received, and is 100% function dependent and no way reflective of NMEA2000, NMEA, Ethernet, OneNet, carrier pigeon, etc.
“The data framing, formatting, transmission and decoding are actually very complicated processes that are handled mostly by specialized integrated circuit modules. The number of data fields and the sizes of individual fields vary with different sentences. Specific details of the field formats are only available from NMEA 2000.”
I have yet to see a NMEA2000 device with “specialized integrated circuit modules” for integrating with NMEA2000. There are none in existence that I’m aware of. The process is simple – you pick a device with a CAN interface on board. This is a physical UART and not some specialized device… you could add it externally, but it’s easier to have it on-board. Perhaps the larger companies like Navico/Furuno/Garmin/etc. use a FPGA to handle some of the interfacing, but I can’t imagine they would need to.
Add a CAN transceiver – $1.00 in quantity for a MAX3051 for example, I think I paid $3 or so in small (
Hi Patrick,
Have you seen the information on Veedims ?
This is a Fort Lauderdale company that claims that CAN and the NMEA 2000 implementation will be replaced by Ethernet.
See: http://www.veedims.com/home
Robert, where did Veedim make that claim? I can’t find any mention of NMEA or CANbus on their site, and I also don’t see any indication that they’re interested in the navigation side of marine networking.
It’s also interesting that Veedim is using a patented proprietary data and power cabling system. Why would that be if there’s an existing Ethernet standard that does the job?
Robert,
Veedims looks like a cool product, but it’s just one manufacturer’s product. Even if it were an industry-wide standard, it still wouldn’t necessarily replace it… lots of “better technology” has a hard if not impossible time replacing a standard. And again, on paper Ethernet has “better numbers” that CAN – but nearly everything that is currently using CAN gets along fine with its data rate/node limitations. So the “better technology” has zero functional value, likely doubles the cost and has an up-hill battle against a huge installed base of equipment and a standard where finally all manufacturers have jumped on the bandwagon.
I think you’re still confused about what NMEA2000 is. NMEA2000 cannot be replaced by Ethernet – NMEA2000 is a standard which would encompass layers 1-7 in the OSI model. Ethernet covers only layer 1. So while Ethernet (with PoE) could “replace” CANbus, you would still need to handle the rest of the communication solution.
The smart thing about OneNet is it allows companies to develop products not just using NMEA2000, but also custom protocols (like Navico’s radar/sonar/etc. which operate over Ethernet, Fusion’s remote, etc.) to handle proprietary communication, and also allow for future new protocol standards like an eventual NMEA2000 augmentation or replacement given the fact that bandwidth limitations would be essentially gone.
Sorry, Ethernet also covers layer 2… and CANbus would not equally compare in the OSI model, but it’s a still an effective comparison 🙂
“The Power on the NMEA 2000 bus is just for isolating the data interface and not for powering Sensors/equipment.”
Joe, I appreciate that you’re posting on Panbo, but that statement is simply not true. On typical NMEA 2000 networks the majority of sensors are fully powered by N2K and that’s a major feature of the standard. Here’s just what I was using today on my boat: GPS, Depth/Speed/Temp (water), Wind/Baro pressure/Temp (air), Heading/Roll/Pitch/Rate of Turn, Garmin GDl40 cellular weather, Fusion Audio remote control, Maretron and Actisense gateways, and I’m sure there are some I forgot.
And I’ve just gotten started really; there are all sorts of alarm and power-related sensors that I intend to test, and I already know that installing them will be considerably easier because they’re powered off the N2K backbone.
Plus I have not yet mentioned the displays. Virtually all N2K instrument displays — like Raymarine ST70 & i70, Garmin GMI10, Simrad IS20, B&G Triton, and even the bigger Furuno RD33 and Maretron DSM200 — are powered via N2K. Major feature!
Yes, there are limits to what a typical backbone can power, and installers need to pay attention. But there are also workarounds like Maretron’s higher amperage MID size cable and segmented power feeds so that no one should get stuck.
Meanwhile, in Ethernet world, it looks to me like PoE standards are rather vague. I know it can work fine, but I’ve seen similar seeming WiFi radios that want PoE at different voltages. I look forward to a standard way of doing PoE on boats.
Well, I think evevery one agrees Ethernet networks is not suitable for all types of sensors. And it does not have to be!
It can really be used as a backbone for existing N2K network and also route native OneNet data.
However, looking at the picture above I see they envision NMEA 0183 devices to be connected to NMEA 2000 Gateways, and then a OneNet gateway, and then a OneNet Swich before reaching the ethernet backbone.
Why would an NMEA 0183(IEC 61162-1) datagram first be converted to N2K, and then to an OneNet encapsulated data? There is already a standard for routing NMEA 0183 data on ethernet, IEC61162-450. This standard allows for both broadcast and adressed communication of NMEA 0183 data.
This should work on OneNet networks as well.
I hope they do not reinvent the wheel here and cause incompatibilities without good reason at least.
One more point, however they decide the connectors should be, there should be a support for at least one standard RJ-45 connectors in the OneNet switch.
Standardizing connectors for everyones needs are difficult, especially if one is trying to go from the leisure market to the professional market.
Larger vessels equipment rooms are office environment, and watertight special connectors are really not needed. The focus is on vibration and fire hazards. Cables must be flame retardant when run inbetween fire sealed compartments.
I expect an installator would like to use his own roll of cable and crimp his own RJ45 connectors att appropriate lengths.
/J
In defense of the statement that power on the NMEA 2000 bus is intended for isolating the data interface, it is agreed that some devices go beyond that and draw power for other purposes. NMEA 2000 was based off the industrial friendly CAN bus architecture which dictated electrical isolation of all node interfaces with minimum node power requirements to preserve the common bus data.
However, The NMEA 2000 specification states no one device shall draw more than 1A off the bus or 20 LEN. Common DeviceNet cable uses 22 Gauge Wire for Power and the Thicker Bus cable 16 Gauge. Given resistance/length issues and termination, Even the NMEA 2000 guidelines call out a Maximum of 1.1 Amps for 16 Gauge wire under worst case installations. Most Electrical Standards use 4 Amps Max for 16 Gauge and 1 Amp max for 22 Gauge (of course total cable length is a major factor too).
In all cases, any device drawing power from the NMEA 2000 Bus must be 100% electrically isolated, meaning the ground and supply wire in the NMEA 2000 cable must have a high impedance (> 100K Ohms) path back to the vessels power/ground system. DC-DC isolators that can do this with high current load are very expensive.
So for the simple case of assuming that each device consumes 5 LEN (250 mA) – a simple NMEA 2000 network using DeviceNet cables may only have from 5-8 devices depending on type/function. The Users Manual for a RAY MARINE E120 states a max power of 32 Watts at 12VDC which is about 2.66 Amps (53 LEN) , clearly exceeding the NMEA specification if implemented. In contrast, a device that only draws bus power for isolated data interface will consume only 1 LEN, easily allowing up to 25 devices on a simple network. In fact, the LEN (Load Equivalent Number) was meant to help determine the number of possible nodes on a network (with each device drawing 1 LEN) and has now evolved to indicate device power draw.
Yes, there are ways to extend this. Shorter Segments with isolated power supplies inserted. Bigger Cables, and so on. If it is intended to rely on NMEA 2000 Bus power for all equipment needs then great care and consideration should be taken to not exceed recommended power loads which can be quickly achieved with just a few devices. Manufactures are encouraged to minimize the LEN of all certified devices to preserve the reliability for the NMEA 2000 Bus data as anytime a high load device is powered up, voltage/current spikes can corrupt the common data transmissions.
Careful attention to individual devices LEN values and cable type/length should be considered in any NMEA 2000 installation.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmart.net
Actually, Joe, there’s no defense for your original statement. It was plain wrong. The vast majority of NMEA 2000 sensors and instrument displays are fully powered off a boat’s N2K backbone. That’s a fact (that you can easily check out).
I have no idea why you reference a Raymarine E120 drawing 2.66 amps because it is NOT powered by N2K, nor is any big display like it. Never was, never will be. But almost all the sensors and instrument displays typically networked to it are powered by N2k, and that’s a major plus for installation and operation.
Another plus of the standard is that maximum power draw in LENs has to be specified for every certified device. Though in the real world of boating, small and medium size vessels rarely approach the outer limits of N2K power abilities. So while your statement that “Careful attention to individual devices LEN values and cable type/length should be considered in any NMEA 2000 installation” is true, it’s mainly relevant for large installs.
I think that every manufacturer now offers a handbook about how to design an N2K network, but note that Maretron has automated the process. Their free N2KBuilder software neatly analyses a proposed N2K network design for voltage drop based on input power, cable lengths, and device LEN needs:
http://www.maretron.com/products/N2KBuilder.php
It’s not that hard to get it right, and even installers who don’t pay attention to the power rules usually succeed. That’s another fact.
Sorry Ben that you did not understand my reference to the Ray Marine E120 display. It was simply an example of the type of device not suitable for direct power off the NMEA 2000 bus as you have also pointed out. No statement was made that it did. Certainly there are others that fit the criteria.
Not all readers may have your in-depth knowledge in regards to NMEA 2000 bus power requirements and limitations but hopefully now they will have a little bit more to work with.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmart.net
Righto, Joe. It’s worth adding that I’ve been recommending NMEA 2000 split power drops for years. It’s such an easy way to double the ampacity of a network, as explained here:
https://panbo.com/archives/2009/03/nmea_2000_power_problem_part_2.html
I’m particularly fond of the new Actisense QPD:
https://panbo.com/archives/2012/02/actisense_qpd_a2k_more_good_choices_in_nmea_2000_cabling.html
“Meanwhile, in Ethernet world, it looks to me like PoE standards are rather vague. I know it can work fine, but I’ve seen similar seeming WiFi radios that want PoE at different voltages. I look forward to a standard way of doing PoE on boats.”
Gee, Ben, I don’t know why POE is confusing to you. Go and get the FREE standard and read it! Or better yet, since the standard is FREE, you can learn about it on places like Wikipedia as the authors aren’t worried about being sued for releasing copyrighted material! Yes that’s true! You don’t have to join the club to read the FREE standard!
:^)
Gee, DotDun, I think a lot of boaters would rather just use a standard without having to read about it. And the Wiki page on PoE confirms that there are both different wires and different voltages used in different forms of the PoE “standard”. That could get pretty messy for a boater trying to convert a normally AC driven PoE device to DC.
Plus it seems like some of the PoE powered WiFi radios like the Ubiquity Bullet use a lower DC voltage than any of the PoE “standards” mentioned on WiKi. That’s actually a good thing as you can run one directly off 12v, but this is all pretty confusing:
http://en.wikipedia.org/wiki/Power_over_Ethernet#Powering_devices
http://www.ubnt.com/bullet
Can you please explain what’s standard about all this? And what use it is to be able to read about all the wire pairs and voltages used for PoE for FREE???
Ben,
1) I was responding to your claim that POE standards are ‘vague’. No, they are not vague, they are very clear as evidenced by the number of successful interoperable products on the market. Standards written by engineers, for engineers, and available to everyone for FREE.
2) If you were to actually read the Ubiquity docs and the wiki page, you would notice Ubiquity supports the ‘non-standard passive POE’. No where does Ubiquity claim supporting either standard 802.3af or 802.3at. In fact, the Ubiquity support KB makes it very clear they are not 802.3af standard.
Since there are no protocol or terminology police, vendors are free to use the generic term POE. Maybe someone should suggest to Ubiquity to use the term PPOTSWITEC. (passive power over the spare wires in the ethernet cable)
:^)
Well, isn’t that interesting?
In his zeal for FREE, DotDun has actually provided a good example of why NMEA and other standards making bodies do what they do. PoE is not copyrighted or trademarked, or necessarily certified, so when you buy a PoE product you don’t really know what you got or what it’s compatible with (unless you’re an engineer and read the FREE docs).
That’s exactly why NMEA 2000 is copyrighted and the products are certified to behave well when integrated on a network. Which costs money, which entails fees.
At any rate, I’m now even more looking forward to OneNet PoE. That’s because a large group of concerned individuals (working for concerned marine electronics companies and related organizations) is looking through all those various PoE “standards” for the best one to use on boats and in due course (a long time, I’m afraid) that particular PoE is the one we’ll usually find on board.
OneNet is copyrighted, by the way, so no one is going to buy OneNet products that actually aren’t, at least not for very long. I think that’s good thing, but let’s note that any boater or company can avoid DotDun’s much feared “protocol and terminology police” by using regular Ethernet and whatever kind of PoE they want. Good luck with that.
I’m certainly glad to see that NMEA has a cheerleader and fan club. They need it.
I can only judge the quality of their work based on their output. They have an onerous task ahead them due to past engineering missteps. 8 bit device addressing on N2k is one example, they have no choice but either update N2k causing backward compatibility issues, or perform network address translations in the OneNet gateways, a mechanism that has caused lots of pain in the IPv4 world. I wish them the best….
Any chance there is an NMEA effort underway to standardize the integration of wireless sensors?
I am evaluating an application that runs on an iPad that could be so much better if it could receive wind and boat speed information (to convert apparent wind to true wind).
As I know it, all such sensors today and their matching base stations are not interoperable with each other.
A better situation is that each sensor followed some standard, multiple devices could listen, virtual sensors could be created as an application on a smartphone of tablet that could transmit as a wireless sensor, and this could all work with or without an N2K network underneath.
I don’t think so, Dan, and I don’t see much reason to bother. I think that the main use for a wireless sensor is for masthead wind units, and even that demand is not huge. Plus it’s not hard to get a TackTick wireless system integrated with an iPad now. You just need a NMEA 0183 to WiFi device connected to TackTicks 0183 interface. I’ve done it with a DMK box to iNavX. Two wireless hops make sense as you can add other inputs to the WiFi box.
I’ve also used an Actisense NGW-1 adaptor to get TackTick data onto a N2K backbone. And I imagine you could get Nexus wireless wind data to WiFi or N2K in similar ways. I don’t know if Raymarine will update the TackTick line but I anticipate N2K/STng output from a pod mounted below if they do.
iNavX (iPad/iPhone) just released an update to include True Wind Direction (TWD) and Magnetic Wind Direction MWD) addition to their package of wind data.
” “TWD” True Wind Direction added to Instruments view and banner.
“MWD” Magnetic Wind Direction added to Instruments view and banner.
“TWA” and “TWS” will be computed/displayed using “AWS” and “AWA” and “SOG” if NMEA data does not provide for “TWA” and “TWS”. “
NMEA Remote and Mill Port Media nGauge also support Wind data display off the NMEA 2000 bus via the SeaSmart.net WiFi (802.11 b/g) adapter. Data can be sourced by any NMEA 2000 or NMEA 0183 device including the AirMar PB200 and PB150 weather stations.
802.11 b/g and Bluetooth radios (2.4 GHZ) are the most common Wireless networks out there. We have several customers doing Ship to Ship NMEA 2000 bus bridging using 802.11 b/g (SeaSmart.net) up to 1 mile line of sight (requires a directional antenna) where they are exchanging vessel weather/wind, depth, water speed, water temp, and navigation data over the bridged link.
Joe Burke
CTO
Chetco Digital Instruments
http://www.seasmart.net
OneNet – inquiring minds want to know…..
Support for IPv6 from the onset?
Is UPnP enough?
–Limited to a single subnet?
–Can’t access boat from home over the Internet?
How to handle N2K 8-bit addressing
–N2K NAT in the gateway?
–Will the gateway proxy a N2K device and advertise via SSDP?
–Will the gateway establish itself as a device on the N2K?
—-Ability to proxy a device from afar?
–Will it be possible to make static N2K to N2K connections?
—-Allowing N2K internetwork communication?
Why not support 802.3at for up to 35w of power?
No mention of 802.11?
Device web page?
–Hosted in the gateway?
–How would that handle proprietary manuf. device config?
Ben: “Ethernet for low bandwidth marine sensors?”
Er, you mean like this: http://www.ambientweather.com/orscwmprwece1.html
I really feel like I am in a time warp. Here people are writing about Ethernet as a point-to-point network that requires cables from each device to a hub as they type on their IPads or phones — wirelessly over the ethernet. I’m sure I’ll start hearing about the evils of collisions — in a 100mbps network on a boat that will have at most 50 talkers. Yeah, right.
I think that NMEA has harmed the industry by putting everything into a box that would have been really cool in 1970. It is perfectly feasable to send ethernet packets over power lines and I in fact own devices to do that. Wouldn’t it have been neat to do this over DC powerlines? That would make wiring a wind sensor easier — except that nowdays all you need to do is make the sensor wireless. (Oh noes, it might interfere with another wireless sensor, just like when too many people try to use their IPhones all at once!)
The advantage that Ethernet happily enjoys with or without the support of the marine industry is that every other industry uses it. If you really want to be blown away, go to COMDEX sometime. That is what something other than a small club of investors looks like.
George, I reference Gilbert and Sullivan when I say that “you are the very model of a modern Ethernutter.” You can sing along here: http://goo.gl/d4Xqc
First of all, the Oregon Scientific IP Ethernet Wireless Weather Station you reference is certainly not a marine sensor. It uses IP for the very good reason that it delivers data to Web sites. In fact, it’s used ashore by some marine businesses like my local Wayfarer Marine ( http://goo.gl/yyyzM ) but it’s nothing like the wind and other environmental sensors on boats.
But in fact there are wireless marine wind sensors on boats, developed both by TackTick and Nexus. Did they use Ethernet? No they did not, though they were completely free to use any technology they wanted as both systems are proprietary at least on the wireless side. George, can you please explain how that fact fits into the Ethernutter theology?
Then there’s your notion that every industry except Marine uses Ethernet. Balderdash and pivel! (And another bow to G&S.) Every major marine electronics manufacturer does use Ethernet when appropriate, and other protocols like CANbus when they’re appropriate. Many other industries have no need for Ethernet and use CANbus or other protocols exclusively. Please check this out: http://goo.gl/NdIxP
And seriously, man, do you really believe that the marine electronics industry is unaware of what goes on at Comdex? Heck, I know for a fact that (at least prior to the recession) some major ME companies sent product managers to Comdex just to look for developments applicable to boats. Actually applicable to boats, not Ethernutter fantasies.
Anybody else want to work on this lyric rewrite?:
I am the very model of a modern Ethernutter,
I’ve information vegetable, animal, and mineral,
I know the kings of England, and I quote the fights historical
From Marathon to Waterloo, in order categorical;
I’m very well acquainted, too, with matters mathematical,
I understand equations, both the simple and quadratical,
About binomial theorem I’m teeming with a lot o’ news –
With many cheerful facts about the square of the hypotenuse.
{chorus}
With many cheerful facts about the IP of the Ethernet,
With many cheerful facts about the IP of the Ethernet,
With many cheerful facts about the IP of the Ether — nutter,
It’s been fun ‘listening’ to this very spirited ‘chat’ and I would like to make a couple of points:
– If you took a current NMEA 2000 sensor and created a new sensor with exactly the same functionality and specification but it was capable of sharing its data over Ethernet instead of CAN bus, you would have to sell that sensor for considerably more money to cover the extra overhead incurred by Ethernet.
It is not (currently) financially viable to remanufacture each and every sensor required on a vessel as an Ethernet / OneNet version. More to the point, why would you want to when you can have a single Gateway that can link all the ‘cost effective’ sensors on an entire NMEA 2000 network to the wider Ethernet world of OneNet?
– The OneNet steering group have spent upwards of 3 years working on making OneNet a reality and I can assure you that all of the potential ‘issues’ with sharing of messages between NMEA 2000 and OneNet (and vice versa) have been ‘brainstormed’ on many occasions and the solutions found.
– We have worked hard to make the OneNet Gateway rules robust enough to handle bi-directional message sharing so that OneNet can leverage the power of NMEA 2000 and build on it.
– Each and every standard OneNet device will come with an industry standard Ethernet waterproof connector.
Andy,
Thanks for jumping in!
I’m struggling to understand the $$ cost difference. When one looks at the price difference between analog sensors and N2k ‘smart’ sensors, it’s north of $100. You are stating that an Ethernet enabled sensor is even a higher cost? Is this COGs? I would think that for every CANbus chipset made there are 100,000 Ethernet chips manufactured.
Where is all the cost?
Thanks!
DotDun,
The automotive industry is using CAN bus nodes in the millions, so the cost of its chips are fairly low.
There is a major increase in the complexity of the microcontroller required: CAN based devices can run on a fairly cheap 8-bit PIC micro, but Ethernet devices are normally built around 32-bit ARM micros.
The CAN transceiver chip is now cheap, whereas the ‘Power-over-Ethernet’ transceiver circuitry is much more complex and therefore more expensive.
At each step in the process of building a CAN device vs an Ethernet device, you find a little more cost. It all adds up.
Software development costs are also very important – especially if the manufacturer has never used an Ethernet capable micro before. Developing software can consume a large amount of engineering time to get the first Ethernet device working. The majority of the product cost these days is the unseen software/firmware cost and not just the hardware cost.
I certainly understand dev costs.
Is there any desire by NMEA for OneNET to be compatible with IEC 61162-450?
Doesn’t matter. As long as the core NMEA 2000 specification are not being opened up, it’s just a ‘proprietary crap protocol’. I actively avoid buying new equipment because I do _not_ want to support such an sneeky ‘standard’.
http://esr.ibiblio.org/?p=2816
No wonder nmea2k has not been more succesful!
That rant is pretty humorous, John. So N2K is unsuccessful because it’s not being used in GPS sensors outside the boating world? Really?
“In fact, uptake of NMEA2000 has been so poor that there are only a tiny handful of GPS sensors supporting it, all of them tightly coupled to the proprietary physical network specification of the protocol and (so far) used only in specialized marine systems.”
In fact the “proprietary physical network specification” is the physical layer of DeviceNet, an open standard widely in industry and transportation. It’s well suited to boats.
Do I have to point out that the National Marine Electronics Association might be quite happy with a data protocol like N2K that is widely used in “specialized marine systems”?
Gee Ben,
After all this time, you finally seem to get it.
“NMEA protocols have never been licensed to end users and I’m 99.99% sure they never will be.”
That is the very definition of a CLOSED PROPRIETARY system. And you said it yourself.
EVERYTHING ELSE that claims *any* kind of “openness” in the protocol world is readily available to ANYONE regardless of their “status” as “users” or “manufacturers” (as if the difference is readily obvious). The entire Internet that Panbo and so many other things now rely upon were built in this way FOR A REASON. Specifically it has better SURVIVAL VALUE in the evolutionary sense.
As soon as NMEA figures out their current monopolistic, proprietary behavior is self-destructive the more likely they have a long-term future.
Happy Holidays,
-mo
What’s the use of this long debate? Does anyone seriously think every N2K device out there is suddenly going into a landfill to be replaced by ethernet stuff?
News flash folks: The election is over, N2K won.
You are arguing about how many angels can dance on the pointy end of a pen, for how long, to what tune, and how they are dressed.
Just stop.
The congregation is singing from the same hymnal, and thats worth more than anything anyone has brought up here.
The announcement of OneNet is an admission by NMEA that they screwed up with N2K. The initial arguments against Ethernet were just plain silly. Now they are creating a cottage industry for N2K to OneNet gateways, a function that serves absolutely zero to the science of operating a marine vessel.
“News flash folks: The election is over, N2K won.”
Well said, Sandy!
Meanwhile Mike had to twist my words 180 degrees to work for his rant. And DotDun seems entirely unaware that bridging NMEA 2000 to Ethernet was planned from the very beginning.
Heck, I saw diagrams like the ones above at the very first press conference about N2K, which was at the Miami Show in 2001, I think (NMEA did not do well with the protocol name ;-).
But what happened was that some of the major manufacturers did the bridging themselves, inside their MFDs (Furuno also did it in some radar scanners). Many boats already enjoy the benefits, like being able to install an MFD on a tuna tower with just power and Ethernet cables. If it’s connected to the same flavor MFD below, it will get all NMEA 0183 and 2000 data in the system, plus the radar, sonar etc. native to Ethernet.
This is also why some manufacturers were fairly ready to integrate N2K data with wireless apps devices. Check out Furuno’s TZT Viewer app and Navico GoFree.
But it sure would have been nice if NMEA had standardized the N2K-to-Ethernet bridging sooner. And ditto for a marine Ethernet plug and cable system. It will also be great if NMEA can agree on a common way to do video and audio over Ethernet. But I hope that everyone notices that OneNet’s ambitions do not include common protocols for radar and sonar. I don’t know if we’ll ever see that happen as those sensors are the intellectual property jewels of the major manufacturers.
I don’t really get Mike and DotDun’s ideological ranting, but that’s all it seems to be and it’s getting pretty tired. I am curious, though, about how many more years Mike can go predicting the demise of the NMEA 😉
Ben,
Your position is well understood. As one that feeds from the coffers of the marine electronics manufacturers, it’s in your personal interest to protect whatever they foist upon marketplace.
Had Ethernet been the choice in the beginning, we would not be having this dialog nor would we have to wait another 5-8 years for equipment from different manufacturers to play nice with each other. Hence, my comment about OneNet being an admission of the mistake made on N2K.
Excuse me Ben, but I was a technical member of NMEA years before that first press conference and had worked within the committee since the beginning of the effort.
The committee explicitly excluded any consideration of Ethernet (and anything else brought up) as a possibility even for *eventually* carrying N2K traffic. Further, they were pointed at the mountain of experience with SNMP which absolutely refuted the claim that binary encodings are no more “efficient” than readable ascii and in fact are usually *slower*
and the packet parser code is *larger*. The committee flatly denied anyone anywhere might have any experience applicable to the problem.
For NMEA to claim the contrary now is just flat out prevarication, although their motivation for continued relevance is clear.
I’ve never predicted the “demise” of NMEA – people can associated with whomever they wish for whatever reason they want. Eg, the “Flat Earth Society” is still alive and well, too.
The issues remain the same ones they conflated when N2K first started – they confused payload information with transport packet format, and they confused transport packet format with media access protocol.
The decision to move from a readable payload representation to a binary encoding syntax was deeply boneheaded but in spite of that, they ultimately produced a serviceable *semantic* cleanup of the 0183 sentences. I note that the N2K payload encoding can be converted to readable ASCII with trivial transformations. I give the committee honest props for the semantic cleanup and reorganization of the data payload. *THAT* was a worthy effort no matter how the payload is encoded, framed, or transported.
Further, realizing that a “publish and subscribe” IPC model (as typified by CANbus and Ethernet multicast at layer 1, and IP multicast at layer 2) is a more appropriate and flexible delivery model because it is *receiver driven*, not transmitter driven. Receivers decide if they want a particular datum – it’s not up to the transmitter to send it to all the interest parties. Note that 0183 *also* supports this model as seen in the 0183 concentrators and routers available in the market. So that’s a case of not breaking something already known to work – again, honest props for that.
At the time N2K was done, the *engineering* choice of CANbus as the first layer 1 protocol was reasonable. Ethernet was still sliding down the cost curve (this was before the days of microprocessors with integral Ethernet being as prolific as microprocessor with integral CAN controllers). Further it was known to have reasonable robustness for the application environment (transportation). Again, honest props for picking something that made engineering sense.
Now we get to the epic blunders which were well certainly understood at the time. Unfortunately,the N2K committee exercised their divine right to make their own mistakes. Unfortunately they failed to exercise the clause that reads “Only make *new* mistakes” and proceeded to take potshots at the streetlights illuminating the road already developed at considerable pain and expense.
The CANbus decision was not made in a vacuum. The drive train manufacturers (read “engine companies”) said “our stuff does CAN and that’s because of all the international regulations, and we’re only doing ONE interface.” We were lucky there, CAN was a reasonable choice independent of that.
But the single-purpose nature of the CAN standard deeply influenced everyone’s thinking. In fact, the manufacturing world which also relied heavily upon CAN were already having to deal with the fact that CAN networks cannot be large, nor very fast (especially if not small), and they don’t *internetwork* at all. That is, joining two CAN networks together is essentially impossible in the general case. Plus the front offices (running IP-based networks based on Ethernet) were needing to interconnect to the factory floor for data collection and programming large CNC machines, so the CAN-Ethernet interoperability questions were already front-and-center in other parts of the world.
Semantic layering is not a simple thing to wrap your head around the first time, and the people on the N2K committee were not already protocol mechanics. They were clearly fighting the *last* war (spelt “0183”), not the next one. Any discussion about the escalating complexity of boat systems and how one should be planning for those and not just unsnarling 0183 were not considered. This is why N2K was designed as a monolith instead of a rationally layered design where the valuable work could be readily reused when the network technology inevitably changed. (The inevitability of such a change was also steadfastly ignored.)
The good news is that the chosen implementation platform, CAN, did enforce a modicum of layering and as said before, the PGN payload layer can be rehosted on a new network relatively easily as long as the publish-and-subscribe behavior is available.
Another blunder was the misplaced faith in “protocol implementation verification” being sufficient to produce genuine interoperability. This was used as one reason the price of admission was so ridiculously high – to pay someone to develop an “N2K Verifier”. DARPA spent many millions of tax dollars pursuing that mirage and had long before given up with the admission that the only way to get real interoperability was the “connectathon”. And finally, after enough heartache, the N2K developers are doing those, too.
So what *is* happening is that the protocol design problems with N2K which were predicted from the very first have indeed come to pass. And the remedies for those issues have largely been adopted.
Here we are with the world demanding an Ethernet encoding to carry the PGN payload. Instead of doing the simple, obvious thing, we get “OneNet” – a product marketing press release. I notice there was no mention of whether or not IPv4 or IPv6 is in the picture, only “Ethernet”, whatever that means. I also notice there are *GASP* switches involved! What happened to all the crazy things said about why Ethernet can never, ever possibly be used in boats for handling such information? Well, when you’re in danger of being rendered irrelevant by all your manufacturers having left you behind, you get a new religion.
Sigh.
Same song, next verse.
I can’t wait for Wikileaks to release the N2K docs and then it will be all over but the shouting. (grin)
-mo
Mike, I distinctly remember that press conference, specifically the diagrams that NMEA Technical Director Larry Anderson showed which illustratee how NMEA 2000 networks would bridge their data up to Ethernet LANs, at least on larger boats. I have some proof, too.
I looked through my archives and found this draft Ocean Navigator electronics newsletter dated 2/27/2002. (Apparently the formal announcement of N2K was in 2002, not 2001; my notes about Larry’s presentation were appended to the draft.) At any rate, check the bold faced paragraph, Mike. I didn’t make that up on my own; NMEA told me that NMEA 2000 would be bridged to Ethernet:
************************************************
“I return from the Miami Boat Show with bags of potential newsletter topics — the evolution of marine electronics continues at a breakneck pace. But, rather than focus on some of the snazzy stuff I saw, I’m devoting this edition to the less-than-glamorous NMEA 2000 networking standard because I suspect it will become a very important marine technology, and I continually come across confusion about it, even amongst the trade.
Networks are typically difficult for everyone but engineers to understand, but NMEA 2000 is further mystified because it has been talked about for years, but only materialized as actual working products late in 2001. Hence the somewhat unfortunate name, though I hold no hard feelings toward NMEA – good work takes time, and 2000 is good work. The result is that many marine electronics enthusiasts have a lingering, if vague, idea of what 2000 is, but have never actually put their eyes and hands on it. Add to that the very well publicized introduction of other network products — Furuno’s NavNet and Raymarine’s HSB most prominently — during this same time frame, and you have a wide area network of confusion.
I had the good fortune of physically experiencing NMEA 2000 aboard Teleflex’s demo boat last October. Never mind that it goes under the brand name Magic Bus (for further confusion, sigh), what I saw was pure NMEA 2000 and it was great. The entire bridge of engine gauges, chart plotter, and autopilot were all digital and all cheerfully talking to each other. Routing and autopilot could work together in ways not usually seen except in highly integrated systems. More impressive were the “fly by wire” throttle, shift, and synch controls. They worked flawlessly. Now imagine how nice it would be to dispense with mechanical cables or to just plug in a second station; then imagine how robust this control gear must be to pass a team of corporate lawyers.
Most impressive was a look under the helm, where almost all this equipment was dropped via rugged T connectors to a single cable backbone. NMEA 2000 is not just a multi-talker, multi-listener communications standard, but also a hardware standard for hooking together up to 200 different devices at up to 50 nodes connected to a 200 meter backbone. The cabling and connectors are borrowed from a heavy industrial standard. 2 wires within shielding carry the data while two others carry 12 volt power. Low drain devices (To repeat, because herein lies much of the confusion, NMEA 2000 is not in competition with the broadband networks. As best as I can see now, the future of marine networks is not either NMEA 2000 or Ethernet, but rather both, or at least NMEA 2000 in smaller boats. Larger boats will likely have an NMEA 2000 backbone with bridges to an Ethernet boat LAN or some other (like HSB) big pipe for large bursts of data. PCs will fit comfortably into any of those configurations.
The NMEA does not (yet?) have much information about 2000 on their Web site, nmea.org, but Teleflex does. Go to http://www.tfxmagicbus.com, then look in the literature section for some informative .pdf files. I liked the “Overview” and “Installation” ones particularly. Expect to see many companies introducing NMEA 2000 compliant devices in the next couple of years.” — B.E. 2/27/2002
Ben – there is an catch phrase in marketing: “If the dogs won’t eat the dog food…”
It doesn’t matter who’s right and who’s wrong or who’s revisionist history is more compelling, the market is pushing back, both the manufacturers and the customers.
If 10 years after the “standard” is introduced, these kinds of conversations still draw so much interest, there is something wrong with the dog food.
Fine, Ben. You win. Obviously I imagined all those painful discussions.
The fact “Ethernet” was included in a drawing at the press conference is clearly compelling proof that MAC layer evolution had been given serious architectural consideration.
Such presentations are so common they even have a name: “marketecture”. During the heat of the protocol wars such announcements happened on a weekly basis.
But you’re right.
If it’s true that history is (re)written by the winners, then the N2K committee is obviously the winner.
Isn’t the most important issue one of interoperability? I am hoping that OneNet will facilitate two basic objectives:
Of course a low cost (say $150) OneNet compliant bridge will be required.
As for high bandwidth applications such as video over IP and proprietary communications (radar and fish finder data streams) I would think that the current players such as Furuno, Raymarine, Garmin and Simrad already have that under control.
NMEA-2000 does a fantastic job for interconnecting low cost/low power devices on a vessel. Ethernet does a great job of carting around high bandwidth data streams and provisioning communication of all data to common appliances and the internet.
*Unrestricted* interoperability is the goal everywhere else in networks these days.
The N2K world, however, works a little differently, as found in Tolkien.
One must make supplication for admission to The Realm of Secrets by paying tribute and swearing fealty to preservation of The Secrets of the Guild. (exorbitant fees, NDAs on everything, claims that software *on the other side of a gateway* is subject to their whim – that’s all within their curious definition of “open”)
Btw – that’s why I always use N2K instead of the other string – I haven’t been certified as compliant and therefore cannot use the other string without infringing on their trademark, or so they claim.
Fine. 2 Nitrogen, 1 Potassium – N2K.
“NMEA-2000 does a fantastic job for interconnecting low cost/low power devices on a vessel.”
But not quite interoperable, ever try to configure a sensor from vendor A with a MFD from vendor B? Hmm, NMEA seem to forget about device configuration in the ‘standard defining interoperability’.
“Ethernet does a great job of carting around high bandwidth data streams and provisioning communication of all data to common appliances and the internet.”
Actually, that’s IP, Ethernet is just one of the many layer 2 mechanisms that can carry IP. BTW, Ethernet can certainly carry low bandwidth data streams also.
Mike and DotDun, thank you for your insight.
I can’t make any constructive sense of your input Mike?
DotDun, I would think that the NMEA-2000 interoperability problem is more one of the vendor than NMEA-2000 itself. I fail to see how application issues such as linearisation of a level sensor or assigning engine ID’s to an engine interface can be blamed on NMEA-2000. I would start complaining to Lowrance or Maretron instead of blaming NMEA-2000. Or maybe a standards based NMEA-2000 to IP bridge (is that OneNet?)will allow the level of interoperability that we all want.
And although Ethernet can carry low bandwidth signals, it wouldn’t make sense to me to use Ethernet over NMEA-2000 from a micro-controller cost, power consumption, memory and program complexity point of view.
Isn’t it just horses for courses? By some arguments presented here you might as well be saying that USB mice and keyboards would be better off on Ethernet
I was hoping that someone could give some constructive insight into the two objectives posed in my post above.
You’re perceptive, OB Gary. It’s my understanding that there is a basic sensor configuration routine built into the NMEA 2000 standard, though you’ll rarely find it possible across manufacturers. Apparently either very few vendors allow open access to their sensor configurations or very few bother to configure other vendor’s sensors that are open, or both.
NMEA seems to be pretty loose about what vendors do with their PGNs as long as they don’t mess a network up, which seems like a reasonable stance. It’s a bit odd that someone like DotDun who thinks NMEA is way too tight with its documents and certification also wants the organization to impose more rules on its vendors.
And of course there’s proof of your “horses for courses” notion. Any manufacturer could have made N2K-type sensors using Ethernet instead but they didn’t, did they?
When I went through my archives for Mike’s sake, it was interesting to note that marine Ethernet really got going just about when N2K did a decade ago. What Furuno, Simrad, and others built on their own was just what NMEA described when N2K was released. They used Ethernet for high bandwidth networking and bridged N2K up to it for easier MFD networking.
Interoperability over N2K is really pretty good these days, as long you don’t expect to configure gear across vendors. And a standard OneNet N2K-to-Ethernet bridging protocol should be good for the development of apps (and the boaters who love them).
It will also be nice if a boat can change gear but keep standard OneNet Ethernet cabling, or if there is an IP camera standard that works with most everyone’s MFD. But as you note most interoperability is ultimately up to the manufacturers.
It’s my understanding that there is a basic sensor configuration routine built into the NMEA 2000 standard, though you’ll rarely find it possible across manufacturers. Apparently either very few vendors allow open access to their sensor configurations or very few bother to configure other vendor’s sensors that are open, or both.
NMEA seems to be pretty loose about what vendors do with their PGNs as long as they don’t mess a network up, which seems like a reasonable stance. It’s a bit odd that someone like DotDun who thinks NMEA is way too tight with its documents and certification also wants the organization to impose more rules on its vendors.
Ben,
‘The organization’ IS the vendors! NMEA is not the “know all/see all brainiacs” you propose, they are the manufacturers that sit around a table and decide what to standardize and what not to standardize.
My point is that interoperability afforded by N2k is diminished significantly when I can’t adjust my Raymarine wind vane with my Furuno MFD. What is the point of interoperability? I can’t buy a Garmin depth transducer and set the keel offset with my Furuno?? That’s called interoperable? No, it’s called vendor lock! And, believe what you want, but it’s a planned attribute!
Just for the record:
* “The organization’ IS the vendors!”
No, it’s not. NMEA was founded by dealer/installers over fifty years ago — largely to have a stronger voice with the vendors — and it’s still dominated by dealer/installers. Just look carefully at who’s on the NMEA Board: http://goo.gl/FIMHW
It may not fit into DotDun’s ideology, but actually NMEA is a complex and somewhat divided organization, not a monolithic club, as I wrote about in August: http://goo.gl/T4rWm
* “I can’t buy a Garmin depth transducer and set the keel offset with my Furuno??”
Yes, you can. Many Furuno displays like NavNet 3D and the FI50 instruments have been able to apply calibrations to any common NMEA 2000 sensor since at least 2008, when I demonstrated the feature: http://goo.gl/VSizA
Navico has a similar universal calibration feature in much of its recent gear, and maybe others do too. It’s arguably not ideal as the calibration values live in the displays of one manufacturer instead of in the sensor itself, where they would go out to all displays, but it’s working for a lot of boaters.
* “It’s called vendor lock! And, believe what you want, but it’s a planned attribute!”
It’s kind of fun to watch the raging DotDun claim telepathic powers, but isn’t it obvious that he doesn’t have a clue?
In fact, there is significant vendor lock in marine electronics, but it doesn’t have to do with NMEA 2000. What happened was the natural evolution of multi-function displays along with all the proprietary high-bandwidth sensors and proprietary Ethernet systems that connect them all together. Nowadays most boaters have to chose a primary vendor for MFDs, radar, sonar, and often several other major components.
If I worked for one of the Big Four, I’d probably try hard to build a system compelling enough to “lock” customers in, and I’d might darn reluctant to part it out. But as a consumer this situation makes me uneasy and I’d love to see someone offer more “open” high-bandwidth components. However, NMEA didn’t create this situation, and doesn’t have the power to change it. OneNet looks like an advance, but only a relatively small one (with no radar or sonar standard). I think that only a major vendor or a highly funded and aggressive newcomer can make the big advance some would like.
Meanwhile, NMEA 2000 has become the standard for narrow-band sensor data and it is reasonably interoperable. Even if a tiny group of folks like DotDun think otherwise, that election is over.
Ben,
Do you actually believe the NMEA BOD determines what gets standardized in the N2k Standards Committee? Do you believe the dealers/installers have engineers on staff that participate in defining communications protocols?
Like I stated, the manufacturers decide what gets standardized and what doesn’t. So, yes, NMEA can standardize sensor configuration, but they don’t want to.
Take a look at the Standards Committee Members from page 15 of:
http://goo.gl/vwpPb
Tell me again that the dealers/installers have consensus control of N2k.
You’re a lot of fun, DotDun. It’s like you set up easy tee shots to illustrate how deluded your N2K rage is. Shall we have a closer look at the 2009 white paper about NMEA 2000 that you found so revealing?
First let’s note the paper’s three authors, who may well be the three guys who are most important to the N2K standards making process:
Steve Spitzer, Technical Director, NMEA — I believe that Steve was hired by and answers to the NMEA Board of Directors, as does the Executive Director.
Lee Luft, USCG Research and Development Center — As I understand it, Lee is encouraged to spend much of his time working on NMEA 2000 because the US Coast Guard thinks that a reliable and interoperable marine data network standard is a good thing for their vessels and for the vessels they have to sometimes take care of. Lee has been involved in N2K since near the beginning and is widely respected for his contributions.
David Morschhauser, Mystic Valley Communications, NMEA Technical Consultant — David’s background is computer networking; I believe he’s written a lot of the N2K documentation and I know he’s taught a lot of installers about it; he’s also developing a programmable N2K backbone bridge and has helped some very small companies adapt their products to N2K.
In sum, not one of these three gentleman works for a major marine electronics manufacturer, and moreover if you actually knew them personally the idea that they would conspire to limit the utility and interoperability of N2K is absurd.
Now let’s review the 2009 NMEA 2000 Standards Committee Members, your key evidence that the standard was created by big manufacturers trying to “lock in” consumers.
I’d never actually looked at this list before (copied in full below), but, wow, does it ever turn your argument upside down. It’s a huge committee and the major manufacturers who might well have an interest in “lock in” are massively outnumbered by niche manufacturers, propulsion companies, boatbuilders, and institutions all of whose natural interest is obviously a solid standard that works across brands. Just like the three authors of the paper, and just like the NMEA BOD dominated by dealer/installers.
DotDun, how many times are we going to do this, where you declare angry certitudes about the evil that is NMEA 2000 which then turn out to be completely unsupported by the facts?
**********************************************
Readers, here’s the complete list of evil doers cited by DotDun. Seriously, does this look like a group of companies that would want to cripple NMEA 2000 so that you’ll only buy their products?
Active Research Limited
Airmar Technologies
Azimut
Blue Water Data
BRP/Evinrude
BEP Marine
Capi2
Colemo Systems
CPAC Systems
CWF Hamilton Jet
Deif
Digital Switching Systems
Deutsch Connectors
Emmi Network
Faria Instruments
Fireboy Xintex
Flir
Floscan
Furuno USA
FW Murphy
Garmin
Glendinning Products
Honda Motor Company
Hummingbird
Imor Engineering
John Deere
JRC
Kohler Power Systems
Krill Systems
Kvaser AB
Magnum Power
Mareton
Mastervolt
Maxsea
Medallion Instruments
Molex
Moritz Aerospace
Mystic Valley Communications
Nautical Systems
Navico
NMEA
Offshore Systems
Oklahoma State
Paneltronics
Phoenix Contact
Phoenix International
Pulse Electronics
Raymarine
Sailormade Brazil
Satloc/NAIITF
Silva
Sperry
Standard Horizon
Suzuki
TC80 WG 6 (IEC)
TechMarine
USCG R&D Center
Vector Can Tech
VEI Systems
Victron Energy
Volva Penta
Westerbeke
Yamaha Motor
YanMar
ZF Marine
While this is entertaining, it’s also become a bit tedious.
On the one hand, DotDun’s point is valid, if not properly founded. NMEA 2000 is a standard the way (apologies to the Italian readers) Italian road signs are the law. The manufacturer’s treat NMEA 2000 as a “guideline”, not a standard.
802.11x, that’s a standard; unambiguously. If your product doesn’t comply, it doesn’t work, you can’t interoperate and you don’t sell any product. In the case of N2K, the manufacturers cherry pick the standard while claiming compliance, and the standard is loose and weak enough to accommodate everyone without achieving the customer’s goal of interoperability.
Whether the manufacturers’ goal was to intentionally not interoperate is only known to the manufacturers, but we all know that in the real world, there is no guarantee of interoperability.
If you want to update the firmware on an N2K device from your PC/Mac, there is no standard means to even reach the device! Updating the firmware on a Furuno Fi-50, Maretron DSM250 or Airmar DST800 requires entirely different hardware in the network path, even though these are all ostensibly N2K devices. I’m not picking on these guys it’s just a hardware reality that I’ve accepted because I own all this stuff.
DotDun’s point about manufacturer lock in is correct in substance, if not in method. Manufacturer’s chose to cherry pick the standard while building in their own proprietary pieces to achieve “lock in”. It didn’t work, Ray went bankrupt in spite of (or perhaps because of) SeatalkNG.
But maybe we could all agree on a few things?
– N2K is not a standard, whether by commission or omission, that ensures interoperability, or even interconnection, between “N2K” devices.
– N2K does not fulfill all of the data networking needs of marine electronics.
– Ethernet, TCP/IP and 802.x are ubiquitous standards which guarantee devices can communicate which each other, but certainly not that they can configure each other (i.e., only good to OSI level 5).
Is there really debate about those three points?
On a more Panbo specific note it feels like Ben is more concerned with defending NMEA and the manufacturers, than in championing the needs of customers to interconnect and interoperate. Since the goal of the former it collect the spare cash of the latter it’s hard to understand why these two goals should be so misaligned, yet these discussions keep coming up. Your readers are not malicious hacks, they want this stuff to work. They want to be out sailing or fishing or generally enjoying their boats and the marine environment, not sitting in the marina trying to make their electronics work.
These threads are born out of frustration, not malice. We want to give our money to the marine electronics industry, get our electronics, and go play on our boats. Why is it so frustrating for the customers that these kinds of threads keep recurring so they can vent?
I’m not interested in placing blame, I’m interested in standards like ethernet, TCP/IP, 802.11x and even NMEA 183 that enable me to buy compliant products without questioning if they will work with my other stuff.
My understanding (from an NMEA member) is that onenet is IPv4 based. Why wouldn’t it be IPv6??
* IPv6 is ideal for a network which includes dumb sensors: no need for an add-on autoconfiguration protocol (this alone is surely reason enough?)
* Flow labels could facilitate real time communication (in conjunction with layer 2 features) in “NMEA certified” switches (ie, money spinner for the NMEA for the premium end, but unnecessary for those at the low end)
* IPv6 would obviate potential criticism of NMEA utilising technology which is obsolete by the time it gains widespread acceptance
* IPv6 is supported on almost all consumer devices (incl. ios and android)
* IPv6 can happily co-exist with IPv4 on existing ethernet/wifi network.
* Offers sales opportunity for “NMEA certified” NAT64 routers, for those who believe they need them
* Mandated support for IPSEC. Obviously there are other ways to enable device authentication but PLEASE tell me the NMEA have realised the requirement for an authentication mechanism of some kind? Unnecessary (and therefore not required to be implemented) in a small yacht, but surely on a commercial or military vessel it is essential to have a standard mechanism to ensure the GPS info on your network is actually from the devices you think it’s from.
Why *wouldn’t* you use IPv6? Larger header? Trivial in terms of network bandwidth, and fixed header size may facilitate faster processing. “Untried”? It’s been with us for nearly 20 years with widespread deployment in china and japan and on backbones worldwide, with mobile operators and ISPs looking at huge rollouts. ANd you’re talking about a deployment where the standards body can specify the whole stack. NMEA members being more electronic engineers than computer scientists and just not being aware of the technology? Hopefully that’s harsh and unfair.
Really like to hear what IPv4 gives that IPv6 doesn’t. Oh, and also to have my concerns about authentication not being considered allayed: Security as an afterthought in a 21st century networking standard would be very, very stupid.
Thanks, Keith, but I have no clue about the details of OneNet and am not sure anyone can share them. But I just forwared your comment to the NMEA Technical Director.
This thread keeps going and going it seems.
Myself and Active Research Limited / Actisense have been part of the OneNet working group for almost 3 years now and have seen OneNet grow from a ‘great idea in theory’ in to something that is close to realisation.
This effort has been huge and would not have happened without the tireless efforts of the NMEA, Steve Spitzer, Lee Luft and all the other working group members.
We have all given our time freely in order for the end result to (we hope) meet the end users needs – as that is the only way to recover our engineering time investment. But our reasons for investing in OneNet go way beyond that – we want the Marine industry to be more and more open and we believe the NMEA’s specifications are the only way to achieve that, however flawed they may appear to be to some. The Marine industry will never be totally open but OneNet will make it more open.
IPv6 is the present and the future. IPv4 is the past. IPv4 is a mishmash of many, many add-ons that have been built on top of the core over the decades whereas IPv6 was redesigned from the bottom up to be far more robust, feature rich and importantly maintainable.
OneNet is a data broadcast and control layer that is not involved with security, however another reason for choosing IPv6 is for its superior security options available to the network administrator and end user.
I guess the thread will continue until there’s another onenet article on panbo to hang comments of 🙂
I’m assuming from Andy’s post that IPv6 is now the main candidate for the network layer. I understand that a draft is not due until later this year but given that some things (autoconfiguration, lack of broadcast) may depend on that choice I would be guessing the network layer choice would be firming up RSN.
Whilst I’d argue that IPv4 is still very much “the present” with the business case for IPv6 still tenuous for most organisations, IPv6 is (imho) ideal for the marine comms environment, so I’m very happy to hear that the NMEA are seriously looking at it.
On the security front, I would absolutely disagree that security can be considered an “add-on”. To do so would be to ignore the past 30 years of computing. There is nothing in IPv6 which magically provides node authentication without assistance from the node itself. There are many ways to do endpoint authentication, it needn’t be enabled in a network, but it does need to be agreed on by all co-operating devices, and that is surely what standards are for. Presumably as electronic engineers you’d see having some kind of checksum on data being transmitted as a given to ensure it hadn’t been corrupted in transit. Just as important to those of us from a computer networking background is the ability to ensure data have genuinely come from where they claim to.
Keith, NMEA Technical Director Steve Spitzer confirmed that OneNet is set to use IPv6, and has been for a while. He noted that while “the smaller embedded sensor manufacturers are finding that their stack vendors are still not fully compliant with IPv6, the Committee is confident enough that by the time the standard is published and adopted those vendors should have IPv6 stacks ready.”
Spitzer also told me that there has been a NMEA OneNet subcommittee on safety and security issues for the last two years.
I notice that there will be a OneNet educational seminar at this year’s NMEA conference and also that the OneNet Committee is putting in 2.5 of work just prior to the main event:
http://www.nmea.org/content/2013_nmeaconf/attendee_info.asp
Thanks for the info. From a brief email exchange with Steve in January, IPv6 was (then) yet to be considered, but very happy to hear it’s now the chosen network layer. Love to attend the NMEA conference but being an impoverished non-US based freeware developer, the cost would be far beyond my means. I look forward to more details on onenet appearing on panbo in future.