Panbo

Furuno FI-50 Multi XL, a NMEA embarrassment?

... written for Panbo by Ben Ellison and posted on Dec 30, 2009
Furuno_FI-507_Multi_XL.JPG

Hey, maybe I can get the NMEA riled up too (though I doubt it has the posse gCaptain does).  Here's the thing:  Furuno's FI-50 line of instruments, including the neat new Multi XL above, are all about displaying NMEA 2000 data, right?  Heck, we've known that since their 2007 introduction.  I later tested them with all sorts of N2K data, saw how well that screen works in direct sunlight, and then used them this summer in a Cruising World article about N2K wind instruments.  They display NMEA 2000 data from most any source, and they're darn good at it!  But I defy you to find any reference to NMEA 2000 in the FI-50 brochure you can download from the Multi XL page.  What the...?...

In fact, there's hardly a mention of NMEA 2000 on Furuno's new instrument mini site (note the new long-wanded wind sensor too) or even in the FI-50 installation guide, except for the coy suggestion that the instruments might work with N2K sensors as well as CANbus ones.  Neither is there a list of the specific N2K PGNs that each model can display, and Furuno is usually very good about that valuable info.
    The cause of this nonsensical and confusing state of affairs?  NMEA will not certify the FI-50 instruments because they allow daisy chaining and Furuno felt it had to scrub most all mention of the Standard to properly acknowledge their lack of certification.  This doesn't seem right to me.  I've yet to find an N2K-aware engineer who thinks daisy chaining is a major problem, I believe it's commonly done with other CANbus networks, and -- probably most important -- two of Furuno's major competitors had already decided that daisy chaining was worth breaking the NMEA 2000 rules for.
   Simrad and Raymarine also developed their own proprietary cables to do daisy chaining and other N2K-type networking with, and while that's further confusing and annoying, I really haven't heard of problems with those systems either.  By contrast, the Furuno FI-50s used standard N2K male and female connectors, metal even (as shown here), and thus function much like a tee in a regular N2K backbone.  If an FI-50 were to fail in such a way that the instruments upstream of it are isolated from the backbone -- which is the fear that NMEA's rule is all about -- an informed owner could just pull the busted unit and connect the two cables to each other.  The problem could be solved without even shutting down the system...not that I've heard of such problems.
   Let's recap:  Three major NMEA members -- all of whom participated in developing NMEA 2000, I think -- have all decided that daisy chaining, which particularly simplifies installations like a row of instruments, is worth defying NMEA for.  Isn't that an issue that should be solved, rather than papered over with silly "CANbus" euphemisms?  I think NMEA should relent and permit daisy chaining.  I want to respect their N2K certification process because I want it to protect me from problems I can't easily understand and troubleshoot, like bogus network messages.  But as far as I know all those Furuno, Raymarine, and Simrad instruments do NMEA 2000 fine, except for the daisy chaining, and I'm willing to recommend them without certification.  Fix this, NMEA, please.  Hell, you could even make these guys put a "Daisy Chaining Warning" label on the offending gear.
 
The brochure diagrams below show the unfortunate "CANbus" nonsense, as well as the relative size of the new Multi XL.  They also illustrate a bit of confusion that Furuno is responsible for.  The folks who write the brochures and manuals like to suggest that Furuno's NMEA 2000/"CANbus" junction box (discussed here) is THE way to install the instruments.  That's simply not true.  Now, who else can I annoy?

Furuno_FI50_NMEA_2000_instruments.JPG


Comments

When I questioned the Furuno Product guys about this issue at their recent Technical Seminars, they said that all of their NMEA2000 products fully comply and pass all of the NMEA2000 certification tests! They just can't call some of them "NMEA2000" or "certified" so they had to come up with some hokey name because of the daisy chain issue and also the terminating resistor pin in their NMEA2000 GPS antennas and new NMEA2000 Ultrasonic Weather Station as well. They even said that Airmar is removing the terminating resistor pin feature and concept out of their similar products ONLY for this stupid reason!!

The NMEA organization should pull their heads out of their butts!

This is only causing confusion and stifling innovation.

Dan

Posted by: Dan T. at December 31, 2009 3:26 AM | Reply

Thanks, Dan; it's good to hear that Furuno's gear does pass the certification tests, and thus should be good network citizens. It's not surprising, given Furuno's technical expertise, but no one should have to learn that second-hand on the Internet!

