Yacht Devices YDNB-07N User manual

User Manual
Yacht Devices NMEA 2000 Bridge YDNB-07
also covers models
YDNB-07N, YDNB-07R
Firmware version
1.42
2022

© 2022 Yacht Devices Ltd. Document YDNB07-005.May 24, 2022. Web: http://www.yachtd.com/
NMEA 2000® is a registered trademark of the National Marine Electronics Association. SeaTalk NG
is a registered trademark of Raymarine UK Limited. Garmin® is a registered trademark of Garmin Ltd.

Contents
Introduction 4
Warranty and Technical Support 6
I. Product Specication 7
II. Installation and Connection to NMEA 2000 or CAN Networks 9
III. LED Signals 11
IV. MicroSD Slot and Card’s Compatibility 12
V. Loading of Programs into the Device 14
VI. Structure and Basic Syntax of the Program 15
VII. Description of the Settings 17
VIII. Programming the Device 21
IX. Optimization and Performance 34
X. Debug and logging functionality 38
XI. Firmware Updates 40
XII. Program protection and encryption 41
Appendix A. Troubleshooting 42
Appendix B. List of NMEA 2000 Messages of the Device 44
Appendix C. Device Connectors 45
Package Contents
Device 1 pc.
This Manual 1 pc.
Stickers for MicroSD slot sealing 6 pc.

— 4 —
Introduction
Yacht Devices NMEA Bridge unies two physical NMEA 2000 networks into a single logical network,
smoothly exchanging messages between them. The Device also allows to organize arbitrary ltering,
processing and routing of any CAN bus messages.
This can accomplish the following tasks:
1. Bypass the physical limits of NMEA 2000 networks concerning length of networks
(100 meters for regular cable and 250 meters for heavy or mid-type cable) and concerning
the maximum number (50) of physical devices attached to the network. On a network with
address capacity of 252, multiple bridges can be engaged to expand to around 250 physical devices.
2. Isolate devices from each other. Using the simple lter, you can block transmission of all
or of selected messages from a given device in a separate subnet.
3. Ensure proper functioning of equipment. Correct the transducer oset of the depth sounder,
or “delete” invalid data in messages from equipment that is only partially operational using
a 2- or 3-line script.
4. To ensure compatibility of equipment from dierent generations. You can create
and send any type of NMEA 2000 message using data from other messages in the network.
5. Diagnose malfunctions in the NMEA 2000 network. The Device can record network
messages and debug data from custom programs on a MicroSD card in a text le. You can view
the data in a standard text editor on a smartphone or tablet with a MicroSD slot, there is no need
for a computer. You can even create and edit programs for the Device right on your phone!
6. Create custom gateways that do not meet NMEA 2000 standards. One of the CAN-interfaces
on the Device has high-voltage galvanic isolation and can operate at a higher supply voltage.
7. Create custom gateways joining two CAN networks with arbitrary protocols. Both 11-bit (CAN
A) and 29-bit (CAN B) frames are supported. One of the network can operate at any baud rate from
50 kbps to 1000 kbps. Though device programming language was not designed for full-edged CAN
applications, one can create, for example, a gateway between CAN-based Propulsion System, Battery
Charger or Servo to NMEA 2000.

— 5 —
8. Create custom NMEA 2000 data procesing device, for example, implement complex digital
switching rules for Yacht Devices NMEA 2000 Digital Switching equipment, such as: delayed and
timed switching, auto-o, conditional switching or trigger warnings on a chartplotter when certain
data values are over the threshold.
Programming the Device requires knowledge of NMEA 2000. Copy of NMEA 2000 standard can be
purchased from the National Marine Electronics Association: http://www.nmea.org.
Yacht Devices would like to note that a NMEA 2000 network might contain important
devices such as a deep sounder, magnetic compass and autopilot. Failure or incorrect
operation of these devices can result in serious accidents and fatalities. When
programming the Device, you must be fully aware of all the implications. Before
making a sea-going trial, conduct mandatory training for the vessel’s crew.

