Saturday, February 29, 2020

Evaluating a Weather Forecast — Slides and Notes Only

These are the slides with short notes and references for the video talk given at the  Cruising Club of America Seminar,  Feb 29, 2020.  You can see the slides in the video, but they do not have the notes and live links, and are not in high res like here. (Disregard the first line below from the first slide; you are looking at that link!)
• This talk is largely highlighting topics whose details are important, which are covered in     
  the book.
• Link to www.starpath.com/wx
1



• I used to say “but they are not marked good or bad," but this is no longer true as we now  
   have probabilistic forecasts for marine weather, as we shall see.
• We have lots of ways to check the timing of a system, mainly with pressure.
• If a forecast is in doubt then just do "half of what you want" until the next forecast in 6 hr
• We are not going to just download a GFS grib and make a decision.
2

• Print out each of the maps viewed side by side for quick overview 
• Both available underway by email request to Saildocs
• Learn something about the map AND something about the text 
• Here we learn the speed of the high moving E 
• We sail around Highs, so this is crucial info 
• First 3 days of GFS is usually good, but we need routes farther, so need extended forecasts. 
• Text forecasts (Storm Advisories) are especially important when dealing with tropical 
   storms. They are available from Saildocs.
3 


• GFS overlaid onto OPC analysis viewed in Expedition compared to official Forecast  
  Discussion 
• We want to use the digital data, so we use OPC maps to check them. 
• Compare at several forecasts. ie compare 06h forecast made at 12z with the 0h 
  forecast made at 18z
• Timing is everything. GFS 0-96h is about 4h, longer forecasts add an hour 
• Discussion tells which models were used and why 
• Both available underway by email request to saildocs 
• Auto load maps in Expedition and OpenCPN. One button click to get georeferenced maps 
   right on your nav screen 
• Let’s look at the zoomed area 
4


• Two GFS isobar parameters — needs a talk of its own! 
• Viewed here in LuckGrib, which has a tutorial with references on MSLET
• Saildocs switched to MSLET as has LuckGrib. Both still call it PRMSL to minimize  
  confusion in display options. WRF models also use MSLET.
• With MSLET we can better understand wind flow relative to isobars (gradient and 
   orientation) 
• Standard PRMSL is effectively an average over ~80 nmi 
• Especially valuable around tropical stormsbut GFS is still not dependable there. 
5 

• Accounts for patches of model wind not consistent with PRMSL isobars 
• Set isobar spacing to 0.25 mb and often see the trof of a front, or some indication of a trof       preceding a front (squall line?) 
6 
• We can set the GRIB viewer or nav software to interpolate the model forecasts to
   the time at hand.
• This wind check process will be illustrated as we proceed
7

• New automated way to compare measurements to models and buoys
• Many videos and info online at modelaccuracy.com
• Calibrated instruments are crucial, as is corrections for wind heights
• Designed for analyzing Expedition log files… but could be other sources.
• N2k gateways provide ways to log wind data from any system
• Our example only with a buoy 
• We added the error bars and redid the base figures
• Automated for buoys with internet connection. We have a note on how to use the buoy
   function underway. Buoy reports by email.
8


• Models and forecasters do not use all ship reports. Many subtle tests applied to the reports 
• Can get either map by email request. Only BW version can we get at 50% size reduction
   from saildocs.
• This bottom right corner or ridge is crucial to Hawaii races, rare to have reports here 
• Either one can be downloaded automatically, georeferenced in opencpn or Expedition. 
• We look at the ship reports on the surface analysis for consistency.  

• Recall nominal wind barbs are ± 2.5 kts
• SST > 80F for hurricane.
• Stable air would make it lower; very unstable only up 10% or so, not 14 to 25.
• Curvature could raise is about 10%. But not in this case
• Ship reports can distort the isobars... ie the forecast adjusts to account for the report
• Something to think about when not in agreement.
• Cannot rely on “wind&waves” maps. Sometimes lots on barbs; more often just
   those from the reports.
10
• Strange format to emphasize we use 80% and not the more standard 60%
• Practice with GFS wind and pressure to see how it works out.
11



