Discussion- Multipurpose Onboard Computers: Networks - Protocols - NMEA+others

Note: This thread is a branch from the ongoing "Discussion- Multipurpose Onboard Computers"

CHALLENGES:

• ROBUST, CONFIGURABLE: network connection system
• INTEROPERABLE: With industry-standard NMEA devices
• RELIABLE WIRING: Onboard environment, vibration

IDEAS AND DIRECTIONS:

• NMEA 0183 based: 4800 Baud Serial, single talker, multiple listeners per segment.
• NMEA 'Combiners' or 'Multiplexers' can take 2 or more NMEA inputs and combine them into one NMEA output, with the messages interspersed.
• NMEA can be (carefully) non-standard: Higher baud rates from combiners to USB, Fiber-Optic or Wireless transmission.
• NMEA Control signals TO devices can be routed through many different listener devices.
• ETHERNET may be used with multiple computers. It is possible to send NMEA messages over ETHERNET.

 

Other Contributors.. please check in!

Some of the people who contributed to this subject in the past were:

• MarshMat: Networks and Protocols
• SAE140, Networks, Protocols

This was on a quick look through the thread, not a Hollywood-Legal set of credits, so please don't beat me up if I missed you! Just jump in and comment/suggest/critique.

 

Placeholder 1

temporary

 

INFORMATION: possible onboard networks

Here is some overview information including ideas and suggestions from the group (The [edited] list is from MarshMat):

CANbus Controller Area Network (CAN) is a broadcast, differential serial bus standard, originally developed in the 1980s by Robert Bosch GmbH, for connecting electronic control units (ECUs). CAN was specifically designed to be robust in electromagnetically noisy environments and can utilize a differential balanced line like RS-485. Although initially created for automotive purposes (as a vehicle bus), nowadays it is used in many embedded control applications (e.g., industrial) that may be subject to noise. The messages it sends are small (8 data bytes max) but are protected by a CRC-15 (polynomial 0x62CC) that guarantees a Hamming bit length of 6 (so up to 5 bits in a row corrupted will be detected by any node on the bus). Bit rates up to 1 Mbit/s are possible .
- Useful and robust protocol, reliable, but so many different variations of it (devices may speak the same basic "language", but different "dialects"- like a Texan talking to a Scot) - NMEA-2000 interfaces are based on the Automotive variant of CANbus.

USB (1.1, 2.0 and soon-to-be-announced 3.0) - High bandwidth, cheap, most consumer devices support it - but 1.1 and 2.0 rather limited in cable length, bandwidth drops with interference. Relatively complex to program for (unless used just as a "serial replacement" where it appears in WIN-XP as serial ports).

NOTE: There are now RF Wireless versions of USB that may be useful onboard. The best onboard wiring might be no wiring.

There are available NMEA-to-USB interfaces.

RS232 (old style serial) - Robust, cheap, easy to code for, but limited data bandwidth and cable length

RS485 (industrial-grade serial) - Really robust, still pretty cheap and easy to code, reliable signal on long cables, but limited bandwidth - The standard physical interface for NMEA0183 . Works well for sensor interfaces, etc. that only transmit strings/arrays of numbers, like NMEA.

IEEE1394 (iLink/Firewire) - Blazing fast speeds but hard to implement and pretty expensive - good for entertainment systems (video etc)? Apparently being superseded by high-speed USB in new designs.

802.11a/b/g/n (WiFi) - Good for wireless computer networks/terminals but I don't think it's a total substitute for a wired connection; not that reliable and quite interference-prone. Used for in-port Internet Access in many places.

Bluetooth - Very Short range wireless, commonly used for cellphones etc - probably too short range and interference-prone/unreliable for our boat purposes, but might be suitable for handheld interfaces (accessing your nav system from your palmpilot)?

ZigBee - Another newer RF Wireless interface.

Ethernet - Cheap, fast, widely supported, but software side somewhat more complex than simpler peripheral busses (in boats, Furuno NavNet is Ethernet-based if I recall correctly) NOTE: There is software/interfaces to send/receive NMEA over Ethernet.

Fiber-Optics - There are various fiber-optic transmitters and receivers that might be used. There are low-speed inexpensive plastic-fiber options that might be good NMEA physical replacements. There are high-speed options that can do Ethernet. The electrical isolation of fiber optics may be an asset in lightning surviveability.

 

INFORMATION: NMEA and other possible protocols.

Many of the simpler Network possibilities in the previous post, like RS232, USB, etc. simply send a "Stream of Bytes". The higher level system may decide (like NMEA) that there must be well-defined groups of data sent (ie. NMEA 'sentences').

Faster networks such as Ethernet or CanBus that can have multiple nodes with defined addresses send data in well-defined chunks or "Packets". What the data is and what it means still depends on agreement between the sender and receiver. Large pieces of data are sent as multiple packets that are reassembled by the receiver, with retries for any missed packets.

At this point, I'm leaning strongly towards Keeping It Simple. NMEA sentences on some "Stream of Bytes" interface seem adequate for the monitoring and control needs we are seeing. Other specialized interfaces like Radar or Camera Video, or computer networking can be separate options.

(NMEA Details below)

Here are excerpts from previous discussions (edited):
------------------------------------------------------------------

... I don't see any compelling reason to go to a more complex system like multidrop RS485 or Modbus, or a true network like CAN / NMEA2000 for the kind of DIY and small boatbuilder and retrofit applications we're considering here. I understand why big boatbuilders and Marine Electronics players want and need NMEA2000, but that's a different scenario.