— 6 —
Warranty and Technical Support
1. The Device warranty is valid for two years from the purchase date. If the Device was purchased in a
retail store, when applying under a warranty case, the sale receipt may be requested.
2. The Device warranty is terminated in case this Manual instructions violating, case integrity breach,
repair or modication of the Device without manufacturer’s written permission.
3. If a warranty request is accepted, the defective Device must be sent to the manufacturer.
4. The warranty liabilities include repair and replacement of the goods and do not include the cost
of equipment installation and conguration, as well as shipping the defective Device
to the manufacturer.
5. Manufacturer responsibility in case of any damage as a consequence of the Device operation or
installation is limited to the Device cost.
6. The manufacturer is not responsible for any errors and inaccuracies in guides and instructions
of other companies.
7. The Device requires no maintenance. The Device’s case is non-dismountable.
8. If the event of a failure, please refer to Appendix A. before contacting the technical support.
9. The manufacturer accepts applications under the warranty and provides technical support only
via e-mail or from authorized dealers.
10. Manufacturer contact details and a list of the authorized dealers are published on the website:
http://www.yachtd.com/.

— 7 —
I. Product Specification
Figure 1. Drawing of YDNB-07R model of the Bridge
Our devices are supplied with dierent types of NMEA 2000 connectors. Models with the sux R
at the end of model name are equipped with NMEA 2000 connectors compatible with Raymarine SeaTalk
NG (as at the picture above). Models with the sux N are equipped with NMEA 2000 Micro Male connectors
(see Appendix C).

— 8 —
Device parameter Value Unit
Power supply voltage, CAN1 interface 9..16 V
Average current consumption, CAN1 38 mA
Load equivalency number, CAN1 1 LEN
Power supply voltage, CAN2 interface 9..30 V
Average current consumption, CAN2 13 mA
Load equivalency number, CAN2 1 LEN
Galvanic isolation electrical strength between CAN1 and CAN2 2500 V
RMS
Reverse polarity protection on both CAN1 and CAN2 interfaces Yes —
Operating temperature range -20..55 °С
Cable length 500 mm
Device’s case length (without connector) CAN1 / CAN2 54/40 mm
Weight without MicroSD card 52 g
Yacht Devices Ltd declares that this product is compliant with the essential requirements of EMC
directive 2004/108/EC.
Dispose of this product in accordance with the WEEE Directive. Do not mix electronic disposal
with domestic or industrial refuse.

— 9 —
II. Installation and Connection to NMEA 2000 or CAN Networks
Never connect both connectors of the Device to the same NMEA 2000 or CAN network.
This can ood the network with innite forwarding of messages and cause a temporary
inoperability of the network.
The Device requires no maintenance. When deciding where to install the Device, choose a dry mounting
location. Avoid places where the Device can be ooded with water; this can damage it.
Device can be directly plugged into to the network backbone connector. YDNG-07N model can also be
connected via standard "DeviceNet NMEA 2000 Micro" drop cable. If you have a CAN bus with a non-
standard physical layer, connect CAN bus rails and power rails according to Device pinout given in
Appendix C. Before connecting the Device, turn o the bus power supply. Refer to the manufacturer’s
documentation if you have any questions regarding the use of connectors:
• SeaTalk NG Reference Manual (81300-1) for Raymarine networks
• Technical Reference for Garmin NMEA 2000 Products (190-00891-00) for Garmin networks
After connecting the Device, close the lock on the connection to ensure water resistance and reliability.
The microcontroller of the Device is powered by the CAN1 interface. The Device will not work until the
CAN1 interface is powered up. If you want to start up the Device for familiarization purposes or you
implement a custom data processing device which does not need to send data between CAN1 and CAN2
interfaces by design, CAN2 interface can be left unconnected.
The Device has a LED which ashes red or green. When Device CAN1 interface is powered, LED will
produce a series of 2 ashes 5 seconds apart. If this does not happen, see Appendix A.

— 10 —
Figure 2. Typical NMEA 2000 bridging application network layout
Please remember that a NMEA 2000 network requires a separate power supply and two terminators,
on each backbone end. If the Device is used as a bridge, connecting two existing NMEA 2000 network
segments, you have to make sure to add terminators to each backbone segment and power both segments
from a 12V power supply. More information on this topic is available in the above listed documents from
Raymarine and Garmin.