Something is wrong here, and I think that NMEA needs to be pressured to make it right. Which is why I only slightly edited your suggestion about where to place their heads. But I most definitely will NOT publish the anonymous comment that just came in denigrating certain individuals. Besides it wasn't true.

Let's keep this conversation on the high road, folks. Constructive criticism or defense of the daisy chain and termination rules only, please.

Posted by: Ben at December 31, 2009 11:14 AM | Reply

Furuno could implement the daisy chain feature with an internal tee and I can't think of how that would be worse than an external tee in any way.

Posted by: norse at December 31, 2009 12:24 PM | Reply

The problem is that NMEA does not allow any tees -- built in or otherwise -- along a drop line. Every device is supposed to be on its own drop line so no device failure can disrupt data flow.

Posted by: Ben at December 31, 2009 12:49 PM | Reply

My suspicion is that NEMA is worried about the possibility of causing additional latency because of cascading devices on the network. This could be addressed by NEMA by simply implementing guidelines based on manufacturer recommendations.

I am frustrated that it has taken so long to be developed, and implemented (I believe that the 2K was meant to signify the target year of introduction). It may have been that there were many vendors dragging their feet. However, there are fewer vendors now, and likely to be fewer in the future. This may speed up the process for a follow on bus...

Also, NEMA 2000 is, in essence a HUB based protocol, with devices vying for control at different times (think of Ethernet hubs). The downside of this is that the entire network can be rendered inoperative by a device that goes crazy. I suspect that somewhere down the line it may be replaced by a more efficient switch centric protocol (think of switched Ethernet) in the future.


Posted by: Anonymous at December 31, 2009 1:40 PM | Reply

Not all Furuno gear is NMEA compliant. We've just run into a situation where an MFDBB is asking for every device on a N2K network to identify itself every five seconds. You can imagine what that does to our network bandwidth. So far Furuno has been completely unresponsive about a fix so we've had to connect our MFDBB thru NMEA 0183. How's that for this great technology?

Posted by: Anonymous at December 31, 2009 2:01 PM | Reply

"a follow on bus"? A replacement for NMEA 2000? Good lord, I hope not! I'm not aware that NMEA or anyone else is working on such a thing. Nor am I aware that NMEA 2000 is failing in any significant ways.

The problems I have seen with N2K almost invariably have to do with message mistakes made by individual devices, and are fairly easily fixed with firmware. I have also heard of problems with larger networks that use less than optimal cabling. There is a scenario where message delivery failures can cause many more message sends, and hence a cascading network failure. But I don't think it's very common, and it's purportedly very fixable with better made cables, or a better cable lay out.

As for the report from anonymous #2 about how a Furuno MFDBB brings down an N2K network, I'm dubious but curious. How big is that network, Anon2, what's on it, and what kind of cabling is used? I know I've run an MFD12 for many hours on a fairly large and somewhat funky N2K network without any problems. Maybe someone from Furuno will address this, um, next year.

Posted by: Ben at December 31, 2009 2:30 PM | Reply

I just checked and all of the Furuno Navnet 3D displays are NMEA 2000 Certified. How could they not be compliant?

Check the site for yourself:

http://www.nmea.org/content/nmea_standards/certified_produ.asp

Posted by: Anonymous at December 31, 2009 4:16 PM | Reply

Follow on to N2k... can you say Ethernet? And why not? Can be daisy chained (if the device is designed for it) or a star topology, industry standard protocols, etc. etc. etc. N2k is cumbersome thanks to the NMEA organization overhead.

The fact that 3 of the 4 (?) major mfgs have done something different that are not in "compliance" speaks volumes to the usefulness of NMEA. If NMEA had spent the last 10 years designing a great marine version of an Ethernet connector, we'ed be miles ahead right now.

Sort of reminds me of the early days of 0183.

Posted by: Anonymous at December 31, 2009 7:17 PM | Reply

It's 2010 and we're still discussing a standard that was supposed to have been implemented 10 years ago?

How about the industry starts on NMEA 15 and maybe they can get it right this time.

Happy New Year!

Posted by: Russ at January 1, 2010 6:41 AM | Reply

NMEA 2000 is really just a bunch of standardized marine data messages and some cable/connector rules laid on top of CANbus. Anyone who thinks it's outmoded, or that Ethernet is anywhere near a viable alternative, ought to look into CANbus, which began in the automobile industry in the 80's and is going very strong.

This article is seven years old, but still quite relevant:

http://www.embedded.com/columns/murphyslaw/13000304?_requestid=36801

In fact, according to this next article, CANbus was in every 2008 automobile and truck:

http://www.aa1car.com/library/can_systems.htm

Isn't it true that a vehicle manufacturer, which retools every year and controls every aspect of a design, could change data network protocols fairly easily?

It turns out that the auto industry isn't even using Ethernet where it might seem most appropriate, carrying high bandwidth video and audio. Nope, they came up with something called MOST:

http://en.wikipedia.org/wiki/Media_Oriented_Systems_Transport

But as for the vehicle systems most analogous to the sort of networking NMEA 2000 set out to accomplish -- simple data sensors, controls, etc. -- CANbus seems to absolutely dominate.

Posted by: Ben at January 1, 2010 9:51 AM | Reply

NMEA 2000 is a bit like OBD-II in the automotive world. You can get all sorts of neat things to read standardized data.

I can understand the development or marketing folks wanting to keep some things/features they way they have been for years (i.e. daisy chained instruments) because it does make sense to install them that way, and yes they are likely cheaper to make too.

I am just happy we have a standard or at least standard elements that is slowly moving the bar ahead, instead of sitting there and not evolving. It is a shame this part of the "electronics" industry moves at the pace of snails relative to other parts! At least the snails have gotten faster recently!

Posted by: Owen at January 1, 2010 3:30 PM | Reply

How about we skip all this proprietary network nonsense and just use Ethernet? :)

Posted by: bcl at January 2, 2010 1:24 PM | Reply

Thanks for the heads-up on MOST. That looks just as useful on a boat as in an automobile.

http://www.telos.de/most/
The design approach behind MOST� technology is to provide a low overhead, low cost network interface to even the most simple multimedia device. It supports devices with low intelligence and no buffering capacities such as D/A converters for speakers as well as much more complex, DSP-based devices and their need for sophisticated control mechanisms and multimedia capabilities. This design principles maximize the flexibility of the overall system.

I'm in geek heaven; there's lots of tech info to read.
http://www.mostcooperation.com/publications/mostbook/index.html
See Appendix A and B for comparisons with Ethernet/WiFi and CAN and Bluetooth.

As for NMEA, the complaints are not about CANbus, they are about the apparent reluctance of NMEA and the marine electronic manufacturers to cooperate and produce interoperable products. It looks like MOST solved that problem, given the name "The MOST Cooperation" and their goal to be a de facto standard.

Posted by: norse at January 2, 2010 4:36 PM | Reply

Norse, I was trying to respond to the various anonymous commenters who seem to think NMEA 2000 is fatally flawed. I don't think they know beans about CANbus.

This entry really isn't about N2K interoperability problems, or reliability problems, but rather a confusing stand-off between NMEA and three major members about daisy chaining. I've mixed together daisy-chained Furuno instruments, daisy-chained SimNet instruments, SeaTalkNG instruments, and all sorts of sensors and other displays without problems. They are interoperable, and I think the reliability factor is still high with daisy chaining. Then again, it's not all that much harder to install them without daisy chaining.

I'm just trying to constructively criticize the daisy chaining rule, and frankly I wish the nattering nabobs of N2K negativity would go elsewhere ;-)

Posted by: Ben at January 2, 2010 5:01 PM | Reply

I should add that no matter what bus is used the application layer still needs to be defined. NMEA has done this for N2K so that there is interoperability. As compared to radar over Ethernet for example, where the needed information is not shared. By the way, my ideal interoperability would include both display and configuration. For example, how many MFDs can display the full range of Maretron sensors?

Each could have implemented their own version of CANbus (SimNet, SeaTalkNG, etc) without any NMEA compatibility. Luckily, they didn't. But if they were really all team players they would not have differentiated them even as much as they did and they would have just called it "NMEA 2000".

The biggest difference between using CANbus in a car and in a boat is that in a car the auto maker gets to make all the decisions. It is a closed system. In a boat, I want to make the decision on every piece of electronic equipment and have the ability to add more later. That makes NMEA's role very important. And makes any shortcomings very visible. We should not be seeing this dirty laundry about daisy chaining in public.

Posted by: norse at January 2, 2010 9:58 PM | Reply

I see daisy chaining simply as a junction box in each instrument. The biggest worry I have when I see pictures of systems made up of cables, tee pieces and branches is the high number of connections per instrument, that is 4. With a junction box or daisy chaining it is 2 connections per instrument which must be a good thing from a reliability point of view.

Within the individual daisy chain instrument the two connectors are simply joined by a passive printed circuit board which will, most likely, still function even if the electronics within the instrument have failed.