• One click download of all buoy data in Expedition... super nice feature
• Mouse over shows what you would read at NDBC
• Procedure, download the buoys then set model time to match the buoy times,
   which may vary from one to the other.
• Expedition brings in latest set of buoy data but saves it when you re-load
• This will be a feature of the S-412 weather overlay to S-100 ENCs.
12

• NDBC stopped sending them to NWS. No reason given. No time for comments.
• No other NOAA source, hence moving weather  data delivery to commercial third parties
• Still in FTP instructions
• We can get the data from Saildocs,  one line per buoy
• Or subscribe specifying days to send, starting time UTC, and hourly interval
• Saildocs has a shortcut: send buoy51000.cur, which works for most buoys but not all. 
  The above link covers all sources as well as land stations such as wpow1.txt
13


• All reports within past 6hr within 300 nmi.
• Server checked on the whole minute and mail sent.
14

• Provides text report plus an attached GPX file of the data
• Includes range and bearing to report.
• Pressure in inches but we convert to mb in the GPX file
15

• Inset shows ship report compared to GFS at the same time
• Can load the GPX reports into any nav program. This example is OpenCPN
• Need to adjust GFS model time to match each report
• We can ID ships to projects when we get later reports
• Can spot isobar shifts. Use red data to figure where that isobar should be.
• Ships with full reports likely have better data… i.e., they are more careful.
• Isobars are moving west at this time.
16


• GRIB ASCAT available from Expedition and LuckGrib.
• Timing the main issue: GRIB versions are 15+ hours old; graphic index is updated
   hourly, and latest pass to show up will be ~ 2.5 hr old
• Latest useful pass could be 6 to 10 hr old.
• Generally get useful data about 3 times a day, since it does not have to be where
   you are to be useful.
• Bottom right is overlay with GFS in Expedition. ASCAT red, GFS black. Shows good  
   agreement east and west of Cabo, but very poor to the SE.
17

• File name index in Modern Marine Weather, the main reference for ASCAT
• Also ASCAT B and C… A plus B makes a somewhat broader swath. Mixing data
   about an hour apart.
• This is a most powerful tool, but it comes with a learning curve. See textbook.
• There is also another set of sat data from Navy WindSat, but it is not often used by NWS.
18


• Text discusses satellite passage apps to help predict when you get the next useful data
• This is rough sketch
• Added so you can read from the slides.
• Can plan out coverage before the race or voyage, so you know specifically when new data
   will be available and you can add it to your sources timetable.
19

• In the NH we sail around Highs
• Omega block can last 10 days
• If a blocking High, the map will look like this tomorrow.
• Else it will likely change
• We can get these 500 mb maps from Saildocs 
20

• Main reference on role of 500 mb maps is from Joe and Lee article. Online at the Mariners
   Weather Log and the book by Chen and Chesneau Heavy Weather Avoidance
• Centers of Action discussed in Modern Marine Weather
21

• See text for more discussion
• These general rules discerned from reading a lot of forecast discussions.
• Operative rule: there is no dependable rule; just guidelines.
• BUT now we have much more to work with… as we shall see.
22


• We will follow up on this example
• Let’s see what happens at about 72 hr out along a Pacific sailing route
23
• SD shows the variations between the ensemble members at each grid point
• A small variation means forecast not as sensitive to input variations and thus it is more
  dependable
• Large SD means forecast  is not as dependable. Small input changes lead to large forecast changes.
• Now back to last slide on 500 mb indicating maybe weak forecast about 72 hr out
24

• SD of 2 kts is more or less consistent, ie ± 2 kts or so is agreement.
• At 44h, 68% of all winds will be within 12 to 16 kts
• Compared to 68% within 0 and 28 kts at 90h with divergence starting about 72h
• Out 84 hours out the SD blows up. Average is about same as control, but member 
   runs diverge a lot, meaning forecast is fragile.
• In short, after about 80 hr the forecast is likely in question.
25

• In stable winds we go out 5 days and still have small SD
26

• Another way to look at forecast dependability
• NBM Oceanic covers most of the globe to 20S
• Probably best extended forecast, meaning more than 3 days or so
• Maybe best on the ocean for all times. This is not clear yet. Could be GFS is best for first 3 days.
• Now look at another example first GFS only, then the blend, then the GEFS
27