— 11 —
III. LED Signals
1. Signal with period of 5 seconds, two ashes of the LED. The rst ash indicates the condition
of the CAN1 interface network. Green LED ash indicates that data has been received or successfully
sent on CAN1 interface within the last 5 seconds period, red if not. The second ash indicates
the condition of the CAN2 interface network.
The Device can be congured to receive only a limited set of NMEA 2000 messages
(see SectionVII.3), the remaining messages are ltered at the hardware level. In this regard,
some NMEA 2000 networks can indicate a red light much of the time, even when
the network is functioning normally. In this case, to check the connection, turn one device that
is on the network (e.g. the chart plotter) o and on again. The status of the network will be displayed
with green ashes for some time as the device is powering up and connecting.
2. Three ashes (colors may vary), one time after inserting the MicroSD card into
the Device. See Section V.
3. Long ash (3-second), red or green. Diagnostics mode started / nished, see Section X.
4. Five green ashes when NMEA 2000 network is turned on. The Device has the MicroSD
inserted with a rmware update, the rmware is updated (see Section XI).

— 12 —
IV. MicroSD Slot and Card’s Compatibility
The Device has a slot for a MicroSD card that allows you to congure the Device (see Section V) and update
the rmware (see Section XI).
Figure 1. Device with MicroSD card (contact pads side visible at left, label side at right)
The Device slot has a ‘push-push’ mechanism that works on a spring and ensures proper
card xation. Improper loading or unloading (withdrawing your nger too quickly or
not waiting for the click) can result in the card being propelled out of the Device up to 5 meters.
To avoid possible eye injury, loss of or damage to the card, and other hazards, insert
and remove the card with caution.

— 13 —
Since the MicroSD slot is usually not in use when the Device is working, we recommend to seal it with the
sticker supplied with the Device or with a piece of tape to prevent water from entering the Device through
the slot.
The Device supports MicroSD memory cards of all capacities and classes. The MicroSD card must be
formatted on a personal computer before it can be used with the Device. The Device supports the following
le systems: FAT (FAT12, FAT16, MS-DOS) and FAT32. It does not support exFAT, NTFS, or any other le
systems.
Be careful when inserting the MicroSD into the Device. The card is inserted with the label side towards the
LED and with the contact pads side towards the cable.

— 14 —
V. Loading of Programs into the Device
Place YDNB.CFG le with the program into the root directory of a MicroSD card with a FAT or FAT32 le
system. Insert the MicroSD card into the Device. After a few seconds, you should observe three LED ashes:
1. Three red ashes indicates that the card cannot be read.
2. A green followed by two red ashes indicates that the YDNB.CFG le cannot be found
on the memory card and the current Device conguration was saved to the YDNBSAVE.CFG le.
3. A red followed by a green and another red ash indicates that the YDNB.CFG le contains
errors and was not accepted by the Device. The text le YDNBERR.TXT was created in the root
directory of the memory card, comprising an error log.
4. Three green ashes indicates that the le has successfully been loaded into the Device. The text
le YDNBSAVE.CFG was created in the root directory of the card, comprising the current program
and used settings.
The Device performs compilation of the program text into bytecode. Before the Device saves a program
in the YDNBSAVE.CFG le, it decompiles the bytecode to text. This is why the contents of the YDNB.CFG
and YDNBSAVE.CFG les can dier from each other.
The YDNB.CFG le must contain at least one interpretable line of code (a setting, lter etc.) without errors,
in order to be loaded into the Device.
To modify the current program, insert a memory card into the Device that does not contain a YDNB.CFG
le. The LED of the Device will ash green, red, red. This inidcates that a YDNBSAVE.CFG le, comprising
the current program, was saved onto the card. This program can be modied, saved as YDNB.CFG, and
loaded back into the Device.

