October 19, 2016  NMEA 2000 Bridge firmware update 1.01 and new CAN Log Viewer tool

Firmware v.1.01 for the NMEA 2000 Bridge includes two significant modifications: the programming language now has new keywords init() and heartbeat(), and an additional format for logs is added. And we are glad to present a new tool for logs viewing and conversion: CAN Log Viewer.

In this firmware, the new keywords init() and heartbeat() were added to the programming language. These allow creation of really smart programs.

init() can be used to initialize program variables; it is guaranteed to be called when the device is turned on, before any other user code. Note, the program inside init() can't send network messages because the NMEA 2000 standard prohibits sending of any messages during the first 250 milliseconds after the device's address claim procedure, and any send() calls from user's code will be ignored.

heartbeat() can be used when a program (or part of user's code) must be executed periodically. It is necessary to specify the periodic interval in milliseconds in the parameter. The heartbeat() keyword is first called from the user's program immediately after init().

These new functions help to create really smart programs. For example, we need to block a Water Depth message (PGN 0x1F50B) from a device with address 0x19 on a NMEA 2000 network. At first glance, it seems that this task can be done with a very short program:

 

	match(ANY,0x1F50B19,0x1FFFFFF)	
	{
	}

 

In the code above, match() has no send() command inside, so messages with the identifier 0x1F50B19 (0x19 is an address and 0x1F50B is water depth PGN) will never be forwarded by the Bridge, so it is blocked.

This program may work well for many years. But, NMEA 2000 addresses are self-configurable, and when you add a new device to the NMEA 2000 network, it is possible that the 0x19 address will be occupied by a new device, and our depth sounder will change its address to 0x25, for example. In this case, the program above will start blocking the messages from other devices and Water Depth data will be available in the network.

To solve such problems, we can use the device's NAME structure instead of the device address. The NAME has an 8-byte structure sent by the device in an "ISO Address Claim" message (PGN 0xEE00). This structure contains the manufacturer's code and the unique device identifier (assigned by manufacturer). Using the device name, we can be sure that we'll never block another device data.

First, we need to catch the NAME. This may be done with the following program (assumed that the device in question is located in a CAN1 sub-network):

 

	DIAGNOSTICS=30 # Turn on logging for 30 seconds
	heartbeat(5000)
	{
	   if (c < 5)
	   {		
		set(0,UINT32,0x18EAFF00 + addr()) # Message ID of ISO Request
		set(4,UINT8,0xff) # marker of single-frame message
		set(5,UINT8,3)    # data length
		set(DATA,UINT32,0x00EE00)  # Request for ISO Address Claim
		send(CAN1)
	       	c = c + 1
	   }
	}
	match(CAN1,0x0EE0000,0x1FF0000) # ISO Address Claim from any address
	{
		send()
	}
	match(CAN1,0x1F50B00,0x1FFFF00) # Water Depth from any address
	{
		send()
	}

 

This program turns on the logging for 30 seconds, and every 5 seconds it sends broadcast requests for an ISO Address Claim message. The Device saves only matched messages to the log file, so we added two match() statements for the ISO Address Claim and Water Depth messages.

As a result, the device's log file will contain data as follows (we highlighted NAME and address of the interested device):

 

   00:00.310 RX CAN1 FILTER 01, 0x18EEFF2B E4E37EE7008C8CC0
   00:00.312 RX CAN1 FILTER 01, 0x18EEFF6F BB1668E72C96A0C0
   00:00.315 RX CAN1 FILTER 01, 0x18EEFF6E A5FC61E72B96A0C0
   00:00.314 RX CAN1 FILTER 01, 0x18EEFFAC F0A963E7388250C0
   00:01.005 RX CAN1 FILTER 02, 0x0DF50B6E 001E010000E701FF
   00:02.005 RX CAN1 FILTER 02, 0x0DF50B6E 001E010000E701FF
   00:03.005 RX CAN1 FILTER 02, 0x0DF50B6E 001E010000E701FF
   00:04.005 RX CAN1 FILTER 02, 0x0DF50B6E 001E010000E701FF
   00:05.000 TX CAN1 HEARTBEAT, 0x18EAFF20 00EE00

 

Now we are ready to create a smart program, which will block the Water Depth message of this device using its NAME.

   init()
   {
	x = 0xE761FCA5 # Low double word of NAME
	y = 0xC0A0962B # High double word of NAME
	z = 0xff       # Invalid value of device's address

	# Prepare ISO Request message and save to SLOT1
	set(0,UINT32,0x18EAFF00 + addr())
	set(4,UINT8,0xff)
	set(5,UINT8,3)
	set(DATA,UINT32,0x00EE00)
	save(SLOT1)
   }
   heartbeat(5000) # Send request if device's address is still invalid
   {
	if (z == 0xff) {
		load(SLOT1)
		send(CAN1)
	}
   }
   match(CAN1,0x0EE0000,0x1FF0000) # Check the NAME and save the address
   {
	if (get(DATA+0,UINT32) == x) {
	   if (get(DATA+4,UINT32) == y) {
	  	z = get(0,UINT8)
		}
	   }
	send()
   }
   match(CAN1,0x1F50B00,0x1FFFF00) # Water Depth filter
   {
	if (z == 0xff) {
	   a = 0xff
	}
	else {
	   a = get(0,UINT8)
	}
	if (a != z) {
	   send()
	}
   }

 

This program waits for the address claim of the device with the required NAME structure (obtained with the help of the previous program). Every 5 seconds, the Device will send broadcast requests for an address claim until the proper device is found. Until the device is found, the Bridge will not forward the Water Depth messages received from any devices.

Of course, this program may be more elegant and you may solve this task in a different ways. For example, it may be better to forward all Water Depth messages while the address of device in question is still being requested. Sure, you can do it easily!

The Bridge now support two formats of log files: text and binary. Text format is used by default (see the example of such log above). You may also force using of text logs in the program's text:


	LOG_FORMAT=TEXT

 

New binary logs are stored in files with a .CAN extension. Unlike text logs, which contain only messages matched with filters (or sent from filters), binary logs contains all messages received or transmitted on both CAN interfaces. And unlike text logs, you can't use the log() function to save a variable's values to the binary log file.

To use new binary logs, add the following line to the program's code:


	LOG_FORMAT=BINARY

 

And we are glad to present a new tool to view, play and convert .CAN files: CAN Log Viewer. This simple tool can convert .CAN files to .CSV (spreadsheets), text and .DAT (format of Voyage Recorder). It also can import .CSV files to .CAN format. This tool is freeware and works under Microsoft Windows, Linux and Max OS X.

 

Screenshot of CAN Log Viewer, click to enlarge

Picture 1. Screenshot of CAN Log Viewer, click to enlarge

 

The .CAN format of the binary logs is described in CAN Log Viewer documentation. This format is very simple, and we will be glad if other companies add the support of this format too. The format will be supported soon in the following Yacht Device products: Voyage Recorder, Engine Gateway, YDVR Converter.

We are also glad to announce, that Voyage Recorder will able to "play" .CAN files to the physical CAN network soon. This feature designed to test, demonstrate and emulate marine equipment. Now this excellent device can do both: recording all yacht data and emulating the whole yacht too!

CAN Log Viewer and new firmware update for NMEA 2000 Bridge are available at Downloads page.

More information about CAN Log Viewer: www.yachtd.com/products/can_view.html

More information about NMEA 2000 Bridge: www.yachtd.com/products/nmea_bridge.html

 

Next articles:

Previous articles:

See also: recent news, all news...