To daisy chain Ethernet you need an active electronic device between the two connectors making the system much more fault prone.

Tedgo

Posted by: Anonymous at January 3, 2010 4:57 AM | Reply

I understand your worries, Tedgo. Over the years I too have seen cable connection failures cause a lot of marine electronics problems. But not with NMEA 2000. The specifications for the certified cables and connectors are pretty serious and the ones that seem to exceed the specs -- like from Maretron and Molex -- are just beautifully rugged.

Posted by: Ben at January 3, 2010 12:53 PM | Reply

Can't resist throwing in my oar ..

NMEA rightly refuses to certify non-compliant devices. It seems there are at least four distinct cases where the physical cabling requirements are seen as a problem:

1. Airmar PB200 and its rebadged Furuno version can optionally act as NMEA2000 bus terminators. The reason is obvious: there's no desire to install a terminator and a drop cable at the top of a mast where space is limited and the environment extreme. A drop cable the length of a mast isn't allowed either. [I have a PB200 myself].

2. Raymarine uses different plugs to facilitate cable pulling. The fat connectors are a serious problem in a loaded conduit.

3. Furuno routes N2K data from their rebadged PB200 into their radar, which then wraps the N2K data in the radars Ethernet transport. This simplifies cabling, but it makes the weather station data dependent on the correct functioning of the radar box.

4. Furuno and some others daisy chain N2K cables between instruments instead of using a bus.

Now, there are good arguments for all four of these transgressions but there is no excuse for NMEA certifying non-compliant devices. Standards are there to be adhered to ensure certain properties are maintained. It seems some readers don't get the idea of a standard.

Daisy chaining isn't allowed because it destroys the vital property that most instruments will have a common failure mode where they simply disappear off the bus. Furthermore, the faulty device can probably be physically removed from its connector without disturbing the other instruments. This is one reason drop cables have to be short: the main bus acts like a transmission line and the terminators at the end are there to stop the signals bouncing: the drop cables are kept short for the same reason.

So you see these properties are not preserved with daisy chains, and they shouldn't be allowed.

Raymarines connector system may well be better, but it isn't standard and shouldn't be certified either.

In fact the PB200 is compliant provided the resistor isn't enabled, but of course it will always be enabled on a sailboat masthead. On a powerboat a drop cable is feasible.

It is certain that Furuno's wrapping of N2K data in Ethernet means that timing requirements of N2K cannot be met. Ethernet is not suitable for high reliability short messaging: it's designed for large scale low quality of service data networking.

If manufacturers think they have a reason for a different cabling option they should apply to NMEA to have the standard changed.

Having said all that .. I have no idea why Furuno's daisy chained devices don't comply: just connect the instruments together in the NMEA2000 compliant way and stick some epoxy in the second port.

Posted by: yttrill at January 4, 2010 12:22 PM | Reply

It is interesting to note that the DeviceNet standard, from version 1.0 onwards (early 1990's), allows daisy chaining in drop cables. NMEA N2K uses DeviceNet cables and connectors.

DeviceNet is used in systems which are both time and safety critical so daisy chaining should not be a problem for N2K.

Furuno's diagram above essentially shows the daisy chained instruments on a drop cable.

Tedgo

Posted by: Anonymous at January 4, 2010 2:03 PM | Reply

Thanks yttrill. I'm not saying that NMEA should just open the gates to non compliance. But I am saying that they should reconsider daisy chaining so that otherwise compliant gear can be certified. I presume that the three manufacturers who are offering instruments with daisy chaining have asked for such change. Some reasons that I may not have been clear about in the entry:

1.) Daisy chaining is completely optional. No one who buys the "non compliant" gear has to use the second connector. I was only half kidding about the warning label.

2.) The fact that three manufacturers decided to enable daisy chaining suggests fairly strongly that it's not all that dangerous an idea. After all, it's those manufacturers who unhappy customers will turn to.

The bigger picture is that I don't see how a standards organization can hold to a rule when the rule is clearly being broken by numerous participants in the standard. The rule becomes pretend, and we all get silliness like euphemisms for NMEA 2000, and a lot of perfectly good N2K instruments that aren't certified.

I don't think that holding to a broken rule makes the standard stronger; the way to do that is make the rules more realistic. And note that the manufacturers are not innocent parties here. They all wear two hats, and one is sitting on the committees that make the rules. They all ought to sit down with the NMEA staff and get real ;-)

Posted by: Ben at January 4, 2010 4:49 PM | Reply

