11. Marine MFD integration by NMEA2000
11.1. NMEA2000 Introduction
Our GX Devices feature an NMEA 2000-out function: when enabled, the GX Device acts as a bridge: it makes all Battery monitors, Inverter/chargers and other products connected to the GX device available on the NMEA2000 network.
Using that feature, and having the GX Device connected a NMEA2000 network, Marine MFDs can read this data and visualise it to the user. Often in a highly configurable manner.
Use our VE.Can to NMEA2000 micro-C male cable to connect the GX Device to the NMEA 2000 network.
Comparison to the App integration
Compared to MFD integration using the App, as explained in the previous chapter, integration via N2K offers a more customisable configuration. The downside of integration via N2K is that there is more work in making such configuration, as well as making sure all PGNs and fields therein are supported and compatible between the Victron system and the MFD.
More information
Besides this chapter, make sure to also read the introduction blogpost, as well as our main Marine MFD Integration document.
Besides this chapter, make sure to also read (1) the introduction blogpost, (2) our main Marine MFD Integration document and (3) the NMEA2000 chapter in the Victron manual for the MFD you are using (Navico/Simrad/Lowrance/B&G, or Raymarine, or Garmin, or Furuno)
Yes that is a lot of reading, but that is basically inherent to NMEA2000: for example some of those MFDs support displaying AC data received over the NMEA2000 wiring, others do not. Some require changing Data instances, others do not, and so forth.
11.2. Supported Devices / PGNs
NMEA 2000 defines several messages. Messages are identified by their parameter group number (PGN). A textual description of the message is publicly available on the NMEA 2000 website (http://www.nmea.org/).
Detailed specification of the protocol and message definition or part thereof can be ordered online on the NMEA 2000 website.
NMEA 2000 is based on and compatible with SAE J1939. All AC information messages are in the AC status message format as defined in J1939-75. The specification of these messages can be bought on the SAE website (http://www.sae.org/).
For a detailed list of PGNs, please refer to our data communication whitepaper.
Inverter/chargers
All inverter/chargers that connect using a VE.Bus port are supported. This includes Multis, Quattros, MultiPlus-IIs, and other (similar) Victron inverter/chargers.
Data is transmitted out; and its possible to set shore current as well as switch the inverter charger on, off, inverter only and charger only.
The interface has two functions:
The function, “153 Inverter”, represents the AC-output
The function “154 AC Input” monitor represents the AC-input
Charger Status messages will be sent by the Inverter function. Both functions have their own network address.
Since both functions transmit the same PGNs, for example an AC Status PGN containing voltage, current and more information, NMEA 2000 data consumers like generic displays will need to be able to make a distinction based on the network address.
Depending on the function belonging to that network address the need to interpret it as either Inverter Input or Inverter Output.
Displays not being capable of doing so will regard the data as belonging to the mains (utility).
The Inverter Output is then interpreted as utility #0 and Inverter Input as utility #1. These default instance numbers can be changed by a network configuration tool if necessary.
Battery temperature as measured by the inverter(/charger) is transmitted as well.
All VREG communications need to be sent to be sent to the address representing the Inverter function. The other one, AC input, does not support VREG requests: that address only transmits AC information related to the AC input.
Inverters
Both the range of Inverters connected via VE.Bus as well as our range of Inverters connected using a VE.Direct cable is supported and its information made available on the NMEA2000 network.
Battery monitors
Supported. This includes any battery monitor as supported by the GX Device.
Solar chargers
Supported. Battery related values as well as the PV Array Voltage & Current is made available on the NMEA2000 network.
AC chargers
Phoenix Smart IP43 Charger 120-240V and 230V models are supported. Only the 120-240V model allows to be remotely controlled (on/off and input current limit) from a compatible MFD.
Tank level data
Supported. Tank levels measured by the GX Device are transmitted using PGN 127505 Fluid Level. The Device instance as well as the Data instance, for this PGN called the Fluid instance, are both automatically numbered for each tank reading. The first tank is assigned number 0, the second tank is assigned number 1, and so forth.
Other data and product types
Not supported. Above explicitly mentioned types are the only ones now supported. For example data from a charger (such as the Phoenix Smart Charger connected via VE.Direct) is not supported and not expected to be supported soon.
11.3. NMEA2000 Configuration
Setting | Default | Description |
|---|---|---|
CAN-bus Profile | VE.Can | Defines the type & baudrate of the CAN-bus network. To use in combination with NMEA2000, make sure to choose one of the profiles that include VE.Can and is at 250kbit/s |
NMEA2000-out | Off | Enables and disabled the NMEA2000-out function |
Unique identity number selector | 1 | Selects the block of numbers to use for the NAME Unique Identity Numbers in the PGN 60928 NAME field. For the GX Device itself, and when NMEA2000-out is enabled, also for the virtual-devices. Change it only when installing multiple GX Devices in the same VE.Can network. There are no other reasons to change this number. For more details regarding the Unique identity number, read the last section in this chapter. |
Check unique numbers | Searches for other devices that use the same unique number. When the search is completed it will respond with either an OK, or the text : There is another device connected with this unique number, please select another one. Note that there is normally no reason to use this function: the GX Device automatically and continuously checks uniqueness of the numbers in use, and will warn when in case there is a conflict. This setting is made available to quickly confirm that everything is OK after changing the setting. |
11.4. NMEA2000 Configuring device instances
The Devices submenu gives access to a list showing all detected Devices on the VE.Can / NMEA-2000 network:
 |
Each entry first shows the name - either the product name as in our database, or when configured, the custom name as configured during installation.
Then, between the square brackets, the Unique Identity Number is shown.
On the right, you can see the VE.Can Device Instance which is the same as the NMEA-2000 Device Instance.
Press enter to Edit that Device Instance. Or, press the right-key to go one step deeper in the menu structure, to a page that shows all generic data available for that device:
 |
11.5. NMEA2000-out technical details
11.5.1. NMEA2000 Glossary
Here is a glossary to help with the interpretation of this text:
Virtual-device: a Battery Monitor, Inverter, or other Victron device that does not have a CAN-bus port by itself, made available “virtually” on the CAN-bus by the NMEA2000-out function of the GX Device.
CAN-bus: the VE.Can port on the GX Device, that, in the context of this chapter, is most likely connected to a NMEA2000 network.
NMEA2000-out function: the software feature in the GX Device, which is described in this chapter.
NMEA2000: Marine CAN-bus protocol, based on J1939.
Instance: there are many types of instances, and explained in detail below.
J1939: A set of standards defining a CAN-bus protocol, defined by the SAE organisation.
Address Claim procedure (ACL): a mechanism, specified by J1939 and used in NMEA2000, which used by devices on the network to negotiate and assign each device on the network a unique network addresses. Its is a number from 0 to 252. There are three special network addresses defined:
0xFD (253) - Reserved
0xFE (254) - Unable to claim address - for example when all others are in use
0xFF (255) - The broadcast address
11.5.2. NMEA2000 Virtual-devices
When the NMEA2000-out feature is enabled, the GX Device acts as a bridge: it will make each Battery monitor, Inverter/charger or other device that is connected, available individually on the CAN-bus.
Individually, as in each with its own network address, its own device instance, function codes, and so forth.
For example, a GX Device with two BMVs connected on a VE.Direct port and an inverter/charger connected using VE.Bus, will make the following data available on the CAN-bus:
Address | Class | Function | Description |
|---|---|---|---|
0xE1 | 130 (Display) | 120 (Display) | The GX Device itself |
0x03 | 35 (Electrical generation) | 170 (Battery) | The 1st BMV |
0xE4 | 35 (Electrical generation) | 170 (Battery) | The 2nd BMV |
0xD3 | 35 (Electrical generation) | 153 | The inverter/charger (AC-output) |
0xD6 | 35 (Electrical generation) | 154 | The inverter/charger (AC-input) |
11.5.3. NMEA2000 Classes and functions
As per NMEA2000 specification, these define the types of senders and devices connected to the CAN-bus. Classes are the main categories, and functions specify it to a further detail.
11.5.4. NMEA2000 Instances
NMEA2000 defines three different instances:
Data instance
Device instance
System instance
For all Battery monitors and other devices that the GX Device makes available on the CAN-bus, each of the above types of instance is available, and can be individually configured.
Per virtual-device, there is one Device instance and one System instance. And depending on the type of the virtual-device, there are one or multiple Data instances.
For example, for a BMV-712 there are two data instances, one “DC Instance” for the main battery, and another one for the Starter battery voltage.
How to configure the instances depends on the equipment and software that is used to read them from the CAN-bus. Examples of equipment and software meant here are MFDs such as from Garmin, Raymarine or Navico; as well as more software oriented solutions from for example Actisense and Maretron.
Most of those solutions identify parameters and products by requiring unique Device instances, or using the PGN 60928 NAME Unique Identity Numbers and do not rely on the data instances to be globally unique. There are, however, a few exceptions: for Raymarine and Furuno MFDs the data instance needs to be changed in order to properly show data. Please refer to the MFD integration page for more details.
The NMEA2000 specification specifies the following: “Data instances shall be unique in the same PGNs transmitted by a device. Data instances shall not be globally unique on the network. Field programmability shall be implemented through the use of PGN 126208, Write Fields Group Function.”.
In other words, data instances need to be unique only within a single device. There is no requirement for them to be globally unique – the only exception is “Engine Instance” that at least for now, to cope with legacy devices, needs to be globally unique (e.g. Port = 0, Starboard = 1). For example, some of our BMV Battery monitors can measure two voltages, one for the main battery, and one for the starter battery, and thats where data instancing is used. Similar for multiple-output battery chargers. Note that there is no need for the installer to change those data instances, as those products are pre-configured to transmit the relevant PGNs with unique data instances (Battery instance & DC Detailed instance, in this case).
WARNING: whilst it is possible to change the data instances, changing them on a Victron devices will render that device impossible to read correctly by other Victron devices.
A note about the Device instances: it is not necessary to assign a unique device instance to each device on the CAN-bus. Its no problem for a battery monitor and a solar charger to both be configured with (their default) Device instance 0. Also when having multiple battery monitors or solar chargers, it is not always necessary to assign each of them a unique device instance. If at all necessary, they only need to be unique between the devices that use the same Function.
And note that changing the Device instance on a Victron device can change its operation, see below.
System instances
As per NMEA2000 specification, this instance is a 4-bit field with a valid range from 0 to 15 that indicates the occurrence of devices in additional network segments, redundant or parallel networks, or sub networks.
The System Instance Field can be utilized to facilitate multiple NMEA 2000 networks on these larger marine platforms. NMEA 2000 Devices behind a bridge, router, gateway, or as part of some network segment could all indicate this by use and application of the System Instance Field.
The ECU instance and Function instance
In some documentation and software tools, yet other terminology is used:
ECU Instance
Function Instance
Device Instance Lower
Device Instance Upper
Here is how they all relate: the ECU Instance and Function Instance terminology originates from the SAE J1939 and ISO 11783-5 specification. And they do not exist in the NMEA2000 definition. However, they all do define the same fields in the same CAN-bus messages which NMEA2000 defines as Device instance.
In more detail: the field that J1939 defines as ECU Instance is in the NMEA2000 specification renamed to Device Instance lower. The Function Instance is renamed to Device Instance Upper. And together they form the Device Instance, an NMEA2000 definition.
While using different terms, those fields are the same fields in both standards. Device Instance Lower being 3 bits in length, and Device Instance Upper 5, together 8 bits. Which is the one byte being the NMEA2000 Device Instance.
The Unique Instance
The Unique Instance is one more word used to describe almost the same information. It's used by Maretron, and can be made visible in their software by enabling the column. The Maretron software itself chooses between Device Instance and Data Instance.
11.5.5. NMEA2000 Changing Instances
Data instance
Even though we recommend to not change data instances (see explanation and WARNING above), it is possible to change them.
There is no option within Venus OS to change them - a third party tool is required and the only tool that we know can do that is Actisense NMEA2000 reader.
To change the Data instances, see this document.
Device instance
To change the Device instances, see this document.
WARNING: these (Victron-)features depend on the Device Instance:
For an ESS system with Solar chargers connected on a VE.Can network, those Solar chargers must remain to be configured to their default Device instance (0) for proper operation. This does not apply to VE.Direct-connected Solar Chargers made available on the CAN-Bus as a Virtual-device, using the NMEA2000-out function. Unless the Device instance of the GX Device is re-configured to another Device Instance. Which is technically possible but not advised and also never required. But in that situation the chargers must be configured to the same instance as the GX Device.
For systems with managed batteries, the same.
For both Solar chargers, as well as AC-Connected battery chargers, when connected in a VE.Can network, they will synchronise their operation. Charge state and such. For that function to work, all chargers must be configured to the same device instance.
In summary, for the majority of systems we recommend to leave the Device instance to its default, 0.
11.5.6. PGN 60928 NAME Unique Identity Numbers
The GX device will assign an individual Unique Identity Number to each virtual-device. The number assigned is a function of the PGN 60928 NAME Unique Identity Number block aka Unique device number for VE.Can as in above screenshot, as configured in the settings of the GX Device.
This table shows how changing that setting translates into the virtual-devices as made available on the CAN-bus:
configured Unique Identity block: | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
GX device | 500 | 1000 | 1500 | 2000 |
1st virtual-device (for example a BMV) | 501 | 1001 | 1501 | 2001 |
2nd virtual-device (for example another BMV) | 502 | 1002 | 1502 | 2002 |
3rd virtual-device (for example a third BMV) | 503 | 1003 | 1503 | 2003 |