Angry about NMEA 2000
Hot words about NMEA 2000 were tossed into a recent rec.boats.electronics thread:
“Oh, boy! Another proprietary, improperly documented, non-standard data protocol designed to keep the marine electronics assholes swimming in money for another decade…”
Yike! I believe that every phrase and implication — heck, every word — in that diatribe is wrong, though I do understand the frustration of hobbyists and small developers who want the same access to NMEA 2000 that they have to 0183. But 0183 can not do what needs to be done on today’s boats, at least not easily. For an example of “not easily” check out the data system on Steve Dashew’s new boat, mentioned earlier, especially the bigger version of the diagram below. I’ll be posting a lot about 2000 in future weeks as I test some interesting gear.
Help me out here. What is there about this diagram which precludes use of NMEA0183?
So you do away with a couple of multiplexers, what else?
I didn’t mean to suggest that this system precludes 0183. I just think, as Dashew suggests, that it’s quite complicated. 0183 was designed as an interface, not a networking protocol; hence all the multiplexers. NMEA 2000 will eventually make this sort of small data networking simpler, more reliable, faster, and much more easily expanded.
My question is, why not use 0183 over a tcp/ip network?
TCP/IP is great for multi node networking.
This has been bugging be for while. Is the power consumption required to maintain the network considered to high? Or is their some other reason.
thanks.
I’m confused about this too…why in the heck can’t somebody just build a multiplexer that converts traditional NMEA 0183 data to an ethernet connection…and then the rest of the industry start wandering towards a total ethernet solution??
Furuno is doing Ethernet on their new NavNet2 system (proprietary of course) but what would be so hard about everybody generating NMEA sentences that point at a specific IP address on a TCP/IP network? Ethernet hardware is reliable and cheap, DHCP could take care of the addressing, and you could dump all of the data into the “pipe”, and then get it out at a plotter, computer, radar display etc….and when in port you could use the same network to surf the web!!
This can’t that hard, I don’t understand why it hasn’t happened already!
NMEA 0183, and 2000, data packets are being send over Ethernet connections like NavNet and Raymarine’s new SeaTalkHS right now, but my understanding is that Ethernet is not a practical protocol for items like speed transducers, nor is it reliable enough to run throttles and shifts, which is another aspect of NMEA 2000. I’ll be writing more about all this in coming weeks.
Great,
I am looking forward to your article.
TCP/IP and Ethernet are not tied to each other by they way.
You can run a TCP/IP network over many different transport mechanisms Ethernet being just one, SLIP, PPP, Token Ring, ARCnet and Even Packet radio being a few more.
In general I am frustrated with all the proprietary standards in the Marine Electronics industry and would really like them to be more open with their standards and code.
If you have the skill, wouldn�t be nice to review the code that drives your Nav system?
Here is a quick example that would not fly with any other hardware/software vender sector.
If you take a look at Raymarines �Latest software summary for ST290 series instruments�
It shows there are updates for many components, but it doesn�t show, what issues the updates address? Are these critical updates? And the kicker, they want you too rip the system out of your boat and send it too them to apply the updates?
Nice Blog by the way!
Thanks
Andrew Smith
Thanks, Andrew. Multi manufacturer plug and play really is happening…I experienced it myself yesterday! More later. Your critique of firmware updating also deserves, and will get, an entry-long response.
Maybe someone can help me. I purchased a new ICOM-VHF with DSC. The radio says that it reads NMEA 0183 ver 2.0 or 3.01, formats are RMC,GGA,GNS and GNL. My Garmin Chart Plotter states that you can connect up to 3 devices with interface formats of (and I will skip to the format that relates to this message) NMEA 0183 ver. 2.0 Approved sentences are GPGGA, GPGSA, GPGSV,GPRMB,GPRMC,GPRTE AND GPWPL. Are 2 of these formats not the same? Due to the GP at the front of the sentence? The radio does not pick up a position. I am lost! Thanks for any comments. Ken
Hi Ken, While I think your troubles are a good example of NMEA 0183’s shortcomings, I also think they are quite solvable. I say that because I have actually watched Garmin plotters receive and plot info from Icom DSC radios. I’m not an expert 0183 diagnostician (they shouldn’t exist!) but guess that the sentence names are only an issue of confused nomenclature. Are you sure you have the DSC output proberly wired to one of the Garmins inputs? Have you gone into Garmin’s menus to turn on that input and spec the right baud speed, handshake etc? Maybe the Icom also has to be told to send out data and may have similar parameter choices? Either technical support line should also be able to help. Please keep us up with your progress; this would make a good entry.
GGA and GPGGA are referring to the same thing. In a NEMA 0183 sentence the first character is a ‘$’ (or ‘!’ for some AIS related messages) and the next 2 characters, ‘GP’ in this case, describe the device sending the message and are usually ignored by the receiver. The important part is the RMC, GGA, etc.
Make sure that both devices are talking using the same 0183 version and baudrate. 4800bps is the standard rate, but some devices support 9600bps.
As far as Ethernet for interconnects I do not see any reason why TCP/IP and UDP cannot be used for control systems. 100M ethernet is going to have very low latencies and if you’re packets aren’t making it through you have bigger problems!
Hello,
I was looking in the Internet for some NMEA 2000 information. I have a small experimental program running at home which distributes NMEA 0183 messages from different sources (GPS’s at the moment) over WLAN (g and b) and Ethernet(10/100Mb). It uses UDP since the information isn’t critical. By adding some extra information at the end of the NMEA message I can even differentiate equal senders, tell a Garmin from a Maggelan GPS. At the moment I don’t see a reason why, on an enclosed environment ethernet, wlan or maybe even bluetooth couldn’t do the job of information distribution. Where the wireless solutions would save the burden of putting more wires everywhere. Cheers Mike
Thanks, Mike. You’re right that Ethernet can carry 0183 packets fine, 2000 packets too, but do you think there will ever be GPSs, depth transducers, compasses, fuel senders, diesel engines, spotlight controls, etc. etc. with Ethernet built into them? NMEA 2000 is designed to live in those sort of sensors, and is also capable of controlling critical devices like throttle and shift. So, sure push the NMEA data up into a boat’s high speed Ethernet, but how do you collect it in the first place? NMEA 2000 and Ethernet are going to cohabitate on boats very nicely.
Hi Ben, I’m not really very actively following this discussion. I’m sorry. I don’t see a reason not to build in a ethernet interface on all the devices you mention. If it fits on a PCMCIA card in my opinion it can fit on anything. It basically comes down to the decisions the manufacturers make. Collecting it is a matter of architecture and bus you want to use. CAN, Profibus, WLAN, Ethernet, Bluetooth or why not USB? In a lot of the cases it will end up at a PC with an application on it. I agree with your conclussion that we’ll in paractice end up with more than 1 kind of bus in one place.
Thanks, Mike. Stay in touch about your “experiments”. Meanwhile, I’ll be on the look out for Ethernet enabled depth transducers, GPS sensors, etc…but I’m not holding my breath!
Guys,
I have just stumbled accross this thread. We are in the process of developing a small box for routing multiple channels of 0183 data and broadcasting it over UDP on Ethernet, with a UDP receive driver that pretends to be a com port on your PC, so PC apps can think they are directly connected. This has the added advantages that it can be routed over WiFi, so the chase boats on the big racing yachts we work on can also catch the data. Any one have any requests for features we can add in?
Thanks, Nick. Please send me some PR when you’re ready. Also, you might want to look at Palladium Technologies Nav Express product. http://www.palladiumtechs.com
WiFi data transmission can run into problems – what if your data is received by another boat close to you? Or vice versa? Confusion and bad things could result from that disorder. Most eqipment sets up using a default address – and let’s be honest – most boaters will go with the default – too complicated to actually specify something on a network. Everyone wants something that will work out of the box – no issues – no ‘hassel’ setup. I would stay away from general wifi ethernet ideas, you would require a more secure setup to run such systems.
The new wireless pilots from Raymarine are a step in the right direction – this is still a proprietary communication protocol, requiring the hand unit be registered to the control station.
NMEA 2000 will makes things more simpler. It’s just one long wire run – no multiplexors – just unit after unit after unit. No looping back – all the connections are standardized – and designed to live in oily wet locations.
It is true that all wire runs end in a PC – even if that PC takes the shape of a Furuno 1953c display. It’s just wanting to talk in it’s own lanuage to its own family. What you want is that when NMEA 2000 starts hitting big, and I think it will, that you will now be able to connect a Raymarine E120 to a Simrad pilot simply by connecting 1 cable. No configuration required.
It’s up to the manufacturers to enable this through their software. It is a business, and the competition is always a concern – of course they want to design products that steer you in the direction of buying all of their products.
The ultimate goal of 2000 would be a plug and play network. I’ve had my hands on the actual cables and seen the connectors to be used. It really will be a good thing. It will provide a much more comprehensive on board network that will be less of a hassel than 0183. 0183 works great to a point – then you start having to make the system so much more involved than what it should be. But rememeber the era that 0183 was developed – we didn’t have WinXP, Google, WiFi, machines running @ 3.5GHz.
It’s all relative.
I just purchased a NASA AIS Engine receiver. It uses NMEA 2000. Is this backwards compatable to NMEA 0183?
The rest of the boat is using this.
thanks,
Paul
Paul, I think you’re confused. I’m testing a NASA AIS engine and its output is NMEA 0183. The only unusual thing (though typical of AIS receivers) is that it runs at 38,400bps instead of the standard 4,800. The instructions I got with it were very poor, which may be the source of your confusion. I’ve written some entries on my testing, starting here:
https://panbo.com/yae/archives/001132.html
AIS output is covered by IEC 61993-2 and 38400bps is the standard speed for any AIS output. It does differ from the NMEA0183 v2.0 standard which is 4800bps. But then it would be difficult to output data from a 9600bps system on a 4800bps serial port!
The Sitex unit I checked out had RS232, 38400bps output on it.
Right, and IEC 61162-2 is also called ‘High speed NMEA 0183’. The point is that the NASA box talks NMEA data strings, and is not in any way NMEA 2000.
Hello Ben,
I managed to implement an application on Linux that will gather NMEA 0183 information from several serial ports, that might also be a Bleutooth serial profile device, and UDP sockets and either display the received information, write it in a logfile or send it on via IP UDP. Configuration is done via a xml configuration file with an easy to understand syntax. I’m still working on Bleutooth distribution of NMEA messages and a graphical front-end for configuring (so I don’t have to edit the xml configuration file anymore) and display NMEA data. I’v tested with 1 Polstar bluetooth GPS, a Garmin 12 GPS and a Magelan/MLR XC 24 GPS, 1 Laptop with WiFi runnig Linux Suse 9.3 to which forementioned devices were attached and running my application, Linksys WiFi access point, Pentium 4, 2.6 Ghz running linux and the application receiving data from the Laptop, 486 100 Mhz, windows 98 running the Kiwi Syslog Deamon as an endpoint to receive the messages. The wireless network is .b, i.e. 11 Mbps, because I couldn’t get my laptop to accept a .g card yet and the wired ethernet is 100 Mbps. Since I only work with GPS’s I only encoded the 16 or so NMEA 0183 sentences that concenr the three named GPS’s. I encoded none of the proprietary messages yet but I’m working on it (it’s just a hobby, right :-)). None decoded messages are being send on as text strings though so nothing gets lost. It seems to be running stable and I found out a few things I’m still thinking about and I’ll post maybe some time later.
HI FROM ATHENS
PLEASE.
HOW CAN TRANSMIT AIS DATA FROM AIS ENGINE RS232 OUT
OVER RF (VHF OR WLAN MODOUL )AS AIS REPEATER OR LINK .DO YOU KNOW ANY INTERFACE FOR THAT PURPOSE.
THANKS
THANASIS GAVALAS
ATHENS
HELLAS
[email protected]
Thanasis, Check out Palladium Technologies’ NavExpress. It will put NMEA 0183 data onto Ethernet, which also means WiFi.
http://www.palladiumtechs.com/HTML/NavExpress.htm
THANKS BEN
CAN I USE A MODEM OR TNC IS THAT RIGHT .IN THAT CASE WHAT SPECIFICATIONS MUST SUPPORT THIS MODEM OR TNC.
I VISIT ALSO cmlmicro.com THEY HAVE INTERESTING PRODUCTS (GMSK MODULATORS…).
THANKS
THANASIS GAVALAS
A linksys or Digi 802.11 to serial box may be useful.
http://www.linksys.com
http://www.digi.com
bob
Hello,
I have been quietly waiting for you to address user end firmware updating and am hoping this will be a gentile reminder 🙂
In my case, I have a Raymaine ST290 system. One of the reasons I bought it was the USB port on the DPU and the promise of easy upgrades via the DPU (see section 1.3 of the manual ‘System Upgrades’
http://www.raymarine.com/raymarine/SubmittedFiles/ST290_sect_01_iss2.pdf
I have now had the units for a few years and there have been a number of firmware upgrades, so I called up the support number. I was first told that it was not possible for a user to perform these upgrades, even if the user is a unix systems engineer, then later told that there was a �software upgrade kit� but the highly recommended sending in the units.
I explained that I would rather give the kit a try and if it failed, then I would send them in. Frankly ripping apart lots of cabinetry is not something I want to do unless there is no other way, plus they pretty much make a point out of easy user upgrades in the manual.
The tech I was speaking with didn�t know the part number for this kit, and transferred me to another, who pretty much said, uhhhm then I was back on hold. Then another tech had no idea, I was on hold again.
Finally I ended up with someone who told me there was no such thing and that there had been no firmware/software upgrades. I pointed out the table �Latest software summary for ST290 series instruments� on the web site, still he had never heard of a kit and the only way to have the serviced was to send them in.
This just seems wrong. Has anyone else been able to get what�s needed to perform these upgrades?
Ben, maybe you know someone with Raymarine who can provide an explaination.
Thanks.
Hello,
I have been quietly waiting for you to address user end firmware updating and am hoping this will be a gentile reminder J
In my case, I have a Raymaine ST290 system. One of the reasons I bought it was the USB port on the DPU and the promise of easy upgrades via the DPU (see section 1.3 of the manual ‘System Upgrades’
http://www.raymarine.com/raymarine/SubmittedFiles/ST290_sect_01_iss2.pdf
I have now had the units for a few years and there have been a number of firmware upgrades, so I called up the support number. I was first told that it was not possible for a user to perform these upgrades, even if the user is a unix systems engineer, then later told that there was a �software upgrade kit� but the highly recommended sending in the units.
I explained that I would rather give the kit a try and if it failed, then I would send them in. Frankly ripping apart lots of cabinetry is not something I want to do unless there is no other way, plus they pretty much make a point out of easy user upgrades in the manual.
The tech I was speaking with didn�t know the part number for this kit, and transferred me to another, who pretty much said, uhhhm then I was back on hold. Then another tech had no idea, I was on hold again.
Finally I ended up with someone who told me there was no such thing and that there had been no firmware/software upgrades. I pointed out the table �Latest software summary for ST290 series instruments� on the web site, still he had never heard of a kit and the only way to have the serviced was to send them in.
This just seems wrong. Has anyone else been able to get what�s needed to perform these upgrades?
Ben, maybe you know someone with Raymarine who can provide an explaination.
Thanks.
Will they ever learn? Closed standards, NMEA-2000 specifically, only encourage development of alternatives that are cheaper to implement. The $10,000+ to put a single device on the NMEA-2000 bus is outrageous (and I’m being nice).
The computer industry had to learn this during the 80’s and 90’s. When will the marine electronics industry learn it? Open standards are good for business, the industry, and most importantly, the consumer.
I spent 16 years with a once great company, HP, and saw them go from closed standards to open ones during the 80’s and 90’s. Business boomed everytime a proprietary standard was thrown out in favor of an open standard. Replacing proprietary, networking protocols and hardware with open LAN standards, graphic libraries with OpenGL, proprietary unix implementations with Linux, etc. Every time the move was to open standards, sales increased, prices went down, and customers benefited.
NMEA-2000, as a closed, proprietary, fee-based club is bad for bringing new innovative, small players into the industry (protecting the less fleet-of-foot old companies), and just keeps prices high for the consumers.
Andrew,
Yeah – I have performed the upgrades on the 290 series – the software is only available to dealers – the process is simple, but even if you are a very technically savvy person – unfortunatly you won’t get that software package…at least not at this point in time. That may change – they haved moved into the realm where almost all products are updated by the user.
You should contact a local dealer and see if they can update the system for you, as they can get the software – there is no part number.
BTW – the update process is not as clear as you might think – that is another reason the software isn’t for public download. You gotta have a guy that knows what he’s doing to update the 290’s, they’re not cheap instruments, let someone else kill them – then the cost is their burden – not yours. You try to update and kill them – you just cost yourself a bit of money.
Well,
I was able to get the update package and it is a pretty simply process. I leave the provider anonymousJ.
The pod updates went without a problem, same with my segmented character display.
The DPU and the Graphic Displays both hung during the upgrade.
From what I can tell they simply reverted back to their original state.
Yes they are expensive, and that�s part of the reason I expect them to work as the manual outlines. And the way I see it, I was able to upgrade most of the system without having to yank the gear out and put it in the mail and hopefully, we�ll work out the problems with the DPU and Graphic displays before spring.
Cheers,
Andrew Smith
Andrew,
Good, glad to hear you got what you were seeking, maybe you need to drop the DPU software version first in order to upgrade, also…check the serial number in the graphic dealer menu – if it says – not set – it won’t accept any software and needs to be replaced – this may be of great importance to you, again contact your local dealer regarding this – they will more than likely talk to Raymarine, very limited issue there.
Thanks,
I have to thank the fine Mr. Panbo for hooking me up with a a person at Raymarine who has been very helpfull and responsive.
1. The NMEA 2000 hardware specification is a derivative of the CARS specification. CARS is used by the auto industry. Now we know that automobiles don�t get wet, vibrate, get cold, aren�t based on 12 Volt DC, etc. so there is no way that the marine industry could adopt a standard where the production is millions of units a year resulting in very low hardware costs if they could modify the specification so that it was propriety.
2. You confuse content, protocol, and transport. The majority of the NMEA 183 specification is content � what the messages look like. There is a hardware protocol (4800 baud, etc.) and a transport (two wire voltage.) Both the industry and individual developers and hobbyists move NMEA 183 messages over all kinds of transport/protocol implementations � Ethernet, USB, RS-232, 802-11. The messages remain the same. It is true that NMEA 183 is missing certain kinds of messages, but that is why the specification went through a variety of implementations (e.g. 1.0, 2.0, etc.) There is no theoretical reason why the new message specifications could not have been added to the NMEA 183 message set. All you need to do is add a new message format. Its been done before, it could be done again.
3. You assert that something like a throttle control or a speed sensor could not run on NMEA 183. Perhaps running on a 4800 baud 2 wire link could be limiting. But you could still send NMEA 183 message formats (if they existed) such as throttle up and throttle down over a faster transport/protocol � e.g. USB 2.0 at 4 megabits per second or Ethernet at 1 gigabit per second. At USB 2.0 speeds you could be sending thousands of throttle control messages per second � far faster than the engine could ever react. Remember that an engine running at 3600 RPM is only running at 60 revolutions per second. Even if you sent one message per revolution you would only need 60 messages per second to control speed. Your bandwidth utilization would be very small. Don�t forget that all these mechanical devices have inertia anyway, they can�t react all that quickly no matter how many commands you send them.
4. Getting to Ethernet or USB is dirt cheap. The chipsets are in the less than $5.00 range. And yes, you are already seeing the sensor manufactures putting the interface chips directly on their sensor hardware. For example, you can purchase a GPS sensor that directly outputs NMEA 183 GPS messages on a USB interface today. More will follow.
5. Let�s make it hard for the average person to get into the game. Try to purchase a copy of the �holy grail� � the NMEA 2000 specification. Last time I looked it was in excess of $3500. On the other hand every major computer protocol is free in the public domain. Maybe the NMEA 2000 specification comes on a solid gold DVD? It must be something.
6. While we are on transport and protocol let me point out that Ethernet and USB are fundamentally transports. TCP/IP (the �Internet Protocol�) is a protocol � the way that two different computers/devices talk to each other � the envelope in which the message (read NEMA 183 text) is sent and received. Since these protocols are designed to permit millions of computers to send trillions of messages to each other all day long (read �the internet�) they are pretty robust � guaranteed delivery, broadcast delivery, quality of service, multicasting, etc. I can not conceive of a communications requirement at the protocol level that could exist on a boat that doesn�t already exist and is solved on the internet.
7. Finally, you assert that the system on Steve Dashew�s boat is complex. Now I know you are a boat guy, and I love your column and check it most every day. But spend about 5 minutes at any automated manufacturing plant and you will see that in the scheme of technology implementation Mr. Dashew�s boat is trivial by comparison.
This takes me back to the comment in the first post � I pass on the personal characterization and the assertion of the profitability of marine electronics � but I fully agree that the industry and the boating public would be far better served by an open standard that takes the maximum advantage of high volume, low cost, off the shelf components and software implementations.
Roger
Thanks for the thoughtful post, Roger, though some of it I don’t get. A few comments:
* NMEA 2000 is based on CANbus, the cabling on DeviceNet. This stuff is used in trucks, factories, etc…often in harsh conditions and often where messages are critical. CANbus microprocessors, compilers, DeviceNet connectors, etc. are all off-the-shelf items.
* I’m certainly not an engineer but I don’t think I’m confused about “content, protocol, and transport”. I think you need a standard that defines all three to get plug and play interoperability. I just did some 0183 installs the other day, and not only were there no plugs, but even when I wired stuff together properly, they didn’t play nicely!
* USB is not a networking protocol, it’s an interface (like 0183, except with a physical layer, ie. a pretty common plug). I doubt you can point to a USB or Ethernet connection that controls something as critical as shift and throttle. CANbus/NMEA 2000 was designed for this–prioritized, guaranteed messages–and there are plenty of examples that it works.
* I buy the idea that NMEA must charge for 2000 implementations to support the needed standards infrastructure, but I agree that there should be free access to the messages, especially as using 2000 with a PC does not require certification (because the gateway box protects the network).
That’s all for now. Someday Panbo will have forums where this sort of discussion can have more elbow room!
Thanks Ben for the response � let me see if I can sort some of it out�
Yes, you are correct that NMEA 2000 is based on CANbus � Controller Area Network – I misspoke. My initial information was that the particular way that the CANbus architecture was to be implemented in NMEA suggested that it would not transparently interface with devices that were implemented for the automotive market. Since I have not chosen to spend the thousands of dollars for the specification I can�t pass on the true or falsehood of this statement.
My most simple point was that CANbus is one physical implementation, the one that NMEA chose, but like all choices it has strengths and weaknesses. In my mind the biggest weakness is that it is slow compared to other protocols. I have worked in manufacturing automation and I can tell you that Ethernet works just fine. BTW,
I have used Ethernet to control things as sensitive as shift and throttle � its no big deal. As I was trying to point out (unsuccessfully) in my post � a higher speed protocol than CANbus might be better for distribution of multiple high bit rate streams (think radar, chart, and full motion video to multiple displays all over a large boat.
I don�t think that an in depth technical discussion would be worthwhile. We have NMEA 2000 and will have it for a while (after all, its 2006 and we are still on NMEA 2000!) My biggest complaint is that even purchasing the message formats is a significant outlay (I think about $500 by the time you are done.) That is a real disincentive to innovation by the great unwashed.
Roger
Hello Roger and Ben,
I want to make a remark about ethernet. Yes it can be fast and yes I believve that you made things as time sensitive as shift and throttle work. I also hope you’ve got a good liability insurance because as soon as somebody decides to connect a PC to the same ethernet net you use for your shift and throttle application and this person also will decide to download the encyclopedia britanica (yes I’m exagerating but hey it’s possible) there is no guarentee that your shift and throttle commands will arrive in time unless you’ve taken drastic measures on the protocollevel. Even then it’s possible through generating great numbers of collisions to shut down the ethernet. The latter can of course happen when a attached device is malfunctioning. If ethernet were a cure all I think the car and the avation industrie would have already made the jump to the much cheaper ethernet solution instead of sticking to CAN and other field busses. Telephony over IP, the trade I’m involved in at the moment, will get one face to face with all the problems of IP and ethernet. You can make the problems of ethernet easily audible with VoIP. So for very time critical applications I would prefer CAN. That said it’s a bit of a waist beause the majority of imaginable applications is not mission critical but relies heavily on great amounts of data being shifted from one place to another with no heavy emphasis on realtime aspects (maps, radar data, etc). Because of CAN applications like that are going to be extremely slow since ethernet has the potential to be 100 or a 1000 times faster if you don’t overload it that,is. These kinds of data are not time critical. Meaning that if the data is a second or so later every once in a while it doesn’t matter that much where as with throttle and shift we are very likely speaking of response times in the milliseconds range or even faster.
USB is just a smart and faster replacement for RS232. What you can do with RS232 you can do with USB as well. The other way around is not necessary possible because of the greater possible speeds with USB the rs232 cabling doesn’t support.
Cheers,
Mike
Mike, you make a good point on one way a malfunctioning Ethernet device could bring down Ethernet. My question though is, what would happen if a NMEA 2000 device malfunctioned and either shorted to ground or locks in a high state the NMEA 2000 bus, would the shift and throttle data get through?
Can a Maretron WSO100 weather station (NMEA 2000) be connected to replace the wind sensor (NMEA 0183) of B&G instruments (Hydra)? Are the sentences for wind direction, wind speed and temperature the same for both standards? Any comments would be welcomed. Thanks, Steve
Steve, I don’t think this will work; everything is different. The only way I know of to turn NMEA 2000 messages into NMEA 0183 is by using Maretron’s PC gateway, which does the conversion because PC programs don’t read 2000 messages directly (yet).
Steve/Ben, I think you can probably use Simrad’s AT10 to convert the NMEA2000 to NMEA0183. It looks like it can handle the wind sentences (MWV) at 1Hz. Incidently, it looks like Maretron added the AT10 to their price list…I’m guessing Rich wouldn’t have added it if he hadn’t had at least some success with it.
I’ll let you know if it works the other direction shortly!
Robert
the reason not to use ethernet for critical
applications is that it is non-deterministic.
There is no way to predict the time it will take
for a message to arrive at its destination.
In fact, there is a vanishingly tiny probability
that it will never arrive.
No problem for sending web pages, or even
dropping a few voice packets on a web call.
But if the information to shift gears, change
throttle, or even radar data gets delayed
there are safety (and liability) issues.
I grant you they are small.
But many government specifications (FAA in particular) banned ethernet entirely from mission critical systems for this reason. If there is
a finite mathematical probability of a message
being delayed beyond usefulness, they won’t stake human life on it.
Or in this case, your boat evidently.
As an engineer I view ethernet as perfectly
acceptable. Unfortunately my lawyers do not.
So we use token buses or NEMA2000 (which is
just an offshoot of CANBUS, an industrial manufacturing bus) in safety applications.
I am sure there are other reasons in the
mess that is the marine electronics industry.
No manufacturer I have seen (save one),
uses NEMA2000 in any sort of compatible manner
or without proprietary formats buried in it to
keep us adding on “foreign’ equipment or actually using their equipment in a way they have not ordained. Seems marine manufacturers all take their lead from microsoft.
But at least here is one plausible reason driven
by something other than the avarice of the
marine manufacturers for not using ethernet.
cheers
gello
Dear Robert,
Avionics Full-Duplex Switched Ethernet (AFDX) is a data network for safety-critical applications that utilizes dedicated bandwidth while providing deterministic Quality of Service (QoS). AFDX is based on IEEE 802.3 Ethernet technology and utilizes commercial off-the-shelf (COTS) components.
The AFDX bus is used in Airbus A380, Boeing 787.
This is one of the backbones of MARSSA.