If you ignore the issue of a single device failure also taking down those chained to it for a moment, and instead champion the idea of Daisy chaining, you could be creating a whole host of future retro-fit issues.

Having the option of daisy chaining would probably be handled correctly by the initial installer, who understands that the maximum drop length (adding up the daisy chains) cannot exceed 6 metres, and also knowns how the NMEA 2000 network has been wired (because he did it himself).

However, having these daisy chaining ports just lying there waiting to be used for the next retro fit opens up a whole can of worms. The next installer/boat owner may not understand the 6 metre rule and simple chain another two or three devices to a convenient 'chain' port. This will create extra interference on the network and could start to generate error messages.

Worse still, a future boat owner could use such a connection to (innocently) connect back to the NMEA 2000 network, creating a loop and a second parallel 'backbone'. You may say this would never happen, but without a simple "this is the backbone, with each and every device connecting directly to it" rule, the true path of the NMEA 2000 network could become confused over time.

I agree that daisy chaining can be useful, and help to reduce costs, which is great. However, I am also well aware of the difficult position they put the NMEA in, as an upholder of the network's safety.

Just to touch on the subject of terminator resistors, I was at an NMEA 2000 connectfest when a manufacturer's built-in termination resistor was forgotten about and subsequently generated a large number of random error messages, confusing us all until the responsible engineer noticed his mistake, moved an innocuous 'jumper' and removed the termination resistor from the network. Magically, the errors disappeared, but not before wasting 30 minutes. This highlighted the true potential of confusion that can arise when an invisible (built-in) resistor is forgotten about.

Posted by: Andy Campbell at January 7, 2010 9:24 AM | Reply

But, Andy, my point is that the can of worms is already wide open!

I believe that there are just two brands of N2K instrument "families", i.e. multi model sets with a mix of analog (looking) and digital data. The very type that get lined up in rows around sailboat wheels and cockpits, and on wheelhouse and flying bridge dashes. That would be Furuno's and Simrad's, both of which offer daisy chaining.

So 100% of the traditional style NMEA 2000 instruments can be installed in a daisy chain. That's almost worth repeating. 100%! Would any competitor who decided to offer a similar line dare not to include daisy chaining? I doubt it.

Admittedly, of the four all-in-one instruments -- Lowrance, Maretron, Garmin, and Raymarine -- only Raymarine's offers daisy chaining. But lining up all-in-one displays is less common, and Raymarine's footprint is pretty large when it comes to instruments.

So this is not a theoretical discussion about whether or not to allow daisy chaining. That cat is way out of the bag. The potentially problematic situations you describe above are being installed on boats every day (though, honestly, I'm not convinced they're all that dire).

I'm not advocating some radical change to NMEA 2000. In fact, I think it's a great standard that will serve us for many decades to come. Which is why we should all work to fix the problems that have come up.

One problem is that NMEA's rule against daisy chaining failed. That's a fact, at least in terms of instruments. It's time to stop worrying about the implications of changing the rule, and start dealing with the fact that daisy chaining exists.

I think maybe the worse way to deal with that fact is to pretend it isn't one. Creating more confusion about the realities of N2K only makes the scenarios you worry about above more likely to happen.

Posted by: Ben at January 7, 2010 10:48 AM | Reply

Anyone who imagines Ethernet cannot easily do what CANbus does, usually for less money, is terribly confused. As for the 7-year-old regurgitation of tired old BS, thank you, I read it the first time and it's still BS. It's hard to buy an Ethernet switch these days that isn't full-duplex and provides back-pressure flow control, so loss of packets from collisions have been very very rare easily the better part of 2 decades.

If you look at Industrial Ethernet, you'll find that Fast Ethernet (100megabit) is used routinely
for high-precision motion control where the feedback loop is running HARD REAL TIME across
the Ethernet just fine. There's even an extension
approved by the IEEE that allows microsecond
clock synchronization between Ethernet stations if you care that much.

The fly-by-wire helm and ride control system on my boat uses Fast Ethernet riding on dual, fault-tolerant counter-rotating fiber rings which can recover from a fiber cut in a few milliseconds.
The two fiber rings run down opposite sides of the hull, so you have to lose both fiber pair on one side to lose a single ring, and you have to get holed in the right places on both sides to lose connectivity all together. if that happens,
you probably have bigger problems than helm control.

Sounds expensive, right? Well, the fiber ring switches, each one of which supports 4-6 100BaseT connections, sell for a couple of hundred dollars apiece, run off industrial DC, and operate at industrial temperatures. And they are easily the most reliable component of the system.