Also, I want to figure out an approach here where many of us with existing boats, refits, and custom builders can put together a working system which includes the many NMEA0183 Instruments out there from CruzPro, Clipper, etc., and including those already onboard and feeding existing cockpit displays.

I don't see any important limitation to the NMEA0183 concept that any segment of a network has only one talker and multiple listeners. NMEA specs say that a Talker should be able to drive 4 Listeners, but that's very easily exceeded, especially with sensitive optically-isolated receivers like a 6N139 with a few other components.

Multiple Instruments, Sensors, Engine monitors etc that are Talkers can be combined (multiplexed) into one NMEA0183 signal going to the computer. At 4800 baud, such a path could saturate at about 10 talkers. BUT there is no reason why the Combiner needs to talk at only 4800 baud, and in fact some combiners use a USB output to the computer at high speed. I like that approach.

So that ends up looking like a 'tree' of NEMA Talkers combining together and going IN to the computer. And devices can be added or removed from (the branches of) that tree without affecting any other devices.

Now, Outputs: As you said, there are very few NMEA devices that need to be talked TO: mainly GPS for upload of waypoints and routes etc, and an Autopilot. I would dedicate one USB/Serial port to this NAV stuff: GPS and probably Depth IN, and Autopilot out. Keep this separated from all the other monitoring and control 'Dashboard' stuff.

Now, if someone builds the hardware and software to do a more complex boat with "Onboard Systems Outputs" as shown on the diagram (See: http://terryking.us/boatbuilding/SystemBlock1.jpg).. these are all Listeners. They may as well be NMEA compatible and listen to one or 2 NMEA outputs. These do not need to be High Speed. Like you said, if there is some high-speed control system it needs it's own dedicated microcomputer.

NMEA OVERVIEW (Excerpt from SailSoft)

The NMEA standard is developed to enable data communication between electronic marine instruments, navigation equipment and communications equipment in a standardized way.

The standard is intended to support one-way serial data transmission from a single TALKER to one or more LISTENERS. This is data in printable ASCII form and may include information such as position, speed, depth etc. Typical messages might be 20 to a maximum of 79 characters in length and generally require transmission with a maximum of one per second. The NMEA 0183 standard is not intended to be used for high-bandwidth applications such as radar or video imagery, or intensive database or file transfer applications.

There is no provision for guaranteed delivery of messages and only limited error-checking capability.

A TALKER is any device that sends data to other devices within the standard. The type of TALKER is identified by a 2-character mnemonic. No provision is made for more than a single TALKER to be connected to the bus.

A LISTENER is any device that receives data from another device within this standard.

Multiple LISTENERS may be connected to a single TALKER. The LISTENER receive circuit shall consist of an opto isolator and should have protective circuits to limit current, reverse bias and power dissipation.

One TALKER and multiple LISTENERS may be connected in parallel over an interconnecting wire. The number of LISTENERS depends on the output capability and input drive requirements of individual devices.

Interconnection between devices may be by means of a two-conductor, shielded, twisted-pair wire.

NMEA 0183 DETAILS

Electrical Interface
The recommended interconnect wiring is a shielded twisted pair, with the shield grounded only at the talker. The standards do not specify the use of any particular connector.

NMEA-0183 recommends that the talker output comply with EIA-422. This is a differential system, having two signal lines, A and B. The voltages on the "A" line correspond to those on the older TTL single wire, while the "B" voltages are reversed (while "A" is at +5, "B" is at ground, and vice versa) In either case, the recommended receive circuit uses an opto-isolator with suitable protection circuitry. The input should be isolated from the receiver's ground.

In practice, the single wire, or the EIA-422 "A" wire may be directly connected to a computer's RS-232 input. Today, many "NMEA Output" devices have a single output terminal with a signal that goes from 0 to +5 volts. This does not really comply with the RS232 or RS422 Standards, but it works because almost all "Serial Port" inputs on modern computers actually sense ones and zeros as "More Negative than + 2 volts" and "More Positive than + 2 volts".

Serial Configuration
Baud Rate: 4800 Data Bits: 8 Parity: None Stop Bits: 1 (or more)

Protocol Rules

• Each message starting character is a dollar sign.
• The next first five characters identify the type of message.
• All data fields that follow are comma-delimited.
• The first character that immediately follows the last data field character is an asterisk.
• The asterisk is immediately followed by a two-digit checksum representing a hex number. The checksum is the Exclusive OR of all characters between the '$' and '*'.
• <CR><LF> ends the message.

NMEA-0183 General Sentence Format
Under the NMEA-0183 standard, all characters used are printable ASCII text (plus carriage return and line feed). NMEA-0183 data is sent at 4800 baud.

The data is transmitted in the form of "sentences". Each sentence starts with a "$", a two letter "talker ID", a three letter "sentence ID", followed by a number of data fields separated by commas, and terminated by an optional checksum, and a carriage return/line feed. A sentence may contain up to 82 characters including the "$" and CR/LF.

If data for a field is not available, the field is simply omitted, but the commas that would delimit it are still sent, with no space between them. Since some fields are variable width, or may be omitted as above, the receiver should locate desired data fields by counting commas, rather than by character position within the sentence.

The optional checksum field consists of a "*" and two hex digits representing the exclusive OR of all characters between, but not including, the "$" and "*". A checksum is required on some sentences.

The standard allows individual manufacturers to define proprietary sentence formats. These sentences start with "$P", then a 3 letter manufacturer ID, followed by whatever data the manufacturer wishes, following the general format of the standard sentences.

Some common talker IDs are:

• GP Global Positioning System receiver
• LC Loran-C receiver
• OM Omega Navigation receiver
• II Integrated Instrumentation
• (eg. AutoHelm Seatalk system)