• With GFS we see the wind and pressure over time. This is a determinist model. We learn the values, 
  but no uncertainties.
• We do see a veer when the trof  the the nW crosses at 66h
 BUT that is all we see!
• Now let's look at this same forecast with NBM
28

• From h0 to h41 wind is ± 2 kts, which is as good as it gets
• Then it blows up
• Forecast is weak after this point
• Now let's compare this same forecast with GEFS (ensemble)
29

• Here we see mean and control winds along with SD values
• When we see both GEFS and NBM indicate weakness or strength at about the same time
   and place, we are likely safe  in believing it.
• Next we look are some really new resource, just one week old
30

• This forecast (a blend of model outputs) added standard deviation (SD) just last week.
• Extends about 400 to 600 nmi offshore.
• We see notable light patch running NE of Guadalupe Island… but no more details.
• Could be best regional model… includes HRRR and NDFD. We need to study this one in
  comparison to HRRR, which we know works well most of the time to learn more about
  local  forecasting.  We have a note online on this topic. Use of Regional Models
31

• Another example of very new data, i.e., SD In NBM conus just last week
• SD in NBM v3.2 new as of Feb 20
• The light patch has good SD
• But before and after are very uncertain ± 5 kts of wind
• Next add lower valley marker
32

• Let’s look at this point on Google Earth
33
• Here we see what likely leads to the uncertainty in the forecast
• About 1,200 ft each side of 150 to 200 ft
• Channeling is very sensitive to upstream wind direction
• In short, SD has shown us where the forecast is weak… which we do not see from
  any deterministic model
34


• New resources that help us evaluate a forecast.
• Note.  In this study we found forecasts that differ quite notably can still yield about the same optimum routes, with different finish times.  So an eye to the polar diagrams can show how sensitive the route is to the actual wind direction. But as stressed many places, the polars have to be right, or the routing has little meaning, if not a distraction. Also we obviously do not want to take risks for small gains, even though the optimum route will do so, namely go for whatever makes it faster. Thus again the value of the statistical forecasts.


Speaker's related sites:

Frank Bohlen's articles on the Gulf Stream

Ocean Prediction Center (ocean.weather.gov, Jos Sienkiewicz, Branch Chief)