One final note: the US Navy uses this same architecture for their fly-by-wire helm, and even uses the very same hardware in the ONR X-Craft.

So don't try to tell me "what Ethernet can't do".

-mo

PS - and if Fast Ethernet's speed of 200x the average speed of CANbus isn't fast enough, gigabit/second Ethernet isn't much more expensive.


Posted by: Mike O'Dell, N4NLN at January 8, 2010 4:58 PM | Reply

Awwwww, Mike, I was hoping to keep this thread focused on an issue that actually matters! I don't even think anyone here tried to tell you "what Ethernet can't do". Ethernet is the king of networking, OK; I bow before it; I'd kiss your precious fiber rings!

But, since we're here, could you please answer the question I keep asking: Why is Ethernet hardly ever used for the networking purposes NMEA 2000 set out to accomplish? Heck, why didn't Furuno make that handsome instrument above run on Ethernet? Furuno loves Ethernet, and arguably pioneered its use on yachts. Now every manufacturer uses Ethernet for networking MFDs, radars, etc. It's become a standard of sorts, though not an interoperable one.

We even know that Furuno (among others) has the ability to packetize NMEA 2000 messages and run them over Ethernet. That XL Multi display up there could be running Ethernet, even POE, and could get that depth PGN and other data really, really fast, with lots and lots of bandwidth to spare! And who knows how much money the use of Ethernet would shave off the cost of that device (now $1,000, btw)...a dollar?...five dollars?

We also know that NMEA apparently can't make these manufacturers use NMEA 2000, or even abide by the rules if they do. If Ethernet was so good for this sort of networking, why isn't SimNet or SeaTalkNG based on it?

And while you're at it, please explain why not a single automobile manufacturer -- with zero interoperability issues to worry about -- has replaced CANbus with Ethernet? Thanks!


Posted by: Ben at January 9, 2010 9:00 AM | Reply

I don't believe a single instrument failure will necessarily take down those instruments daisy chained to it. It is certainly no worse or better than connecting up the instruments as NMEA would have you do it. The male and female connectors, on the daisy chainable instrument, will simply be hard wired together with the instruments electronics teed off those wires. At the end of the day it is simply a built in tee and engineering wise rather elegant. I understand Furuno frustration.

As to Mike's comment about Ethernet, I have no doubt that Ethernet can do it. However his helm control will probably use raw Ethernet without a TCP/IP stack and most likely will be proprietary. I have done that myself in industrial control, it has the elegance of a canbus system but needs a hub if there are more than two devices.

To make it less proprietary you need a TCP/IP software stack which adds thousands of lines of code and a real time operating system. Processing data thru the stack takes time and the theoretical high Ethernet bandwidth is dragged down by having a large packet even if you only want to send a few bytes. This includes and effects all the house keeping required on your average network, such as ARPing, DHCP, rooting, TCP establishment and synchronisation and Server Message Block services. If you want to gather data from a few instruments the end result will still be proprietary as there is no suitable standard available, just look at SiMON and Krill.

NMEA with N2K is creating, albeit slowly, a non proprietary standard open to all interested manufactures who can afford the fees. Its main weakness is that it is being developed for data collection and not real time control.

Personally I have been looking at canbus for the last 20 years but have only started using it in the last 18 months. Its an elegant bus with low software requirements, my own interest lies with duplicated or triplicated real time control applications.

Its interesting to note that Airbus and Boeing have just agreed a joint canbus data protocol standard to use on the new A350 and Dreamliner respectively. They anticipate using hundreds of canbus devices in the new planes.

Tedgo

Posted by: Anonymous at January 9, 2010 9:11 AM | Reply

Tedgo -

Using Ethernet/IP does not require TCP. From my monitoring of NMEA2K traffic, it's mostly broadcast anyway, UDP would by the choice.

Although, if they used Ethernet how would the N2K to USB gateway vendors make a living? Oh yeah, the $25 each tee and connectors also!

It's protectionism!

Just an end-user.....

Posted by: Anonymous at January 10, 2010 1:59 PM | Reply

I would agree that one would use UDP, but UDP is part of the TCP/IP stack. Put a couple of PC's on an Ethernet network and they chat away all day long doing housekeeping at all stack levels.

What we all want to hear from the Ethernet fans is who makes Ethernet based marine sensors and what would your UDP packets look like.


Tedgo

Posted by: Anonymous at January 11, 2010 6:09 AM | Reply