— 15 —
VI. Structure and Basic Syntax of the Program
The program denes algorithms and rules for the processing and forwarding of NMEA 2000 or other CAN
messages that the Device receives via the CAN1 and CAN2 interfaces.
The program consists of settings, built-in functions, lter subprograms and comments. Settings, functions
and lters are described in detail in the later sections of this Manual.
Comments in the program are added after the # symbol. Comments can be situated at the beginning
of a line as well as after interpretable program text.
Settings can be set anywhere in the program, except for inside subprograms of lters. Nevertheless,
we recommend declaring settings before lters.
Example 1.
# Example N1
FW_CAN1_TO_CAN2=ON # Allow forwarding of all mismatched messages
FW_CAN2_TO_CAN1=OFF # Setting for other direction
match(CAN2,0x01FD0600,0x01FFFF00) # 1st lter
{
# Empty subprogram, matched messages will be dropped
}
match(CAN2,0x00000010,0x000000FF) # 2nd lter
{
send(CAN1) # Forward of matched message to CAN1 interface
}
match(CAN1,0x00000020,0x000000FF) # 3rd lter (for CAN1)
{
# No send(), matched messages will be dropped
}
# End of program

— 16 —
A lter consists of a header, which begins with the keyword match() with parameters dening the incoming
CAN frames "match criteria" followed by a data processing subprogram in specially created programming
language.
The order of the lters is signicant. Device will match received messages against the lters in an exact
same order they are specied in the program. After a successful match, the message will be processed by
corresponding lter subprogram and will not be processed by further lters.
In case there is no match with any lters, the Device follows the forwarding settings. If message forwarding is
enabled for the interface (by default, yes), the given message will be sent to the other CAN interface. If disabled,
the message will be discarded.
Looking ahead, we explain the operation of this program.
The program in example 1 above has only two forwarding settings and three lters.
First, we have two default forwarding rules — those will be applied to messages for which no corresponding
match() subprogram was dened. FW_CAN1_TO_CAN2=ON instructs the Device to forward all messages
received on CAN1 interface to CAN2 interface. FW_CAN2_TO_CAN1=OFF instructs the Device to not forward
(drop) all messages received on CAN2 interface to CAN1 interface.
1st lter will intercept PGN 0x1FD06 received on CAN2 interface — from any device address, however, as its
subprogram is empty, this PGN will be dropped.
2nd lter will intercept any PGN received on CAN2 interface — but only from device with address 0x10 —
and as the subprogram dictates, it will send the message to CAN 1 interface. As PGN 0x1FD06 was already
processed by the 1st lter, forwarding is disabled via FW_CAN2_TO_CAN1=OFF and there are no more lters
for CAN2, the net result will be that all PGNs from CAN2 device 0x10 will be forwarded to CAN2, except
0x1FD06.
3rd lter will intercept all PGNs received on CAN1 interface from device with address 0x20 and block
it. As we have CAN1 -> CAN2 forwarding enabled via FW_CAN1_TO_CAN2=ON, the net result will be
that all PGNs from CAN1 will be forwarded to CAN2, except those from device 0x20.

— 17 —
VII. Description of the Settings
Note that a vertical bar (pipe) is used in the descriptions below to separate alternative setting values.
ON|OFF means, that the setting can have two dierent values — ON or OFF.
1. Forwarding of messages
FW_CAN1_TO_CAN2=ON|OFF
FW_CAN2_TO_CAN1=ON|OFF
Sets the default forwarding rules — denes the behaviour for messages with no corresponding match()
lters. ON — forward, OFF — do not forward (drop).
2. Assembly of NMEA 2000 fast-packet messages
PGNS_TO_ASSEMBLY=x
x — from one to ve PGN, entered as decimal or hexadecimal values, separated by commas.
NMEA 2000 Standard denes a special protocol extension for PGNs with payload overall length higher than
8 bytes (from 9 to 223 bytes) — payload is transmitted in a series of standard CAN frames, each having a
payload length from 8 to 1 byte (refer NMEA 2000 Standard, section "3.1 Fast-packet messages").
The Device can "assemble" NMEA 2000 fast-packet PGNs from the series of CAN frames and present the
whole PGN payload to the program. Messages not completely assembled will be discarded. Assembly takes a
lot of RAM though, so you can select only up to ve PGNs for assembly.
Note that assembly also takes time, as Device will wait until the last CAN frame will be received before
passing the assembled PGN to the program, this will introduce a delay. Use frame-by-frame data processing
technique whenever possible (see Section IX).