Locus Weather (Ken Mckinley's weather services)

HoneyNav.com (Stan Honey and Sally Lindsay Honey's 's articles and videos)

Seattle Forecast Office (Kirby Cook, Science and Operations Officer)

Starpath.com (David Burch HQ)

References cited in discussions:

Use of Regional Models

Inverse Barometer Effect

Free Marine Barometer app (iOS and Android)

Saildocs

Expedition

LuckGrib

OpenCPN

XyGrib

NOMADS (NCEP source of model data)

How to Obtain Custom Grib Files

How to Combine Grib Files




Friday, February 28, 2020

Introduction to NMEA 2000, with a refresher on NMEA 0183.

Most marine electronics that communicate with each other do so these days using a standard called NMEA 0183, defined by the National Marine Electronics Association (NMEA),  a trade organization of companies working with marine electronics production, service, and sales. Their online magazine Marine Electronics Journal is an excellent source of latest developments in marine electronics, with in-depth articles on all public matters of the NMEA standards. "NMEA" is, for some unknown historic reason, usually pronounced "nee ma."

The NMEA 0183 standard has been in use for over 30 years. It transmits data between instruments in plain language text sentences, via a one-to-one serial connection between them. In this system, one talker  (the instrument sending the data) can have multiple listeners (instruments receiving the data), but each must have its own wire (or wireless) connection to the talker. When the talker talks, the listeners must listen, so this is a bit like talking on a simplex radio connection. While you are talking on VHF channel 9, for example, several folks could tune into channel 9 and hear you—but that is the end of the analogy. When you stop talking, they cannot talk back to you; they are listeners.

A typical GPS unit, for example, sends out several NMEA 0183 sentences once per second or so, one of which is called "GGA," the abbreviation for GPS Fix Data. Every NMEA sentence has a three-letter description or abbreviation that is usually used in discussing them. A typical GGA sentence looks like this:

$GPGGA,223448.00,4740.4726,N,12223.9026,W,1,08,1.0,39.9,M,-17.3,M,,0000*6A

The NMEA sentence is everything between the $ sign and the *, which are the beginning and end markers for the sentence. Characters following the * are a checksum used to confirm a proper sentence was received. There are always 5 characters after the $ that identify the source (talker) and the type of data, which is conveyed by the sentence. The first two (GP in this example) identify the talker instrument as a GPS unit. These talker identification prefixes are specified by NMEA, but they are usually not crucial and not always used consistently—the exceptions are sentences that begin with a P, meaning they are unique (proprietary) to a specific instrument manufacturer.

The GGA in this case is the sentence abbreviation or nickname. There are over a hundred of these defined by NMEA, meaning the data following the comma must be in a specific format and order. Each data element is separated by a comma, with no spaces. If part of the specified data are missing, a null placeholder (,,) must still be in right place. An example is the next to the last data entry in the GGA sentence above, meaning in this case of GGA that the data are not a differential GPS signal.

There are also dozens of these sentences that were at one time defined and recommended by NMEA but are now called deprecated, meaning no longer recommended for new instrumentation—although a few are still required in specific navigation software. MDA (meteorological composite), for example, is required if we wish to display barometric pressure in the Plots plugin of OpenCPN—at least at the time of this writing. The dedicated barometer sentence MMB is also deprecated with suggested replacement of XDR, a generic sensor output sentence.

The required data format in a 0183 sentence is sometimes logical and other times not. In the GGA sentence above, 223448.00 is a time, 22h 34m, 48.00s, which is sort of logical, but the position reported (4740.4726,N,12223.9026,W) is an unusual way to specify 47º 40.4726' N, 122º 23.9026' W, although it must make sense from some digital perspective.

Documentation of the standard, meaning what sentences exist and how they are formatted, is proprietary to NMEA, which they offer in an expensive document, several thousand dollars, depending on the category of the buyer. It is in fact a closely guarded document. Their website warns that anyone who talks about this standard is probably wrong and likely infringing their copyright!  An unofficial description of just the sentences can be found online under the name "NMEA revealed." It is a long standing work of Eric Raymond that thousands of navigators have benefited from over the years—keeping in mind the NMEA warning mentioned above.

NMEA 2000, nicknamed N2k, is the modern upgrade to NMEA 0183. It most likely started in the year 2000!, but seems to have been slow getting underway. I see increased articles and discussion on line about it starting around 2009 or so. There are numerous reasons that 0183 needed to be updated, largely traceable to the very many more sensors we now find on typical vessels, with associated requirements for higher transmission speeds. The slow, one-to-one wiring of the 0183 showed its limits very quickly in this evolution. A need for improvements in data definitions and combinations were also on a steady increase as our instrumentation became more sophisticated.

While this need for improvement was increasing in the marine industry, a similar need in the automotive industry had been largely solved. The electronic circuits in a typical modern car include 50 or more Electronic Control Units (ECU), each of which is made up one or more microprocessors that monitor and control various subsystems on the car.

It is crucial for safe, efficient operation that these controllers can communicate back and forth amongst themselves quickly and dependably. The networking standard that was developed to meet these needs is called the Controller Area Network (CAN). It is based on a single cable bus that all the ECU tap into called the CAN bus.



Sample of a car mechanic's diagnostic tool tapped into the car's network viewing the status of various components. Similar tools are now available to marine electronics engineers for testing vessel's N2k networks.

The automotive CAN bus system is the protocol or standard that N2k was adapted from. It is also used to manage systems of medical instruments, as well as, for example, the many interacting systems of large complex buildings. In the marine application, the CAN bus is called the backbone, and the controllers or nodes along the bus are the instruments or sensors in use.



A schematic showing how the two systems might link several instruments to a computer to display or use the data. The gateway translates the N2k signals to 0183 used by many nav programs.

The N2k backbone is a 5-pin cable that wanders through the vessel providing a single path for all electronics to tap into. We can get data from GPS units, heading sensors, knotmeters, heel and pitch, radar CPA data, wind instruments, various temperature sensors, barometer and humidity sensors, soundings, house and navigation lights, multimedia equipment, engine, battery, and refrigeration monitors, and more. It is not intended for high bandwidth nodes such as video or live radar, but these inputs are commonly combined with N2k networks.

These data in turn are shared with various multifunction displays (MFD), chart plotters, and switch controllers, along the backbone, and somewhere along the line we have to tap in 12V to power the devices (some devices may still need an independent power source). The power tap can be at one end of the bus, or a special N2k power tee that can send power both directions in the backbone. A 3A inline fuse is typical. The N2k standard is 12V only, with no 24V alternative—although in principle an all-24V system can be used.

Also, somewhere we need to tap in with a gateway device that lets us read and connect to any or all of the outputs in a computer or mobile device.  Conveniently, it does not matter where the various components tap into the backbone. The gateway devices can also be the place where 0183 instruments are added to the network via 0183 to N2k converters, or this can be done with a separate device on its own node. Gateways are discussed further below.

NMEA 0183 standard network speed is 4800 baud (4.8 kbps), corresponding to about 10 messages per second, with high-speed options, such as 9600 baud for NAVTEX, or 38400 for AIS. N2k speeds are nominally 250 kbps, which is about 50 times faster than 0183 networks. In N2k there are no designated talkers nor listeners; all devices (up to 50 nodes on a backbone) can send, and all can receive, although priorities among them can be set. Larger vessels or more complex networks might have more than one backbone in use.


A schematic N2k network. Terminator plugs (120 ohms) are required at each end of the back bone. There are male and female versions to accommodate each end. Not shown is one of the popular wireless gateways that transmits the data to tablets and phones on the vessel. The multiport connector indicated is called "N2k approved." I first saw it in an official NMEA video, but they now warm that care must be taken when using them, and they are not a "certified" device.


Many N2k suppliers have network installation guides that discuss the networks in general, plus crucial details such as how to compute maximum drop line lengths, power drops along a long backbone, and more—it has long been our advice with all electronics that we should read as many manuals as we can find, not just those for our own brand, because we usually learn something new from each one. Here are a couple samples of the generic network manuals:  Actisense,  Garmin, Maretron.

There are many virtues of the N2k network, which we look at below, but one simple one is when we are confronted with three or four alarms going off at once, we can turn to one custom designed screen that will not only identify the alarms, but graphically show what parts of the vessel are involved. Sample screen displays are shown below.


Sample from a large power-driven vessel, but even smaller vessels, power and sail, can design a panel with all important gauges showing. Without knowing the details, crew standing watch can report if any lights go red. 


Users can design their own displays. Both of the above from Maretron's N2kView.

Other navigation and performance displays can also be custom defined with some N2k instruments or software products. But that feature is not new. We can do customized performance display with many 0183 instruments; it is just that much more can be included in N2k, and at faster speeds, and indeed the wiring running through the boat is very much cleaner and much easier to assemble.

Here is the backbone on the J/105 Jaded. Thanks to skipper Chris Phoenix for inviting us onboard and taking the panel down to give us a look.


Far left is the power tee and far right is a Garmin GND 10 gateway that converts the N2k data to 0183 for display in the PC nav program Expedition. Other drop lines are MFD displays and wind instruments. The VHF-AIS is mounted on the panel in front. 

Chris noted that last year he purchased a N2k heading sensor to be integrated into several devices just before departing on the delivery to the Swiftsure Race, 35 nmi to the north. On the trip north he read the instructions and installed it, then swung ship to calibrate it just before tying up at the dock, and has not had any issues with it since then. It would take an even braver person to make such a last minute underway installation of such a crucial instrument with conventional 0183 wiring.

Thanks, also, to another J/105 (Jubilee) skipper Erik Kristen who shared his experiences with his N2k system and offered his system for several tests we did together on his boat and with his Actisense gateway in our office.

But despite all its advantages, it would be a long stretch to consider N2k as a step toward a "simpler" networking protocol compared to 0183. It is faster and more versatile, and indeed it is much simpler to plug in all the presumably compatible (certified) components, but it is not in any other sense simpler.  Indeed, I would have to guess that this system has notably enhanced the role of trained electronics installers on setting up our electronics, especially if we need to include some 0183 components, which is often the case.

In the 0183 system it has always been easier to interface instruments if we used as many as possible instruments from the same manufacturer. Interfacing instruments from different companies has historically been difficult or impossible. This problem is very much reduced in N2k, which is in principle plug and play amongst N2k devices from any company... but not quite.

We still have instruments from prominent marine electronic companies such as Raymarine SeaTalkNG, Simrad SimNet, FurunoCAN that are N2k systems, but they each use their own custom connectors and cables—although some now offer official N2k hardware, which follows the DeviceNet standard (Micro-C, M12, 5-pin screw connectors), an N2k standard also adapted from the auto industry. Furthermore, not all devices that use official N2k connectors meet the official N2k device standards.

NMEA warns us that devices advertised as N2k compatible or compliant or approved are not the same as N2k Certified, which is their proprietary terminology. Components may have the same connectors, but non-certified devices may not interoperate as intended. Think of how many software programs we use daily that start out at installation with a warning from Microsoft or Apple that they are not approved, so you are on your own. Many such apps work fine for what we need, but there could be limits we are not testing. There is a searchable list of certified devices at nmea.org, or we can check with someone who is already using a device in question as we want to.

Note that a "NMEA 2000 approved" device is not an official description implying a certified device, but a "NMEA 2000 approved" cable or backbone component does mean it meets the N2k DeviceNet standard. So the terminology for devices and hardware is slightly different. For actual devices and instruments, look for the official logo on NMEA certified products to gain confidence with interconnecting different company's products.


A big difference between N2k and 0183 that perplexed me early on is the raw data stream in N2k cannot be read like we can read the text sentences in 0183. We have to have an interpreter. The device that typically includes this function is a N2k gateway, mentioned above. They serve as a bridge between the N2k network and an external computer or other device. A gateway can do more than just display message content and transfer the data to a computer for navigation or analysis, they can also be used to configure various parameters such as frequency of measurements,  as the signals move from backbone to computer. Some gateways can also be used to combine 0183 and N2k data as it enters the computer, along with other tasks. Some gateways are data loggers as well, which can in turn display graphs of various parameters.

The various N2k gateways available and what they do make up a subject of its own. Your gateway of choice will be a key component of your N2k system. There are several versions available from several companies, and you may need or benefit from more than one. They each have a hardware and software component. Generally they are designed around the devices of a specific company, but in turn they interact on some level with all signals on any backbone. They can offer USB or wireless export from the backbone, with wide-ranging functionality.  Several examples are mentioned below.

An example of a wireless gateway display on an iPad

Many mariners have gotten by for years without getting into the details of the NMEA 0183 sentence structure, but sometimes we cannot avoid it. In fact, with the transition into N2k we might have to learn more about 0183 sentences than we needed before we got involved with N2k. This can come about when setting up navigation software that reads various performance sensors, because the nav program needs to know where to look for specific data. Sometimes data such as, say, true heading or apparent wind data can be in two or more sentences, which can pose an issue if the software is setup to only read one of them. Or more subtle, some sophisticated wind instruments include GPS, heading sensor, and heel sensor, so they can output a sentence with true wind speed and direction, whereas the software might be intent on computing this themselves from apparent wind and some measure of vessel speed and direction. Some nav software has more control over what sentences are used or allowed to be used than others. In short, there is not a standard that covers how we should use the standards.

This issue has not totally gone away with N2k, but it is much reduced in the new system of data specification. N2k does not use 0183 text sentences, but instead uses hexadecimal data messages identified by their Parameter Group Number (PGN). Thus a PGN in N2k corresponds to a NMEA sentence in 0183. Below are some examples.

If we connect several 0183 devices to a computer, and then looked at the serial input with a terminal emulator such as CoolTerm, we would see something like the following:


These are sentences from a GPS, a heading sensor, and a barometer. Most nav programs have a way to look at this type of raw input without the need of a separate terminal emulator, usually in the connections section of the setup screens. The terminal emulator remains valuable, however,  if we, for example, do not see anything getting through to the program; also some programs let us block specific sentences, so knowing what we are sending to the program can be helpful. If these were 0183 devices, this data stream would look essentially like this for any device,  and we could plug them into any computer. The structure is:

$ (to start), xx (to ID the talker), xxx (to ID the sentence type), x,x,x... (the data), * (to end),  xx (checksum).

On the other hand, if the above devices were N2k we would not be able to directly see equivalent raw data streams in our navigation programs (such as Expedition, Time Zero, OpenCPN, etc). We would need a gateway, whose main job is to make the N2k data visible to programs expecting 0183 data. When we look at these same devices as N2k instruments we would see something like the following for the N2k data stream, depending on the gateway in use.


This is a section of an output screen from the Yacht Devices (YD) Can Log Viewer software (CanView) that reads its USB gateway (YDNU-02NM) from our test bench backbone. The red values are the ones that are changing.

Our simple test bench is shown below.


Left to right: Actisense NGT-1 gateway, Lowrance Point-1 GPS and heading sensor, Yacht Devices YDNU-02NM gateway,  YD barometer YDBC-05N, 12V power tee
with 120-ohm terminators at each end.

Key components of a PGN message reflected above are a System ID, followed by a data length code (DLC), followed by the data in coded hexadecimal. The SID encodes and relates the actual data type (PGN) along with other data needed (in other PGNs) to interpret the source and destination, including which data are valid at the same times, priority of devices when more than one has same data, and so on. It is common to have more than one GPS, for example, so one gets priority; also in a complex system that might have competition for bandwidth, a GPS signal will get priority over the temperature of your fridge. In short, there are numerous PGNs needed to interpret the data that are not just the PGNs with direct sensor outputs that have corresponding NMEA sentences.

Within the CanView software we can also look at other aspects of the network including a logging function to plot trends in any of the data.


Several displays from the YD CanView software listing components of the network and present values. Other displays list the NMEA sentences they have created, and more.

This gateway can also be used to set units on the output as well as apply offsets for calibration. The serial numbers and firmware versions of all components can also be accessed here; N2k products are all evolving, so convenient updates is an advantage.

Below is a sample display from the Actisense gateway viewed in their app called NMEA Reader.

 This display shows the sentences they have created from the input PGNs along with an option to translate the NMEA 0183 sentence components.

Again, the big difference between viewing N2k raw data streams and the corresponding data stream from a native 0183 device is we cannot read the PGNs in plain language. Everything is encoded. We can't even easily see what the PGN values are themselves. There is an official NMEA look up table that describes the PGNs very generally (and this NMEA list that has a bit more detail), but the official N2k standard does not seem to prescribe directly how 0183 sentences are to be converted to PGNs, or vice versa. It appears this is decided by the gateway manufacturers. To see how this is being handled we have to look at the gateway output. As with 0183, the same data can appear in more than one PGN, but the trend is to reduce this variation, meaning multiple sentences that include a specific parameter get rendered into fewer PGNs.

Samples of N2k raw data streams are shown below.


Gateways often include the data conversion information in their manuals—the Maretron manuals have especially good sections on this, with valuable annotations. A sample of how they describe the PGNs they use is below.


Other gateway documents and displays correlate the conversions being made, as shown in this sample from an Actisense document:


The above list includes the statement "The NMEA conversions detailed in this list may change without prior notice as part of our ongoing product improvement process," which supports the idea that individual gateways decide how they are going to make the conversions, and that they can vary from one gateway to another.

A barometer pressure, for example, can be contained in two 0183 sentences, MDA or XDR. The former, named Meteorological Composite, is actually deprecated, but some popular programs still require it, such as OpenCPN. The latter is a generic Sensor Output, which is now the preferred choice. Coincidentally, there are also two PGNs that include atmospheric pressure, 130310 and 130311, both called Environmental Parameters, and we have just learned that there is a new recommendation, 130314, called Actual Pressure, although few devices actually read this PGN.  In short, the N2k goal of simplifying the parameterization must be a still on going process.

In our tests, the N2k barometer shows up as both 0183 sentences in one gateway, but only as MDA in the other. These matters can be more challenging when working with wind data where we have to distinguish water-referenced wind and ground-referenced wind, with and without corrections for leeway and heel. In this regard, there seems to be enhanced performance of a gateway with its own N2k devices, compared to mixing device and gateway sources.  Universality has definitely improved with N2k, but it is not 100 percent. We will have a follow up article on the excellent YD N2k barometer and the unique GPS plus heading sensor from Lowrance.

There is rarely any issue when using all the same manufacturer's sensors, feeding them into the manufacturer's own chart plotter or MFDs. The navigator's challenge comes about mostly when inputting data from diverse sources into a navigation program on a computer or tablet. Then we rely on a gateway for the translations.

A potential nuance is something like this: in 0183 sentences AAM and RMB there is a field for waypoint Name (in other places called waypoint ID). In the 0183 definitions these Names or IDs can be alphanumeric, such as "04-Jones-Pt."  This is consistent with our long standing advice that waypoints should always have both a number and a name. It saves a lot of potential troubles underway. The PGN 129284 is the one often associated with AAM and RMB, but N2k waypoints IDs can only be digital numbers, so using and maintaining real waypoint names could be an issue to keep an eye on.

We can correlate the 0183 sentences with N2k PGNs in many cases, but certainly not all. There are some 148 NMEA 0183 sentences with about 560 parameters defined, in contrast to some 163 N2k PGNs with some 1570 data fields defined, according to a post on an Actisense blog. Nevertheless, despite the expanded options for general communications, most navigation and environmental messages are getting more unified, which is probably for the best.

Again, it seems the key to interacting with a N2k network is the choice of gateways we make. Each of the popular ones we looked at offers a free copy of their software along with samples of data files that can simulate an actual connection to a backbone. Working with these programs and their test files seems a good way to find the best choice for the application at hand. Here are the three we looked at:
Actisense NMEAReader (PC)
Yacht Devices Can Log Viewer (CanView)  (PC and Mac) 
Maretron N2kAnalyzer (PC)
If it might help, NMEA 0183 sentences can be decoded online, as well as 0183 AIS sentences.

Some aspects of N2k may not be of much interest to many sailboats, but typical medium to large power boats have more systems to monitor. The subjects of switching systems and engine monitoring are all covered well in N2k and can have a major impact on the navigation and functioning of the vessels. Engine monitoring is done on a similar but different network called J1939, but devices are available to combine them.

Summary of N2k Benefits

•  Lets any component communicate with the entire system. See all parts of the network on one screen and tap into any one for diagnosis or configuration.

•  Relatively low cost, due to simplified wiring via one backbone. Plus wireless gateways can now replace expensive multifunction displays. (On the other hand, some components are notably more expensive than they might be due to high NMEA N2k licensing fees.)

•  Simplified power distribution to most components, with the 12V lines within the backbone. 

•  Improved protection against individual failures, electromagnetic interference, or salt water damage.

•  Technically superior network: faster, safer, and more efficient.

•  Flexibility. Add and remove components as needed, often with plug and play ease.

• With several gateway  brands we can log data from any device (i.e., wind speed and direction) and then graph the results or export them as csv to be analyzed in another program. High-end nav programs and high-end sensors offer this feature in several cases on their own, but now it is more generally available to essentially any parameter. Plotted data are always a boon to good navigation.

N2k is much more powerful and versatile than 0183 and vessels will benefit greatly in convenience, efficiency, and indeed safety as a result. The question skippers might face when updating electronics is: Do I add N2k units to my 0183 system, or do I bite the bullet and replace all with a new N2k system? I have spoken with folks who have done both, and my small sample shows two categories: those who are glad they went to all N2k at once, and those who in retrospect wish they had.

Our workplaces on land are more networked and efficient now than they were 10 years ago, but many offices pay the price of needing new staff or consultants trained in what has come to be called "information technology."  Well... we have to face it now that navigators are going to have to take on more of the role of an IT person, as well as the other duties in their lap, which include weather work, another area that is becoming more and more technical.

This trend is not going to diminish. The next generation of electronic charts, for example, which we have recently learned will replace all paper charts within five years, are going to be massive GIS products that include an overlay of live weather data available with a click on the chart. Get out your pocket protectors and buckle up!