UDP, I think not. If NMEA-2000 had not existed and a TCP/IP solution came in it's place, we would surely have had sensors that were browser configurable using software similiar to the cheap web server software that comes embeded in our home routers. And futhermore, we would have XML to make the configuration of displays to accept new sensors easy, and our main gripe by the end of 2010 would be the displays falling short of giving us the same capabilities we have in PC's to map data against our choice of custom GUI dashboard widgets.

UDP, wow that would have been a dissapointment. But that dosn't matter now, this topic is going nowhere.

Posted by: Dan Corcoran (b393capt) at January 11, 2010 9:19 PM | Reply

I think the mistake that was originally made in going with Canbus for NMEA-2000 was the underlying (not unreasonable at the time) assumption that since Canbus was used by the auto industry for assembly line mass produced vehicles (cars) it would be equally well suited for one offs (boats).

While literally millions of cars have identical electronics, I can't recall seeing two identical marine systems. There is simply no way to spend on a single boat the time and money routinely spent to design a system for a car or airplane. Each boat, in one way or the other, ends up as a custom design.

If you need a sensor which will be used in millions of cars, saving $1 on a part results in millions of dollars of savings. But with boats, the cost of electronics has little to do with the cost of the underlying parts. Would you choose one sensor for your because it was a dollar less than another? Only if it was a "boat dollar".