— 18 —
NMEA 2000 Standard does not require a strict order of fast-packet frames on the bus. Device CAN controller
has 3 "outboxes", thus fast-packet CAN frames can be put in dierent "outboxes" in the outgoing queue, this
may lead to fast-packet frames to be sent out-of-order. Some NMEA 2000 equipment can not handle this
situation well, in such cases use the following data ow control setting:
STRICT_QUEUE=OFF|CAN1|CAN2|ON
This setting forces strict order of outgoing fast-packet frames for CAN1, CAN2 or both interfaces (ON). By
default is disabled (OFF). Enabling has a slight performance penalty.
3. Hardware lters
CAN1_HARDWARE_FILTER_y=f,m
CAN2_HARDWARE_FILTER_y=f,m
y — number of the hardware lter, decimal number from 1 to 7;
f — lter value, decimal or hexadecimal number (29 signicant bits);
m — lter mask, decimal or hexadecimal number (29 signicant bits).
The Device can lter messages received from the CAN1 and CAN2 interface at hardware level, which in
some cases can reduce the load on the microprocessor by a factor of up to a 100. The message selection is
carried out through the 29-bit identier of CAN frame (CAN ID), which contains the message priority, PGN,
the sender’s address and (in some cases) the recipient’s address.
Formal match comparison expression for both hardware and software lters is:
if ( ( CAN_FRAME_ID AND mask ) == lter ) then MATCH else NO_MATCH
Messages are only passed to the program if they match one of the hardware lters. It is possible
to set up to 7 custom hardware lters for each interface, with numbers from 1 to 7.
Device also has a system hardware lter number 0 which can not be modied by user:
CAN1_HARDWARE_FILTER_0=0x00E80000, 0x01F90000
CAN2_HARDWARE_FILTER_0=0x00E80000, 0x01F90000

— 19 —
The lter (rst parameter) sets bits for the comparison with the message identier and
the mask (second parameter) indicates the bits whose comparison result is signicant. ( 1 — corresponding
by position bit of message CAN ID should match the bit set in lter exactly, 0 — can be any ).
Thus, the system hardware lter passes only messages with the following PGNs: 0xE800 (ISO
Acknowledgement), 0xEA00 (ISO Request), 0xEC00 (ISO Transport protocol), 0xEE00 (ISO Address
Claim).
If no custom hardware lter for the interface is dened in the program, a lter that accept all messages
will be automatically added for the given interface:
CAN1_HARDWARE_FILTER_1=0,0
So if no custom hardware lter is set in the program, all messages will be passed to the program.
4. NMEA 2000 instance
DEVICE_INSTANCE=x
SYSTEM_INSTANCE=y
x — number from 0 to 255, y - number from 0 to 15.
These settings allow you to set the Device's NMEA 2000 "Device Instance" and "System Instance" values
which are used for generation of NMEA 2000 "Device Information" (NAME) transmitted in the ISO
Address Claim message.
The default value of both settings is 0. These settings will not be saved to the YDNBSAVE.CFG le if they
have the default values.
Note that when CAN2 baud rate is set to 250 (CAN2_SPEED=250), setting SYSTEM_INSTANCE=8 (or
higher) prevents sending device own "Address Claim" PGN from CAN2

— 20 —
5. Message slots initialization
SLOTx=aabbccdd… or SLOTx=aa bb cc dd…
x — slot number, 1 – 3;
aabbccdd — sequence of bytes (1 – 229), hexadecimal values.
Device has 3 buers, called "SLOTS" which can be used as outgoing CAN frames templates or as a data
storage buers. SLOTx settings allow to ll slots buers with predened data before program start. Buer
format is described in VIII.2. You can load slot contents to main message buer (DATA) with load()
function and overwrite slot content with save() function (see VIII.8)
Example of non-addressed ISO Request of ISO Address Claim:
SLOT1= 00FFEA18 FF 03 00EE00
Here 00FFEA18 is CAN ID for "ISO Address Claim" in LSB-rst byte order (message priority + PGN
number + device address = 18EAFF00) FF — single frame PGN marker, 03 — payload length in bytes,
00EE00 — PGN payload.
6. Speed of the CAN2 interface
CAN2_SPEED=x
x - speed in kbps, factory setting is 250, allowed values are 50, 125, 250, 500 and 1000.
CAN2 interface speed can be set within a range from 50 to 1000 kbps (NMEA 2000 has 250 kbps speed).
This allows interoperability with various CAN networks. CAN1 interface speed cannot be changed, it has
xed speed of 250 kbps.