As for the complicated software stack of Ethernet, it is worth noting that this software is the oldest (it began at Bell Labs in the 60's), most ubiquitous, well tested, and crucially important software ever developed.

However, if I were an electronics manufacturer, it would seem foolish to buck the current trend and develop Ethernet based sensors on my own. I'd rather, just like VHS/DVD, end up selling the same thing twice.

I'm sure a measure of protectionism was also at play in the decision. After all, how many Canbus/N2K experts are there compared to the millions who spend their waking hours with TCP/IP.

In any event, like it or not, we're stuck with N2K for a while. Hopefully, someday soon someone will come up with an N2K to Ethernet bridge and both sides can live in peace.

Posted by: Noel at January 14, 2010 11:02 AM | Reply

There are plenty of canbus to Ethernet bridges available, there is just no international standard for N2k to UDP available yet for software writer to get their teeth into.

Wow Dan fitting each sensor with a embedded web server, how old fashioned. Haven't you noticed how slow the screens appear when setting up your home router or network drive.

Why burden the sensor with html files, FTP, TCP and CGI, when all you want is a compass reading 10 times a second for the radar and autopilot.

Let the sensor broadcast a compact UDP package (standardised by NMEA) and your widget designers imagination can run wild, like they can with N2K.

Tedgo

Posted by: Anonymous at January 14, 2010 6:23 PM | Reply

NMEA 2000 is not a "standard" at all. Every manufacturer uses a different connector, different name etc. To top it all off, NMEA doesn't even have a "standard" to certify devices, in that Raymarine gear has the ability to be daisy chained and yet still certified as NMEA 2000 compliant. But when Furuno did it a couple months later, NMEA has an issue with it. (Furuno did it better than Raymarine though by adding the NMEA specified connector and by having the male/female combination of connectors.)

Posted by: Anonymous at January 14, 2010 7:44 PM | Reply

Wow, anonymous, you managed to pack a lot of ignorance into that one paragraph! What I wrote above is true. No daisy chained instruments are NMEA 2000 certified; not Raymarine's ST70, not Simrad's IS15's; and not Furuno's FI-50's. You can easily look it up yourself right here:

http://www.nmea.org/content/nmea_standards/certified_produ.asp?a=1

You'll find 351 NMEA 2000 certified products there, from close to 30 different manufacturers. Only two of those manufacturers -- Simrad and Raymarine -- use non standard connectors and cables with a different name.

As for "NMEA 2000 is not a 'standard' at all", you'd have a hard time explaining the connect fest happening in my basement lab right now. I haven't yet counted nodes, devices, and manufacturers, but there are a whole lot of them talking to each other down there.

Posted by: Ben at January 14, 2010 8:56 PM | Reply

Looks like someone is claiming to own NMEA over IP!

http://www.freepatentsonline.com/y2005/0076147.html

Posted by: Noel at January 15, 2010 9:21 AM | Reply

I would just add this bit of info to the Ethernet thread:
http://en.wikipedia.org/wiki/Power_over_Ethernet

This standard allows up to 25 watts (per line) at 48V nominal (44V-57V actual). Some vendors are providing up to 50 watts. There is still some flux in the standard regarding multiple wires for the higher current levels.

Cat/5 cable (for indoor use) is so ubiquitous that it is now cheaper than even USB cable.

I did not look around to see if any hubs, switches, etc. are yet available under the new standard. Cisco sells incompatible hubs with 10W per port, using their own pre-standard setup.

I like the idea of using Ethernet for a variety of reasons, not the least of which is that it would nearly eliminate any issues of insufficient bandwidth. I think there is an opening before the major vendors get into the game, for someone to build gateways for analog and digital data sources and sinks. This could be an interesting way to allow folks with older instruments to build a network.

Another potential future solution would be wireless USB (http://www.usb.org/developers/wusb/), which uses ultra wideband (UWB) for data transmission. UWB is the ultimate 'spread-spectrum' signalling protocol, which looks like very low-level white noise to anything that doesn't know the correct signalling pattern.

Whatever is used, something has to be done to stop the vendors from their attempts to lock the user into single-vendor networks. Imagine if freeway entrances each had one or more of a 'Chevy' lane, a 'Ford' lane, a 'Honda' lane, a 'Toyota' lane, ... If a particular entrance didn't have the proper lane for your car you'd have to drive out of your way to get to the proper entrance. NOBODY WOULD USE THE FREEWAY!!

Posted by: Gary B at March 13, 2010 7:09 PM | Reply

Two more bits: It is possible that another factor for NMEA choosing CANBUS instead of Ethernet for the NMEA 2000 standard back in the 1990's was that at that time Ethernet components were not cheap, mostly not robust enough for use in a machine environment, not integrated down to single-chips and did not include a provision for power over the same cable. So at that time Ethernet was not a good solution.

Also, there is yet another initiative that bears watching for the future - but probably not yet. Quote from Wikipedia (http://en.wikipedia.org/wiki/G.9960):

G.hn is the common name for a new home network technology standard being developed under the International Telecommunication Union (ITU) and promoted by the HomeGrid Forum and several other organizations.

Because it supports networking over power lines, phone lines and coaxial cables with data rates up to 1 Gbit/s[2], G.hn's proponents believe that it will become a universal standard for home networking.
G.hn is a new standard for existing-wire home networking (a wired and complementary counterpart to the popular Wi-Fi wireless home networking standard). G.hn targets gigabit per second data rates[2] and operation over all three types of legacy home wires: phone wires, coaxial cables and power lines.

Posted by: Gary B at March 13, 2010 7:29 PM | Reply

Hi, Does anyone have a wiring diagram for fitting a BK control kit OP05-41 to a Furuno 1552 SSB, to enable the use of an SCS Pactor modem?
They are fitted to the latest Furuno 1503EM SSB units.
All the best. John.

Posted by: John Burns at November 1, 2010 7:53 PM | Reply

Noel - you suggested that ethernet 'began' at Bell labs in the 60's.

Actually, ethernet came from Xerox Palo Alto Research centre around 1975.

Posted by: RoyHB in reply to Noel at November 1, 2010 8:55 PM | Reply

That depends upon the meaning of "began". UNIX was developed in the (late) 60's by Bell Labs. Today, its' derivatives power the majority of Internet servers, and with iPhone and Android included is rapidly taking over clients as well. In computing, that's truly unique for a 40+ year old concept. Clearly, others particularly including Xerox, which also developed the Star (Apple Mac), have made the Internet what it is today. It's just that the seed (to me) was UNIX.

In any event, I'm confident that CANBUS will never match the R&D level of the increasingly ubiquitous Internet. So the quicker we can transition to that environment for networking the better.

Noel

Posted by: Noel at November 4, 2010 9:59 AM | Reply

Noel;

I have no desire to prolong this debate, the topic is not about the history of ethernet. I just responded to what you said which was:

"As for the complicated software stack of Ethernet, it is worth noting that this software is the oldest (it began at Bell Labs in the 60's), most ubiquitous, well tested, and crucially important software ever developed."

When Unix was developed ethernet did not yet exist and wouldn't exist till 1974 or 19755. Unix systems initially communicated using hardware layers that were much slower than ethernet would later be. I remember very well linking Unix systems using serial links, frame relay, X.25 and other such techniques that did exist in the 70's. I agree that Unix is very well suited to networking but that isn't the issue.

Anyway Noel, have a good life and fight the good fight. Discussions like this topic (other than our diversion) are really healthy and hopefully lead to an advance in the state of the art.

Posted by: RoyHB at November 5, 2010 4:18 AM | Reply

Leave a comment